On Jul 25, 2015, at 8:19 AM, Paul Wouters <paul(_at_)nohats(_dot_)ca> 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 Paul(_at_)nohats(_dot_)ca is the same as
paul(_at_)nohats(_dot_)ca,
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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp