IETF Logo Mail Archive

Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV

Martin Rex <mrex@sap.com> Fri, 11 December 2009 02:08 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 8A5FF3A6897 for <tls@core3.amsl.com>; Thu, 10 Dec 2009 18:08:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.192
X-Spam-Level:
X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 8EQ1KnHtrHMj for <tls@core3.amsl.com>; Thu, 10 Dec 2009 18:08:47 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 896753A6803 for <tls@ietf.org>; Thu, 10 Dec 2009 18:08:47 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBB28TLt027749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Dec 2009 03:08:29 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912110208.nBB28SIT024876@fs4113.wdf.sap.corp>
To: mickgray@au1.ibm.com
Date: Fri, 11 Dec 2009 03:08:28 +0100
In-Reply-To: <OF077778A0.30F948CF-ON4A257687.007F44D3-4A257688.000C7CE6@au1.ibm.com> from "Michael Gray" at Dec 10, 9 12:16:24 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV
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: Fri, 11 Dec 2009 02:08:48 -0000

Michael Gray wrote:
>
> > in order to reliably provide this,
> >
> >   - MCSV is defined to represent an empty TLS extension RI
> >
> >   - MSCV MUST be included in *ALL* initial ClientHello handshakes
> >     messages _plus_ all renegotiation ClientHellos in backwards
> >     interop scenarios (independent of full handshake or session resume).
> >
> >   - empty TLS extension RI MUST NOT be sent, ever!
> 
> This looks good to me, the only thing I would change is I think MUST NOT
> would be better as SHOULD NOT as the later requires that the implementer
> examine the conditions and implications etc to make the best decision.

You are right.  I'm sorry.  I got a little carried away.

A SHOULD NOT for sending _empty_ TLS extension RI is more appropriate.

-Martin

v2.27.8 | Report a Bug | By Email | System Status