On Thu, Jun 05, 2014 at 01:51:27PM -0400, Paul Wouters wrote:
> It all seems local policy to me that does not need to be specified in
> the document.
Leaving key implementation correctness details out of documents
leads to shoddy non-interoperable implementations. The issues are
somewhat subtle, and clearly not obvious to many. My plan is to
explain the issues and offer clients a choice.
> >Finally, the WG could decide that servers which publish U/S/M
> >combinations in their TLSA RRset that contain only future or only
> >past keys are "misconfigured", and that servers SHOULD NOT do that.
>
> Why does the WG need to decide that? It's simply the case now?
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. To enable key rotation, some records will not, and there
is no guidance on how to do key rotation in a way that supports
all possible subsets of supported U/S/M values.
> AFAIK, all thoughout DANE the policy is "grab the TLSA RRset - if you
> find no usable record, authentication fails".
This leaves all the relevant details to the point of vacuous
irrelevance. This is a subtle topic that requires attention to
detail.
> The problem I have is your desire to drop oob when finding a non-"3 1 x"
> record AND a "3 1 x" record, and argue that the latter record "might be
> incorrect and the server admin might not realise this when he updated
> the other type of TLSA record and therefore we should not allow mixed
> types ever".
Not just "might", will be incorrect a non-trivial fraction of the
time, unless we specify new server-side requirements.
> >In that case arguably the burden to get this right is on the server
> >and the client can be let off the hook.
>
> I don't see why this is ever NOT the case.
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").
> For any set of X TLSA records of various types, to rollover you add a
> matching X sets of TLSA records with the new pubkey/cert/chain record.
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}
While a simple key rotation looks like:
Initial:
IN TLSA 3 1 1 {legacy EE blob}
Intermediate:
IN TLSA 3 1 1 {legacy EE blob}
IN TLSA 3 1 1 {new EE blob}
[switch keys]
Final:
IN TLSA 3 1 1 {new EE blob}
> >And thus client caution is approriate where there is little
> >to lose by suppressing a minor TLS optimization.
>
> That's your personal subjective value judgement. I would say, when the
> operator publishes a TLSA record to match SPKI, they are working hard to
> get rid of this legacy X.509 container disaster using a very important
> new TLS extension.
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.
> 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) to make sure DANE works reliably (always
when everyone does what's expected of them and written down).
Authentication protocols that fail in non-obvious corner-cases are
not progress.
The WG can help shift the balance of the burden to either the client
or the server. My plan is encourage caution on both sides. The
consequence of caution will be fewer users spending sleepless
nights debugging non-obvious problems while cursing the designers
of the fragile systems they've saddled with supporting.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
