Re: [keyassure] Objective: Restrictive versus Supplementary Models

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Eric Rescorla
> Sent: Wednesday, March 30, 2011 2:28 PM
> To: Richard L. Barnes
> Cc: [e-mail]
> Subject: Re: [keyassure] Objective: Restrictive versus Supplementary
Models
> 
> On Wed, Mar 30, 2011 at 2:18 PM, Richard L. Barnes <[e-mail]>
> wrote:
> > I agree with Ekr and Steve that these are the right goals.  I don't have
any
> further goals to add.  Just trying to re-state in bullet-point form:
> >
> > 1. Cert-lock / CA-lock
> > 1.1. Use case:
> > 1.1.1. Client initiates TLS connection and gets server cert chain
> > 1.1.2. Client performs normal TLS/PKIX validation on cert chain 1.1.3.
> > Client retrieves DANE records from DNS 1.1.4. DANE records specify EE
> > or CA certs that MUST be present in cert chain 1.1.5. Client verifies
> > that TLS cert chain meets DANE constraints 1.2. Security goal: Defend
> > against issuance of other certs for this domain 1.3. DNSSEC
> > RECOMMENDED, not REQUIRED; attacker can only cause connection failure
> >
> > 2. Domain-managed authentication
> > 2.1. Use case:
> > 2.1.1. Client retrieves DANE records from DNS 2.1.2. DANE records
> > specify Trust Anchors for PKIX certificate validation 2.1.3. Client
> > adds DANE CA certs to TA store (optionally, drops all others) 2.1.3.
> > Client initiates TLS connection and gets server cert chain 2.1.4.
> > Client performs normal TLS/PKIX validation on cert chain

I have some concerns about making these a TA in all cases.  Specifically if
this is an intermediate CA in a chain that goes to a TA that I have
configured in my system.  Turning this CA into a TA means that any
configuration information that I have on my TA plus any extensions that are
in CA certificates between the TA and CA in the DANE statement are all
suddenly ignored.  I think this is bad behavior.

Jim

> 
> I don't think this last point has consensus. Certainly, in the case where
the
> certificate in question is the terminal certificate, I think at least some
people
> don't care if it's invalid from a PKIX perspective.
> 
> -Ekr
> 
> > 2.2. Security goal: Allow TLS to work without pre-configured TAs 2.3.
> > DNSSEC REQUIRED; attacker can insert bogus TAs
> >
> >
> >
> >
> >
> > On Mar 30, 2011, at 10:48 AM, Eric Rescorla wrote:
> >
> >> To follow up on my comments at the microphone, there are two
> >> potential objectives for technology of this type:
> >>
> >> 1. Protecting against CA mis-issue (as in CA/cert lock).
> >> 2. Allowing TLS to work without getting a certificate from one of the
> >> established trust anchors.
> >>
> >> In the first case, the idea would be that the relying party would go
> >> through its ordinary validation logic and if that failed, would
> >> reject the certificate. However, if the validation succeeded, it
> >> would check DNS and if that check failed, would then reject the
> >> certificate. Only if both checks succeeded would the certificate be
> >> accepted. [0] The objective of this type of mechanism would be simply
> >> to defend against unauthorized certificate issuance.
> >> Note that in this case, the DANE data need not be DNSSEC secured,
> >> because an attacker who tampers with it will solely be able to cause
> >> a connection failure, and in many cases (TLS, SSH, etc.) an attacker
> >> with those capabilities can tamper with the A record and block the
> >> connection that way.
> >>
> >> In the second case, the intention is to allow clients to effectively
> >> bypass the existing trust hierarchy by injecting a new trust point
> >> via the DNS. Thus, either the certificate validation simply will not
> >> be used at all (in the case where a terminal certificate is provided)
> >> or will be used up to a newly inserted trust anchor. In either case,
> >> the presumptive rationale here is that it's too inconvenient to deal
> >> with the existing CAs and that DANE will be easier.
> >> This version of DANE *does* need to be protected via DNSSEC because
> >> tampering with these records allows the attacker to impersonate the
> >> authenticating party to the relying party.
> >>
> >>
> >> The draft to some extent conflates these two objectives, since it
> >> *both* injects a new trust
> >> anchor and restricts the list of potential certificates. It does not
> >> allow you to simply restrict the list of CAs/certificates without
> >> also injecting a new trust point.
> >>
> >>
> >> Opinion follows:
> >> For my money the most important driving use case for this work is the
> >> first case, for two reasons. First, it's the more pressing problem
> >> since it's not really
> >> *that* hard to get a
> >> certificate from one of the existing CAs, but this also means that we
> >> have to worry about mis-issue by misbehaving CAs, as we have recently
> >> seen. Second, the incremental deployment story is much easier, since
> >> clients which don't speak DANE will just not be protected against
> >> attack, whereas in the second case clients which don't speak DANE
> >> will experience certificate errors when connecting to a DANE-only
> >> site.
> >>
> >> -Ekr
> >>
> >>
> >> [0] The checks can be done in either order. This is only for clarity.
> >> _______________________________________________
> >> keyassure mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/keyassure
> >
> >
> _______________________________________________
> keyassure mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/keyassure