On Tue, Mar 05, 2013 at 02:21:00PM -0500, Andrew Sullivan wrote:
> On Tue, Mar 05, 2013 at 07:09:14PM +0000, Viktor Dukhovni wrote:
> >
> > The choice should be up to the server owner, and there is no reason
> > for the client (really clients collectively by enforcing name checks
> > in sufficient numbers) to take away this choice.
>
> I think this boils down to the usual philosophical issue about whether
> the party whose interests are to be most protected is the client or
> the server. My own view is that it is entirely legitimate for the
> client to be in control here, because it is never possible for a
> server to assert anything that a client must do.
This is a flippant response. Sure, the client can chooose to not
implement DANE, or choose to misimplement it by adding 1 mod 4 to
each cert usage and to take the bitwise complement of each digest
value. Or any other number of crazy things.
This thread is about the semantics of the TLSA "1 x y" RR (and the
hopefully settled "3 x y" RR), and whether such records are
potentially valid when the DNSSEC fqdn after _port._proto is not
listed as a SAN or CN in the certificate.
The semantic validity of such RRs is moot if client implementations
(guided or perhaps misguided by RFCs) reject the target EE certificate.
If such RRs, when intentionally created by domain owners, are to
be given the chance to be useful, then clients that do choose to
implement DANE must not enforce name checks on 1/3 EE certs. Name
checks are only unavoidable when there is no explicit EE cert at
hand, and all we have is an issuing CA and so are forced to check
that we have the *right* EE cert by comparing names.
When an EE cert is given a priori, trust chain validation boils
down to making use of a revocation service for said EE certificate.
This is the difference between 1 and 3 that follows from a security
analysis.
We can attempt to more completely mimmic legacy public CA PKI
certificate validation and remove the choice I advocate, but that
would be unfortunate, since it would needlessly only serve to limit
the choices available to domain owners.
There is nothing in the legacy public CA model that looks like
usage "1" with an a priori given EE certificate, therefore it is
not an axion that certificate validation (which always had two
parts: trust chain checks often in SSL libraries, and name checks
often at the application level) should look the same in this new
case.
Is it reasonable to continue to advocate my interpretation based
on logic and consideration of security models? Or is it the group's
view that structural similarity to existing legacy CA PKI practices
trumps logical analysis? [ Cargo-cult security at the IETF? I hope
not! ] Or is "the die cast" and it is simply too late to clarify
the ambiguity in section 4 of 6698.
At the very least, I hope updated dane-srv and dane-smtp drafts
and final RFCs will not mandate name checks for "TLSA 3 x y", so
this thread won't be entirely hot air. I also hope that the
group will consider clarification the 0/2 1/3 feature matrix:
High bit: PKIX trust chain validation
Low bit: EE certificate, hence no name checks
if nothing else this is a more orthogonal feature matrix. As
I tried to show it supports reasonable additional use cases
and opens no new attack vectors.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
