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

From: Marsh Ray <[email-masked]>
Date: Fri, 18 Dec 2009 14:12:54 -0600

Martin Rex wrote:
> Marsh Ray wrote:
>> Martin Rex wrote:
>>>
>>> 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.
> 
> "A secure handshake" is one where client and server will check
> whether the contents of the TLS renegotiation RI match the
> verify_data from the Finished messages from the enclosing TLS session
> and TLS peers should abort the handshake if the conveyed information
> does not match.  The presence of an empty TLS extension RI in ClientHello
> is obviated by presence of SCSV in this ClientHello handshake message.

OK, let's see how that definition passes the substitution test:

"TLS_RENEGO_PROTECTION_REQUEST is a request from the client to the
server to perform a handshake where client and server will check whether
the contents of the TLS renegotiation RI match the verify_data from the
Finished messages from the enclosing TLS session and TLS peers should
abort the handshake if the conveyed information does not match and
confirm this by sending TLS extension RI in ServerHello."

Hmm, complete nonsense. That definition talks about how RI data is
interpreted which is the antithesis of what SCSV is about.

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.

Real difficulties in doing this is, in my experience, a pretty good sign
that something is wrong with a design.

I think this is possible to do with wording (I) and much more
challenging with the others.

> Do not try to describe scenarios.  That is completely unecessary,
> very confusing and you may easily get the description of one of
> the cases wrong and cause confusion among implementors.

So you can't define SCSV, and I can't enumerate the scenarios where it
can be used either?

> The implementer's feedback was:
> In order to implement this MUST NOT I have to add two extra conditionals
> to the code, and I have to build test cases to check whether that doesn't
> break anything and whether I am compliant -- but in reality these
> two conditionals are completely useless, they do not add any value
> to the protocol and neither to the security.

I would build those test cases anyway.

Having all cases defined and handled in an intentional way (even where
they are defined to be ignored) is a good thing and inherently valuable.
Perhaps nowhere more so than in the TLS initial hello handshaking.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 18 Dec 2009 12:37:00 -0800

> 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."

Mike

---

From: Marsh Ray <[email-masked]>
Date: Fri, 18 Dec 2009 14:46:01 -0600

> as an empty RI.  When RI is present, SCSV is ignored."

Hmmm...doesn't quite meet the stated requirements.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 18 Dec 2009 13:02:57 -0800

> 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!!"?

Mike

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 Dec 2009 22:47:58 +0100 (MET)

> 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

---

From: Steve Checkoway <[email-masked]>
Date: Sat, 19 Dec 2009 00:46:45 -0800

> Why do you want the last one to be "ABORT!!"?

It's pretty clear (to me) that it doesn't matter if the last one is  
allowed or not, as long as the spec makes a clear decision. It's  
roughly the same amount of code (plus or minus a conditional and an  
alert). The four conditions have to be tested regardless of how it's  
defined.

Is this point really so important that it's worth holding up  
publication and subsequent implementation? I say it is not.

-- 
Steve Checkoway

     "Anyone who says that the solution is to educate the users
     hasn't ever met an actual user." -- Bruce Schneier