On Sun, 13 Mar 2016, Doug Barton wrote:
Hi Doug,
Date: Sun, 13 Mar 2016 23:58:53
From: Doug Barton <dougb@xxxxxxxxxxxxx>
To: ietf@xxxxxxxx
Subject: Re: dane-openpgp 2nd LC resolution
In general I support the idea of an *experimental* draft on this topic.
Thanks.
However, I have some serious concerns about the suggested approach. I
realize that I'm late to the party on this, so I apologize in advance to
Paul. I've subscribed to the DANE WG ML so hopefully I can make a more
useful contribution going forward. (FWIW, the last time I checked the
suggested approach was one I agreed with, so I diverted my attention to
more personally critical pursuits.)
Yes, you are about 1.5 years late. And your arguments are (un)fortunately
not new arguments. Since the archive on this draft is rather huge, I can
understand that you missed part of this discussion. So for completeness
sake, I will answer your questions again.
Fundamentally I think that using this RR to return the cert itself is
the wrong approach. IMO it should return the full fingerprint of the key
and let the sending user retrieve the key itself, with all corresponding
material.
This argument has come up a number of times, and it has been rejected each time.
This overcomes several problems I see with the proposal:
1. We know from vast experience with PGP that users are very lazy about
updating keys, and everything associated with them.
I don't see how that differs from where they need to update the key
from/to.
2. The draft recommends that the version of the key that is published be
stripped of any "extraneous" material such as unrelated UIDs, photos,
various certifications, etc. Given the desire to keep the packet size as
small as possible these recommendations are sensible, but I question
whether the resulting certificate has sufficient utility.
Leaving some signatures on it to anchor it in the web of trust is fine.
What is meant is to strip away the photo, and other non-required
items. The problem is not really of "big keys", which we handle fine in
DNSSEC (see below) but there is an upper limit of 64k in DNS that you
must remain under. So having 100s of signatures and a photo is not going
to fit. It does not matter whether the key is 2k, 12k or 63k.
One could also
argue that most users think of "my PGP key" as the entire package of the
main key, along with the the various associated UIDs, subkeys, etc.
That's fine. See above.
3. Encryption subkeys are not tied to specific UIDs. Also, it's not at
all clear to me how the mechanism described in this draft would interact
with a "key" that has multiple encryption subkeys.
I don't see why the draft needs to say anything about that? How is that
different from obtaining this key via another transport like HKP ?
4. The draft suggests (primarily in Section 7.1) that this mechanism be
utilized in a side channel (my term) separate from the sending user's
existing keyring(s).
I do not understand what you mean here.
I have deep concerns about this approach, as it
increases the risk that a message could be sent encrypted to the wrong
key. The biggest risk in this case is that of a false positive, where
the sending user believes that the message was correctly encrypted.
This draft on purpose provides no GUI to the user. As it states clearly,
this is not a replacement for the Web Of Trust.
That's arguably still better than the alternative of sending the same
message unencrypted.
Not "arguably". There is nothing to argue about it. It _IS_ better than
sending it plaintext - if you do not mislead the sender by any
"security" claims in the GUI.
However it's not better than the alternative of
informing the user that the MTA was not able to send the message because
it couldn't find a key that it could rely on.
Hard fail is certainly possible as a local policy, and everyone is free
to implement that. It is not up to the draft to dictate either hard fail
or soft fail. This is identical to TLS soft/hard fail which is a browser
matter, and not a TLS protocol matter. Local policy might be different
based on whether there is a direct link to the enduser (MUA) or not (MTA)
5. Super large OPENPGPKEY RRs will undoubtedly be used as DDOS
amplification fodder. For example, using Paul's software to generate the
RR for my primary key/UID the resulting packet would be over 12k.
The draft is very clear about how to avoid amplification. It is not
supposed to respond on non-source verified transport, such as plain UDP.
It should be used with TCP or UDP with DNS COOKIES for this very reason.
All 5 of these issues are resolved by having the OPENPGPKEY RR specify
the signature of the key, and having the sending user's software deal
with the full key instead of only a truncated version.
But it introduces a complexity of third party PKI systems on top of
DNSSEC and/or direct unfiltered/uncensored communucation to this third
party service. If you point to an HTTPS server, then one needs to take
that trust model with PKIX/CAs into account. What do you do when the TLS
certificate is expired? Or from a bad CA? Or when you just don't receive
an answer to your first TCP packet because the attacker is on-path and
filtering you to attempt to lure you into sending it in the clear? Or
when it is an SMTP extension but your ISP blocks all SMTP communication
to non-ISP SMTP servers. The strength of this document lies in the fact
that it does not depend on third party services.
DNSSEC provides the Indeterminate and Bogus status, so you know when an
attack is happening. Adding third parties to that destroys this property
which is essential.
1. To the extent that users are likely to update anything with their
key, they are likely to send a current version to the key servers.
The key servers are the equivalent of the Great Garbage Patch of the
internet. It is full of expired keys, lost keys, mallicious keys and
fake keys. These servers are also closely monitored and/or attacked
by nationa states, etc etc. It provides a simple central point of failure.
The strength of DNS is that it is a distributed system with intermediary
caches.
Further, in the case of a key revocation (particularly for a compromised
key), it may not be possible to remove or modify the OPENPGPKEY RR in a
timely manner, or at all.
A good implementation would use reasonable TTL's and provide a decent
GUI for inserting, updating and deleting the DNS record. This is not
worse then a website needing to update their A record. We are not saying
A records are bad because a website cannot update their A records in a
timely matter. So I find this argument a bit of a straw man.
However the receiving user should be able to
upload a revocation cert for the key to the key servers, which would be
picked up by sending user's software.
Realistically, the real problem is losing the key to be able to revoke
it. With DNS, you can just stop publishing that key. So it is in fact
much better than a third party append-only store like current pgp key
servers.
2. Having the sending user's software retrieve the full key gives them
the most up to date version, and matches better with what I believe the
expectations of most users would be for this RR.
Email software doing so can do that from alternative locations if
desired. It does not need to be in the core functionality of this draft.
Especially for security reasons I mentioned earlier.
3. Retrieving the whole key puts the problem of multiple encryption
subkeys into the hands of the sending user's software, where there are
already well known solutions.
You can publish as much of the key as you need to get the equivalent.
The draft is fine with keys up to 63k.
4. The way that this mechanism interacts with the user's existing key
ring still needs more thought.
That is really local policy and we have given some guidelines on it. Anything
more specific runs into infinite discussions about what the protocol should
dictate and where people want local policy to apply.
Regarding 4, I see several likely scenarios:
1. The user already has exactly 1 key that contains exactly 1 UID which
matches the e-mail address:
- The OPENPGPKEY result matches: The user is notified, the user's
software MAY make note of this match and suitably increase the "validity
score" for the key (if the software has such a concept)
- The OPENPGPKEY result does not match: The user is notified, MTAs/MUAs
SHOULD halt processing at this point, and let the user manually rectify
the error. User's software MAY make note of the mismatch and suitably
decrease the "validity score" for the key (if the software has such a
concept)
It would depend. Currently we state the local key ring always trumps the
policy, so if the user manually put trust in that key it should use that
key instead. If MAY inform the user if a mismatch occurs. It MAY decide
to use the new key if it is signed by the locally stored manually
trusted key. All of this is really local policy and it will take another
10 years to get any kind of consensus on trying to write this down as a
protocol specification.
2. The user has more than one key, and/or more than one UID which
matches the e-mail address:
- There is an RR which corresponds to one of the known keys: See the
first mechanism under 1 above.
- Otherwise see the second mechanism under 1 above. Additionally, the
software MAY ask the user if they would like to download the key that
matches the RR for evaluation.
I don't see how this draft prevents you from doing so. If you have a
local key that is manually verified, it and the user local policy
trumps and an implementation MAY decide to warn to user instead of using
either old or new key.
3. The user has no extant keys which match the e-mail address:
- There is an RR which corresponds: The software MAY ask the user if
they would like to download the key that matches the RR for evaluation.
- There is not, the user is notified, and the software MAY suggest that
the user search the key servers.
I would not want to specify that users should go to search existing key
servers. See above :P All of this is local policy and none of us should
attempt to dictate that.
The draft currently suggests a mechanism for using the RR data in an
unattended manner. I believe that this is a mistake for an experimental
draft, and should be replaced with text which makes it clear that at
this stage of the experiment the software SHOULD NOT proceed without
user confirmation.
That destroys opportunistic encryption for no good reason and I'm FIRMLY
against any proposal for that. Encrypted to OPENPGPKEY without informing
the user of "additional security" is ALWAYS better than sending in the
clear, which is the situation we have today. Manual key verification has
failed and is the main reason most of our emails are not end-to-end
encrypted as it is. Your suggestion of bringing back the user before
using a key to encrypt basically adds nothing to today's failed state
of mostly unencrypted emails being sent.
Some other thoughts:
The draft needs to be even more clear about its intentions. Specifically
it needs to spell out how the mechanism should be used. I see two
scenarios, but that doesn't mean there are only two:
1. This mechanism can be used as a data point in the WOT
2. This mechanism can be used for opportunistic encryption
Personally I don't see anything wrong with #2, but the sending user has
to be involved in the decision-making process. Retrieving the full key
will make that user's decision making process easier.
I've answered above already why I think this is wrong.
I would like to see more explanation of the mechanism for representing
the local part. I think that the explanation of "Why do we need to hash
it?" is good, however it's not clear to me why SHA-256 was chosen, or
why the hash value is truncated the way that it is.
I don't see why that information needs to be in the draft. SHA-256 was
chosen over SHA-224 and SHA-1 because:
1) SHA1 is being removed from libraries and/or is disallowed in FIPS mode.
2) SHA2-224 is not part of the Microsoft Crypto library.
3) SHA2-256 does not suffer from 1) or 2) and we need to be < 63 octets.
Obviously a full 64
character hex encoding of a SHA-256 hash would overflow the 63 byte
limit for a single DNS label. But why truncate the value specifically to
28 octets? If the 63 byte limit is the concern, why not use SHA-224?
Microsoft :P
I'd also like to suggest an alternative mechanism for this problem. In
cases where the entire local part of the address consists exclusively of
1-63 Letter-Digit-Hyphen (LDH) characters, allow that representation to
be used directly.
That would greatly simplify provisioning in the common
case, and also go part of the way towards addressing John Levine's
concern about the poor DNS admin who needs to go in and clean up those
records later. (That said, the records themselves refer to a key which
will answer said admin's question, so while it's a bit of extra work the
hash doesn't make answering the question impossible.)
That leads to maybe requiring multiple queries, and additionally it
was pointed out that it makes it easier for DNS servers to log the
usernames. yes hashing is not irreversable, especially for predictable
and published names, but people believed the additional privacy was still
worth it. And the reason for hashing the local-part and not the entire
email address is to allow users to use CNAME/DNAMEs) without needing to
create OPENPGPKEY records per zone.
This would also require a bit of text warning mail/DNS admins to mandate
hashes in the event that local delivery is case sensitive, but I really
think that this is such a corner case (again, pun intended) as to be
nearly a non-issue.
Yes, this non-issue has generated the majority of emails and delays,
so I am very reluctant to make any further changes and re-ignite this
discussion as people simply have different opinions that are unchanging.
In cases where the local part contains a non-LDH character, the hashing
mechanism is mandatory. Obviously the system should fall back to trying
the hash version of the RR for a "simple" local part as described above.
If we cannot even decide on when we can lowercase() I really don't want
to talk about which characters are "legal" and can do without hashing,
and which cannot. But regardless, the privacy issues with DNS resolver
intermediaries also makes hashing a requirement, even for US-ASCII.
Given that the draft specifies a new RR with its own ID, there is no
need for the _openpgpkey intermediate label. A query such as 'dig
doug.barton.us openpgpkey' would do the right thing (once all the
software catches up to the eventual RFC of course).
The subzone allows a separate DNS server to act as a DNS keyserver. For
instance, when we populated the fedoraproject.org zone with a couple of
thousand keys, the size of the zonefile was big enough to cause problems,
and it is nice to be able to store and serve it as a separate zone on
possibly a separate machine.
I would avoid using 'LHS' to refer to the local part of the e-mail
address in order to avoid confusion with the way that acronym is
commonly used in reference to DNS RRs.
The draft uses local-part everywhere. The term "LHS" appears once:
If one of the OpenPGP key uids contains only a single wildcard as the
LHS of the email address, such as "*@example.com", the OpenPGP public
And it refers to using "*" as the LHS. It is not a local-part of an
email address.
The discussion about local part wildcards in 5.3 confuses me. How would
the user know how to hash the wildcard to look up the RR, given a real
e-mail address as the starting point?
A wildcard would match any hashed attempt. the user does not need to
know anything and can just hash its intended local-part.
The details on how the sending user's software should use the returned
data should be moved out of Section 7 (Security Considerations) and into
Section 5. Also, see above. :)
If we stick with sending the whole cert back in the RR the Security
Considerations section should list use of such answers in DDOS
amplification attacks as a risk.
You think 7.4 in the Security Considerations is not enough?
7.4. Response size
To prevent amplification attacks, an Authoritative DNS server MAY
wish to prevent returning OPENPGPKEY records over UDP unless the
source IP address has been confirmed with [EDNS-COOKIE]. Such
servers MUST NOT return REFUSED, but answer the query with an empty
Answer Section and the truncation flag set ("TC=1").
Paul