Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert

Peter Saint-Andre <stpeter@stpeter.im> Fri, 04 June 2010 21:19 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 159B43A67AE for <tls@core3.amsl.com>; Fri, 4 Jun 2010 14:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.122
X-Spam-Level:
X-Spam-Status: No, score=-2.122 tagged_above=-999 required=5 tests=[AWL=0.477, 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 Dg7mCLpmLvFT for <tls@core3.amsl.com>; Fri, 4 Jun 2010 14:19:03 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3CE0C3A6782 for <tls@ietf.org>; Fri, 4 Jun 2010 14:19:03 -0700 (PDT)
Received: from squire.local (dsl-205-108.dynamic-dsl.frii.net [216.17.205.108]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A48D840E44 for <tls@ietf.org>; Fri, 4 Jun 2010 15:18:48 -0600 (MDT)
Message-ID: <4C096DB7.3090804@stpeter.im>
Date: Fri, 04 Jun 2010 15:18:47 -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.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: tls@ietf.org
References: <201006041847.o54IliTQ001508@fs4113.wdf.sap.corp> <4C09597D.1060304@extendedsubset.com>
In-Reply-To: <4C09597D.1060304@extendedsubset.com>
X-Enigmail-Version: 1.0.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030106080305070704030405"
Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jun 2010 21:19:04 -0000

On 6/4/10 1:52 PM, Marsh Ray wrote:

> I'm sorry if I missed this in earlier discussion, but why on earth would
> an SNI-aware server ever want to continue a handshake with a client that
> asked for a name he didn't serve?
> 
> A simple solution seemed to work for session resumption:
> 
> From http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-08 :
>>    A server that implements this extension MUST NOT accept the request to
>>    resume the session if the server_name extension contains a different
>>    name.
> 
> Can we just define this situation as a fatal handshake error and be done
> with it?

+1