WKD spec, draft 05

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

WKD spec, draft 05

Bernhard Reiter-7
Moin Werner,
a happy new year to you and all GnuPG people!

Just saw today that you have published a v05 of
https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service
(I like the diff tool [1] to check changes.)

* What is a good way to track the development of the draft?
  Does the IETF offer a tool to send me an email if a new revision is
  published? Could you drop me (and the devel-list) an email if a new
  revision is there?

* The new requirement for serving WELLKNOWN/policy to be able to detect
  the existence of the service makes sense to me. Especially because I believe
  that the draft should state that the server MUST prevent walking
  the list of available pubkeys for privacy reasons, for instance by disabling
  the directory display function of a web server.

 Can you add the statement to the next revision?
 
  Rationale for suggesting: MUST over SHOULD:
  I can see usecases where re-using the
  .well-known/openpgpkey/hu/ as way to publish all OpenPGP pubkeys
  at once, but I'd say that this is the exceptional case and there are better
  methods of publishing a set of pubkeys, e.g. by using a single file with
  serveral pubkeys or by generating a HTML page with all email addresses.

* There is a typo in v05:
     The file contains keywords and optioanlly values
probably should be
     The file contains keywords and optional values

Best Regards,
Bernhard


[1]
https://www.ietf.org/rfcdiff?url1=draft-koch-openpgp-webkey-service-04&url2=draft-koch-openpgp-webkey-service-05&difftype=--html



--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WKD spec, draft 05

Werner Koch
On Thu,  4 Jan 2018 17:13, [hidden email] said:

> Just saw today that you have published a v05 of
> https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service

The old version was about to expire thus I published a revision.

> * What is a good way to track the development of the draft?
>   Does the IETF offer a tool to send me an email if a new revision is
>   published? Could you drop me (and the devel-list) an email if a new

I don't think so.  It is recorded at the WG page
https://tools.ietf.org/wg/openpgp/

But note that the latest rfc4880bis draft -03
https://datatracker.ietf.org/doc/draft-ietf-openpgp-rfc4880bis/
is not anymore record4d there.  I assume this is because the IETF closed
the WG (but not the mailing list).

> * The new requirement for serving WELLKNOWN/policy to be able to detect
>   the existence of the service makes sense to me. Especially because I believe

GnuPG uses it to detect whether a domain supports WKD at all.  Since the
last release Dirmngr caches this info but needs a way to check whether
it is supported at all.

>   that the draft should state that the server MUST prevent walking
>   the list of available pubkeys for privacy reasons, for instance by disabling
>   the directory display function of a web server.

These are public keys and testing for their existence is trivial as it
it with all mail addresses.  If someone wants to add an index file for
this it is at their discretion and we should not impose a restriction on
this.  A SHOULD NOT would be okay, though.

> * There is a typo in v05:

Fixed.  Thanks.


Shalom-Salam,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WKD spec, draft 05

Bernhard Reiter-7
Am Freitag 05 Januar 2018 13:13:37 schrieb Werner Koch:
> >  that the draft should state that the server MUST prevent walking
> >  the list of available pubkeys for privacy reasons, for instance by
> > disabling the directory display function of a web server.
>
> These are public keys and testing for their existence is trivial as it
> it with all mail addresses.  

The problem ist not the pubkeys, but it can be used to detect all existing
email addresses of an email domain (that have pubkeys). An advantage
of WKD is that you do not need to publish your email address to everyone
and it would get lost if people publish all the email addresses' pubkeys at
once.

> If someone wants to add an index file for this it is at their discretion
> and we should not impose a restriction on this.

I agree that it could be used in a good way, if done deliberately. So I was
undecided over "MUST" or "SHOULD NOT" at first. Overal I like to design for
the simple case and prevent unthoughtful default configuration and later in
the wild use. I guess a number of sites will have a directory listing enabled
by default, so I'd rather give them a clear hint to disable it. And sites you
actually want to publish a list of the email addresses they serve should be
required to do extra efforts. In addition I do not want WELLKNOWN/hu/ to
become an interface to find all pubkeys for an email domain.
So I'm favouring the "MUST" now.

> A SHOULD NOT would be okay, though.

Adding a "SHOULD NOT" and a mention in the security considerations is an
improvement, thanks for adding it!

Best Regards,
Bernhard

--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WKD spec, draft 05

Werner Koch
On Mon,  8 Jan 2018 08:48, [hidden email] said:

> The problem ist not the pubkeys, but it can be used to detect all existing
> email addresses of an email domain (that have pubkeys). An advantage

You can do that with and without an index file.  It might be easier with
an index file because you can get the list of local-part hashes all at
once.  But in any case you need to compile a list of local-parts to test
whether the has exists.  However, spammers have more resources than
everyone else and thus it does not really matter whether they do lots of
https queries or simply sending test mails.

>> A SHOULD NOT would be okay, though.
>
> Adding a "SHOULD NOT" and a mention in the security considerations is an
> improvement, thanks for adding it!

Thanks for suggesting this.


Shalom-Salam,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WKD spec, draft 05

Bernhard Reiter-7


Am Dienstag 09 Januar 2018 09:53:03 schrieb Werner Koch:
> On Mon,  8 Jan 2018 08:48, [hidden email] said:
> > The problem ist not the pubkeys, but it can be used to detect all
> > existing email addresses of an email domain (that have pubkeys).

> You can do that with and without an index file.  It might be easier with
> an index file because you can get the list of local-part hashes all at
> once.

If you agree that it is harder without index file, than we are on the same
page, as security economics is always about making some "attacks" a bit
harder.

> But in any case you need to compile a list of local-parts to test
> whether the has exists.  However, spammers have more resources than
> everyone else and thus it does not really matter whether they do lots of
> https queries or simply sending test mails.

I guess some standards counter measures could be used to make it less feasable
to walk all email address hashes if there are no index files. Server
providers e.g could tarpit or auto-blacklist requestors based on requests to
honey email addresses. So far I believe it does matter (at least a little
bit).

Best Regards,
Bernhard

--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (484 bytes) Download Attachment