Re: Review of draft-saintandre-tls-server-id-check
Peter Saint-Andre <stpeter@stpeter.im> Thu, 09 September 2010 17:56 UTC
Return-Path: <stpeter@stpeter.im>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C372F3A6831; Thu, 9 Sep 2010 10:56:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.569
X-Spam-Level:
X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 RSBp28bopKHQ; Thu, 9 Sep 2010 10:56:41 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9A7833A680C; Thu, 9 Sep 2010 10:56:41 -0700 (PDT)
Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BCC5040074; Thu, 9 Sep 2010 12:00:52 -0600 (MDT)
Message-ID: <4C891FF3.8070607@stpeter.im>
Date: Thu, 09 Sep 2010 11:57:07 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7
MIME-Version: 1.0
To: Stefan Santesson <stefan@aaa-sec.com>
Subject: Re: Review of draft-saintandre-tls-server-id-check
References: <C8ADEB52.EBBB%stefan@aaa-sec.com>
In-Reply-To: <C8ADEB52.EBBB%stefan@aaa-sec.com>
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: Bernard Aboba <bernard_aboba@hotmail.com>, IETF cert-based identity <certid@ietf.org>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Sep 2010 17:56:49 -0000
On 9/8/10 5:39 PM, Stefan Santesson wrote: > Peter, > > Thank for the clarifying example. I see now what problem you are addressing. > > Comments in line; I'm short on time right now so will reply briefly at the end. > On 10-09-09 12:35 AM, "Peter Saint-Andre" <stpeter@stpeter.im> wrote: > > <stuff deleted> > >>> It is not. RFC 4985 says the following in section 2: >>> >>> _Service.Name >>> >>> <snip> >>> >>> Name >>> The DNS domain name of the domain where the specified service >>> is located. >> >> Perhaps some examples would help. >> >> The good folks at example.com have delegated their IM service to >> apps.hosting.net. When the user someone@example.com does an SRV lookup >> for _xmpp-client._tcp im.example.com, its client gets back something >> like this: >> >> 20 0 5222 apps.hosting.net. >> >> The client resolves apps.hosting.net to an IP address and connects to >> that machine. >> >> During TLS negotiation, the application service for example.com (which >> is in fact being serviced by apps.hosting.net) presents a certificate >> that contains an SRV-ID. Which of the following is it? >> >> 1. _xmpp.example.com >> >> or: >> >> 2. _xmpp.apps.hosting.net >> > > According to the actual intent of RFC 4985 the right answer is 1, however > reading the definition of the name form it suggests 2, since this is where > the service is located. However I think this is an error in RFC 4985. See > below. > > In case of 2, If the DNS fooled you, then you may end up at an authorized > service for hosting.net that has no business serving example.com, and you > have no way to tell. > > >> If #1, then the "Name" in _Service.Name is indeed a "Name" as defined in >> RFC 2782. >> >> If #2, then the "Name" in _Service.Name is actually a "Target" as >> defined in RFC 2782. >> > > >>> The client now has assurance from the CA that this host is in fact >>> authorized to provide this service. >> >> To use my example, the CA is providing assurance that apps.hosting.net >> is authorized to provide the XMPP service on behalf of example.com. That >> seems reasonable if the presented identifier based on the source domain >> (example.com) However, if the assurance is checked on the client side >> by finding _xmpp.apps.hosting.net as the presented identifier then I >> fail to understand something very basic: how does the client tie that >> SRV-ID to the source domain (example.com) in a secure fashion? The >> presented identifier seems to be a mere assertion without any connection >> whatsoever to the source domain. > > I actually think we made an error in 4985 and that the domain name should be > the domain that the service is authorized to represent. > > RFC 4985 is ambiguous here: the definition of the name form says: > > "The DNS domain name of the domain where the specified service > is located." > > This corresponds to #2 in your example > While the description underneath the definition states: > > "The purpose of the SRVName is limited to authorization of service > provision within a domain." > > Which corresponds to #1. > > I think there should be an errata correcting the definition to be: > > "The DNS domain name of a domain for which the certified subject > is authorized to provide the identified service." > > As it is now, the RFC is ambiguous. > >> If we just wave our hands and say "the >> client can simply let the user believe that it's OK for apps.hosting.net >> to assert a right to provide the IM service for example.com and it >> doesn't matter if there is no basis for that belief because the >> information might not be trustworthy" then I wonder what RFC 4985 really >> accomplishes or whether we want to encourage anyone to use the SRVName >> extension (at least absent DNSSEC, see for example draft-barnes-xmpp-dna). >> > > I agree. But if we can correct the definition (or specify a new OID for a > corrected name form) according to my proposal above, and clarify the use in > your document, would that help in any way? > > I agree that if the SRVName in the cert provides a domain name that is > different from the domain name you asked for (and it's not DNSSEC), then you > will have to rely on local configuration in order to accept it. I'm happy that we're all on the same page and that we only have a spec error in RFC 4985. > I'm not sure how we should fix this. We had quite large review of this RFC > but nobody caught this error. Submitting an erratum is a good first step, I think. Peter -- Peter Saint-Andre https://stpeter.im/
- Review of draft-saintandre-tls-server-id-check Bernard Aboba
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- RE: Review of draft-saintandre-tls-server-id-check Bernard Aboba
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check =JeffH
- Re: Review of draft-saintandre-tls-server-id-check t.petch
- RE: Review of draft-saintandre-tls-server-id-check Bernard Aboba
- Re: [xmpp] Review of draft-saintandre-tls-server-… Bernard Aboba
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check t.petch
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- RE: Review of draft-saintandre-tls-server-id-check Bernard Aboba
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Shumon Huque
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- RE: Review of draft-saintandre-tls-server-id-check Bernard Aboba
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Shumon Huque
- Re: Review of draft-saintandre-tls-server-id-check Shumon Huque
- Re: [certid] Review of draft-saintandre-tls-serve… Shumon Huque
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: [certid] Review of draft-saintandre-tls-serve… Shumon Huque
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Martin Rex
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Paul Hoffman
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check Shumon Huque
- Re: [certid] Review of draft-saintandre-tls-serve… Richard L. Barnes
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Shumon Huque
- Re: Review of draft-saintandre-tls-server-id-check Dave Cridland
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Dave Cridland
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check Dave Cridland
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check Dave Cridland
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check Dave Cridland
- Re: [certid] Review of draft-saintandre-tls-serve… Shumon Huque
- Re: [certid] Review of draft-saintandre-tls-serve… Dave Cridland
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check t.petch
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Why require EKU for certid? Paul Hoffman
- Re: Why require EKU for certid? Peter Saint-Andre
- Re: [certid] Why require EKU for certid? Martin Rex
- RE: [TLS] Why require EKU for certid? Jim Schaad
- Re: [certid] Why require EKU for certid? Henry B. Hotz