Re: [TLS] SCSV vs RI when both specified - consensus?

Marsh Ray <marsh@extendedsubset.com> Mon, 21 December 2009 21:20 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 536A53A690B for <tls@core3.amsl.com>; Mon, 21 Dec 2009 13:20:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.592
X-Spam-Level:
X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 Tu9IQ4-Z+GuX for <tls@core3.amsl.com>; Mon, 21 Dec 2009 13:20:58 -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 6A06F3A68F2 for <tls@ietf.org>; Mon, 21 Dec 2009 13:20:58 -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 1NMpgH-000Dwd-Ri; Mon, 21 Dec 2009 21:20:41 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id CAEC4603A; Mon, 21 Dec 2009 21:20:40 +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: U2FsdGVkX18WraS1IRb0P5abXJp03JNRLJtL2uMJ5M0=
Message-ID: <4B2FE6AC.6060808@extendedsubset.com>
Date: Mon, 21 Dec 2009 15:20:44 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Michael D'Errico <mike-list@pobox.com>
References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854018@LLE2K7-BE01.mitll.ad.local> <808FD6E27AD4884E94820BC333B2DB7758409B30F1@NOK-EUMSG-01.mgdnok.nokia.com> <4B2FAAFB.5090908@pobox.com> <4B2FB265.5040203@drh-consultancy.demon.co.uk> <4B2FB68C.1000400@pobox.com> <4B2FB80E.8080300@extendedsubset.com> <4B2FE15B.1050704@pobox.com>
In-Reply-To: <4B2FE15B.1050704@pobox.com>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] SCSV vs RI when both specified - consensus?
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: Mon, 21 Dec 2009 21:20:59 -0000

Michael D'Errico wrote:
> Marsh Ray wrote:
>>
> 
> As Nasko pointed out, we don't need to talk about multiple RI extensions.

I think there is a need to reiterate it, at least to the point of
spending a sentence or two reminding about it.  It sounds like this
might be the main RFC some folks will be reading when they go to
implement minimal extension handling.

Many security bugs exploit the way different system components handle
ambiguous situations. For example, if a server interpreted the first RI
extension, yet his inspecting firewall interpreted the last one...

It's also an easy mistake to make. For example, I don't think the code I
posted here a few weeks ago checked for the case.

> Perhaps:
>
>   This SCSV is not a true cipher suite and cannot be negotiated; a
>   server that encounters SCSV but not RI MUST proceed exactly as if
>   an empty RI extension had been received.

I'd prefer not to use the word "exactly" when there are subtle
differences (e.g., hash computation).

Also, I'm not really sure the behavioral requirement belongs in that
section. The first part of the sentence says what SCSV is not, the
second says how one endpoint handles one particular possible case.

// How about: (with input from MRex)

A client MAY specify the SCSV in the same Client Hello message as an RI
extension (the SCSV will be effectively ignored). Note that TLS
[RFC5246] prohibits clients from putting multiple occurrences of an RI
extension in the same Client Hello message.
[...]
A server receiving a Client Hello containing the SCSV and an RI
extension is to interpret the RI as usual and ignore the SCSV. A server
receiving a Client Hello containing multiple RI extensions MUST handle
it as an error per TLS [RFC5246].

// Change the current:

This SCSV is not a true cipher suite and cannot be negotiated. It
merely has exactly the same semantics as an empty "renegotiation_info"
extension.

// to:

This SCSV is not a true cipher suite and cannot be negotiated, it
has similar semantics as an empty "renegotiation_info" extension.

- Marsh