[TLS] SCSV vs RI when both specified. Was: Updated draft

Marsh Ray <marsh@extendedsubset.com> Fri, 18 December 2009 19:31 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 C2FC73A6ABD for <tls@core3.amsl.com>; Fri, 18 Dec 2009 11:31:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.591
X-Spam-Level:
X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 oy0GCs0GnMF7 for <tls@core3.amsl.com>; Fri, 18 Dec 2009 11:31:31 -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 9E6083A6ACB for <tls@ietf.org>; Fri, 18 Dec 2009 11:31:31 -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 1NLiXk-000PzD-4E; Fri, 18 Dec 2009 19:31:16 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 170BB6678; Fri, 18 Dec 2009 19:31:14 +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/9H588IuGnqxoDZQYSbE59yFiTDCQjGuQ=
Message-ID: <4B2BD881.1050600@extendedsubset.com>
Date: Fri, 18 Dec 2009 13:31:13 -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: <200912181745.nBIHjPN5028573@fs4113.wdf.sap.corp>
In-Reply-To: <200912181745.nBIHjPN5028573@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: rdugal@certicom.com, tls@ietf.org
Subject: [TLS] SCSV vs RI when both specified. Was: Updated draft
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: Fri, 18 Dec 2009 19:31:32 -0000

Martin Rex wrote:
> Marsh Ray wrote:
>> Currently, the SCSV achieves its primary objective with a very simple
>> definition. It has "exactly the same semantics as an empty
>> 'renegotiation_info' extension".
> 
> How about
> 
> TLS_RENEGO_PROTECTION_REQUEST is a request from the client to the
> server to perform a secure handshake and confirm this by sending
> TLS extension RI in ServerHello.

But what does that mean? What is "a secure handshake" if you're not
sending the RI extension? To the extent that this document is describing
how to perform a secure handshake, that definition is circular.

So there are three cases with the SCSV:

A. SCSV without RI extension.
B. SCSV with empty RI extension.
C. SCSV with non-empty RI extension.

The current draft-ietf-tls-renegotiation-02 defines A as semantically
equivalent to an empty RI extension. That appeals to me greatly, but it
is certainly not the only way to look at it.

Cases B and C are currently undefined AFAICT. We should fix this.

Case B looks redundant under the current wording. RFC 3546 does not seem
to say anything about multiple extensions of the same type.

Case C looks like it's self-conflicting.

So if I understand the current discussion correctly, it is about whether
or not cases B and C are explicitly forbidden or explicitly allowed?

== (I) Here's some proposed wording to fix the issue with in the favor
of forbidding cases B and C:

> Clients MUST NOT put multiple occurrences of an RI extension in the
> same Client Hello message. Clients MUST NOT send the SCSV in the same
> Client Hello message as any RI extension, not even an empty one.
>
> A server receiving a Client Hello containing multiple RI extensions
> or the SCSV and one or more RI extensions MUST generate a fatal
> "decode_error" alert and terminate the connection.

== (II) Wording (which explicitly allows case B but forbids C:

> Clients MUST NOT put multiple occurrences of an RI extension in the
> same Client Hello message. A client MAY specify the SCSV in the same
> Client Hello message as an empty RI extension, but MUST NOT specify
> the SCSV in the same Hello as a non-empty RI.
>
> A server receiving a Client Hello containing multiple RI extensions
> or the SCSV and one or more non-empty RI extensions MUST generate
> a fatal "decode_error" alert and terminate the connection.

We'll have to fix the conflict with 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 something like:
> This SCSV is not a true cipher suite and cannot be negotiated, it
> has similar semantics as an empty "renegotiation_info" extension.

== (III) Wording which explicitly allows both cases B and C:

> Clients MUST NOT put multiple occurrences of an RI extension in the
> same Client Hello message. A client MAY specify the SCSV in the same
> Client Hello message as an RI extension (the SCSV will be effectively
> ignored).
>
> A server receiving a Client Hello containing multiple RI extensions
> MUST generate a fatal "decode_error" alert and terminate the
> connection. A server receiving a Client Hello containing the SCSV
> and an RI extension is to interpret the RI as usual and ignore the
> SCSV.

We'll have to fix the conflict with 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 something like:
> This SCSV is not a true cipher suite and cannot be negotiated, it
> has similar semantics as an empty "renegotiation_info" extension.

== Relative benefits.

Clearly the current wording needs to be improved just a bit.

My vote is for (I) because:
* It allows a definition of the meaning of SCSV.
* It involves the least wording change.
* Fewer allowed combinations generally makes security easier to analyze.

Cons of (I):
* Implementers will have to set the SCSV pro programmatically.
* Servers are required to be extra strict in what they accept.


Pros of (II):
* SCSV and empty RI together appear harmlessly redundant.

Cons of (II):
* Clients have flexibility which may surprise servers that weren't
tested in all cases.
* No good definition of what SCSV actually means.


Pros of (III):
* SCSV and empty RI together appear harmlessly redundant.
* Clients can set-and-forget SCSV in all cases.

Cons of (III):
* Clients have flexibility which may surprise servers that weren't
tested in all cases.
* No good definition of what SCSV actually means.


==

Martin Rex wrote:
> 
> This will also fix the awkward disconnect between the symbolic name of
> the SCSV and the current description of its semantics.

I feel consistent names are important too, but have avoided questioning
that choice of names.

Now

- Marsh