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

From: John Gilmore <[email-masked]>
Date: Thu, 15 Jan 2015 14:24:50 -0800

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.

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?

	John

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 15 Jan 2015 22:48:57 +0000

> 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.

> 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.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 16 Jan 2015 10:27:24 -0500 (EST)

> to be phrased differently, patches (to the XML please) welcome.

Before I send patches, we will need a discussion, because I know you
will reject the proposals I would write. The whole point of DANE-EE(3)
with  selector SPKI(1) was to demote _any_ X.509 material apart from
the public key as legacy garbage. But people couldn't say that out
loud so the wording in 6698 was done in a way to make both sides of
the argument happy. As John showed, and the WG agreed to, we needed to
make that more explicit. After I presented John's draft at the meeting,
the consensus was these changes should be folded into this document as
it already updates 6698.

So instead of text stating "ignore the expiry date of the certificate",
the next needed is that for DANE-EE(3) and selector SPKI(1) everything
but the SPKI of the certificate should be completely ignored. In fact,
RFC 7250 allows for certificates that contain nothing more than SPKI.

Then, to attempt to avoid a problem with the text as it is currently
in the draft, this band-aid is specified:

    Clients that employ DANE to
    authenticate the peer server SHOULD NOT negotiate the use of raw
    public keys unless the server's TLSA RRset includes compatible TLSA
    records.

The only reason for this is because enough of the certificate wasn't
already ignored by clients not supporting raw public keys!

Also, the DANE document is not the place to specify how TLS clients
with raw key support should do TLS negotiations with extensions. The
only thing this document needs to state is "DANE-EE(3) and selector
SPKI(1) means only look at the public key, ignore everything else" and
than magically both clients that don't support raw keys but implement
this document and clients that do support raw keys and implement this
document, will work fine.

If you agree with these points, I'm happy to submit xml updates.

> Perhaps it is time to move the OPS draft into LC

No. I think we need to resolve this issue first. It has been evaded for
years, from the start of the work on 6698 up to this latest draft.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 16 Jan 2015 16:47:13 +0000

On Fri, Jan 16, 2015 at 10:27:24AM -0500, Paul Wouters wrote:

> will reject the proposals I would write.

I'd like to think we're not likely to disagree.

> The whole point of DANE-EE(3)
> the public key as legacy garbage.

And indeed this is essentially accomplished with the SMTP and ops
draft already, by requiring the validator to ignore any hostnames
and expiration data in any enclosing certificate even with selector
Cert(0).

In Postfix, in fact everything in the certificate other than the
public key is already ignored with DANE-EE(3).

> But people couldn't say that out loud so the wording in 6698 was done in
> a way to make both sides of the argument happy. As John showed, and the
> WG agreed to, we needed to make that more explicit. After I presented
> John's draft at the meeting, the consensus was these changes should be
> folded into this document as it already updates 6698.

I agree.

> RFC 7250 allows for certificates that contain nothing more than SPKI.

I agree, and I thought that the current text says essentially that,
since by allowing RPK we're effectively saying that nothing else
matters.  A leaf certificate matched via "3 1 X" is simply a less
space efficient format for RPK.

I paved the way for this with the SMTP and OPS drafts, getting the
initial consensus on the hostname and expiration bits, but my
argument to ignore *everything* else (though it was also for
Cert(0)), ran into some opposition, so I settled for what's essential
to the operational success of DANE with SMTP.

>    public keys unless the server's TLSA RRset includes compatible TLSA

Naturally enough, if the server's TLSA RRs is, e.g.,  "IN 2 0 1
<blob>" it would be rather unwise to propose RPK in the TLSA
handshake, since that'll lead to DANE verification failure.

However, if the server publishes at least some "IN TLSA 3 1 X"
record, then one can offer to negotiate RPK.

> already ignored by clients not supporting raw public keys!

No.  The reason is to avoid negotiating non-interoperable parameters.

> with raw key support should do TLS negotiations with extensions.

The DANE document is the place where one can specify how RPK interacts
with DANE.  We're talking about extending 6698 to cover use of "3 1 X"
records with RPK.

Paul, I really am going to agree with you on the technical points.
I sense only a conflict where you seem to believe that I'll be
opposed to RPK, but I'm not.  I fully support extending DANE-EE(3)
with SPKI(1) to interoperate with RPK.

> The only thing this document needs to state is "DANE-EE(3) and selector

It is also I think appropriate to say (and the document attempts
to do so) that when authentication is going to be DANE-based, faced
with a TLSA RRset that does not include any "3 1 X" records, RPK
would be unwise, but when "3 1 X" RRs are published, one can safely
offer to negotiate RPK.

There are then considerations for key rotation, as servers moving
from "3 1 X" to "2 0 1" should ensure that their "3 1 X" records
still match reality during the transition.  See

    https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.2

> If you agree with these points, I'm happy to submit xml updates.

I see little substantive disagreement.  Unless you are adamant that
the document should be silent on when a DANE client should avoid
RPK for lack of compatible TLSA records.

> years, from the start of the work on 6698 up to this latest draft.

Sometimes LC is the only way to get meaninglful discussion, but I
am quite open to such discussion before, during or after WG LC.

And I think we are in violent agreement, and the only thing between
us is just some residual heat from the embers of "Opportunistic
Security" fire.  A few beers might solve that, but sadly I am not
planning to be at IETF Dallas.  If you're ever in NYC, look me up.

-- 
	Viktor.