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
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
