On Wed, 5 Aug 2015, Daniel Kahn Gillmor wrote:
i'm not subscribed to dane(_at_)ietf(_dot_)org, feel free to forward if you
think
this would be useful.
[ I added dane back to the CC: as I think it will be useful to keep the
openpgp discussion there too, as some people there also wanted a
different specification of the RDATA ]
key discovery vs key validation
-------------------------------
As an optional key discovery mechanism for OpenPGP, i think this
proposal has merit. I share Watson's concerns about "smuggling in a
different trust model", but i have no complaints about DNSSEC validation
being used as a corroborative validation mechanism, should clients
choose to accept it for validation purposes. For clients that *don't*
choose to accept it for validation purposes, they should validate the
keys via their usual mechanisms, and rely on OPENPGPKEY records solely
for discovery purposes.
The text does make it clear that you have that choice:
The proposed new DNS Resource Record type is secured using DNSSEC.
This trust model is not meant to replace the Trust Signature model.
However, it can be used to encrypt a message that would otherwise
have to be sent out unencrypted, where it could be monitored by a
third party in transit or located in plaintext on a storage or email
server. This method can also be used to obtain the OpenPGP public
key which can then be used for manual verification.
So there is no "smuggling".... DNSSEC is used to protect the transport,
and as a poor man's better-than-nothing web-of-trust alternative.
metadata leakage
----------------
I'm a little concerned about the potential for metadata leakage -- i
don't want my MUAs to do DNS lookups every time i try to send mail to
someone whose keys i dont have.
The MUA can present you with information to manually verify or put a trust
level to the key. The MUA should also cache negative attempts to get a
key and limit these so avoid fingerprinting email send times by looking
at DNS queries. That part is not in the current RRtype specification,
but should go into the openpgpkey-usage document (co-authors wanted!)
localpart mangling
------------------
I have no strong preference for base32 vs. digested localpart for the
hostname. Digested localparts require a little bit more work to invert
than base32, but given the low entropy of typical normalized localparts,
they don't provide a lot of protection against a determined attacker.
And as clearly stated, were never meant to provide security.
I'm slightly more concerned with e-mail address length limits on base32
than on digested localparts -- a long localpart plus a long domain name
could make for a very large DNS label, whereas a fixed digest should
give us a fixed bound on size.
Do you forsee email addresses > 256/2 to be common use?
In either case, some canonicalization will be required (before base32 or
digest, whichever is chosen). fwiw, i believe that case normalization
of the localpart is pragmatic for today's networks, despite not being
within the letter of the RFC. I would advise clients to downcase before
doing a lookup.
Thanks. I share that belief.
The main advantage for base32 over digested localpart seems to be for
synthesized OPENPGPKEY records in an online-signing DNSSEC-capable
server. I don't believe this is a significant advantage for a key
discovery mechanism for OpenPGP, because i believe some people will want
to verify the OpenPGP certificate itself, regardless of its DNSSEC
status, and the OpenPGP certificate won't have wildcards in it.
Other people believe there is some use. If the only downside is not
supporting insanely long email addresses, which I think are a more
rare event, I think that it is okay.
RDATA content/structure
-----------------------
The -03 spec §2.1 currently suggests that the RDATA should be an
"RFC4880 OpenPGP public keyring", but RFC 4880 doesn't define a "public
keyring" in any reusable way (see
https://tools.ietf.org/html/rfc4880#section-3.6).
§ 2.2 says:
The RDATA Wire Format consists of a single OpenPGP public key as
defined in Section 5.5.1.1 of [RFC4880]. Note that this format is
without ASCII armor or base64 encoding.
But 5.5.1.1 is *just* a public key packet. This is not a useful record
to store.
Instead what you want is probably exactly one "Transferable Public Key"
(https://tools.ietf.org/html/rfc4880#section-11.1), which is the
standard for the composable OpenPGP certificate format. But see the
"Filtered Certificates" section below for more detail.
I will update the reference to refer to that section. Thanks. That
does look better.
Key Transitions
---------------
While i say "exactly one" Transferable Public Key, i'm assuming that the
DNS is OK with serving multiple OPENPGPKEY records at a single label.
What is the advantage of multiple DNS records with 1 key over one DNS
record with multiple keys? While I'm all four specifying one method to
increase chances of interop, I'm not particularly set on one or the
other solution.
Filtered Certificates
---------------------
Given that some users have aggregated OpenPGP certificates that are
quite large (my own is currently ~475KB), we don't want to require
people to publish their entire certificate in the DNS. Because OpenPGP
certificates ("transferable public keys) are composable (they consist of
a series of packets, many of which can be dropped), a reasonable policy
for filtering the certificate for size purposes should be suggested.
We mention this in Section 5:
https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03#section-5
At a minimum, the OPENPGPKEY record for alice(_at_)example(_dot_)com MUST
contain:
* primary key X
- one User ID Y, SHOULD match 'alice(_at_)example(_dot_)com'
- self-signature from X, binding X to Y.
[ note: I do not believe we need to require that the User ID MUST match
the looked-up record, though it's obviously preferable to a validator
if it does. ]
This extremely minimal record might not provide an encryption-capable
subkey, though, and the primary key may not be encryption-capable
itself.
So a more sensible transferable public key would also include all
relevant subkeys:
* primary key X
- one User ID Y, SHOULD match 'alice(_at_)example(_dot_)com'
- self-signature from X, binding Y to X.
- encryption-capable subkey Z
- self-signature from X, binding Z to X.
- [ other subkeys if relevant ...]
Owners of the record may also want to include some up-to-date
third-party certifications which they think would be helpful for
validation, which would result in:
* primary key X
- one User ID Y, SHOULD match 'alice(_at_)example(_dot_)com'
- self-signature from X, binding Y to X.
- third-party certification from V, binding Y to X
- [ other third-party certifications if relevant ...]
- encryption-capable subkey Z
- self-signature from X, binding Z to X.
- [ other subkeys if relevant ...]
[...]
With GnuPG, you can achieve a rough minimization with:
gpg --export-options export-minimal,no-export-attributes $PGPFPR >
opengpgpkey.pgp
The idea was not to specify these policies in the DNS RRtype. Just tell
people to keep to small keys. It did include an example gpg command
in appendix A, but your command seems even better so I will update it.
I would prefer not to mention specific key elements as those might
change and are not really relevent for the DNS specification. Or perhaps
these recommendations could go in the openpgpkey-usage document.
Paul
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp