On Fri, May 30, 2014 at 01:57:21AM -0400, Paul Wouters wrote:
> >The server will indeed have full certs and corresponding or
> >independent bare keys. However all the TLSA RRs MUST be "3 1 X"
> >RRs (matching all the deployed certificates and public keys),
> >or else clients MUST NOT indicate support for "oob public key".
>
> A client can indicate support for oob public key that is not based on
> DANE.
Yes, of course. But if the client intends to perform DANE
authentication, it should not preclude verification via any RRs
that require a full certificate chain. In practice, server RRs
for servers that want to support the new TLS extension will be all
"3 1 X" for both "active" and "legacy" keys, but (DANE-aware)
clients will need to be prepared for exceptions.
> >The point being that the client does not know which TLSA RRs are
> >"live" and which are "legacy" as a result of key rotation.
>
> Why does that matter? the client receives either the server's full
> certificate or its 'bare key certificate'. It looks through the list of
> obtained TLSA records and looks if anything matches. It does not need
> to prove every TLSA record is valid.
There may be no records that match the SPKI of the active public
key. You're not thinking sufficiently clearly about the full TLSA
record lifecycle, key rotation, changes in usage/selector over
time, ...
> Also, all TLSA records are "live", and I don't understand your
> terminology of "live" versus "legacy" at all.
Not all server keys are "live" some will refer to the previously
fielded key, to accomodate key rollover.
> If the client only has a bare public key of the server and the TLSA record
> is only "2 x x" the setup is broken. sure. Don't do that? If there is a
> "3 x x" TLSA record, there is no issue.
Not true, firstly because it needs to "3 1 X" not "3 X X", but also
because even "3 1 X" may describe a stale configuration that is no
longer active.
> Why isn't only _one_ TLSA record of type "3 1 x" good enough? Why can't
> the admin publish a "3 1 x" and a "1 x x" or "2 x x" ?
Because there is no guarantee that that particular RR still matches
the server's chain. All we know is that *some* RR is supposed to
match the chain, during key rotation, some do not.
The ones that do not might be "legacy" or might be "future" (keys
that are no longer deployed, or keys soon to be deployed).
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
