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

[Viktor Dukhovni <[e-mail]>]

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

> >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.
> 
> Before I send patches, we will need a discussion, because I know you
> 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)
> with  selector SPKI(1) was to demote _any_ X.509 material apart from
> 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.

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

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.

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

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.

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

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

> Also, the DANE document is not the place to specify how TLS clients
> 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
> 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.

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.

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

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.