Re: [TLS] Other S->C signaling methods

Martin Rex <mrex@sap.com> Wed, 25 November 2009 22:34 UTC

Return-Path: <mrex@sap.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 ABF023A6B52 for <tls@core3.amsl.com>; Wed, 25 Nov 2009 14:34:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.167
X-Spam-Level:
X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 QlWC6bI7fo3h for <tls@core3.amsl.com>; Wed, 25 Nov 2009 14:34:46 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id AEF4D3A68CF for <tls@ietf.org>; Wed, 25 Nov 2009 14:34:45 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAPMYau2016288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 23:34:36 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911252234.nAPMYZAx029809@fs4113.wdf.sap.corp>
To: nelson@bolyard.me
Date: Wed, 25 Nov 2009 23:34:34 +0100
In-Reply-To: <4B0DAE38.8030206@bolyard.me> from "Nelson B Bolyard" at Nov 25, 9 02:22:48 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Other S->C signaling methods
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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: Wed, 25 Nov 2009 22:34:46 -0000

Nelson B Bolyard wrote:
> 
> On 2009-11-25 01:39 PST, Yoav Nir wrote:
> > On Nov 25, 2009, at 10:11 AM, Stefan Santesson wrote:
> > 
> >> So how would this work as a middle way between the proposals:
> >>
> >> C->S Signaling:
> >> 1) Client MUST include either the magic CipherSuite or RI extension or both
> >> 2a) TLS compatible server MUST support magic CipherSuite and RI.
> >> 2b) SSLv3 servers MUST support magic CipherSuite and MAY support RI
> > 
> > How about:
> > 2a) TLS 1.1+ compatible server MUST support magic Ciphersuite and RI
> > 2b) SSLv3 and TLS 1.0 servers MUST support magic Ciphersuite and MAY support RI
> 
> Why would you separate TLS 1.0 servers from TLS 1.1+ ?

Maybe because a large number of TLS 1.0 servers do not support TLS extensions
(rightly so), they're just extensions-tolerant.

-Martin