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

Steve Checkoway <s@pahtak.org> Sat, 30 January 2010 00:24 UTC

Return-Path: <s@pahtak.org>
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 E88973A679C; Fri, 29 Jan 2010 16:24:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 dFYQMpdQocbf; Fri, 29 Jan 2010 16:24:19 -0800 (PST)
Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by core3.amsl.com (Postfix) with ESMTP id CF9FF3A635F; Fri, 29 Jan 2010 16:24:18 -0800 (PST)
Received: by gxk26 with SMTP id 26so736295gxk.8 for <multiple recipients>; Fri, 29 Jan 2010 16:24:38 -0800 (PST)
Received: by 10.150.184.16 with SMTP id h16mr2474807ybf.344.1264811077631; Fri, 29 Jan 2010 16:24:37 -0800 (PST)
Received: from ?128.54.2.40? ([128.54.2.40]) by mx.google.com with ESMTPS id 20sm902231ywh.17.2010.01.29.16.24.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Jan 2010 16:24:36 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Steve Checkoway <s@pahtak.org>
In-Reply-To: <C78933B7.7FDE%stefan@aaa-sec.com>
Date: Fri, 29 Jan 2010 16:24:31 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <5D436DF5-AE4B-42DC-9454-0383004D9C66@pahtak.org>
References: <C78933B7.7FDE%stefan@aaa-sec.com>
To: tls@ietf.org
X-Mailer: Apple Mail (2.1077)
Cc: 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: Sat, 30 Jan 2010 00:24:20 -0000

On Jan 29, 2010, at 3:54 PM, Stefan Santesson wrote:

> The key is though that being liberal is only an option when this does not
> hurt security, and that is a tricky balance act.

I'm not sure why you say that. Marsh's example of HTML shows interop issues that came from being liberal that had nothing to do with security. Allowing SCSV + RI doesn't hurt security, but that's not an argument for allowing it.

> I totally agree in principle. However, if a renegotiating client sends a
> full RI extension with valid data AND the client also sends SCSV, then what
> security problem is introduced by allowing the renegotiation (i.e. Not
> aborting)

None.

> Hence, the "MUST abort" requirement seems like an unmotivated restriction.
> I'm not saying that we have to change the current draft, I'm just curious to
> understand the real benefits of this requirement.

I'm not convinced that there is a real benefit one way or the other. People have been disagreeing about which is better, but none of the arguments on either side have been very convincing.

> 
> 
>>> So This "MUST NOT" requirement will likely be
>>> ignored by some implementations.
>> 
>> They should expect the market to hold them accountable if problems result.
>> 
>> The implementers on this list have indicated they could produce
>> interoperable implementations of this spec. And they appear to have
>> proven it by demonstrating implementations which actually interoperate.
>> 
> 
> Again, based on what I have seen, I would not be surprised.
> I don't think being accountable to the market is a very strong threat if a
> safe adjustment to a more liberal processing helps customers to avoid
> interop problems while maintaining the security of the protocol.

It seems rather unlikely that disallowing SCSV + RI is going to cause interop problems. An implementor who hasn't bothered to read the 1700+ emails about this is going to determine pretty quickly that SCSV + RI is not in spec during normal testing if the MUST NOT was overlooked in the spec.

Given that there are no security concerns and the interop concerns seem pretty minor at best, it makes sense to me to publish and get the fix out sooner rather than spending another month arguing about something, that in the end, doesn't change the security guarantees of TLS.

-- 
Steve Checkoway