Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer

Peter Saint-Andre <> Wed, 30 September 2009 16:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3524F3A68BB; Wed, 30 Sep 2009 09:50:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.762
X-Spam-Status: No, score=-2.762 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oYfXkBCtw855; Wed, 30 Sep 2009 09:50:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AEA7E3A677D; Wed, 30 Sep 2009 09:50:04 -0700 (PDT)
Received: from ( []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 5144D4007B; Wed, 30 Sep 2009 10:51:27 -0600 (MDT)
Message-ID: <>
Date: Wed, 30 Sep 2009 10:51:26 -0600
From: Peter Saint-Andre <>
User-Agent: Thunderbird (Macintosh/20090812)
MIME-Version: 1.0
To: "Joseph Salowey (jsalowey)" <>
References: <><><> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
OpenPGP: url=
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Simon Josefsson <>,,
Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Sep 2009 16:50:06 -0000

Hash: SHA1

On 9/30/09 10:45 AM, Joseph Salowey (jsalowey) wrote:
>> -----Original Message-----
>> From: Simon Josefsson [] 
>> Sent: Tuesday, September 29, 2009 10:20 PM
>> To: Joseph Salowey (jsalowey)
>> Cc: Michael D'Errico;;;
>> Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis 
>> (Transport Layer
>> "Joseph Salowey (jsalowey)" <> writes:
>>> It seems that this is really up to the application.  Both 
>> server names 
>>> are authenticated under the same session.  It seems an application
>>> server may require them to be the same or allow them to be 
>> different.   
>> I would agree if the draft wouldn't prevent clients from 
>> requesting a different server name at the application layer:
>>    negotiated in the application protocol. If the server_name is
>>    established in the TLS session handshake, the client SHOULD NOT
>>    attempt to request a different server name at the 
>> application layer.
>> At least that is how I read it.
> [Joe] Good point, however I still think it is application protocol that
> needs to enforce the matching if it cares.  Perhaps we can add some text
> that states
> "Since it is possible for a client to present a different server_name in
> the application protocol, application server implementators should take
> this into account and take appropriate action to avoid introducing
> security vulnerabilities if the names do not match.  "

I think that text is helpful. Overall, however, I wonder if this is
something that truly belongs in rfc4366bis or if it is more appropriate
to define a set of best practices for application protocols that use
TLS. A group of folks in the Apps Area has started to do that here:

It can't hurt to place a brief warning in the core TLS spec, though.


- --
Peter Saint-Andre

Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla -