Mailing List Archive

On Wed, Jan 20, 2021 at 1:55 PM Werner Koch <wk@gnupg.org> wrote:

> Broken implementations are not a reason to break correct
> implementations.

Since 'broken' implementations are available and can handle both cases,
and this is now generally known, people do *not* need to follow a *draft*
and can *happily* write code as they please to wish.

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Hi all,

after some more thought I came up with a possible wording to clarify the
fallback behavior. Assuming that an opportunistic approach is
preferred, so the direct method should be used not only based on the
existence of openpgpkey as a SRV or other record. Here goes:


---SNIP--- (page 3, second paragraph in the current draft version 11)

There are two variants on how to form the request URI: The advanced and
the direct method. Implementations MUST first try the advanced method.
If that does not conclude with a successful HTTP response (e.g. status
code 2xx), they MUST fall back to the direct method. If the required
sub-domain exists, but other errors occur during the connection, they
SHOULD output an error message pointing out the failure reason to the
end user. Such other errors include, for example, invalid, expired or
misconfigured TLS certificates and HTTP failure codes (4xx or 5xx).

---SNIP---


The last "SHOULD" clause would allow for Sequoia's current behavior to
silently switch over, but shows what the Right Way would encompass.
Regarding GnuPG, the second "MUST" clause requires a change to fall back
after later connection errors. I think that this logic still holds just
in case SRV records are to be used again.

So what do you think? I'm not subscribed to any IETF mailing lists, but
feel free to propose this in the relevant circles. I hereby renounce my
rights on the modified text :-)

Kind regards
André

--
Greetings...
From: André Colomb <andre@colomb.de>

On Wed, Jan 20, 2021 at 4:15 PM Stefan Claas
<spam.trap.mailing.lists@gmail.com> wrote:
>
> On Wed, Jan 20, 2021 at 1:55 PM Werner Koch <wk@gnupg.org> wrote:
>
> > Broken implementations are not a reason to break correct
> > implementations.
>
> Since 'broken' implementations are available and can handle both cases,
> and this is now generally known, people do *not* need to follow a *draft*
> and can *happily* write code as they please to wish.

P.S. I would like to inform the community that I installed the lastest
version of Mozilla Thunderbird, a couple of minutes ago, and guess
what ... Thunderbird fetched my github.io properly with their WKD
implemtentation.

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Wed, Jan 20, 2021 at 9:21 PM Stefan Claas
<spam.trap.mailing.lists@gmail.com> wrote:
>
> On Wed, Jan 20, 2021 at 4:15 PM Stefan Claas
> <spam.trap.mailing.lists@gmail.com> wrote:
> >
> > On Wed, Jan 20, 2021 at 1:55 PM Werner Koch <wk@gnupg.org> wrote:
> >
> > > Broken implementations are not a reason to break correct
> > > implementations.
> >
> > Since 'broken' implementations are available and can handle both cases,
> > and this is now generally known, people do *not* need to follow a *draft*
> > and can *happily* write code as they please to wish.
>
> P.S. I would like to inform the community that I installed the lastest
> version of Mozilla Thunderbird, a couple of minutes ago, and guess
> what ... Thunderbird fetched my github.io pub key properly with their
> WKD implemtentation.

P.P.S. 78.6.1 from their offical web site and not a nightly build etc.

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 2021-01-20 at 20:29 +0100, Andr? Colomb wrote:
> Hi all,
>
> after some more thought I came up with a possible wording to clarify
> the
> fallback behavior. Assuming that an opportunistic approach is
> preferred, so the direct method should be used not only based on the
> existence of openpgpkey as a SRV or other record. Here goes:
>
>
> ---SNIP--- (page 3, second paragraph in the current draft version 11)
>
> There are two variants on how to form the request URI: The advanced
> and the direct method. Implementations MUST first try the advanced
> method.
> If that does not conclude with a successful HTTP response (e.g.
> status code 2xx), they MUST fall back to the direct method. If the
> required sub-domain exists, but other errors occur during the
> connection, they SHOULD output an error message pointing out the
> failure reason to the end user. Such other errors include, for
> example, invalid, expired or misconfigured TLS certificates and HTTP
> failure codes (4xx or 5xx).
>
> ---SNIP---

Hello Andr?

Thanks for contributing

Suitable return codes for fetching a key would be 200 (for successful
keys) and 404 (the key is not in the server). In both cases, if it is a
valid wkd server, the server shouldn't fall back to direct.

You could also have a 304 if the client was refreshing a key. Maybe 201
if a web-based submission protocol was added in the future.

https://mailarchive.ietf.org/arch/msg/openpgp/f6V8W9wKY6dt2wAq4FBOWk8wtos/ seems to expect that HTTP redirects would work as well (seems
reasonable), although it isn't explicitly stated in the document.

