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/