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

Martin Rex <mrex@sap.com> Fri, 18 December 2009 21:48 UTC

Return-Path: <mrex@sap.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 E0F573A68F4 for <tls@core3.amsl.com>; Fri, 18 Dec 2009 13:48:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.194
X-Spam-Level:
X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 LvNubjYArmhq for <tls@core3.amsl.com>; Fri, 18 Dec 2009 13:48:15 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 8F5653A67F3 for <tls@ietf.org>; Fri, 18 Dec 2009 13:48:15 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBILlxEo008480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 22:47:59 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912182147.nBILlwv4012510@fs4113.wdf.sap.corp>
To: mike-list@pobox.com (Michael D'Errico)
Date: Fri, 18 Dec 2009 22:47:58 +0100 (MET)
In-Reply-To: <4B2BEE01.90700@pobox.com> from "Michael D'Errico" at Dec 18, 9 01:02:57 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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 21:48:17 -0000

Michael D'Errico wrote:
> 
> Marsh Ray wrote:
> > Michael D'Errico wrote:
> >> Marsh Ray wrote:
> >>> Come up with a way to complete a sentence that begins with
> >>> "TLS_RENEGO_PROTECTION_REQUEST is" or "SCSV means" such that it
> >>> describes the three cases for it in a reasonably consistent way.
> >> "In the absence of an RI extension, SCSV conveys the same meaning
> >> as an empty RI.  When RI is present, SCSV is ignored."
> > 
> > Hmmm...doesn't quite meet the stated requirements.
> 
> Because I used two sentences?  Because I didn't start my sentence
> with "SCSV means"?
> 
> My two sentences describe everything you need to know:
> 
>     SCSV absent,  RI absent:   hide the kids
>     SCSV absent,  RI present:  same as RI
>     SCSV present, RI absent:   same as empty RI
>     SCSV present, RI present:  same as RI (SCSV ignored)
> 
> Why do you want the last one to be "ABORT!!"?

I think Marsh is looking for a descriptive text of the semantics
of SCSV, instead of an implementation guidance what to do when
-- that latter one is easy and intuitive to implementers, which
is why Robert asked for this change in the first place.


Personally, I feel it is much simpler to first describe the
design of the solution at the abstract level, then see where
SCSV fits in the abstract level.  When doing that, everything
falls in the right places all by itself.

At the abstract level, the solution to the TLS renegotiation problem
provided by TLS extension RI contains the following elements:

briefest (where "required" means required for the solution to be secure)

 (1)   required: mutually confirm that new handshake is available

 (2)   optional: distinguish initial from renegotiation handshake

 (3)   required: authenticate the enclosing TLS session during
                 the renegotiation handshake

brief:


 (a1a)  Client->Server "Hi, I'm updated -- new handshake semantics please"
 (a1b)  Server->Client "Good to hear, lets handshake securely"

 (a2a)  Client->Server "this is an initial handshake"
 (a2b)  Server->Client "this is an initial handshake

 (a3a)  Client->Server "this is a renegotiation handshake"
 (a3b)  Server->Client "this is a renegotiation handshake"

 (a4a)  Client->Server "I want to renegotiate this previous TLS session"
 (a4b)  Server->Client "I am renegotiating this previous TLS session"


Let's look at the (spec-level) implementation details of the approach
originally described in draft-ietf-rescorla-00:


 (i1a)  implemented by presence of *any* RI in ClientHello
 (i1b)  implemented by presence of *any* RI in ServerHello

 (i2a)  implemented by _empty_ RI in ClientHello
 (i2b)  implemented by _empty_ RI in ServerHello

 (i3a)  implemented by non-empty RI in ClientHello
 (i3b)  implemented by non-empty RI in ServerHello

 (i4a)  implemented by RI with Client.Finished in ClientHello
 (i4b)  implemented by RI with Client.Finished+ServerFinished in ServerHello

 
Now let's add SCSV to the picture.  SCSV in ClientHello can only convey
a single bit of information (i1a), where as you can see above,
empty RI in ClientHello actually conveys 2 bits of information (i1a)
(i2a) because sometimes a complementary non-empty RI is used.

Therefore describing SCSV as to mean an empty RI is inappropriate,
because it DOES NOT mean that, SCSV is simply an alternative
spec-level implementation of (a1a), something like (i1a').

If we use SCSV on extension-less ClientHellos or on SSLv2 ClientHellos
then it only conveys (a1a), but not (a2a).  Security-wise this is no
problem, because the distinction of initial vs. renegotiation hanshake
is an optional feature in the architecture, it is _NOT_ a criticial
part to the design.

Now if we compare the architecture and the resulting signaling
when RI and SCSV are both part of the spec-level implementation:
You describe the possible contents of ClientHello:


 (I)   SCSV absent,  RI absent:   hide the kids
 (II)  SCSV absent,  RI present:  same as RI
 (III) SCSV present, RI absent:   same as empty RI
 (IV)  SCSV present, RI present:  same as RI (SCSV ignored)


(I) describes the ClientHello from an old client

(II) represents (i1a), and depending on the contents
     of RI additionally (i2a) or (i3a)

(III) represents (i1a')

(IV)  represents (i1a') and depending on the contents
      of RI additionally (i2a) or (i3a)


Marsh is questioning that (IV) makes sense.

Let's check our architecture:

What semantics has the combination of (a1a) and (a2a) according
to the architecture of our solution:

 (a1a)  Client->Server "Hi, I'm updated -- new handshake semantics please"
 (a2a)  Client->Server "this is an initial handshake"


What semantics has the combination of (a1a) and (a3a) according
to the architecture of our soltion:

 (a1a)  Client->Server "Hi, I'm updated -- new handshake semantics please"
 (a3a)  Client->Server "this is a renegotiation handshake"


I really do not see an problem with allowing (IV) for our architecture.


So what is left is a simple matter of wordsmithing.


-Martin