Subject: Re: [dane] Last Call: <draft-ietf-dane-openpgpkey-05.txt> (Using DANE to Associate OpenPGP public keys with email addresses) to Proposed Standard

From: Petr Spacek <[email-masked]>
Date: Thu, 3 Sep 2015 21:50:00 +0200

Hello,

as far as I can tell people favor various LHS-hashing variants for privacy
reasons. Assuming that this observation is correct, I consider current hashing
scheme totally insufficient - it does not protect anyone's privacy against
even against moderately-funded attackers. We should do better (not only to
please Snowden :-)

I very much like the generic idea of salting described in variant a) here:
https://mailarchive.ietf.org/arch/msg/dane/LuC7BYtd6zVEWJF0s4cnmBLL1rU
(I'm not so certain about "rulez", but that is a separate discussion. Do not
conflate these two discussions.)

Personally I would store salt+iteration parameters in "_openpgpkey.<domain>"
so the whole tree can be shared/DNAMEd at will.

Yes, this requires additional lookup. Still, I can see important benefits
which in my eyes outweigh the disadvantage:

- The additional "salt" lookup works as privacy guard for domains which did
not deploy _openpgpkey at all. If the client does not find "salt" record then
no lookups for names derived from LHS should be made. This effectively
prevents leaks for domains which did not deploy _openpgpkey. (Domain name
leaks anyway because of MX lookups.)

- The "salt" record for big mail providers will be often in a nearby cache so
the additional time-overhead for big mail providers will be negligible. And of
course, TTL for this kind of record can be pretty long.

- Salt/iteration count can be increased over time so we can keep raising the
bar to make it costly to revert the hashing as computing power gets cheaper.

Really, I think that we should rethink the hashing if we are serious about
privacy.

Petr Spacek

On 28.8.2015 17:11, The IESG wrote:
> The IESG has received a request from the DNS-based Authentication of
> Named Entities WG (dane) to consider the following document:
> - 'Using DANE to Associate OpenPGP public keys with email addresses'
>   <draft-ietf-dane-openpgpkey-05.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2015-09-11. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 3 Sep 2015 16:26:38 -0400 (EDT)

On Thu, 3 Sep 2015, Petr Spacek wrote:

note if you meant this as a comment for the IETF LC, you should use that
threat over at [email-masked] and not this one.....

> even against moderately-funded attackers. We should do better (not only to

I don't think anything helps against moderately-funded attackers. How
long does it take to build a dictionary of common email names/varients ?
As the nsec3 cracker shows, it's going to be a simple offline attack to
generate the qname's, then you go online to fire them off.

> so the whole tree can be shared/DNAMEd at will.

That would cause an additional administrative burden though. Now one
cannot just "add OPENPGPKEY" record to the zone. Now you have to query
for the salt before you can generate and then add the OPENPGPKEY record
to the zone. And whoever updates the salt record now needs to ensure
to update all existing OPENPGPKEY records. so in theory you would have
to:

1) query the salt
2) generate the openpgpkey record
3) give it to whatever human/webui adds it to the zone
4) requery the salt to ensure it hadn't changed
5) keep querying the salt to see if you need to submit an updated record

That's a lot of overkill and someone (google) can still simply lookup the salt
and run it over strings like "paul" and compare it with the DNS query log.

> leaks anyway because of MX lookups.)

That's even more state. And you still have the case where the salt
record is there but no OPENPGPKEY record for paul is there, and you
end up possibly requerying for paul many times anyway. That is, it
does not really solve the problem. Only a small part of it.

> bar to make it costly to revert the hashing as computing power gets cheaper.

when does "raising the bar" become "denial of service"? Especially when
the nation states have more CPU power than we do :P

> Really, I think that we should rethink the hashing if we are serious about

The real answer here is DPRIVE plus using a trusted DNS resolver. Which
solves query privacy in general and is not specific to one record type.

Paul

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Sep 2015 19:35:19 +0200

I believe it would be a mistake to publish this document without having
it include a discussion of its relationship to RFC 4648.  As far as I
can tell, the CERT record defined in RFC 4648 solves roughly the same
problem as OPENPGPKEY and CERT is already deployed with support in (for
example) GnuPG.  I believe the community would benefit from sorting out
the relationship before publication, not after, when we would have two
RFCs describing solutions for what appears to be the same problem.

/Simon

The IESG <[email-masked]> writes:

> Abstract
>    OpenPGP is a message format for email (and file) encryption that
>    lacks a standardized lookup mechanism to securely obtain OpenPGP
>    public keys.  This document specifies a method for publishing and
>    locating OpenPGP public keys in DNS for a specific email address
>    using a new OPENPGPKEY DNS Resource Record.  Security is provided via
>    DNSSEC.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Sep 2015 19:40:21 +0200

Sorry -- I meant RFC 4398 and not RFC 4648!

/Simon

Simon Josefsson <[email-masked]> writes:

> The IESG <[email-masked]> writes:
>
>> [email-masked] mailing lists by 2015-09-11. Exceptionally, comments may be
>> sent to [email-masked] instead. In either case, please retain the
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: manning <[email-masked]>
Date: Thu, 10 Sep 2015 10:39:40 -0700

I’d have to agree with Simon here.  

manning
[email-masked]
PO Box 6151
Playa del Rey, CA 90296
310.322.8102

---

From: Paul Wouters <[email-masked]>
Date: Thu, 10 Sep 2015 19:38:49 -0400 (EDT)

> RFCs describing solutions for what appears to be the same problem.

This issue has also come up several times in the working group
discussion. While a paragraph could surely be added to the document, I
don't see much value in such historic inclusion to implementors.

The CERT record uses sub typing which is (now) considered to be bad
in DNS, including by at least one of the authors of the original CERT
record RFC-2538.

It includes dependancies on other security modules besides DNSSEC (PKIX,
CA's, generic URI's dealing with TLS security, etc.) which makes it hard
on implementors that only want to implement certain security schemes
(eg just OpenPGP and not PKIX, SPKI, X.509 blobs, etc). So that leaves
only the PGP and iPGP sub types of the CERT. That also means the DNSKEY
algorthm number of the CERT RDATA is always 0 (and really not needed)

Indirect URI schemes of CERT can also be used to trick MUA's or MTA's
into connecting to random rogue servers, which is both a security and
a privacy problem. This makes the CERT sub-type IPGP undesirable.

The OPENPGPKEY record uses no sub types, involves no other PKIs, and
supports one clear RDATA format to implement. Depending on only DNS(SEC)
means that openpgp key data can be distributed easilly and widely,
without creating single point of failures or easilly blocked HTTP
requests that are indistinguisable from outages.

With DNSSEC, tampering is visible because there will be a BOGUS DNS answer
when the data is filtered or the data is obtained. Whereas with indirect
methods there can be "unknown errors" in reaching the indirectly pointed
by resource.

The CERT record did not address the local-part lookup problem.
So regardless, a new RFC would be needed to specify the local-part
lookup. That RFC would than basically have to say "Only use IANA
certificate type is 3 (PGP) and algorithm type 0 (not a DNSKEY algorithm).

It seems much cleaner to limit the RDATA section to just the OpenPGP key
material without unused sub-typing and zero'd algorithm identifiers.

The OPENPGPKEY record early code point has already seen more deployment
than the CERT record.

The SMIME record draft also does not plan on using the CERT record.

Paul

---

From: Petr Spacek <[email-masked]>
Date: Mon, 14 Sep 2015 13:16:33 +0200

> The OPENPGPKEY record early code point has already seen more deployment

I agree with your reasoning, Paul. On the other hand, it makes sense to write
one paragraph about it to the draft so we do not need to explain and again and
again, especially to future generations.

-- 
Petr Spacek  @  Red Hat