On Thu, Jun 05, 2014 at 02:56:19PM -0400, Paul Wouters wrote:
> >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.
That claim is not universal. For a DANE-capable SMTP client TLSA
records actually set a bunch of TLS policy. The "discovery" vs.
"lookup" non-issue.
> 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.
Authentication is behaviour.
> >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}
Well, now before the switch you have a "2 0 1" U/S/M with no active
keys. A transition in the opposite direction would break with
"oob" clients because it would be the "3 1 1" that matches "future"
keys. The safe version of the reverse change looks like:
Initial:
IN TLSA 2 0 1 {legacy TA blob}
Intermediate:
IN TLSA 3 1 1 {EE association for legacy TA issued chain}
IN TLSA 3 1 1 {future EE blob}
[switch keys]
Final:
IN TLSA 3 1 1 {new EE blob}
Had the intermediate listed the original "2 0 1" for the legacy
chain, "oob" clients would lose.
> 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?
Right, they'll publish "3 1 1", but for some time the actual TLS
handshake will exchange certs containing the SPKI, rather than bare
SPKI. Eventually clients will start optimizing out the certs.
> >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.
First correct, then optimized. Note the definition of "3 1 1"
already (once the SMTP and OPS drafts are adopted) largely ignores
the cert content (names and expiration, re Yahoo). So the main
difference between now and a future client that uses bare keys is
that the server sends less data from which the client extracts the
SPKI (an optimization).
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