I think the main status that would bring such trouble would be 401,
403, 5xx, although there could be some exotic cases (e.g. 407).
Erroring to the user on any status code the client does not know how to
handle seems the safe procedure.



> So what do you think? I'm not subscribed to any IETF mailing lists,
> but feel free to propose this in the relevant circles. I hereby
> renounce my rights on the modified text :-)

I think the right venue would be the openpgp wg. This was discussed
there in the past, and I hope to see WKD published through it one day.
However, although there were interesting ideas on this thread for
advancing it (amidst all the generated noise), I am hesitant to open a
discussion there about wkd, since openpgp working group was recently
rechartered to produce the rfc 4880 bis, and wkd is not covered by its
current scope.
I don't think there would be opposition for adopting it if rechartering
after rfc 4880bis is out, but it's a bit odd to open a discussion about
something else before starting the actual chartered work. Maybe other
people have an opiniono on this ?


Kind regards


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Hi all,

On 21/01/2021 01.29, ?ngel wrote:
>> If that does not conclude with a successful HTTP response (e.g.
>> status code 2xx), they MUST fall back to the direct method. If the
>> required sub-domain exists, but other errors occur during the
>> connection, they SHOULD output an error message pointing out the
>> failure reason to the end user. Such other errors include, for
>> example, invalid, expired or misconfigured TLS certificates and HTTP
>> failure codes (4xx or 5xx).
>
> Suitable return codes for fetching a key would be 200 (for successful
> keys) and 404 (the key is not in the server). In both cases, if it is a
> valid wkd server, the server shouldn't fall back to direct.

Restricting to only the 200 OK status code would probably be fine. I
looked at the other 2xx codes and probably no others would apply to WKD.
Not quite sure about 228 IM Used (not familiar with RFC 3229).

I tend to disagree regarding the 404 case though. As this thread has
shown, there might be legitimate use cases where a WKD user has enough
control over the domain's web server to set up the direct method. But
there might be a wildcard subdomain entry with a webserver and (valid)
TLS setup, totally unrelated to WKD, which is not under the same user's
control. In that case, the unrelated webserver would happily answer the
openpgpkey subdomain request, but simply not find the required directory
structure, giving a 404. My proposed solution would give the user a
chance to still enjoy the WKD direct method.

> You could also have a 304 if the client was refreshing a key. Maybe 201
> if a web-based submission protocol was added in the future.

Agree, 304 kind of makes sense, although the WKD client first needs to
implement the associated caching / Last-Modified header logic. Not sure
it that's worth the effort to explicitly mention it in the WKD protocol.

Other 2xx codes could be discussed. 201 Created doesn't make much sense
for the GET request, but could also convey that a key was just
auto-generated on the fly, e.g. for opportunistic encryption? I would
understand a 204 No Content status to mean "yes, this is a WKD server
and the requested user is known. There is just deliberately no key
offered." In that case stopping without fallback would be desired. All
of these somehow acknowledge that the requested .well-known/... resource
does make sense to the responding server. Hence my proposal for a
generous 2xx in the specification.

> I think the main status that would bring such trouble would be 401,
> 403, 5xx, although there could be some exotic cases (e.g. 407).
> Erroring to the user on any status code the client does not know how to
> handle seems the safe procedure.

Agree, let's not complicate the protocol with hard-to-implement, very
specific error handling rules.

One more needed change if the above proposal is accepted:

---SNIP--- (page 4, first paragraph in the current draft version 11)

Sites which do not use the advanced method but employ wildcard DNS
for their sub-domains MUST make sure that the "openpgpkey" sub-domain
is not subject to the wildcarding. This can be done by inserting an
empty TXT RR for this sub-domain.

---SNIP---

That MUST becomes a SHOULD, in order to avoid traffic by falling back
early. But with the new fallback cases, it's no longer *required*.

Regarding where this is discussed, I hope Werner will pick up relevant
pieces for a draft version 12 in order to unify the now differing
implementations. IIUC, he is the main (and only?) draft author, so
before IETF gets formally involved, the draft proposal can be iterated
easily.

Kind regards
Andr?

--
Greetings...
From: Andr? Colomb <andre@colomb.de>

On 2021-01-22 at 22:15 +0100, Andr? Colomb wrote:
> Restricting to only the 200 OK status code would probably be fine. I
> looked at the other 2xx codes and probably no others would apply to WKD.
> Not quite sure about 228 IM Used (not familiar with RFC 3229).
>
> I tend to disagree regarding the 404 case though. As this thread has
> shown, there might be legitimate use cases where a WKD user has enough
> control over the domain's web server to set up the direct method. But
> there might be a wildcard subdomain entry with a webserver and (valid)
> TLS setup, totally unrelated to WKD, which is not under the same user's
> control. In that case, the unrelated webserver would happily answer the
> openpgpkey subdomain request, but simply not find the required directory
> structure, giving a 404. My proposed solution would give the user a
> chance to still enjoy the WKD direct method.

