Re: [openpgp] [dane] The DANE draft

[Paul Wouters <[e-mail]>]

On Sat, 25 Jul 2015, Phillip Hallam-Baker wrote:

>       This document has not progressed "quickly". The original draft was
>       published in July 2013. No one is trying to rush this through
> 
> I am quite happy waiting till 2016 or 2018. 
> 
> If it isn't done right its better not to publish at all.

While a worthwhile generic goal, let's do a reality check here. We are
talking about assigning a DNS RRcode for an experimental RFC for storing
RFC 4880 section 5 openpgp packet types into an RDATA field at a
predictable DNS QNAME entry.

If that takes 5 years, the IETF will be on its way to become irrelevant,
and the associated working groups will be to blame for the proliferation
of more TXT type records containing non-text content. It ignores that
many of the original DNSSEC architects meant for the DNS to be able to
securely store signed data.

>             I was a bit disappointed by the process: I learned about the I-D too late
>             and was surprised that it started out at the OpenPGP WG mailing list (2
>             years ago?) with just a few messages and then continued at the DANE list
>             without having notified the OpenPGP list.
>
>       This is now the fourth time I am having this discussion with you, so I
>       think your representation is not entirely fair. The previous discussions
>       ended with you saying we should not do this and stick to the CERT record
>       type and me stating why I disagree with that view.
> 
> Ummm watch your attributions, that is Werner, not me.

My apologies that was not made clearer. I indeed meant to indicate I was
talking to Werner.

> The DANE group has been rather ineffective in getting the constituencies they purport to be
> serving to buy into their proposal.

Are you referring to the OPENPGPKEY document when saying "their proposal" ?

The DANE working group in general has the strange effect that it
is completely ignored when it writes documents to use DNSSEC based
Authentication (its main charter goal!) and only when documents are
getting to WGLC, do people in other areas suddenly wake up and throw on
the brakes waving their expert hats around saying that the DANE working
group cannot make any decisions about their protocol. I've heard in
hallway talks that some people felt so attacked that they basically left
the DANE working group. We had a round of PKIX people, we had a round
of email people, all coming in really late into the process. It would be
really helpful if people get involved earlier in the process.

>       Additionally, because the CERT record is a meta-container record,
>       support for CERT is not good because to properly parse it you need
>       all of openpgp and all of x509 and all of what other subtypes would
>       be added later on. So instead of implementing CERT records partially,
>       many DNS implementations just did not bother with it at all.
> 
> All of X509 isn't a big barrier.

The point is preventing needless CVE's, not adding ASN.1 parsers and
X.509 parsers where not needed. If you don't think X.509 is a problem,
then you haven't been paying attention to CVE's.

> I am not aware of any major crypto package that doesn't have the ability to parse X.509

I am not aware of any major crypto package that did not have a number of
CVE's in their X.509 code.

> . Werner isn't the only person who has a PKIX package in his OpenPGP library. 

Actually, a quick ldd on /usr/bin/gpg* shows no libraries that I know of
that do PKIX. And it would be good not to add new ones just because we
are trying to save one DNS RRTYPE code point by re-using a bad idea from
the past that is today basically unused (the CERT record).

>              The CERT record is more flexible because it also allows the use of an
>              indirect specification via fingerprint.
>
>       Which is a problem not a feature. It makes the security model very
>       complex.
> 
> No, the security model is complex because you are trying to use a vast, aging and vaguely
> understood infrastructure with a byzantine administrative model to provide security.

I am not even sure what refers to what in that sentence. DNS is a set of
well maintained protocols, and RFC 4880 is solid and seeing an update
now in the newly re-chartered openpgp working group. Email addresses
in their current form while vast and old, aren't being obsoleted
any time soon and I don't think my [e-mail] address is aging.

I also find it _really_ ironic that it is not the openpgp key servers
that you are calling "vast, aging and vaguely understood infrastructure"
because if anything is a dangerous misunderstood mess that we cannot
seem to clean up, it is the current electronic garbage heap of pgp
keys we can never clean up because the owners lost their keys or
the keys were generated and uploaded by those not actually being the
real owners of those email address specified in the openpgp key id.

It is _really_ difficult to design any other method of openpgp key
distribution that would be _worse_ than the current key servers.

> Failing to accept that fact is one of the many reasons people are skeptical of this project and
> looking for ways to work round it.

And this is an actual real problem. There is no valid reason for needing
to "work around" an experimental proposal that has a significant backing
of people in the IETF, the mail community and opensource software
writers and distributions. This document is not a protocol extension
you are forced to deal even though you never wanted to. You can simply
not publish OPENPGPKEY records and remain as secure as you are today.

If there are real security issues or operational issues that this draft
might cause, then I would love to hear those. But I've spoken with the
bind implementors and others and they know how to serve big zones and big
records and know how to deal with DOS attacks. They do not see this record
as harmful. The latest suggested base32/split for QNAME was suggested to
support the issues raised by the email and online signing communities.

If you have any specific security concerns about the draft that is not
addressed in the security section, let's discuss those on the list(s)
and fix it.

Paul