Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-not-03.txt>

Martin Rex <mrex@sap.com> Fri, 03 December 2010 19:57 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 53B9B3A698E; Fri, 3 Dec 2010 11:57:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.114
X-Spam-Level:
X-Spam-Status: No, score=-10.114 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 p3HBvj-uxAGm; Fri, 3 Dec 2010 11:57:25 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 2C1D23A697A; Fri, 3 Dec 2010 11:57:25 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id oB3Jwf2q008557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Dec 2010 20:58:41 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201012031958.oB3JweOg015633@fs4113.wdf.sap.corp>
To: gwz@net-zen.net
Date: Fri, 03 Dec 2010 20:58:40 +0100
In-Reply-To: <000401cb92a4$c1917ba0$44b472e0$@net> from "Glen Zorn" at Dec 3, 10 11:44:18 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal03
X-SAP: out
Cc: tls@ietf.org, ietf@ietf.org
Subject: Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-not-03.txt>
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, 03 Dec 2010 19:57:26 -0000

Glen Zorn wrote:
> 
> Martin Rex wrote:
> >
> > Glen Zorn wrote: 
> > >
> > > Maybe I just don't understand the word "use".  It seems like if a
> > > server accepts a protocol message it's using the protocol...
> > 
> > With "negotiate" I meant returning a ServerHello handshake message with
> > that version number (neither an SSL 2.0 SERVER-HELLO, nor an SSLv3
> > ServerHello with a server version of { 0x02,0x00 }).
> > 
> > With "use" I meant to successfully complete the handshake and start
> > exchanging application data protected under protocol version
> > {0x02,0x00}.
> 
> Maybe you could spell these things out in the draft just as you have above?

I'm sorry, my explanations were misleading.  I explained what I meant
when I wrote these statements that ended up in the document.

  http://www.ietf.org/mail-archive/web/tls/current/msg07091.html

The author/editor of this I-D is Sean Turner.


> 
> > The Server accepts the SSL 2.0 CLIENT-HELLO protocol data unit (PDU),
> > but not the SSL 2.0 protocol.  
> 
> I see.  Perhaps the distinction between PDU and "protocol" is just too
> subtle for me, but assuming (maybe too generously ;-) that I'm not a total
> moron, others might find it a little bit confusing as well.

I do agree that the "specification" part is extremely brief.
The best way to adjust this (as we are in IETF Last Call for this
document) is to propose a specific replacement/update text.  :)


The distinction is not so much about the difference between "PDU" and
"protocol", than it is about "active" and "passive" and the general
IETF principle of "Be liberal in what you accept, and conservative
in what you send".

So we don't want servers to "actively" (=send out) SSL 2.0 protocol,
but continue to be liberal in what they accept, e.g. "SSL 2.0 CLIENT-HELLO
as the first message of an SSLv3 or TLS handshake".  At least while
there is _no_known_ security problem associated with this particular
behaviour, because it improves interoperability with the installed
base.


-Martin