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

[John Gilmore <[e-mail]>]

> Sorry for the top posting of our main arguments. 
> RFC7250 has shipped, please do not hold up the publication. 
> We need a quick turnaround to address the issues you identified below. 
> 
> As Wes Hardaker commented in a later message we have an “Dane uses and fixes” document in the
> queue and adding this to it is appropriate. (dane-ops) 

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.

It has been argued by an RFC 6698 co-author that only an RFC which
"Updates: 6698" and goes through "the IETF community" and the DANE WG
can amend the strong statements in RFC 6698 that invalidate any
DANE protocol use that doesn't involve PKIX.  He said:
> Under no circumstances should RFC 6698 be updated in the fashion
> that John suggests below. The IETF community did not have an
> opportunity to review the proposed changes, the draft in question
> never mentioned that it would update RFC 6698, and the DANE WG was
> only informed of this during AUTH48.
>
> The authors could, and should, simply do a short Internet Draft that
> updates RFC 6698. Many / most of us would support that.

The Dane-Ops Draft doesn't meet these criteria.  So, either that
co-author would have to recant his previously expressed stance in
order to resolve the "TLSA for raw public keys" issue in the Dane-Ops
Draft; or else Dane-Ops would have to become a standards-track
protocol spec, not a BCP.  Perhaps if the WG agrees with this
co-author, the only thing is to ignore Dane-Ops and instead write a
new 2-page Internet-Draft.

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.

I thought that we had consensus that just publishing a "3 1 x" key
would suffice, but it has become clear that others have very different
ideas, including "4 1 x" records, "1 1 x" records, etc.

I think that the real stumbling block here is the attitude that "DANE
is only for PKIX", which some WG participants came in with, which was
embedded into what became the primary DANE RFC (TLSA RFC 6698), and
which some continue to argue for.  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.

	John