Re: Review of draft-saintandre-tls-server-id-check

Stefan Santesson <stefan@aaa-sec.com> Wed, 08 September 2010 21:08 UTC

Return-Path: <stefan@aaa-sec.com>
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 0C5163A696A for <ietf@core3.amsl.com>; Wed, 8 Sep 2010 14:08:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.387
X-Spam-Level:
X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.862, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 cHwaMP3pW6Dc for <ietf@core3.amsl.com>; Wed, 8 Sep 2010 14:08:06 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.115]) by core3.amsl.com (Postfix) with ESMTP id 15B793A6978 for <ietf@ietf.org>; Wed, 8 Sep 2010 14:08:05 -0700 (PDT)
Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 8EB763CCE4F for <ietf@ietf.org>; Wed, 8 Sep 2010 23:08:39 +0200 (CEST)
Received: (qmail 3440 invoked from network); 8 Sep 2010 21:08:34 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.5]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <shuque@isc.upenn.edu>; 8 Sep 2010 21:08:34 -0000
User-Agent: Microsoft-Entourage/12.26.0.100708
Date: Wed, 08 Sep 2010 23:08:29 +0200
Subject: Re: Review of draft-saintandre-tls-server-id-check
From: Stefan Santesson <stefan@aaa-sec.com>
To: Shumon Huque <shuque@isc.upenn.edu>, Bernard Aboba <bernard_aboba@hotmail.com>
Message-ID: <C8ADC7ED.EBA4%stefan@aaa-sec.com>
Thread-Topic: Review of draft-saintandre-tls-server-id-check
Thread-Index: ActPmfwzvu4rRm49WkiAbBO1k+H9OA==
In-Reply-To: <20100908195349.GA4292@isc.upenn.edu>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: 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: Wed, 08 Sep 2010 21:08:07 -0000

On 10-09-08 9:53 PM, "Shumon Huque" <shuque@isc.upenn.edu> wrote:

>> If the "reference identifier" is  _Service.Name then the match is being done
>> on the *input* to the SRV lookup process, not the output, and prohibition on
>> DNS lookups would not apply (or even make any sense).
> 
> Yes.
> 
> The output of the SRV record lookup contains a target hostname,
> not a service name, so it's not applicable to the SRVName name
> form. The target could be used in another name form (dNSName)
> as the reference identifier, but then the client needs to convince
> itself that the lookup was done securely (DNSSEC or some other
> means) otherwise there's a security problem.

I disagree,

A client can use the output from the DNS lookup also from a normal insecure
DNS server.

The only thing the client need to do is to verify that the domain name
provided in the input to the lookup matches the host names provided in the
output. It can then safely use the host names in the SRV record as reference
identifiers IF the SRV-ID in the server certificate matches the the
reference identifier.

A false host represented by a false identifier from a bad DNS server will
not be able to present a trusted certificate that supports it's claim to be
an authorized provider of the requested service for the domain in question.

/Stefan