Re: [keyassure] Objective: Restrictive versus Supplementary Models

Yoav Nir <> Thu, 31 March 2011 09:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9261A28C204 for <>; Thu, 31 Mar 2011 02:38:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.549
X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4NAj9iGQUlNu for <>; Thu, 31 Mar 2011 02:38:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0CDB828C216 for <>; Thu, 31 Mar 2011 02:38:31 -0700 (PDT)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id p2V9cPcu014825; Thu, 31 Mar 2011 11:39:57 +0200
X-CheckPoint: {4D944AFF-5-1B221DC2-FFFF}
Received: from ([]) by ([]) with mapi; Thu, 31 Mar 2011 11:39:24 +0200
From: Yoav Nir <>
To: "Richard L. Barnes" <>
Date: Thu, 31 Mar 2011 11:39:22 +0200
Thread-Topic: [keyassure] Objective: Restrictive versus Supplementary Models
Thread-Index: Acvvh4RvDhWjW2aiR+69y9QbXi8Fxw==
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Mar 2011 09:38:57 -0000

On Mar 31, 2011, at 11:15 AM, Richard L. Barnes wrote:

>>>> If the attacker injects fake dns records pointing to a fake server, they
>>>> can include a dane rr.  It only makes the attack slightly harder, doesn't it?
>>> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause the connection to fail, it won't result in the client connecting to a bogus server.   That's why it's RECOMMENDED instead of REQUIRED.
>> Not if you are a MITM on the wire as well (more star bucks wifi use cases) and
>> you're directing the user to your own website with a dane rr matching public key.
> You're confusing the "Cert Lock" and "Install TA" use cases.  If all the server doing is "Cert Lock", then the bogus DANE record will simply cause the client to reject the server's cert and the connection to fail.  In the "Install TA" case, DNSSEC would be REQUIRED, for exactly the reason you note.

So it's really down to 4 cases:
- CA-lock (I only use Verisign)
- Cert-lock (I only use this cert)
- This CA (This is the CA cert that issues my certificate, and it may not be in your TAS)
- This Cert (this is the cert I'll be using, and I'm not promising that you can validate it)

While I see some value in cert-lock, I don't see much value in CA-lock. It would solve Comodogate if I was a customer of another CA, but not if I was a customer of Comodo.

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.

And yes, a certificate from a known CA can be appropriate for both use cases, and I expect that at least initially those would be more popular, as they work with "legacy" relying parties.