IETF Logo Mail Archive

Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer

Marsh Ray <marsh@extendedsubset.com> Wed, 02 December 2009 04:04 UTC

Return-Path: <marsh@extendedsubset.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 3534A28C136 for <tls@core3.amsl.com>; Tue, 1 Dec 2009 20:04:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level:
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 nFU16VHndvae for <tls@core3.amsl.com>; Tue, 1 Dec 2009 20:04:53 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 7667528C11B for <tls@ietf.org>; Tue, 1 Dec 2009 20:04:52 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NFgSK-00055g-DV; Wed, 02 Dec 2009 04:04:44 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 98DCF603C; Wed, 2 Dec 2009 04:04:41 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/8j2xvIY0F8iasYQvxaWyLM3D/J7FJKvU=
Message-ID: <4B15E759.7070108@extendedsubset.com>
Date: Tue, 01 Dec 2009 22:04:41 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: mrex@sap.com
References: <200912020329.nB23TMcL010059@fs4113.wdf.sap.corp>
In-Reply-To: <200912020329.nB23TMcL010059@fs4113.wdf.sap.corp>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: ekr@rtfm.com, tls@ietf.org, Kyle Hamilton <aerowolf@gmail.com>
Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer
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, 02 Dec 2009 04:04:54 -0000

Martin Rex wrote:
> Kyle Hamilton wrote:
>> What I'm seeing here:
>>
>> An implementation continues to be conformant to TLS even if the RI
>> isn't sent.  If a client doesn't send the RI (either cipher suite flag
>> or extension), the server can't send the RI extension back (as it's a
>> violation of TLS 1.2 for a server to send an unsolicited extension).
>> If a client does send the RI cipherflag or extension, the server may
>> send back the RI reply, or (if its security policy prohibits
>> renegotiation -- to reduce the possible impact of large numbers of
>> reneg's overwhelming any crypto implementation, or because it's known
>> that client certificates are never going to be solicited by the
>> server, to name a couple of possible reasons) it may choose not to
>> reply with the extension.
> 
> It has been previously mentioned: this is likely an insufficiently
> clear wording of the spec.

It sure sounds wrong that a implementation could become conformant with
no discernible change on the wire.

> The TLS_RENEGO_PROTECTION_REQUEST cipher suite value is _not_
> a means to request secure renegotiation (for the TLS extension RI,
> only the extension containing the verify_data is such a request).
> 
> The purpose of the magic cipher suite is a request for protection
> from the _INsecure_ or "old" renegotiation.

Good point.

> The spec should explicitly say that every updated/conforming client
> MUST add that cipher suite value into every ClientHello handshake
> message that it sends out, and that includes clients that do not
> implement renegotiation or have it disabled.

It must add the MCSV and/or the extension.

> That decision MUST
> be free from policy and configuration.

I understand the sentiment, but that wording doesn't make sense to me.
To the extent that we're defining a wire protocol rather than certifying
specific implementations, restrictions like that don't belong. After
all, what stops them from adding a configuration switch to enable or
disable support for the draft altogether?

Seems like any arguments in support of that wording would also apply to
every other usage of 'MUST' in every RFC. Which is a pretty good reason
not to include it.

- Marsh

v2.23.0 | Report a Bug | By Email