PKA updates

[Daniel Kahn Gillmor]

On Thu 2015-02-26 03:34:23 -0500, Werner Koch wrote:
> On Wed, 25 Feb 2015 21:34, dkg at fifthhorseman.net said:
>
>> https://tools.ietf.org/html/draft-ietf-dane-openpgpkey ?  Should we try
>> to support this draft?
>
> I looked at this again.
>
>  - It requires a new record type

I'm not sure that a new record type is much of a problem.  Most DNS
servers support generic types these days, and the hash-slinger code
can produce hex-encoded records that should be acceptable.

 http://people.redhat.com/pwouters/hash-slinger/

>  - It merges the first time key retrieval with the validation of the
>    key.

The draft allows for validation of the key via DNS fetch, but it doesn't
require that the MUA treat the dnssec validation as authoritative.

>  [ - Why using SHA224 for hashing if this is just for maiing the
>      local-part. ]

i'm not sure what the issue is here.  can you explain further?  My
understanding is that the digest is to avoid DNS labels that are either
too long, or contain unwieldy characters, not as an attempt to mask the
identity being looked up.

> That was my original idea behind PKA.  I don't think that is anymore
> justified.  However, if you trust DNSSEC gpg can already be tweaked to
> that that in account by using "--verify-options pka-trust-increase" etc.

Can you explain more why you no longer think that using dnssec as a
corroborative channel is justified?  I'm personally wary of the
hierarchical model for DNSSEC, but i don't think that invalidates it for
corroboration.

>> There are other kinds of security at issue, though: DNS provides a
>> pretty nasty leakage channel, since confidential DNS query mechanisms
>> are not widely deployed.  I'd hope that DNS lookups aren't necessarily
>
> I think this decision should be left to the MUAs.  If it is enabled by
> default, that would be better than sending mails in the clear.  Thus for
> a first time non-expert installation enabling such a feature by default
> would be the Right Thing.

Well, sending mail in the clear over a STARTTLS submission channel only
leaks the To: information to the user's sending MTA, while the DNS query
leaks the same information to every machine along the network path to
the DNS server.

But i think you're right that this is something that can be mitigated
with sensible MUA operation, caching results, etc.

     --dkg