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

[Paul Wouters <[e-mail]>]

On Thu, 5 Jun 2014, Viktor Dukhovni wrote:

> No it is not.  Look at the verification logic in the appendix that
> loops over all the records.  There is no expectation that every
> TLSA RR reflects current reality, nor can there be.  All that's
> required is that *at least one* TLSA record matches the server
> chain.

Right. Which is why you can have mixes of types/selectors/usage.

> Because there is nothing in any DANE document that encourages, let
> alone obligates the server to ensure the necessary invariants.
> Left to their devices server operators will publish the problematic
> RRsets (which cause no obvious problems without "oob").

TLSA records are not TLS client remote configuration records.

I think it is a bad idea to allow a TLSA record to modify TLS client
behaviour for TLS extensions. TLSA is to authenticate, not to configure.

> Suppose the goal is to switch a TA-issued cert (previous self-signed)
> and publish a DANE-EE(2) association, from a current "3 1 1" leaf
> cert.  This can't be done while preserving the stated invariant
> without a non-obvious intermideate stage in the DNS keys, because
> the self-signed initial cert has no TA.
>
>    Initial:
>
> 		IN TLSA 3 1 1 {legacy EE blob}
>
>    Intermediate:
>
> 		IN TLSA 3 1 1 {legacy EE blob}
> 		IN TLSA 3 1 1 {EE association for new TA issued chain}
>
>    [switch keys]
>
>    Final:
>
> 		IN TLSA 2 0 1 {TA cert blob matching new chain}

Why can't I do:

     Initial:
  		IN TLSA 3 1 1 {legacy EE blob}
     Intermediate:
  		IN TLSA 3 1 1 {legacy EE blob}
  		IN TLSA 2 0 1 {TA cert blob matching new chain}
     [switch keys]
     Final:
  		IN TLSA 2 0 1 {TA cert blob matching new chain}

The only requirement is to ensure old TLSA RRsets without the new
TLSA record do not live anywhere in cache anywhere when the new TLS
cert/key/chain is deployed on the server.

> Most operators who publish "3 1 X" will publish *ONLY* "3 1 X" and
> my oh-so-subtle comments won't apply.  The deployment of "oob" will
> not be in any way reduced.  By making it safer to deploy "oob" (not
> causing unnecessary outages) I am on your side.

Most operators who want to get rid of X.509 containers and uselessly
expiring X.509 certificates (Like Yahoo yesterday?) and wanting to
deploy oob will first use a DANE-EE SPKI on a full cert, and do any kind
of CA/TA based matching anyway?

>> Restricting the TLSA RRset or pro-actively dropping the oob extension
>> based on a mixture of TLSA U/S/M records is undesirable, and your
>> justification of "the admin might make an erorr" is an extremely weak
>> reason for it.
>
> And yet you're simply wrong about that.  Somewhere, either the
> client or the server or both need to do some non-obvious things
> (that I plan to write down)

I have no problem writing down the non-obvious. I just disagree with
your proposed TLS client behaviour.

I think we both understand each other's viewpoint. It's time for others
to chime in.

Paul