Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys

[Viktor Dukhovni <[e-mail]>]

On Thu, Jun 05, 2014 at 05:21:44PM -0700, John Gilmore wrote:

> Today I read the dane-ops-03 document.  The latest is from February,
> which seems rather old.  Also, it is designed to be a Best Current
> Practice, and it does not update the DANE TLSA RFC 6698.

Indeed, sorry about that, since just before London, we've focused
primarily on the SMTP draft, to the detriment of progress on the
ops draft.  Cycles were limited.  This is about to change...

In particular the ops draft will shortly be revived from limbo,
changed to standards track and will update 6698.

> Also, various people in the DANE WG have different ideas on how to
> represent Raw Public Keys (RPKs) in TLSA records, what operational
> constraints to put on TLSA records involving RPKs, and even how the
> TLS protocol itself should evolve to require retries when using
> RPKs. It seems a bit too early to say, "just release RFC 7250, it
> won't need any more changes" when these issues have not been resolved,
> nor even extensively explored.

You'll find that there is little support for RPK formats other than
"3 1 X", despite a small number of suggestions to the contrary.  A
consensus around "3 1 X" is I think a safe bet.

It is also not clear that "RPK" is fundamentally dependent on an
extant definition of how it is to be used with out of band DANE
authentication.  The base specification it seems is mechanism
neutral.  So the specifics of associated TLSA RR formats are only
an issue for DANE clients, thus not unreasonably defined in a
related new DANE WG document.

> I think that the real stumbling block here is the attitude that "DANE
> is only for PKIX",

That may be true of some past history, but I've seen very little
of that here in the last year a bit that I've been active in this
group.  DANE is not only for PKIX, but RFC 6698 as it stands does
not currently describe associations to objects other than X.509
certificates.  We'll address extending the definition to RPK in
the ops draft, or a separate document if there's a strong preference
for that.  Since some of the content would overlap with related
material in the ops draft, I'd prefer to not split this out.

> Until and unless that attitude
> is definitively repudiated by the WG in toto, I suspect that we will
> continue to have problems reaching consensus whenever any IETF member
> tries to use DNSSEC for a protocol (like Raw Public Keys) that does
> not use PKIX certificates.

We should not confuse the circumscribed scope of 6698, which looks
today to be more a matter of caution to not overreach, rather than
any specific bias in favour of a particular key management approach.

There could have been some players who during the development of
6698 had an agenda in one direction or another, but the document
itself is at worst too narrow, rather than biased.

It also does not consider the opportunistic use-case and various
other issues that would probably have further delayed adoption.

RPK via "3 1 X" is a natural extension of 6698 to include in a 6698
update.  If new certificate usages are needed in the future for
more radically different use-cases, these can be added in separate
documents or in any future comprehensive updates.

Bottom line, I've not run into any difficulties agenda-driven
conspiracies here yet.  I'd like to add RPK support to Postfix at
some point, once code for this is available (in OpenSSL).

You'll likely find more resistance to RPK from some of the various
toolkit maintainers (of OpenSSL, NSS, GnuTLS, ...) than on the DANE
WG, where I expect RPK has a decent body of support.  Like RPK DANE
TLSA is a departure from the established order, and the two share
common use-cases.

-- 
	Viktor.