On Sat, May 31, 2014 at 02:58:08PM -0400, James Cloos wrote:
> VD> If the TLSA records don't include any [3-0-0 or 3-1-x], or are
> VD> mixed, the client must not negotiate "oob public key".
>
> That is a valid point, but if they are mixed, the clients can try, and
> if the offered key doesn't match the suitable tlsas, it can drop the
> connection and try again without specifying the extension.
To what end? The server recently had, has now or soon will have
TLSA records that require full certificates. The server should be
able to offer a matching certificate, containing a suitable key.
I am not a fan of various fallback schemes and associated downgrade
attacks.
> When properly configured, if the server's only current cert(s) is full,
> then the server should not agree to the tls extension. The need to drop
> and restart should be rare.
The need for the client to not offer "oob public key" will also be rare,
generally servers won't have mixtures of different C/U values across
key rollover. Some sites will have only "2 0 1" records:
;; Key rollover state:
;; Current and either future or recent past associated data
example.com. IN TLSA DANE-TA(2) Cert(0) SHA2-256(1) {blob1}
example.com. IN TLSA DANE-TA(2) Cert(0) SHA2-256(1) {blob2}
while other sites will have only "3 1 1" records:
;; Key rollover state:
;; Current and either future or recent past associated data
example.com. IN TLSA DANE-EE(3) SPKI(1) SHA2-256(1) {blob1}
example.com. IN TLSA DANE-EE(3) SPKI(1) SHA2-256(1) {blob2}
and the mixed cases will only be seen briefly in transition between
the two models. That said, transitions should not be disruptive.
A client that sees:
;; Trust model rollover state:
;; Current and either future or recent past associated data
example.com. IN TLSA DANE-TA(2) Cert(0) SHA2-256(1) {blob1}
example.com. IN TLSA DANE-EE(3) Cert(1) SHA2-256(1) {blob2}
has no idea whether the "3 1 1" record is sufficient for authentication,
and should simply not offer to negotiate bare public keys (unless it
it is statically configured to authenticate these by other means, and
the DANE records are largely out of scope).
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