That's the point where the fact that a WKD server MUST have a policy
file become useful for a fetching-only client. If it's a real WKD
server the file shall be there, if it's a 404, that's probably
meaningless.

GnuPG first tries to directly fetch the key from the url where it's
supposed to be. If it's found, it finishes there. If that's a 404, it
then check that there is a policy file (and if there's not, the process
caches in memory that there is no WKD on that place and won't contact
that server again)
On the other hand, flowcrypt first tries to read the policy file, and
only after that succeeds, does it go for the public key.


On this line, a few days ago I suggested changing the draft to require
fallback to direct if such file is missing (as opposed to considering
that the openpgpkey subdomain exists just when having an A/AAA record):

> - An idea that seems worth considering, inspired by the way flowcrypt
> does its check, is to fall back to the direct method if the
> openpgpkey subdomain exists but it doesn't serve a policy file.
>
> This would solve the issue of non-malicious NXDOMAIN hijackings or
> DNS wildcards (assuming the certificate was valid).

https://lists.gnupg.org/pipermail/gnupg-users/2021-January/064741.html



and over the course of the days, I have only become more convinced that
this would be a good idea.

It doesn't impose any new restriction on existing servers, clarifies
when a wkd subdomain "exists" (if it has the appropiate files), neatly
solves the exposed cases of unintended wildcard domains (when properly
configured), and uses a way available for web clients (which might not
be able to obtain the DNS response).


Best regards



_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 23/01/2021 04.17, ?ngel wrote:
>> control. In that case, the unrelated webserver would happily answer the
>> openpgpkey subdomain request, but simply not find the required directory
>> structure, giving a 404. My proposed solution would give the user a
>> chance to still enjoy the WKD direct method.
>
> That's the point where the fact that a WKD server MUST have a policy
> file become useful for a fetching-only client. If it's a real WKD
> server the file shall be there, if it's a 404, that's probably
> meaningless.

Very good point. So that could be the second definite point to decide
that the advanced method should be working and not fall back to direct.

> GnuPG first tries to directly fetch the key from the url where it's
> supposed to be. If it's found, it finishes there. If that's a 404, it
> then check that there is a policy file (and if there's not, the process
> caches in memory that there is no WKD on that place and won't contact
> that server again)
> On the other hand, flowcrypt first tries to read the policy file, and
> only after that succeeds, does it go for the public key.

Obviously another case where the draft is not clear enough, as it leads
to the same setup working with some clients, but not others. The
current draft has this to say about the policy file checking:

[Section 3.1]
The server MUST serve a Policy Flags file as specified below. That
file is even required if the Web Key Directory Update Protocol is not
supported.

[Section 4.5]
A site supporting the Web Key Directory MUST serve this file; it is
sufficient if that file has a zero length. Clients may use this file
to check for Web Key Directory support.

> On this line, a few days ago I suggested changing the draft to require
> fallback to direct if such file is missing (as opposed to considering
> that the openpgpkey subdomain exists just when having an A/AAA record):
>
> [...]
>
> and over the course of the days, I have only become more convinced that
> this would be a good idea.

I agree it's a nice possibility to explicitly control the fallback
cases. How about this suggested wording to specify client behavior:

[Section 3.1]
There are two variants on how to form the request URI: The advanced
and the direct method. For either method, client implementations
MUST first request the Policy Flags file at its respective location,
described below. Implementations MUST first try the advanced method.
If that results in a successful HTTP response (e.g. status code 2xx)
for the Policy Flags file, it proves the intention to use the chosen
method, so the client MUST NOT fall back to a different method, even
when the request for the key itself indicates an error (e.g. not
found). If the Policy Flags file is inaccessible, they MUST fall
back to the direct method.

If the required sub-domain exists, but other errors occur during the
connection, implementations SHOULD output an error message pointing
out the failure reason to the end user. Such other errors include,
for example, invalid, expired or misconfigured TLS certificates and
HTTP failure codes (4xx or 5xx).

[Section 4.5]
A site supporting the Web Key Directory MUST serve this file; it is
sufficient if that file has a zero length. Clients MUST use this
file to check for Web Key Directory support, before sending requests
for any actual keys.


Probably still rough around the edges and maybe not quite clear enough,
but it's a starting point to attract comments on the approach.

By the way, is there something like a repository to send and discuss
pull requests against the WKD draft document? Or is it just
hand-crafted text edited by the submitter based on suggestions?

Kind regards
Andr?

--
Greetings...
From: Andr? Colomb <andre@colomb.de>