Re: [openpgp] The DANE draft

[Olafur Gudmundsson <[e-mail]>]

> On Jul 25, 2015, at 8:19 AM, Paul Wouters <[e-mail]> wrote:
> 
> On Fri, 24 Jul 2015, Werner Koch wrote:
> 
> PHB wrote:
> 
>>> 2) If people find it does not meet OpenPGP needs, they should say so and
>>> have no qualms about objecting. It is much more important that there be a
>>> spec people use than that the document progress quickly.
> 
> This document has not progressed "quickly". The original draft was
> published in July 2013. No one is trying to rush this through.
> 
>> I was a bit disappointed by the process: I learned about the I-D too late
>> and was surprised that it started out at the OpenPGP WG mailing list (2
>> years ago?) with just a few messages and then continued at the DANE list
>> without having notified the OpenPGP list.
> 
> This is now the fourth time I am having this discussion with you, so I
> think your representation is not entirely fair. The previous discussions
> ended with you saying we should not do this and stick to the CERT record
> type and me stating why I disagree with that view.
> 
>> IIRC, I send some thoughts on
>> this to the GnuPG list but people told me that it is too late for
>> changes to the I-D - so I gave up.
> 
> That is not a fair representation of what happened. I have told you on
> the openpgpkey, on the dane list and in private emails why we do not
> want to use the CERT record. It is fine to disagree with that, but the
> reason for not going back to CERT have nothing to do with timing. It
> is never too late to say a certain draft has no merit and should be
> shot or majorly changed. I am sorry if our previous communication did
> not make that clear.
> 
>> Here are some thoughts, anyway:
>> 
>> - Why a new DNS record despite that the CERT type has PGP support for
>> 9 years now (RFC-4398).
>> 
>> The argument for a new record is that this makes parsing easier
>> because there is no need to loop over the record's sub-types.  I do
>> not consider it a valid argument because there is a need to loop
>> anyway because there may be several DANE records for the same key.
>> Adding an extra loop over the sub-types is a non-brainer and the
>> selection logic to find the best matching record will be the same.
> 
> Using subtypes for DNS is something the DNS people in general have
> concluded to be a wrong idea. As stated before, even Olafur who is one
> of the authors of the CERT RRtype advised us not to use CERT (or
> subtyping in general)

I want to strongly support this point, Bulk container records like CERT have been shown to be a bad idea is 
every time they get used in DNS. Lets learn from experience. 

> Additionally, because the CERT record is a meta-container record,
> support for CERT is not good because to properly parse it you need
> all of openpgp and all of x509 and all of what other subtypes would
> be added later on. So instead of implementing CERT records partially,
> many DNS implementations just did not bother with it at all.

+1 

> 
>> The CERT record is more flexible because it also allows the use of an
>> indirect specification via fingerprint.
> 
> Which is a problem not a feature. It makes the security model very
> complex. Specifying a fingerprint and a URI that could be http or https
> reduces the security of the key to the strength of the fingerprint.
> Did we not already ran into issues in older (v3?) keys on this issue?
> Adding a level of indirection where not required does reduce the
> security.
> 
> If using https, it adds back a whole trust mechanism of CA's, or it
> confusingly will ignore the CAs involved in the transaction.
> 
> If the http(s) service is blocked by an attacker, it is indistinguishable from
> a regular outage.
> 
> Putting the keys into DNS without indirection avoids all these problems.
> I know the CERT could also store the entire certificate, but this
> difference then has to be explained to the user, and that is way too
> complicated. Compare:
> 
> "The user you are trying to mail has published their OpenPGP key in DNS,
> do you wish to use this key to encrypt this email?"
> 
> versus:
> 
> "The user you are trying to mail has published their OpenPGP
> key fingerprint in DNS and the key was obtained over HTTP(S) on
> anothersite.com whose certificate was validated by ACME inc. Do
>  you wish to use this key to encrypt this email?"
> 
> And the additional:
> 
> "The user you are trying to mail has published their OpenPGP
> key fingerprint in DNS but the URI resource anothersite.com appears
> to be down. do you wish to postpone this email or send it
> unencrypted?"
> 
>> GnuPG has support for such CERT records including a script to create
>> them also for about 9 years.  It is not widely used because most users
>> have no way to add records to their zone - that is the same problem
>> for DANE of course.
> 
> CERT wasn't widely used because frankly pgp is not widely used. Also,
> CERT without DNSSEC makes no sense, and we are only seeing DNSSEC
> protected application data being deployed recently in the last few
> years only. We now see small email providers adding webgui elements
> for their users to upload their pgp key to publish in DNS. So I do
> believe we are seeing an uptake in "pgp keys from dns". Of course
> this has no relation to the CERT vs OPENPGPKEY format question.
> 
>> - The I-D says about the local-part of the mail address:
> 
> The I-D was left unchanged at the request of the chairs. The intention
> right now is to use a base32 encoding split on 60 character labels.

