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

[Viktor Dukhovni <[e-mail]>]

On Thu, Jan 15, 2015 at 02:24:50PM -0800, John Gilmore wrote:

> It has been seven months since the DANE WG "adopted" my very short
> draft that repealed the CA-motivated anti-interoperability
> prohibitions in RFC 6698 and simply specified how DANE authenticates
> or publishes raw public keys.  Therefore, the draft has expired.  In
> the meantime, as far as I can tell, nothing has been done.

The dane-ops draft in section 5.1 specifically extends the semantics
of "3 1 X" to cover RPK.  (The reference to the RPK draft needs to
be updated to reference the published RFC).

    http://tools.ietf.org/html/draft-ietf-dane-ops-07#section-12

       *  In Section 5.1 we update [RFC6698] to specify peer identity
	  matching and certificate validity interval based solely on the
	  basis of the TLSA RRset.  We also specify DANE authentication of
	  raw public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with
	  Certificate Usage DANE-EE(3) and selector SPKI(1).

If the text in section 5.1 of that document needs to say more, or
to be phrased differently, patches (to the XML please) welcome.

This group moves slowly.  I wish it were otherwise, but it seems
that working on DANE is nobody's day-job.

> All the urgency to actually solve this problem evaporated as soon as I
> allowed RFC 7250 to issue despite containing no text that addressed
> this problem.  I was assured by my friend Olafur and my colleagues
> Warren and Stephen, the people in authority over this working group
> and this whole security area, that they would address the issue "ASAP"
> if I would just follow their recommended procedures.  Yet it did not
> happen.
> 
> I did it the way you-all recommended, and nothing got done.  So the
> self-serving CA lobby won (delay is a win), and the NSA won (delay is
> a win for them too), and the public lost.
> 
> Where do we go from here?

Perhaps it is time to move the OPS draft into LC, now that the SMTP
and SRV drafts have had their turn.  (And perhaps time to move
those into IETF last call).

-- 
	Viktor.