Re: [openpgp] The DANE draft

[Paul Wouters <[e-mail]>]

On Wed, 5 Aug 2015, Daniel Kahn Gillmor wrote:

> i'm not subscribed to [e-mail], 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 [e-mail] MUST contain:
>
> * primary key X
>  - one User ID Y, SHOULD match '[e-mail]'
>   - 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 '[e-mail]'
>   - 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 '[e-mail]'
>   - 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