Dane WG (which I co-chair) is trying to settle this issue by the end of July 
so if you have a comment please state it there. 

> 
>>     ... it is turned into lowercase and hashed using the SHA2-256
>>     [RFC5754] algorithm, with the hash truncated to 28 octets ...
>> 
>> Lowercasing UTF-8 characters is not easy and a likely reasons for
>> interoperability problems.  It would be better to only require
>> lowercasing ASCII characters and keep characters > 127 as they are.
> 
> Yes, that was discussed on the dane list and after consultation with
> internationalised email address experts, this same conclusion was
> reached. I am not sure if we actually reached consensus about the
> lowercase vs using a second DNS lookup for lowercase if the first
> query fails to find a record. The argument here is that a client
> should not "guess" that [e-mail] is the same as [e-mail],
> but there does seem to be concensus that in practise these are the
> same and it should be supported either through a lowercase before
> base32 (for ASCII only) or be allowing the client to try both as
> base32 lookups. One of the main reasons here is that virtual keyboards
> and web form fields often automatically capitalise recognised names,
> and otherwise we would need to add two records (Paul and paul) for
> each LHS side.
> 
>> - There is no hint in the RFC on how to find a key to verify a
>> signature.  This can't be done via a mail address but requires the
>> fingerprint (or as of today the key-id).
> 
> The draft is about finding keys based on email address. It is not meant
> to be the global keyserver bag for all keyids or fingerprints. If you
> only have a keyid and nothing else, the DNS hierarchy cannot help you.
> 
> But perhaps the openpgp group can extend the signature format allowing
> the inclusion of an ID so this could be possible in the future?

As Paul says this is about connecting a one form of ID to a OPENPGP key 
this can be used as additional method. 
As a matter of fact the reason I stopped using PGP many years ago was the difficulty
in discovering someone’s else PGPkey, in particular there was no way to look up based on the
handles I had. 

> 
>> - How shall a key be retrieved or updated after a mail account has been
>> closed?  It should be possible to verify signatures at all times.
> 
> Why should that be possible? In fact, the key could be compromised so
> it might lead to the wrong actions if you verified the signature.
> 
> The OPENPGPKEY draft specifies one method of finding a key. What you
> do with it, or what the lifetime of such a key or its signatures
> are is completely out of scope of this key discovery mechanism.
> 
> If we want to specify those kind of usage scenarions, we can revive
> the openpgpkey-usage draft document. But I fear everyone has their
> own local policies on these.
> 

I asked the same questions and came to the following conclusion:
OPENPGP via DANE/DNSSEC verification SHOULD be done when the email is received and
that information should be stored with the message.
DNS lookup of a key via the method specified here provides a binding at particular point in time. 
For the email provider it is her choice to remove the key or revoke the key, the net effect is the same 
they key is not available for use after that action. 
How this is done is depends on the software that validates the message. 

>> Thus another non DNS service to keep the key available needs to be
>> setup too (e.g. a keyserver).

This is the core difference between the way Certificate world thinks and how DNS world behaves. 
DNS is and answer at particular point in time. Either the data exists or does not exist. No history at all.
Removal of OPENPGP is almost a revocation, addition is “publication”. 

> 
> I disagree. If the email was sent while the mail account was still
> operational with OPENPGPKEY, you should have fetched and stored the
> key then. If the account is closed and you don't have a copy of the
> key, than that is your problem. If you want to have some kind of
> global key store for all keys ever issued, then I guess you could
> look at something like "transparency" for openpgp keys. But that
> is a out of scope for this document, just as me sending you a key
> without any advertising on any public key server resource and
> then closing my mail account is.
> 
>> dissemination of revocation certificates.  IPGP records could be kept
>> as long as the mail address has not been re-assigned.
> 
> Again, that seems like a "transparency" issue. The issue of losing
> control of your email address, and someone else generating a new key
> for that email address and advertising thism, whether in DNSSEC or
> on keyservers, in an attempt to get encrypted email intended for you,
> is really not in scope here either. It might be in scope for the
> openpgpkey-usage document, but it seems to me to be a more generic
> openpgp issue, so perhaps would be better in the openpgp bis document
> or elsewhere. (and of course this would be no different with CERT
> records in DNS)
> 
>> - Implementation nit: The I-D states:
>> 
>>     The lookup result MUST pass DNSSEC validation; if validation
>>     reaches any state other than "Secure", the verification MUST be
>>     treated as a failure.
>> 
>> As an implementer I see no way to do this without adding a full
>> fledged DNSSEC resolver.
> 
> There are various libraries to do this. You can look at getdns,
> libunbound or various other libraries. We hope you would not write
> your own dnssec validation code. If you do not want to link against
> new unknown libraries you could outsource it to a separate tool, and
> possibly warn the user of that. I'm happy to help you with that.
> 
>>> People have been attempting to put email address related records into the
>>> DNS since the first drafts of the spec and none has taken off.
>> 
>> That is a general problem.  You need the support from the mail
>> providers.
> 
> Of course this is a big catch22. While I have been approached by a few
> email providers who have or are implementing this to allow their users
> to publish their openpgp keys this way, the 5 big email providers
> business model relies on advertisement targetted specifically by
> reading your email. So I do not expect those email providers to have
> much incentives to become free binary blob relaying services.

> 
>>> I do not find the idea of relying on the DNS for my keys remotely
>>> comforting and would not want to rely on such a record directly. The DNS
>>> has no persistence to it. Give me the MIT keyserver any day.
>> 
>> When intending to send a mail the first time the DNS is pretty useful
>> because it creates an association between mail address and key.  Thus
>> you can pick the right key and the recipient won't be annoyed by
>> encrypted mails they can't decrypt because the keyservers carry several
>> "faked" keys for their mail address.
> 
> Indeed. And no one is saying you should ONLY trust the DNS. In fact, no
> one is saying that. The prime motivation for this document is to allow
> MTAs and MUAs to encrypt emails that would otherwise be send out in the
> clear by the user. In no way is it intended to replace the web of trust
> or manual key verification, and I hope implementations will ensure this
> point to their users.
> 
> 
> Now, one thing I _would_ like to see from the openpgp working group, is
> comments on content of the public key ring format that we should or
> should not put into the OPENPGPKEY record. The draft basically refers
> to the openpgp RFC, but people have wondered about some things:
> 
> - What to do when there is more than one pubkey?
> - Should it be mandatory for the email address to appear as an ID
>  on the key? (if yes, how to support domain wild cards)
> - Should any third party signatures be allowed/encourages/discouraged?
> - Should revoked keys be allowed?
> 
> One issue during deployment for all fedora developer keys was that people
> do have keys that are larger than 64k and those will not fit into the
> DNS. There is no easy way for tools to try and reduce the signatures
> because it does not know which signatures carry more weight for the user.
> 
> Paul

Olafur