Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation

"Rex, Martin" <martin.rex@sap.com> Wed, 27 January 2010 14:19 UTC

Return-Path: <martin.rex@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 DFFBC3A6AA0; Wed, 27 Jan 2010 06:19:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.77
X-Spam-Level:
X-Spam-Status: No, score=-9.77 tagged_above=-999 required=5 tests=[AWL=0.479, 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 dcS69rI+tgJd; Wed, 27 Jan 2010 06:19:32 -0800 (PST)
Received: from smtpgw.sap-ag.de (smtpgw01.sap-ag.de [155.56.66.96]) by core3.amsl.com (Postfix) with ESMTP id 8D4723A6A9F; Wed, 27 Jan 2010 06:19:31 -0800 (PST)
From: "Rex, Martin" <martin.rex@sap.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Date: Wed, 27 Jan 2010 15:19:34 +0100
Thread-Topic: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation
Thread-Index: AcqfV1ndf4wT1KnaTMaCihQFKy0zwQAAezfg
Message-ID: <D28848FB278CE54FB6A302F413ECF730059269903F@DEWDFECCR07.wdf.sap.corp>
References: <E1NZvE3-0005m4-Qw@wintermute02.cs.auckland.ac.nz> <201001270005.o0R05dX8018122@fs4113.wdf.sap.corp> <c331d99a1001262333n1c369dd3qec421542004bed97@mail.gmail.com>
In-Reply-To: <c331d99a1001262333n1c369dd3qec421542004bed97@mail.gmail.com>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation
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: Wed, 27 Jan 2010 14:19:33 -0000

 

> -----Original Message-----
> From: mrex@sap.com [mailto:mrex@sap.com] On Behalf Of Nikos 
> Mavrogiannopoulos
> Sent: Wednesday, 27. January 2010 08:33
> To: Rex, Martin
> Cc: Peter Gutmann; ietf@ietf.org; tls@ietf.org
> Subject: Re: [TLS] Metadiscussion on changes in 
> draft-ietf-tls-renegotiation
> 
> On Wed, Jan 27, 2010 at 1:05 AM, Martin Rex <mrex@sap.com>; wrote:
> >
> > That may be attributed to the fact that a large part of PKIX is dealing
> > with policy issues with the objective to prevent/prohibit interoperability.

The above was a comment about PKIX, not SCSV.


> 
> On the contrary. I believe allowing the sending of both SCSV 
> and extension might harm interoperability instead. Consider the
> case of most popular client implementations are sending both SCSV
> and extension (it's easier to do so).
> A developer of a server might then consider checking only for 
> SCSV (since all of the popular ones he tested with send both).
> Thus interoperability with less popular clients that only send
> extension stops.

I'm somewhat confused what makes you saying this.
Support for SCSV is *required* for initial handshakes in the
-03 document -- if it wasn't, SCSV could be removed from the
document entirely.  The reason for this is that otherwise
existing usage scenarios would be susceptible to downgrade
attacks (which is what the confusing reference in section 4.2
refers to).


What I am opposing is the MUST NOT for the secure renegotiation.

Secure renegotiation requires that both, server and client
verify the contents of the "renegotiation_info".  If some
implementor forgets that without the SCSV MUST NOT, then you
have much more serious issues to worry about than SCSV semantics.

If _some_ implementors, without this MUST NOT, would really accidentally
forget to verify the verify_data of the renegotiation_info for
secure renegotiation, then we should dump TLS extension RI and
go for the approach draft-mrex-tls-secure-renegotiation, because
it is fairly unlikely that you get an implementation of this
draft to interoperate in regular interop scenario _without_
getting the secure renegotiation working correctly.


> 
> This scenario might not be very likely, but this kind of issues were
> not rare in TLS for quite long :)

I would have loved to get rid of the empty TLS extension RI entirely,
(making SCSV the mandatory to use signaling method) just like
Eric Rescorla proposed here:

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

because it would the most robust approach, but it had severe
aesthetical acceptance problems (not a single technical
problem is on record).


-Martin