From paul@xelerance.com Fri Apr 1 00:12:19 2011 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B24A3A6BF3 for ; Fri, 1 Apr 2011 00:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKgjJMjIRV2C for ; Fri, 1 Apr 2011 00:12:18 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 6A2EF3A6BD7 for ; Fri, 1 Apr 2011 00:12:18 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id DDE47C5A0; Fri, 1 Apr 2011 03:13:55 -0400 (EDT) Date: Fri, 1 Apr 2011 03:13:55 -0400 (EDT) From: Paul Wouters To: Yoav Nir In-Reply-To: <7629D2C2-16DC-4ED8-B1AE-14900891448B@checkpoint.com> Message-ID: References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> <7629D2C2-16DC-4ED8-B1AE-14900891448B@checkpoint.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org 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: Fri, 01 Apr 2011 07:12:19 -0000 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 paul@xelerance.com Fri Apr 1 00:16:33 2011 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F5263A6BD7 for ; Fri, 1 Apr 2011 00:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b50y8bvmU2LP for ; Fri, 1 Apr 2011 00:16:29 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 8C5A63A6849 for ; Fri, 1 Apr 2011 00:16:28 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 42A90C5A0; Fri, 1 Apr 2011 03:18:08 -0400 (EDT) Date: Fri, 1 Apr 2011 03:18:07 -0400 (EDT) From: Paul Wouters To: Martin Rex In-Reply-To: <201103311336.p2VDafum022751@fs4113.wdf.sap.corp> Message-ID: References: <201103311336.p2VDafum022751@fs4113.wdf.sap.corp> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org 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: Fri, 01 Apr 2011 07:16:34 -0000 On Thu, 31 Mar 2011, Martin Rex wrote: > To me, processing unsigned TLSA records is similar to > processing unsigned OCSP responses or unsigned CRLs. > I would not do the latter, and I'm in doubt that the former > is a good idea. Agreed. Paul From ynir@checkpoint.com Fri Apr 1 00:18:42 2011 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622C13A69B5 for ; Fri, 1 Apr 2011 00:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.553 X-Spam-Level: X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QG-umDm7+KGO for ; Fri, 1 Apr 2011 00:18:41 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id E80033A691A for ; Fri, 1 Apr 2011 00:18:40 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p317KJe9017798; Fri, 1 Apr 2011 10:20:19 +0300 X-CheckPoint: {4D958AA4-22-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 1 Apr 2011 10:20:19 +0300 From: Yoav Nir To: Paul Wouters Date: Fri, 1 Apr 2011 10:20:17 +0300 Thread-Topic: [keyassure] Objective: Restrictive versus Supplementary Models Thread-Index: AcvwPUEZ40fnJTE3RWiWgGNoRXHURg== Message-ID: <67E85313-0B69-4AAA-B2BE-BABA5363D148@checkpoint.com> References: <201103311336.p2VDafum022751@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org 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: Fri, 01 Apr 2011 07:18:42 -0000 On Apr 1, 2011, at 10:18 AM, Paul Wouters wrote: > On Thu, 31 Mar 2011, Martin Rex wrote: >=20 >> To me, processing unsigned TLSA records is similar to >> processing unsigned OCSP responses or unsigned CRLs. >> I would not do the latter, and I'm in doubt that the former >> is a good idea. >=20 > Agreed. >=20 > Paul +1 (and it's also like an unsigned cert) From paul@xelerance.com Fri Apr 1 00:21:20 2011 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F8523A691A for ; Fri, 1 Apr 2011 00:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyUityYQZFmA for ; Fri, 1 Apr 2011 00:21:07 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 9D2AB3A69B5 for ; Fri, 1 Apr 2011 00:21:00 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 1B65CC5A0; Fri, 1 Apr 2011 03:22:40 -0400 (EDT) Date: Fri, 1 Apr 2011 03:22:39 -0400 (EDT) From: Paul Wouters To: Jay Daley In-Reply-To: Message-ID: References: <4F5CBD0D-E9D4-4042-B082-B15D3D509A37@edvina.net> <57F0D906-4EF8-4628-AAE0-34C661A7184E@bbn.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] The draft and subj alt names X-BeenThere: keyassure@ietf.org 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: Fri, 01 Apr 2011 07:21:20 -0000 On Fri, 1 Apr 2011, Jay Daley wrote: >> As I've said in other threads, this WG should be silent on requirements for certificate names, since different applications use TLS certificate names in different ways. See for example the difference between RFC 2818 and RFC 6125. The text you reference in the draft is technically harmless ("must" not "MUST"), but should probably be deleted anyway. > > There are two separate issues here: > a) whether we think name matching is still needed with DANE > b) what the draft should say about that > > On a) I would make the case that name matching is should not be done because > - DNSSEC provides sufficient trust > - name matching forces certain operational decisions onto end user (e.g. multiple certs, cert reuse) that are unreasonable Also, image you have to keep updating your cert in DANE every time you add/remove a vhost and you have to update the subjectAltname. One of the advantages of putting it in DNS is that you know the name of the entity without having to look inside the cert. The cert is just a legacy container for the public key. We should not be adding policy in DANE that entangles DANE with PKIX (or any other trust scheme) Paul From ynir@checkpoint.com Fri Apr 1 00:21:21 2011 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D48B3A69D3 for ; Fri, 1 Apr 2011 00:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.554 X-Spam-Level: X-Spam-Status: No, score=-10.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOuDKQPyAdta for ; Fri, 1 Apr 2011 00:21:09 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 6B03F3A6B03 for ; Fri, 1 Apr 2011 00:21:07 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p317MfQV018079; Fri, 1 Apr 2011 10:22:41 +0300 X-CheckPoint: {4D958B32-2-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 1 Apr 2011 10:22:41 +0300 From: Yoav Nir To: Paul Wouters Date: Fri, 1 Apr 2011 10:22:40 +0300 Thread-Topic: [keyassure] Objective: Restrictive versus Supplementary Models Thread-Index: AcvwPZZSPiOLsiexRWCPor5y2T44Pw== Message-ID: <97668833-DC1B-4371-85F5-60ABBE8CA2F2@checkpoint.com> References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> <7629D2C2-16DC-4ED8-B1AE-14900891448B@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org 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: Fri, 01 Apr 2011 07:21:21 -0000 On Apr 1, 2011, at 10:13 AM, Paul Wouters wrote: > On Thu, 31 Mar 2011, Yoav Nir wrote: >=20 >> Cert-lock (and CA-lock) are what EKR calls supplementary, while the othe= rs are the restrictive. While the sever (and domain owner) can't dictate cl= ient 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 cl= ient (relying party) may have a policy to ignore records that push a non-va= lid 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 contai= ner for a public key, not something you can chain and validate. >>=20 >> So I think the requirements document should describe EKR's use cases, an= d require that the TLSA record be able to differentiate between records tha= t are appropriate for the two use cases. >=20 > Are you really suggesting some kind of indicator that says "you can ignor= e the cruft from the cert that is bogus > 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 pu= blic key.= From paul@xelerance.com Fri Apr 1 00:27:32 2011 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6815C3A6BEC for ; Fri, 1 Apr 2011 00:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDE9-YcJMJCP for ; Fri, 1 Apr 2011 00:27:31 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 96F9E3A6BD7 for ; Fri, 1 Apr 2011 00:27:31 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 2E9A6C5A0; Fri, 1 Apr 2011 03:29:11 -0400 (EDT) Date: Fri, 1 Apr 2011 03:29:10 -0400 (EDT) From: Paul Wouters To: Yoav Nir In-Reply-To: <97668833-DC1B-4371-85F5-60ABBE8CA2F2@checkpoint.com> Message-ID: References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> <7629D2C2-16DC-4ED8-B1AE-14900891448B@checkpoint.com> <97668833-DC1B-4371-85F5-60ABBE8CA2F2@checkpoint.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org 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: Fri, 01 Apr 2011 07:27:32 -0000 On Fri, 1 Apr 2011, Yoav Nir wrote: >>> 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"? > > 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 ietf@augustcellars.com Fri Apr 1 01:14:31 2011 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 813B23A6AF8 for ; Fri, 1 Apr 2011 01:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQkaYOT0DiAw for ; Fri, 1 Apr 2011 01:14:30 -0700 (PDT) Received: from new-smtp02.pacifier.net (new-smtp02.pacifier.net [64.255.237.176]) by core3.amsl.com (Postfix) with ESMTP id 629E828C104 for ; Fri, 1 Apr 2011 01:14:30 -0700 (PDT) Received: from TITUS (dhcp-168b.meeting.ietf.org [130.129.22.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by new-smtp02.pacifier.net (Postfix) with ESMTPSA id 133AE2CA02; Fri, 1 Apr 2011 01:16:09 -0700 (PDT) From: "Jim Schaad" To: "'Eric Rescorla'" , "'Richard L. Barnes'" References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> In-Reply-To: Date: Fri, 1 Apr 2011 10:15:51 +0200 Message-ID: <003601cbf045$05a10740$10e315c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMhc87ggVnYLx8lyDMlS27ZZ4x4/gIJtPsyAcxg//6RfvFC8A== Content-Language: en-us Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org 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: Fri, 01 Apr 2011 08:14:31 -0000 > -----Original Message----- > From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] = On > Behalf Of Eric Rescorla > Sent: Wednesday, March 30, 2011 2:28 PM > To: Richard L. Barnes > Cc: keyassure@ietf.org > Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models >=20 > On Wed, Mar 30, 2011 at 2:18 PM, Richard L. Barnes > wrote: > > I agree with Ekr and Steve that these are the right goals. =A0I = don't have any > further goals to add. =A0Just 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 >=20 > 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. >=20 > -Ekr >=20 > > 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 > >> keyassure@ietf.org > >> https://www.ietf.org/mailman/listinfo/keyassure > > > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure From rbarnes@bbn.com Fri Apr 1 06:09:22 2011 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7819E3A6850 for ; Fri, 1 Apr 2011 06:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yn+mJrhbJ7PL for ; Fri, 1 Apr 2011 06:09:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3C95C3A6838 for ; Fri, 1 Apr 2011 06:09:21 -0700 (PDT) Received: from [128.89.255.170] (port=59930 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q5e7w-000JpW-3W; Fri, 01 Apr 2011 09:11:00 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <05F78A16-9DC8-4412-9F18-8976928BE8C4@nzrs.net.nz> Date: Fri, 1 Apr 2011 15:10:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <169F9D88-5BAF-4772-BBA3-C3949872D72D@bbn.com> References: <4F5CBD0D-E9D4-4042-B082-B15D3D509A37@edvina.net> <57F0D906-4EF8-4628-AAE0-34C661A7184E@bbn.com> <3DCDB1C2-A372-43F0-A87A-AC97D1FEA8A8@bbn.com> <05F78A16-9DC8-4412-9F18-8976928BE8C4@nzrs.net.nz> To: Jay Daley X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] The draft and subj alt names X-BeenThere: keyassure@ietf.org 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: Fri, 01 Apr 2011 13:09:22 -0000 Let me phrase it differently. If you give DANE specific name matching = requirements, then you not only have to update the appropriate = application RFCs, you have to change all the corresponding code. If you = look at HTTPS libraries, for example:=20 -- Most of them will only check the cert against the domain name in the = HTTPS URI (with no user-configurability) -- Some can be configured to accept a list of names -- None that I'm aware of have a "don't check the name" option. =20 (Some of them don't ever check names, but they're non-compliant anyway.) This is not to mention that if you put a cert with the wrong domain name = in TLS, you're going to break non-DANE clients. =20 I don't think that all this trouble is worth the small optimization, and = (not to be a process weenie) I don't think that working at the = application layer is within the scope of this working group. --Richard On Apr 1, 2011, at 5:15 AM, Jay Daley wrote: > On 1/04/2011, at 3:06 PM, Richard L. Barnes wrote: >=20 >> The only choice that avoids updating several RFCs is 5. >=20 > Is that your only reason for not wanting to tackle this? Do you have = any view on the nature of trust that DNSSEC provides to applications or = not? >=20 >> Just leave it alone! >=20 > No. >=20 > warmest regards > Jay >=20 >> --Richard >>=20 >>=20 >> On Mar 31, 2011, at 10:41 PM, Jay Daley wrote: >>=20 >>> On 1/04/2011, at 12:12 AM, Richard L. Barnes wrote: >>>=20 >>>> As I've said in other threads, this WG should be silent on = requirements for certificate names, since different applications use TLS = certificate names in different ways. See for example the difference = between RFC 2818 and RFC 6125. The text you reference in the draft is = technically harmless ("must" not "MUST"), but should probably be deleted = anyway. >>>=20 >>> There are two separate issues here: >>> a) whether we think name matching is still needed with DANE >>> b) what the draft should say about that >>>=20 >>> On a) I would make the case that name matching is should not be done = because >>> - DNSSEC provides sufficient trust >>> - name matching forces certain operational decisions onto end user = (e.g. multiple certs, cert reuse) that are unreasonable >>>=20 >>> On b) There are six options for the draft: >>>=20 >>> 1. State that name matching must be done >>> 2. State that name matching must not be done >>> 3. Leave it to applications with a recommendation to match >>> 4. Leave it to applications with a recommendation not to match >>> 5. Leave it to applications with no recommendation >>> 6. Add a flag into TLSA that specifies whether name matching is to = be done or not >>>=20 >>> My choice, in order of preference would be 2, 6, 4. =20 >>>=20 >>> Jay >>>=20 >>>>=20 >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>> On Mar 31, 2011, at 12:05 PM, Olle E. Johansson wrote: >>>>=20 >>>>> I have read the draft and reacted to one thing. Sorry if this = already have been discussed on the list. >>>>>=20 >>>>> The draft -06 says >>>>> "The end entity certificate from TLS, regardless of whether it was >>>>> matched with a TLSA type 1 certificate or chained to a TLSA type 2 = CA >>>>> certificate, must have at least one identifier in the subject or >>>>> subjectAltName field of the matched certificates matches the = expected >>>>> identifier for the TLS server. " >>>>>=20 >>>>> The new RFC 6125 tells us that we should: >>>>> "Move toward including and checking even more specific >>>>> subjectAlternativeName extensions where appropriate for using the >>>>> protocol (e.g., uniformResourceIdentifier and the otherName form >>>>> SRVName)." >>>>>=20 >>>>> I feel we need to be more specific in the draft. What type of = subjectAltName should we match with? >>>>> dnsName? >>>>>=20 >>>>> And if we're using SIP, and have URI's in the certificate - should = that be part of this draft >>>>> or should we open for protocol-specific specifications for other = types of subject Alt Names? >>>>>=20 >>>>> /O >>>>> _______________________________________________ >>>>> keyassure mailing list >>>>> keyassure@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/keyassure >>>>=20 >>>> _______________________________________________ >>>> keyassure mailing list >>>> keyassure@ietf.org >>>> https://www.ietf.org/mailman/listinfo/keyassure >>>=20 >>>=20 >>> --=20 >>> Jay Daley >>> Chief Executive >>> .nz Registry Services (New Zealand Domain Name Registry Limited) >>> desk: +64 4 931 6977 >>> mobile: +64 21 678840 >>>=20 >>=20 >=20 >=20 > --=20 > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 >=20 From mrex@sap.com Fri Apr 1 06:55:13 2011 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28E673A681C for ; Fri, 1 Apr 2011 06:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.221 X-Spam-Level: X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vip1uJXsaP2Z for ; Fri, 1 Apr 2011 06:55:12 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 85FBB3A67FC for ; Fri, 1 Apr 2011 06:55:11 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p31DuRvp003620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Apr 2011 15:56:27 +0200 (MEST) From: Martin Rex Message-Id: <201104011356.p31DuRUK014555@fs4113.wdf.sap.corp> To: jay@nzrs.net.nz (Jay Daley) Date: Fri, 1 Apr 2011 15:56:27 +0200 (MEST) In-Reply-To: from "Jay Daley" at Apr 1, 11 09:41:24 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] The draft and subj alt names X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 13:55:13 -0000 Jay Daley wrote: > > 6. Add a flag into TLSA that specifies > whether name matching is to be done or not I think that (6.) would be the most sensible solution. Especially for self-signed X.509 certificates, it doesn't make sense to look at name attributes of the certificate at all, because these are all self-asserted attributes, not certified attributes. The only thing that really matters is the public key. Today's browsers show a very intimidating warning page when they receive a server cert that doesn't match their expectations. But once you have convinced your browser that you want to connect, and to make this decision persistent (cert pinning), then there are no more warnings on further connects about mismatches on name attributes of the certificate. TLSv1.2 1. Introduction, last sentence http://tools.ietf.org/html/rfc5246#page-5 the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS. HTTP over TLS, 3.1 Server Endpoint Indentification, 2nd paragraph http://tools.ietf.org/html/rfc2818#section-3.1 If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows the certificate that the server will present.) or the new RFC-6125 http://tools.ietf.org/html/rfc6125#page-8 o Keys or certificates employed outside the context of PKIX-based systems. Some deployed application technologies use a web of trust model based on or similar to OpenPGP [OPENPGP], or use self-signed certificates, or are deployed on networks that are not directly connected to the public Internet and therefore cannot depend on Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol [OCSP] to check CA-issued certificates. However, the method for binding a public key to an identifier in OpenPGP differs essentially from the method in X.509, the data in self- signed certificates has not been certified by a third party in any way, [...] -Martin From ondrej.sury@nic.cz Fri Apr 1 07:36:50 2011 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 838E73A6851 for ; Fri, 1 Apr 2011 07:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MQakqZ9-vgB for ; Fri, 1 Apr 2011 07:36:49 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 06E623A6850 for ; Fri, 1 Apr 2011 07:36:49 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 008B22A2ABB for ; Fri, 1 Apr 2011 16:38:28 +0200 (CEST) Message-ID: <4D95E363.4000304@nic.cz> Date: Fri, 01 Apr 2011 16:38:27 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Thunderbird/3.1.9 MIME-Version: 1.0 To: keyassure@ietf.org References: <201104011356.p31DuRUK014555@fs4113.wdf.sap.corp> In-Reply-To: <201104011356.p31DuRUK014555@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [keyassure] The draft and subj alt names X-BeenThere: keyassure@ietf.org 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: Fri, 01 Apr 2011 14:36:50 -0000 On 1.4.2011 15:56, Martin Rex wrote: > Jay Daley wrote: >> >> 6. Add a flag into TLSA that specifies >> whether name matching is to be done or not > > I think that (6.) would be the most sensible solution. This starts to look like overengineering. Let's not put too many ingreedients into one pot please. > Especially for self-signed X.509 certificates, it doesn't make sense > to look at name attributes of the certificate at all, because these > are all self-asserted attributes, not certified attributes. The > only thing that really matters is the public key. On the other hand it's not that hard to issue a self-signed CA issued cert which matches the domain name, isn't it? The other option would be use the bare keys (see Paul W. proposal in TLS WG). E.g. if you use X.509 do match, if you use bare key, don't match. > TLSv1.2 1. Introduction, last sentence > > http://tools.ietf.org/html/rfc5246#page-5 > > the decisions on how to initiate TLS > handshaking and how to interpret the authentication certificates > exchanged are left to the judgment of the designers and implementors > of protocols that run on top of TLS. > > HTTP over TLS, 3.1 Server Endpoint Indentification, 2nd paragraph > > http://tools.ietf.org/html/rfc2818#section-3.1 > > If the client has external information as to the expected identity of > the server, the hostname check MAY be omitted. (For instance, a > client may be connecting to a machine whose address and hostname are > dynamic but the client knows the certificate that the server will > present.) > > > or the new RFC-6125 > > http://tools.ietf.org/html/rfc6125#page-8 > > o Keys or certificates employed outside the context of PKIX-based > systems. > > Some deployed application technologies use a web of trust model > based on or similar to OpenPGP [OPENPGP], or use self-signed > certificates, or are deployed on networks that are not directly > connected to the public Internet and therefore cannot depend on > Certificate Revocation Lists (CRLs) or the Online Certificate > Status Protocol [OCSP] to check CA-issued certificates. However, > the method for binding a public key to an identifier in OpenPGP > differs essentially from the method in X.509, the data in self- > signed certificates has not been certified by a third party in any > way, [...] I think that those paragraphs are exactly the reason why the option "Leave it alone - it's up to the application" is most appropriate for the DANE WG. And there will be interest I think that it could be solved elsewhere or here as BCP RFC. O. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From jschmidt@jasadvisors.com Fri Apr 1 14:34:08 2011 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B46928C0D8 for ; Fri, 1 Apr 2011 14:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYZbVeZ68wAz for ; Fri, 1 Apr 2011 14:34:07 -0700 (PDT) Received: from relay-hub202.domainlocalhost.com (relay-hub202.domainlocalhost.com [74.115.204.52]) by core3.amsl.com (Postfix) with ESMTP id 76FC33A698E for ; Fri, 1 Apr 2011 14:34:07 -0700 (PDT) Received: from MBX202.domain.local ([169.254.2.125]) by HUB202.domain.local ([74.115.204.52]) with mapi id 14.01.0255.000; Fri, 1 Apr 2011 17:35:47 -0400 From: Jeff Schmidt To: Paul Wouters , Jay Daley Thread-Topic: [keyassure] The draft and subj alt names Thread-Index: AQHL74s8QmwRa1lb4kmHso/AEMV0KpRHjQYAgACe8QCAALMqgIAAmoaA Date: Fri, 1 Apr 2011 21:35:46 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [192.168.64.22] Content-Type: text/plain; charset="us-ascii" Content-ID: <47EE21DFBAB895409A293E7E95EA946F@domain.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] The draft and subj alt names X-BeenThere: keyassure@ietf.org 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: Fri, 01 Apr 2011 21:34:08 -0000 On 4/1/11 2:22 AM, "Paul Wouters" wrote: >The cert is just a legacy container for the public key. We should not be >adding policy >in DANE that entangles DANE with PKIX (or any other trust scheme) +1. Or have an easy way to unwind any such entanglements (i.e. make them optional). Jeff From Jeff.Hodges@KingsMountain.com Mon Apr 4 07:49:25 2011 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F5193A680A for ; Mon, 4 Apr 2011 07:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qppuL5ia7dfj for ; Mon, 4 Apr 2011 07:49:18 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id 8FF4C3A67F5 for ; Mon, 4 Apr 2011 07:49:18 -0700 (PDT) Received: (qmail 30755 invoked by uid 0); 4 Apr 2011 14:51:01 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy2.bluehost.com with SMTP; 4 Apr 2011 14:51:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=kj94Fj/28g/7ukp8p5L5lkLZyqGfeDqZskg1xicA9+pz5dRwbmWTZp9lE7d4VhNOeuR4GP6T9lzeQPlzmhdSlaHGX2EglY6wmxYXLapTegsCQbkQUiFZDbEJqazW9N6P; Received: from zcu-mobile-n410.zcu.cz ([147.228.185.154]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Q6l7M-0005O1-Rm for keyassure@ietf.org; Mon, 04 Apr 2011 08:51:01 -0600 Message-ID: <4D99DAD3.50205@KingsMountain.com> Date: Mon, 04 Apr 2011 07:50:59 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 147.228.185.154 authed with jeff.hodges+kingsmountain.com} Subject: Re: [keyassure] The draft and subj alt names X-BeenThere: keyassure@ietf.org 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: Mon, 04 Apr 2011 14:49:25 -0000 On Mar 31, 2011, at 12:05 PM, Olle E. Johansson wrote: > I have read the draft and reacted to one thing. Sorry if this already have been discussed on the list. > > The draft -06 says > "The end entity certificate from TLS, regardless of whether it was > matched with a TLSA type 1 certificate or chained to a TLSA type 2 CA > certificate, must have at least one identifier in the subject or > subjectAltName field of the matched certificates matches the expected > identifier for the TLS server. " > > The new RFC 6125 tells us that we should: > "Move toward including and checking even more specific > subjectAlternativeName extensions where appropriate for using the > protocol (e.g., uniformResourceIdentifier and the otherName form > SRVName)." > "Richard L. Barnes" replied on Thu, 31 Mar 2011 13:12:32 +0200.. > > As I've said in other threads, this WG should be silent on requirements for > certificate names, since different applications use TLS certificate names in > different ways. +1 to what Richard says. The RFC6125 (aka "TLS Server Identity Check") text quoted by Olle is a suggestion to _applications_ to move away from CN-ID and towards leveraging SubjectAlternativeName (SAN) name types in terms of the identifiers embedded in certs and checked against _at the app layer_ during TLS connection establishment. I think that Richard is correct that what the DANE WG is designing lies "below" the applications, and it is still their job to ascertain whether the name(s) embedded in the cert used to secure the connection meaningfully match the intended server. Please see sections 1 and 2 of RFC6125 for an in-depth discussion of the nuances. HTH, =JeffH