Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation
Stefan Santesson <stefan@aaa-sec.com> Fri, 29 January 2010 08:47 UTC
Return-Path: <stefan@aaa-sec.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB67728C144 for <ietf@core3.amsl.com>; Fri, 29 Jan 2010 00:47:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 fucovd1J68JI for <ietf@core3.amsl.com>; Fri, 29 Jan 2010 00:47:32 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id EF8E628C133 for <ietf@ietf.org>; Fri, 29 Jan 2010 00:47:31 -0800 (PST)
Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 89E2A35A059 for <ietf@ietf.org>; Fri, 29 Jan 2010 09:45:14 +0100 (CET)
Received: (qmail 18526 invoked from network); 29 Jan 2010 08:45:09 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.6]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <nmav@gnutls.org>; 29 Jan 2010 08:45:09 -0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Fri, 29 Jan 2010 09:45:07 +0100
Subject: Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation
From: Stefan Santesson <stefan@aaa-sec.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>, mrex@sap.com
Message-ID: <C7885EA3.7F9D%stefan@aaa-sec.com>
Thread-Topic: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation
Thread-Index: Acqgv1uhIJ3HhLP6RE27N7biS3auKQ==
In-Reply-To: <c331d99a1001262333n1c369dd3qec421542004bed97@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: tls@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2010 08:47:32 -0000
This makes no sense to me. Developers tend to live by the rule to be "liberal in what you accept" as it tends to generate less interop problems. It makes no sense to abort a TLS handshake just because it contains an SCSV if everything else is OK. So This "MUST NOT" requirement will likely be ignored by some implementations. 03 gives SCSV somewhat double and conflicting semantics. 1) Present in an initial handshake it signals client support for secure renegotiation. 2) Present in a renegotiation handshake it signals that the client DOES NOT support secure renegotiation (Handshake MUST be aborted). I think this is asking for trouble. /Stefan On 10-01-27 8:33 AM, "Nikos Mavrogiannopoulos" <nmav@gnutls.org> wrote: > On Wed, Jan 27, 2010 at 1:05 AM, Martin Rex <mrex@sap.com> wrote: > >>> <aside>That's been the standard for PKIX RFCs for at least ten years >>> (actively acknowledged by WG mmembers), although perhaps its spread >>> to other groups should be discouraged.</aside> >> >> I fully agree. >> >> 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. > > 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. > > This scenario might not be very likely, but this kind of issues were > not rare in > TLS for quite long :) > > best regards, > Nikos > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
- Re: [TLS] Metadiscussion on changes in draft-ietf… Nikos Mavrogiannopoulos
- RE: [TLS] Metadiscussion on changes in draft-ietf… Rex, Martin
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Metadiscussion on changes in draft-ietf… Stefan Santesson
- Re: [TLS] Metadiscussion on changes in draft-ietf… Marsh Ray
- Re: [TLS] Metadiscussion on changes in draft-ietf… Stefan Santesson
- Re: [TLS] Metadiscussion on changes in draft-ietf… Marsh Ray
- Re: [TLS] Metadiscussion on changes in draft-ietf… Steve Checkoway
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex