IETF Logo Mail Archive

Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 01 December 2009 11:36 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 4A9C53A688F; Tue, 1 Dec 2009 03:36:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.528
X-Spam-Level:
X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 Dg8wMeywwIjh; Tue, 1 Dec 2009 03:36:45 -0800 (PST)
Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by core3.amsl.com (Postfix) with ESMTP id 4659F3A6819; Tue, 1 Dec 2009 03:36:45 -0800 (PST)
Received: from mail174-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 8.1.340.0; Tue, 1 Dec 2009 11:36:37 +0000
Received: from mail174-tx2 (localhost.localdomain [127.0.0.1]) by mail174-tx2-R.bigfish.com (Postfix) with ESMTP id D0A9B1C503C4; Tue, 1 Dec 2009 11:36:37 +0000 (UTC)
X-SpamScore: -40
X-BigFish: VPS-40(z1725nz1432R98dN1442J9371Pzz1202hz4fhz1033ILz2dh6bh87h61h)
X-Spam-TCS-SCL: 0:0
X-FB-DOMAIN-IP-MATCH: fail
Received: from mail174-tx2 (localhost.localdomain [127.0.0.1]) by mail174-tx2 (MessageSwitch) id 1259667394903599_10133; Tue, 1 Dec 2009 11:36:34 +0000 (UTC)
Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.251]) by mail174-tx2.bigfish.com (Postfix) with ESMTP id D97001920055; Tue, 1 Dec 2009 11:36:34 +0000 (UTC)
Received: from imx2.tcd.ie (134.226.1.156) by TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server id 14.0.482.32; Tue, 1 Dec 2009 11:36:33 +0000
Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 2096468005; Tue, 1 Dec 2009 11:36:33 +0000 (GMT)
Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A00D3B1329C; Tue, 01 Dec 2009 11:36:33 +0000
Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id D6EE768005; Tue, 1 Dec 2009 11:36:32 +0000 (GMT)
Message-ID: <4B14FFC0.3040404@cs.tcd.ie>
Date: Tue, 01 Dec 2009 11:36:32 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Thunderbird 2.0.0.23 (X11/20090812)
MIME-Version: 1.0
To: "ietf@ietf.org" <ietf@ietf.org>
References: <20091130153734.D44C63A6AA9@core3.amsl.com> <7C44D6AC-C936-4AAB-983C-A6928FE01637@checkpoint.com>
In-Reply-To: <7C44D6AC-C936-4AAB-983C-A6928FE01637@checkpoint.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-AntiVirus-Status: MessageID = A10D3B1329C
X-AntiVirus-Status: Host: imx2.tcd.ie
X-AntiVirus-Status: Action Taken:
X-AntiVirus-Status: NONE
X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.114.5)
X-Reverse-DNS: imx2.tcd.ie
Cc: "tls@ietf.org Group" <tls@ietf.org>
Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard
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: Tue, 01 Dec 2009 11:36:46 -0000

Yoav Nir wrote:
> On Nov 30, 2009, at 5:37 PM, The IESG wrote:
> 
>> The IESG has received a request from the Transport Layer Security WG 
>> (tls) to consider the following document:
>>
>> - 'Transport Layer Security (TLS) Renegotiation Indication Extension '
>>   <draft-ietf-tls-renegotiation-01.txt> as a Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action.  Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2009-12-14. Exceptionally, 
>> comments may be sent to iesg@ietf.org instead. In either case, please 
>> retain the beginning of the Subject line to allow automated sorting.
> 
> I oppose publishing the current draft. 

I strongly support it.

I don't buy the claims that extension handling as required here
is so hard to implement and all clients & servers need modification
in any case. (Not that its really relevant, but writing that code
would be much easier that reading the recent TLS list traffic;-)

I also don't see any concrete benefit in not sending the verify
data over the wire, but I do see more possibility for error in
terms of how to incorporate that data if its not sent.

My comments on -01 are below. While I'd like to see these addressed
of course, I think progressing this document speedily is more
important than resolving my comments. I think the same applies
to all other comments that I've seen, both during IETF LC and
on the TLS list since this problem was announced.

Regards,
Stephen.


1. The reference for the HTTP splicing attack is still a
placeholder. "[REF]"

2. I don't see any particular reason why the ServerHello RI value
contains both client and server values. I think it'd be marginally
better if the server just sent its value since the current approach
makes it easier for a server to mess up the ordering.

3. (Crossing page 5/6) It says the both "MUST verify" that the
values are correct, but doesn't explicitly say how to verify
the values, but just "as specified below" - where below?
It might be good to be extra-clear here, and add e.g. "A correct
value is one that was the verify_data of the Finished message
from the previous TLS session, or else the "empty" value given
above."  or something like that.

4. I'm slightly concerned that middleboxes might barf on the
new ciphersuite. Be good if someone had tested that in the wild,
but I've not seen a mail that says that that's happened. (The test
I mean is inclusion of a totally new ciphersuite value, not the
inclusion of a previously-allocated-but-mostly-unused value.)

5. (Similar to above.) It'd be great if we had data to allow
us to recommend either the RI in the initial handshake or else
recommend the ciphersuite. I can see implementers not knowing
what to do there, leading to a 50-50 split in terms of who
does what, possibly leading to lack of interop. If it were up
to me, I'd remove the ciphersuite and just go with the RI.

6. Is there an explicit statement somewhere that servers MUST
support both the RI extension and the ciphersuite? If so, I
skipped over it, so maybe highlighting it somehow would be
good. If not, please add, so that someone generating tests
from the RFC's "MUST" statements generates one for that.

7. 6.2 says: "If servers wish to <<avoid attack>> they MUST
NOT <<do stuff>>" Isn't that equivalent to servers SHOULD
NOT? I think a SHOULD NOT is better. (And that's the form
used in section 7.)

8. I would be for removing the new requirement that the
identity not change. This spec is in response to one thing
and should only fix that thing. Any other considerations
should not get the "emergency" treatment being applied
here especially since there could be unforseen side-effects
of the additional change. (E.g. some deployed application
making use of an id-change.)

9. The security considerations and the introduction
should include a statement that another mitigation that's
useful in many cases is for a server to simply disallow
all renegotiation and encourage implementers to allow
deployments to control that.

v2.23.0 | Report a Bug | By Email