PKA updates

[Michael Felt]

My two cents - more organizational than technical.

Any technology, to gain acceptance, needs to be easy to implement - so that
the benefit overwhelms you. The technology might not be perfect - a 1st
generation, basically by definition - never is.

However, if the benefit is clear - AND minimal/no (further)
organizational/management load to provide "some additional" security -
then, even if not perfect adoption starts.

What I read above is that the technology will be able to (better) support
management in how to setup "this new feature" and it will be easier to
automate better secrecy (aka encryption) of e-mails than now. I hope I got
that part right at least.

So, a choice between nothing, or something AND easy to implement, may be a
first step into gaining ADOPTION of PKA, DNSSEC, XXX.

Maybe - rather than being initially concerned with the encryption of
messages - a way to automate the signing and verification of messages will
be something that will interest users.

In short - fulfill a need and technology (improvements) will follow.

Michael

On Sat, Feb 28, 2015 at 5:08 AM, Daniel Kahn Gillmor <dkg at fifthhorseman.net>
wrote:

> 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
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150301/b8e08830/attachment-0001.html>