From stefan.winter@restena.lu Mon Aug 2 02:39:28 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6E733A695B for ; Mon, 2 Aug 2010 02:39:28 -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 hXExmzYajClJ for ; Mon, 2 Aug 2010 02:39:25 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by core3.amsl.com (Postfix) with ESMTP id F0E483A6824 for ; Mon, 2 Aug 2010 02:39:24 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 6CD1F10584 for ; Mon, 2 Aug 2010 11:39:50 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 43D2E10582 for ; Mon, 2 Aug 2010 11:39:50 +0200 (CEST) Message-ID: <4C569260.7070602@restena.lu> Date: Mon, 02 Aug 2010 11:39:44 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.11) Gecko/20100714 SUSE/3.0.6 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: certid@ietf.org References: <20100715230822.5B1583A6B94@core3.amsl.com> <4C49B477.80700@stpeter.im> <20100730034415.GA28022@isc.upenn.edu> <4C5267FF.2090701@edelweb.fr> <20100730162031.GA15319@isc.upenn.edu> In-Reply-To: <20100730162031.GA15319@isc.upenn.edu> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFF0EBD6CEBB6B22346A16ECD" X-Virus-Scanned: ClamAV Subject: Re: [certid] Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 09:39:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFF0EBD6CEBB6B22346A16ECD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Well that, and SRVName. There are many other custom types > defined by specific applications but those aren't the focus > of this document. > =20 a closely related question to that. In one of my drafts, SRVNames are used, but not directly. There is a S-NAPTR based algorithm which first tries to find a specific S-NAPTR, and then follows the results from there (typically, via SRVName to hostname to IP addresses). If there is no S-NAPTR, a SRV query is tried. In the latter case, matching between the SRV record in DNS vs. SAN-SRVName can be done, and the server id can be verified. But in the former case, if S-NAPTR in DNS is forged, it is well possible to drive the querying peer to a bogus SRV record, and an attacker can have a (unrelated) certificate for this other SRVName. That was, the querying host can be tricked into initiating a connection to a false peer because it cannot verify that the NAPTR -> SRV step was correct. I've been thinking about a workaround for that. As much as I know, there is no subjectAltName for NAPTR verification. So my only conclusion so far is: using NAPTR can only work securely if requiring DNSSEC; so that the NAPTR can't possibly be forged. I wonder: is there another way of securing server discovery in the presence of a NAPTR -> SRV redirection? And do you consider disususing this issue in your draft? Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigFF0EBD6CEBB6B22346A16ECD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxWkmYACgkQ+jm90f8eFWZy/wCfWH5mTlicvQolknmE6RCRFQ0d 9mMAn2gGWvzvjrDi6aqT0WEDm4X+SUvZ =pNVe -----END PGP SIGNATURE----- --------------enigFF0EBD6CEBB6B22346A16ECD-- From stpeter@stpeter.im Mon Aug 2 08:12:07 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0E23A685B for ; Mon, 2 Aug 2010 08:12:07 -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 ZEn+xN0PiJoP for ; Mon, 2 Aug 2010 08:12:02 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id DC2CE3A6BA3 for ; Mon, 2 Aug 2010 08:11:56 -0700 (PDT) Received: from squire.local (rtp-isp-nat1.cisco.com [64.102.254.33]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1BCC940074; Mon, 2 Aug 2010 09:12:41 -0600 (MDT) Message-ID: <4C56E056.8070808@stpeter.im> Date: Mon, 02 Aug 2010 17:12:22 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <4C3BB2C5.9030106@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] Sorting the reference identifiers X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 15:12:07 -0000 On 7/13/10 3:34 AM, Paul Hoffman wrote: > Thank you for the -08 update; it looks very good. It clears up a > bunch of the comments I was about to make. :-) I still have one > leftover question. The middle of Section 4.2 says: The client then > orders the list in accordance with the following rules: Then, in 4.3, > it checks each reference in this ordered list until it (hopefully) > finds a match. Given that it is going to do an exhaustive search, > what is the purpose of ordering? Jeff and I talked about this in Maastricht and we agreed to remove the text about ordering. That change will be in the next version, which we plan to submit by the end of the week (we're still working to settle a few more issues first). Peter -- Peter Saint-Andre https://stpeter.im/ From shuque@isc.upenn.edu Tue Aug 3 19:57:26 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A8613A6B8E for ; Tue, 3 Aug 2010 19:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.029 X-Spam-Level: X-Spam-Status: No, score=-4.029 tagged_above=-999 required=5 tests=[AWL=-1.430, 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 dcBzGEmvtft3 for ; Tue, 3 Aug 2010 19:57:25 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 324623A67B8 for ; Tue, 3 Aug 2010 19:57:25 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 1B93A2481; Tue, 3 Aug 2010 22:57:54 -0400 (EDT) Date: Tue, 3 Aug 2010 22:57:54 -0400 From: Shumon Huque To: Stefan Winter Message-ID: <20100804025753.GA16078@isc.upenn.edu> References: <20100715230822.5B1583A6B94@core3.amsl.com> <4C49B477.80700@stpeter.im> <20100730034415.GA28022@isc.upenn.edu> <4C5267FF.2090701@edelweb.fr> <20100730162031.GA15319@isc.upenn.edu> <4C569260.7070602@restena.lu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C569260.7070602@restena.lu> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: certid@ietf.org Subject: Re: [certid] Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 02:57:26 -0000 On Mon, Aug 02, 2010 at 11:39:44AM +0200, Stefan Winter wrote: > Hi, > > > Well that, and SRVName. There are many other custom types > > defined by specific applications but those aren't the focus > > of this document. > > > > a closely related question to that. In one of my drafts, SRVNames are > used, but not directly. > > There is a S-NAPTR based algorithm which first tries to find a specific > S-NAPTR, and then follows the results from there (typically, via SRVName > to hostname to IP addresses). > If there is no S-NAPTR, a SRV query is tried. > > In the latter case, matching between the SRV record in DNS vs. > SAN-SRVName can be done, and the server id can be verified. > But in the former case, if S-NAPTR in DNS is forged, it is well possible > to drive the querying peer to a bogus SRV record, and an attacker can > have a (unrelated) certificate for this other SRVName. That was, the > querying host can be tricked into initiating a connection to a false > peer because it cannot verify that the NAPTR -> SRV step was correct. > > I've been thinking about a workaround for that. As much as I know, there > is no subjectAltName for NAPTR verification. So my only conclusion so > far is: using NAPTR can only work securely if requiring DNSSEC; so that > the NAPTR can't possibly be forged. Stefan, Yes, I think I agree with your analysis. And even if there were a subjectaltname for NAPTR services, it appears that the components of the (service specific) identity you want to verify are in the RDATA of the NAPTR record, rather than the owner name of the record, so you need to secure the DNS mapping. > I wonder: is there another way of securing server discovery in the > presence of a NAPTR -> SRV redirection? Besides DNSSEC, or some other secure mapping service, I can't think of an obvious one. You'd need to figure out how to encode the service identity in the DNS query name, which is precisely the thing the S-NAPTR lookup is trying to find. > > And do you consider disususing this issue in your draft? > Are you proposing to just discuss this issue, or that we should try to find a solution to the problem? -- Shumon Huque University of Pennsylvania. From stefan.winter@restena.lu Tue Aug 3 22:46:14 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464EA3A6BD1 for ; Tue, 3 Aug 2010 22:46:14 -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 A3UgKykUA4Um for ; Tue, 3 Aug 2010 22:46:12 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E0233A6817 for ; Tue, 3 Aug 2010 22:46:12 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id BD64110586; Wed, 4 Aug 2010 07:46:39 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id A436D10584; Wed, 4 Aug 2010 07:46:39 +0200 (CEST) Message-ID: <4C58FEBF.3080807@restena.lu> Date: Wed, 04 Aug 2010 07:46:39 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.11) Gecko/20100714 SUSE/3.0.6 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: Shumon Huque References: <20100715230822.5B1583A6B94@core3.amsl.com> <4C49B477.80700@stpeter.im> <20100730034415.GA28022@isc.upenn.edu> <4C5267FF.2090701@edelweb.fr> <20100730162031.GA15319@isc.upenn.edu> <4C569260.7070602@restena.lu> <20100804025753.GA16078@isc.upenn.edu> In-Reply-To: <20100804025753.GA16078@isc.upenn.edu> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1FA2C475575787C38D9C9E5C" X-Virus-Scanned: ClamAV Cc: certid@ietf.org Subject: Re: [certid] Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 05:46:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1FA2C475575787C38D9C9E5C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Besides DNSSEC, or some other secure mapping service, I can't think=20 > of an obvious one. You'd need to figure out how to encode the service=20 > identity in the DNS query name, which is precisely the thing the=20 > S-NAPTR lookup is trying to find. > =20 Thanks for giving this some thought! >> And do you consider disususing this issue in your draft? >> >> =20 > Are you proposing to just discuss this issue, or that we should > try to find a solution to the problem? > =20 I wouldn't mind if you try to solve it, of course :-) But since there is apparently no trivial "fix" to server id validation, I'd be just as happy with a simple paragraph stating that validation of (S-)NAPTR-derived identities doesn't work in a trusted manner without DNSSEC. (But that's just me, since I don't mind prescribing DNSSEC in my draft; but my working group chair already expressed that he'd prefer something else) Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig1FA2C475575787C38D9C9E5C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxY/r8ACgkQ+jm90f8eFWZiDACfVb/jYzS9Q7VSRrxQ13JPzCNE crMAoIvT00Ea7PjAFqkdGZ0u+AJ9dX0r =k67x -----END PGP SIGNATURE----- --------------enig1FA2C475575787C38D9C9E5C-- From stpeter@stpeter.im Thu Aug 5 13:10:39 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9A13A6998 for ; Thu, 5 Aug 2010 13:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 rN8CBK8puYcs for ; Thu, 5 Aug 2010 13:10:30 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B9C053A69E5 for ; Thu, 5 Aug 2010 13:10:30 -0700 (PDT) Received: from squire.local (ip-216-17-182-116.rev.frii.com [216.17.182.116]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6A85540074; Thu, 5 Aug 2010 14:11:36 -0600 (MDT) Message-ID: <4C5B1AD3.2050204@stpeter.im> Date: Thu, 05 Aug 2010 14:10:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Stefan Winter References: <20100715230822.5B1583A6B94@core3.amsl.com> <4C49B477.80700@stpeter.im> <20100730034415.GA28022@isc.upenn.edu> <4C5267FF.2090701@edelweb.fr> <20100730162031.GA15319@isc.upenn.edu> <4C569260.7070602@restena.lu> <20100804025753.GA16078@isc.upenn.edu> <4C58FEBF.3080807@restena.lu> In-Reply-To: <4C58FEBF.3080807@restena.lu> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 20:10:40 -0000 On 8/3/10 11:46 PM, Stefan Winter wrote: > Hi, > >> Besides DNSSEC, or some other secure mapping service, I can't think >> of an obvious one. You'd need to figure out how to encode the service >> identity in the DNS query name, which is precisely the thing the >> S-NAPTR lookup is trying to find. >> > > Thanks for giving this some thought! > >>> And do you consider disususing this issue in your draft? >>> >>> >> Are you proposing to just discuss this issue, or that we should >> try to find a solution to the problem? >> > > I wouldn't mind if you try to solve it, of course :-) But since there is > apparently no trivial "fix" to server id validation, I'd be just as > happy with a simple paragraph stating that validation of > (S-)NAPTR-derived identities doesn't work in a trusted manner without > DNSSEC. > > (But that's just me, since I don't mind prescribing DNSSEC in my draft; > but my working group chair already expressed that he'd prefer something > else) I've added a note about this to our working copy (Jeff and I are working to push out -09 today). Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Aug 5 13:58:25 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D31DE3A6959 for ; Thu, 5 Aug 2010 13:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 sMT88NoNKDBG for ; Thu, 5 Aug 2010 13:58:24 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C69C63A67A4 for ; Thu, 5 Aug 2010 13:58:24 -0700 (PDT) Received: from squire.local (ip-216-17-182-116.rev.frii.com [216.17.182.116]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8FD8640074; Thu, 5 Aug 2010 14:59:30 -0600 (MDT) Message-ID: <4C5B2605.2070309@stpeter.im> Date: Thu, 05 Aug 2010 14:58:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Shumon Huque References: <4C43E3B9.6040004@velox.ch> <201007191657.o6JGvoFU011620@fs4113.wdf.sap.corp> <20100720041307.GA5313@isc.upenn.edu> In-Reply-To: <20100720041307.GA5313@isc.upenn.edu> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org, Kaspar Brand Subject: Re: [certid] Need to define "most specific RDN" X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 20:58:25 -0000 On 7/19/10 10:13 PM, Shumon Huque wrote: > On Mon, Jul 19, 2010 at 06:57:50PM +0200, Martin Rex wrote: >> [...] >> But frankly, I do no see much value in trying to describe all possible >> interpretation of a fairly vague wording, that itself was an attempt >> to characterize, NOT specify, what kind of behaviour there is in the >> installed base. Leaving the vague description of rfc-2818 as is, >> and pointing out more prominently that it is really deprecated >> should be perfectly sufficient. >> >> -Martin > > I'm in full agreement. I think this spec tries to further deprecate the "most specific" wording from RFC 2818, but I've tried to amplify upon that in the implementation note from Section 2.3, as follows: ... various specifications refer to the order of RDNs using terminology that is not directly related to the information hierarchy, such as "most specific" vs. "least specific", "left- most" vs. "right-most", "first" vs. "last", or "most significant" vs. "least significant" (see for example [LDAP-DN]). To reduce confusion, in this specification we avoid such terms and instead use the terms provided under Section 1.4; in particular, we do not use the term "(most specific) Common Name field in the Subject field" from [HTTP-TLS] and instead state that a CN-ID is a Relative Distinguished Name (RDN) in the certificate subject that contains one and only one attribute-type-and-value pair of type Common Name (thus removing the possibility that an RDN might contain multiple AVAs of type CN, one of which would be considered "most specific"). /psa From stpeter@stpeter.im Thu Aug 5 14:02:43 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579373A6A08 for ; Thu, 5 Aug 2010 14:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 wh3Zi0k3JA5i for ; Thu, 5 Aug 2010 14:02:42 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7CEE73A69E5 for ; Thu, 5 Aug 2010 14:02:42 -0700 (PDT) Received: from squire.local (ip-216-17-182-116.rev.frii.com [216.17.182.116]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BAF9140074; Thu, 5 Aug 2010 15:03:48 -0600 (MDT) Message-ID: <4C5B2710.6030202@stpeter.im> Date: Thu, 05 Aug 2010 15:03:12 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: mrex@sap.com References: <201007191612.o6JGCEnr008883@fs4113.wdf.sap.corp> In-Reply-To: <201007191612.o6JGCEnr008883@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] Need to define "most specific RDN" X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 21:02:43 -0000 On 7/19/10 10:12 AM, Martin Rex wrote: > One thing that I find particularly irritating in -08 is that > it completely ignores a much more secure authentication > scheme for servers, by clients knowing the entire subject DName > of a certificate rather than matching only a single > name component. Good point. To make these (and other) matters clearer, I have written a new section on the applicability of this document: *** 1.2. Applicability This document does not supersede the rules for certificate validation provided in [PKIX]; specifically, in order to ensure proper authenticationm application clients need to verify the entire certification path (this document addresses only the DNS domain name of the application service itself, not the entire trust chain). This document also does not supersede the rules for verifying server identity provided in existing application protocol specifications, such as those mentioned under Appendix A. However, it is the intent of the authors that the best current practices described here can be referenced by future specifications. It is also expected that this document will be updated or obsoleted in the future as best practices for issuance and verification of PKIX certificates continue to evolve through more widespread implementation and deployment of TLS- protected application services over the Internet. *** /psa From stpeter@stpeter.im Sat Aug 7 04:40:10 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1738E3A67EB for ; Sat, 7 Aug 2010 04:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 I2uOM4QaSR87 for ; Sat, 7 Aug 2010 04:40:05 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A40143A6910 for ; Sat, 7 Aug 2010 04:40:05 -0700 (PDT) Received: from squire.local (dsl-228-99.dynamic-dsl.frii.net [216.17.228.99]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BD5EC40074 for ; Sat, 7 Aug 2010 05:41:21 -0600 (MDT) Message-ID: <4C5D462A.1040203@stpeter.im> Date: Sat, 07 Aug 2010 05:40:26 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: IETF cert-based identity X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/mixed; boundary="------------040006060803070604070001" Subject: [certid] Fwd: I-D Action:draft-saintandre-tls-server-id-check-09.txt X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2010 11:40:10 -0000 This is a multi-part message in MIME format. --------------040006060803070604070001 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit FYI. A diff from -08 is here: http://tools.ietf.org/rfcdiff?url2=draft-saintandre-tls-server-id-check-09.txt -------- Original Message -------- Subject: I-D Action:draft-saintandre-tls-server-id-check-09.txt Date: Fri, 6 Aug 2010 18:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security Author(s) : P. Saint-Andre, J. Hodges Filename : draft-saintandre-tls-server-id-check-09.txt Pages : 41 Date : 2010-08-06 Many application technologies enable a secure connection between two entities using certificates in the context of Transport Layer Security (TLS). This document specifies best current practices for representing and verifying the identity of application services in such interactions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-09.txt --------------040006060803070604070001 Content-Type: Message/External-body; name="draft-saintandre-tls-server-id-check-09.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-saintandre-tls-server-id-check-09.txt" Content-Type: text/plain Content-ID: <2010-08-06183346.I-D@ietf.org> --------------040006060803070604070001 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSS1ELUFu bm91bmNlIG1haWxpbmcgbGlzdApJLUQtQW5ub3VuY2VAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UKSW50ZXJuZXQtRHJhZnQg ZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwKb3IgZnRwOi8v ZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQKCg== --------------040006060803070604070001-- From paul.hoffman@vpnc.org Sat Aug 7 07:38:36 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3E4E3A69AC for ; Sat, 7 Aug 2010 07:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.69 X-Spam-Level: X-Spam-Status: No, score=-99.69 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, 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 dMo3t2alXXQl for ; Sat, 7 Aug 2010 07:38:34 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 983FF3A698D for ; Sat, 7 Aug 2010 07:38:34 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o77Ed3nc010687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Aug 2010 07:39:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C5D462A.1040203@stpeter.im> References: <4C5D462A.1040203@stpeter.im> Date: Sat, 7 Aug 2010 07:39:03 -0700 To: Peter Saint-Andre , IETF cert-based identity From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [certid] Fwd: I-D Action:draft-saintandre-tls-server-id-check-09.txt X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2010 14:38:36 -0000 Excellent set of changes! This is looking much more solid and internally consistent than it did a few months ago. --Paul Hoffman, Director --VPN Consortium From Jeff.Hodges@KingsMountain.com Wed Aug 18 16:09:04 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6C93A677D for ; Wed, 18 Aug 2010 16:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.956 X-Spam-Level: X-Spam-Status: No, score=-101.956 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_23=0.6, 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 C2iMuLBFmSsW for ; Wed, 18 Aug 2010 16:09:02 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 5614E3A67F3 for ; Wed, 18 Aug 2010 16:09:02 -0700 (PDT) Received: (qmail 1625 invoked by uid 0); 18 Aug 2010 23:09:36 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 18 Aug 2010 23:09:36 -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:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=oM9RRC6VXKjsiDjwMkVkBCS3HntZrqw4PwPUwWuMntsX9uqF9qrApwtcsT4QnHSmEfXDeX14LnTeWZ1THG3M8078oBmsLesDlLaoBpzgJi1Se2VFbVlm9UyH8jC4E2SZ; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.49.165]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OlrlI-0000xE-Cf; Wed, 18 Aug 2010 17:09:36 -0600 Message-ID: <4C6C6830.9040103@KingsMountain.com> Date: Wed, 18 Aug 2010 16:09:36 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity , IRTF PKng WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: ondrej.sury@nic.cz Subject: [certid] fyi: keyassure@ mailing list - aka tls@dnssec, certs/keys-in-DNS(sec), DKI X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 23:09:04 -0000 Of possible interest... A new pre-BoF list (keyassure@ietf.org, see below) is discussing=20 certs/keys-in-DNS(sec) both as a way to augment present-day PKI, and as a= way=20 to re-invent it. In addition to the various references helpfully listed below by Ondrej, t= here's=20 this recent preso by Dan Kaminsky, presented a couple weeks ago at Black = Hat... Black Ops of Fundamental Defense: Introducing the Domain Key Infrastructure (DKI) http://www.recursion.com/files/BlackOps-2010.pdf =3DJeffH ------ Subject: [keyassure] You want to read this :) (Was: Welcome to the mailin= g list, and possible charter.) From: ondrej.sury@nic.cz Date: Wed, 18 Aug 2010 09:50:29 +0200 To: keyassure@ietf.org (text/plain) Just to add some reading material to the mailing list archive... You may want to read: New I-D by Jakob, Paul, Warren and Adam: http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-0= 0.txt Slightly older CERT RR (which we already have): http://tools.ietf.org/html/rfc4398 And various older proposals which didn't make it: (Jakob's) http://stupid.domain.name/ietf/draft-schlyter-pkix-dns-02.txt (RR TYPE request I did) http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg00421.htm= l This is just to summarize the ideas which were floating around for some time. The basis on our work will be in the most recent I-D. On 17.8.2010 19:21, Warren Kumari wrote: > Hello all, > > We are investigating starting a working group to leverage the DNSSEC > trust anchor as a trust anchor for various other protocols. We are > initially focusing on TLS, but are also interested in other > protocols. > > Just so that we are all level set, here is our initial (draft) > problem statement. > > Problem Statement: > > The DNS Security Extensions are a collection of resource records and > protocol modifications that provide source authentication for the > DNS. > > The DNSSEC signed root infrastructure provides a single, well > published trust-anchor and a method to build a chain of trust from an > individual resource record (RR) to that TA. By leveraging this > infrastructure we can securely bind information (such as a public > key, certificate identifier, etc) to a DNS name. > > Increasingly people would like to be able to take advantage of the > confidentiality and identity validation provided by protocols such as > TLS. There are numerous barriers to this, including cost, ease of > use, complexity, certificate management, etc. By allowing users to > securely publish public key information we can allow users to easily > and securely make use of self-signed certificates. > > Currently, one of the issues limiting the use of self-signed > certificates is the difficulty in key-distribution - it is infeasible > to distribute a key binding at the web scale. By providing a means to > publish (and securely validate) this information in the DNS, we allow > for users to attest to the validity of keying information and > establish trust in the published public key. > > The DNSSEC root trust anchor can also be used for additional > validation during the current path validations. By validating that > the certificate presented is the certificate identified by the DNS, > we can provide additional confidence that the client is connecting to > the intended server - this helps alleviate concerns that a valid > certificate has been obtained by an attacker (for example from a CA > not used by the victim). --=20 Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- _______________________________________________ keyassure mailing list keyassure@ietf.org https://www.ietf.org/mailman/listinfo/keyassure From paul.hoffman@vpnc.org Tue Aug 24 17:54:18 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6BF03A6958 for ; Tue, 24 Aug 2010 17:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[AWL=0.998, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 Itim-fwbTKPR for ; Tue, 24 Aug 2010 17:54:17 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id B7E213A6948 for ; Tue, 24 Aug 2010 17:54:17 -0700 (PDT) Received: from [75.101.18.87] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o7P0snqN070923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Aug 2010 17:54:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 24 Aug 2010 17:54:43 -0700 To: certid@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [certid] Fwd: Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 00:54:18 -0000 >From the ietf-general list: >From: Bernard Aboba >To: , >Subject: Review of draft-saintandre-tls-server-id-check >Date: Tue, 24 Aug 2010 17:38:30 -0700 > >I reviewed draft-saintandre-tls-server-id-check. > >In a number of instances, this document is vague on the verification of an SRV-ID, and in one instance, it appears to contradict RFC 4985, even though it does not update that document. > >Section 2.1 states: > > o An SRV-ID can be either direct (provided by a user) or more > typically indirect (resolved by a client) and is restricted (can > be used for only a single application). > >This is consistent with RFC 4985 Section 2.1 which states: > > The SRVName, if present, MUST contain a service name and a domain > name in the following form: > > _Service.Name > >Yet, Section 5.1 states: > >When the connecting application is an interactive client, the source >domain name and service type MUST be provided by a human user (e.g. >when specifying the server portion of the user's account name on the >server or when explicitly configuring the client to connect to a >particular host or URI as in [SIP-LOC]) and MUST NOT be derived from >the user inputs in an automated fashion (e.g., a host name or domain >name discovered through DNS resolution of the source domain). This >rule is important because only a match between the user inputs (in >the form of a reference identifier) and a presented identifier >enables the client to be sure that the certificate can legitimately >be used to secure the connection. > >However, an interactive client MAY provide a configuration setting >that enables a human user to explicitly specify a particular host >name or domain name (called a "target domain") to be checked for >connection purposes. > >[BA] As I understand RFC 4985, the SRV-ID provided in the target certificate is to be >matched against components (service name and domain name) of the SRV RR obtained >via lookup within the source domain. As a result, I don't believe that RFC 4985 is >consistent with this advice (e.g. the reference identifier is not matched against the >SRV-ID). > >Section 4.1 is not as clear as it could be on this point, given that it talks about both >matching of the source domain and the target domain: > > 4. When checking a reference identifier against a presented > identifier, the client (a) MUST match the source domain (or, in > some cases, target domain) of the identifiers and (b) MAY also > match the service type of the identifiers. > > Implementation Note: Naturally, in addition to checking > identifiers, a client might complete further checks to ensure that > the server is authorized to provide the requested service. > However, such checking is not a matter of verifying the > application service identity presented in a certificate, and > therefore methods for doing so (e.g., consulting local policy > information) are out of scope for this document.