Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

From: Paul Wouters <[email-masked]>
Date: Fri, 1 Apr 2011 03:13:55 -0400 (EDT)

On Thu, 31 Mar 2011, Yoav Nir wrote:

> Cert-lock (and CA-lock) are what EKR calls supplementary, while the others are the restrictive. While the sever (and domain owner) can't dictate client policy, they should be able to indicate whether the Certificate (TA or EE) that's in the TLSA record is supposed to be validatable or not. The client (relying party) may have a policy to ignore records that push a non-valid certificate, but if you're going to publish a record with a certificate that you have just issued using openssl on your laptop and expires in 1975, the TLSA record had better reflect that this certificate is just a container for a public key, not something you can chain and validate.
>
> So I think the requirements document should describe EKR's use cases, and require that the TLSA record be able to differentiate between records that are appropriate for the two use cases.

Are you really suggesting some kind of indicator that says "you can ignore the cruft from the cert that is bogus
that I vouched for via the RRSIG"?

Paul

---

From: Yoav Nir <[email-masked]>
Date: Fri, 1 Apr 2011 10:22:40 +0300

> that I vouched for via the RRSIG"?

Stated like this, it conveys policy. I just want it to say that this is the cert I'm going to use, and I can't vouch for anything there besides the public key.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 1 Apr 2011 03:29:10 -0400 (EDT)

> Stated like this, it conveys policy. I just want it to say that this is the cert I'm going to use, and I can't vouch for anything there besides the public key.

The obvious answer here is to make it explicit that you are only vouching for the public key... by only putting
the public key in the DANE record to sign.

1) You're not signing items you want the client to ignore
2) You're not signing for information that contradicts itself (RRSIG/TTL vs Expiry or RRlabel vs Subject*)

Paul

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 1 Apr 2011 10:15:51 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Eric Rescorla
> Sent: Wednesday, March 30, 2011 2:28 PM
> To: Richard L. Barnes
> Cc: [email-masked]
> Subject: Re: [keyassure] Objective: Restrictive versus Supplementary
Models
> 
> On Wed, Mar 30, 2011 at 2:18 PM, Richard L. Barnes <[email-masked]>
> 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
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/keyassure
> >
> >
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure