Re: [openpgp] The DANE draft

[Daniel Kahn Gillmor <[e-mail]>]

On Wed 2015-08-05 04:14:42 -0400, Paul Wouters wrote:
> 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.

ah, right.  Please don't use the term "Trust Signature model" here.
While RFC 4880 does specify "trust signatures", they're not commonly
used, and they don't represent the most common implementations of how
people interact with OpenPGP's network of identity assertions (aka "web
of trust") -- we don't want to conflate "Trust Signature" with "web of
trust".

>> 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.

i think you are referring to the validity of a key for a given e-mail
address here.  in OpenPGP-land, "trust" usually means something
different (e.g., how much you're willing to rely on identity assertions
made by the key itself, analogous to "is this X.509 cert a trust
anchor?")

> 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!)

Sounds far more reasonable than query-on-every-message, though i'm not
just worried about fingerprinting e-mail send times -- i'm also worried
about tracking user associations directly by lookup.


>> 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.

Digested local parts provide a little more privacy, not security.  But i
agree it's only a little bit, given the low entropy of most localparts.

Is it conceivable that someone wants to use a high-entropy localpart to
avoid address leakage via key lookup? In that case, it seems like you'd
do just as well to have your high-entropy localpart uniquely identify
your key in the first place, with something like
[e-mail].

>> 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?

you've dropped the units here -- 256/2 what?  are we talking about
characters or octets?  if octets, under what encoding?  I agree that
e-mail addresses are rarely this long today, but we should be cautious
and explicit about any additional constraints when we're proposing to
mapp a limit from one domain (DNS) onto another domain (e-mail
localparts).

> 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.

Steven's point about raising the cost slightly for passive attackers
(e.g. TEMPORA) seems at least as relevant to me as the feasibility of
online-signed zones serving up end-user OpenPGP certificates that can't
possibly match the requested address exactly.

That said, there's a separate scenario, where as a domain administrator
i want to mint and sign an OpenPGP certificate on each query (even ones
where i have no user), to avoid the possibility of someone enumerating
all my actual users by walking the localpart space.  minting a matching
certificate would be creatable with the base32 approach

(how would this work?  something like the following: the DNS server
responsible for these records would keep a domain-wide long-term secret.
upon a query that it finds it has no legitimate record for, it would
hash the query name and the long-term secret into a seed for a PRNG.
from the PRNG output, it would deterministically derive secret key
material and any other variable metadata (like creation date) needed to
derive a new certificate.  it could cache or discard these certificates
as requested, because it could always re-generate them exactly from a
new query.  when a user opens a matching account, the user's personal
key would replace the domain-generated one.  i'm not saying this is a
great system, just outlining how it might be done for a system that
wants to keep its userbase hidden)

I'm still on the fence here, as you can tell :P

>> 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.

Hm, the more i think about it i find i prefer it aesthetically, but i'm
not sure i have a good engineering argument.  I don't see a great way to
effectively prevent people from doing either one -- are there any DNS
record types explicitly prohibit multiple records in response to a given
query?

OpenPGP composable certificates are just a series of OpenPGP packets
concatenated; two certs concatenated together are themselves also just a
series of OpenPGP packets by induction.  We could say that the RDATA
"MUST start with a Public Key Packet and MUST NOT contain more than one
Public Key Packet".


>> 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

looks sensible, though i think some of the terminology is slightly off
there.  i could try to provide patches for that section if you like.
how is the draft developed -- how do you prefer edits sent to you?

> 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.

That seems OK to me as well.

     --dkg