[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
- [TLS] Updated draft Eric Rescorla
- Re: [TLS] Updated draft Michael D'Errico
- Re: [TLS] Updated draft Robert Dugal
- Re: [TLS] Updated draft Marsh Ray
- Re: [TLS] Updated draft Robert Dugal
- Re: [TLS] Updated draft Eric Rescorla
- Re: [TLS] Updated draft Martin Rex
- Re: [TLS] Updated draft Marsh Ray
- Re: [TLS] Updated draft Martin Rex
- Re: [TLS] Updated draft Michael D'Errico
- Re: [TLS] Updated draft Stephen Farrell
- Re: [TLS] Updated draft Martin Rex
- Re: [TLS] Updated draft Martin Rex
- Re: [TLS] Updated draft Marsh Ray
- Re: [TLS] Updated draft Martin Rex
- Re: [TLS] Updated draft Michael D'Errico
- [TLS] SCSV vs RI when both specified. Was: Update… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- [TLS] Apologies Martin Rex
- Re: [TLS] Updated draft - editorial tom.petch
- Re: [TLS] Updated draft tom.petch
- Re: [TLS] Updated draft Marsh Ray
- Re: [TLS] Updated draft tom.petch
- Re: [TLS] Updated draft: Minor Edits peter.robinson