IETF Logo Mail Archive

Re: [TLS] Proposed changes to draft-ietf-tls-rfc4366-bis

Marsh Ray <marsh@extendedsubset.com> Sat, 15 May 2010 03:56 UTC

Return-Path: <marsh@extendedsubset.com>
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 15A113A686D for <tls@core3.amsl.com>; Fri, 14 May 2010 20:56:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_50=0.001]
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 xvIgv0umDlSz for <tls@core3.amsl.com>; Fri, 14 May 2010 20:56:35 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 52A3B3A67D4 for <tls@ietf.org>; Fri, 14 May 2010 20:56:35 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OD8UD-000OMX-UA; Sat, 15 May 2010 03:56:25 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id B20EB6456; Sat, 15 May 2010 03:56:24 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18G1K49iIyMMVO4bik/dXSPE5KE71bYhPo=
Message-ID: <4BEE1B68.7060406@extendedsubset.com>
Date: Fri, 14 May 2010 22:56:24 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: Michael D'Errico <mike-list@pobox.com>
References: <AC1CFD94F59A264488DC2BEC3E890DE50A43B2D7@xmb-sjc-225.amer.cisco.com> <808FD6E27AD4884E94820BC333B2DB775B82DD0CE1@NOK-EUMSG-01.mgdnok.nokia.com> <AANLkTikvkuR5_6kHnpwM19PxSvtBv4qrC1_QldxMnOWE@mail.gmail.com> <4BEE0EAB.5030806@pobox.com>
In-Reply-To: <4BEE0EAB.5030806@pobox.com>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Proposed changes to draft-ietf-tls-rfc4366-bis
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: Sat, 15 May 2010 03:56:36 -0000

On 5/14/2010 10:02 PM, Michael D'Errico wrote:
>
>    "When the server resumes a session, the server_name extension
>    is ignored."

Conversely, the act of considering (i.e., not ignoring) the SNI
prohibits the server from resuming the session.

So this wording would seem to eliminate the possibility of having
multiple TLS server stacks selected by SNI.

Might rule out some interesting "reverse" proxy hardware on a
technicality. Or, more likely, the rule would just be ignored if the
design works in practice.

- Marsh

v2.23.0 | Report a Bug | By Email