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

From: "Blumenthal, Uri - 0662 - MITLL" <[email-masked]>
Date: Sun, 20 Dec 2009 19:53:56 -0500

OK. Karlsruhe server time-outs on me, so no chance to get enlightened by checking that thread. Please indulge me: the one short compelling reason why we don't want to say "when two signals are present use this one and ignore the other" instead of "when two signals are present - abort connection" - is...?

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Steve Checkoway <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Sun Dec 20 17:39:47 2009
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

Steve Checkoway wrote:
> 
> My point was merely that publication and subsequent implementation of  
> the fix is more important than worrying about the specifics of what  
> happens when two signals are used (as long as it is clearly specified,  
> of course). Others may feel differently.

http://digbib.ubka.uni-karlsruhe.de/volltexte/documents/1827

-Martin
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: <[email-masked]>
Date: Mon, 21 Dec 2009 09:57:19 +0100

Uri Blumenthal wrote:

> OK. Karlsruhe server time-outs on me, so no chance to get enlightened
> by checking that thread. Please indulge me: the one short compelling
> reason why we don't want to say "when two signals are present use this
> one and ignore the other" instead of "when two signals are present -
> abort connection" - is...?

Well, if the spec says "the client MUST not send two signals", then if
two signals are present, it's probably safer to abort (since the
client is not following the spec anyway, it's hard to guess
what its intent was...)

Best regards,
Pasi
(not wearing any hats)

---

From: Yoav Nir <[email-masked]>
Date: Mon, 21 Dec 2009 11:01:00 +0200

It makes the semantics of SCSV unclear. Not a good enough reason in my opinion, but still...

On Dec 21, 2009, at 2:53 AM, Blumenthal, Uri - 0662 - MITLL wrote:

> Scanned by Check Point Total Security Gateway.

---

From: Martin Rex <[email-masked]>
Date: Mon, 21 Dec 2009 16:16:01 +0100 (MET)

Blumenthal, Uri - 0662 - MITLL wrote:
>
> Please indulge me: the one short compelling reason why we don't want
> to say "when two signals are present use this one and ignore the other"
> instead of "when two signals are present - abort connection" - is...?

I do not think such a reason exists.

The justification that has been given so far is
"because that is what the document says".

If you look at the document from the perspective of formal correctness
proofing, then this is justification is based on a defect in the document.

> by checking that thread.

That URL refers to a publication called 
  "Would you ever risk a non-monomorphic specication?"
It is about formal correctness proofing of specifications
and implementations.

I am _not_ an expert in the field of formal correction proofing,
and in theoretical math stuff, I am more of a practical type of person.

But I have a good understanding of some of the principles and
methodologies involved.  In 1996 I shared office for 5 month with
a student from the University of Karlsruhe who did his master
thesis at our company developing a formal specification for the
authorization model in our application software and doing a
formal correctness proof, using a tool called
"Karlsruhe Interactive Verifier (KIV)" which was also used for
above document.  This resulted in a number of fixes to our
design and implementation.

I found the underlying concepts and methodologies so interesting
and intriguing that I started implmenting a "generic" gssapi-mechanism
in order to locate inconsistencies and ambiguities in the GSS-API v2
during the following 2 years, and get them fixed in the
IETF CAT WG before publishing GSS-API v2.

(the most part of this generic implementation was re-used to build
 my gssntlm.dll/gsskrb5.dll wrappers for Microsoft NTLM and
 Kerberos 5 SSP to provide a GSS-API v2 compliant API
 ftp://ftp.sap.com/pub/ietf-work/gssapi/gsskrb5/)

The methodology of the KIV tool is to create an implementation
of the given specification, and it asks the operater to manually
("interactively") resolve all ambiguities and conflicts that prevent
an full implementation of the spec.  The KIV tool will actually
output a 100% bugfree implementation of the spec (back then you
could ask for C or C++ output).

Probably the biggest and most time-consuming part for tool-based
formal verification is the translation from a specification that
mere humans understand into predicate logic (and backwards for
all the resolved problems).

What formal proofing does _not_ provide is coming up with
specification that are actually useful and do what you want.

The most intriguing part is, that the methodology not only
works for the spec -> code transformation, it can also
be used for the  solution-architecture -> spec transformation.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 21 Dec 2009 09:06:03 -0800

So what's the consensus on this?

   1) client MUST not send both signals, and a server MUST abort
      if it sees both

or

   2) client MAY send both signals, and the server MUST ignore
      SCSV when RI is present

I prefer (2) since there is no security problem with the client sending
both -- the only problem is the current wording in the spec.  Remember
the spec is currently a DRAFT, and that means it is open to changes!  I
don't understand the reluctance to clarify this.

Mike

---

From: Dr Stephen Henson <[email-masked]>
Date: Mon, 21 Dec 2009 17:37:41 +0000

> don't understand the reluctance to clarify this.

I'd have a minor preference for #2 but I'd also vote for option #3

3) Couldn't give a toss just get the fecking spec finalised, OK?

;-)

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Martin Rex <[email-masked]>
Date: Mon, 21 Dec 2009 18:50:12 +0100 (MET)

> client is not following the spec anyway, it's hard to guess

There would only be an ambiguity when the signal could indicate
two different semantics.

The description of the semantics of TLS_RENEGO_PROTECTION_REQUEST
in draft-tls-renegotiation-02 is defective and needs to be fixed.

The currently flawed defintion for TLS_RENEGO_PROTECTION_REQUEST
is what caused this:

  http://www.ietf.org/mail-archive/web/tls/current/msg05155.html
  http://www.ietf.org/mail-archive/web/tls/current/msg05186.html

and resulted in this text in draft-tls-renegotiation-02.txt:

  6.1  Client Considerations

   [TODO:  this needs a discussion of what signal to send in legacy
   renegotiation to match the resolution of the paired TODO in Section
   4.]

The purpose of TLS_RENEGO_PROTECTION_REQUEST is to request _ONLY_ the
new handshake semantics (which first-of-all concerns those peers
in the communication that are performing a renegotiation handshake).

The resistence to adopting the correct semantics for
TLS_RENEGO_PROTECTION_REQUEST is probably because from the viewpoint
of formal correctness proofing, the correct definition implies that
this signal MUST be asserted on every ClientHello (because the absence,
that would then indicate "old handshake semantics" would be incompatible
with the presence of an TLS extension RI.

But for the old renegotiation scenario, the result of the correct
definition of TLS_RENEGO_PROTECTION_REQUEST would provide an obvious,
intuitive and fully backwards interoperable solution.  
In addition, everyone would save code, and the solution would
become less complex.

What makes me feel slightly uneasy is that some people think the
above is a special case that needs to be seperately addressed
in the document.  With a clean architecture, that is no special
case.  The problem with draft-tls-renegotiation-02 is, that it
comes without architecture.  It is an implementation of an
unspecified solution architecture.  And that leads to discussions
about belief, rather than characteristics of a specific
(spec-level) implementation of a solution architecture, where
it is possible to check implementation details with methodologies
used in formal correctness proofs.

The reason why the TLS renegotiation vulnerability was not noticed
for so long is quite related to this.  The SSL and TLS protocols
completely failed to describe its architecture, otherwise the
defect would have been obvious.  Once I had described the
architecture of TLS renegotiation to Larry and Nico in the
discussion about channel bindings early November, it became
obvious to me, from last paragraph of this:

  http://www.ietf.org/mail-archive/web/tls/current/msg03922.html

to this:

  http://www.ietf.org/mail-archive/web/tls/current/msg03928.html

And that applies to all other problems recently discussed.
The lack of an (explanation of) the architecture hides most
of the problems, like identity change during renegotiation,
the possibility of application data interleaved with renegotiation
handshakes, the effect of TLS session resumption and TLS session
caching strategies on certificate path validation.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 21 Dec 2009 09:55:24 -0800

I agree we need to publish ASAP, but if consensus is (1), then I need
to change my (running) code since it currently does (2).

Mike

---

From: Marsh Ray <[email-masked]>
Date: Mon, 21 Dec 2009 12:01:50 -0600

Is everybody OK with this wording? (it's the more lenient choice):

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

- Marsh

---

From: Nasko Oskov <[email-masked]>
Date: Mon, 21 Dec 2009 18:20:16 +0000

Marsh Ray wrote:
>> 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.

I generally agree with this wording. I find the sentence describing multiple
RI extensions behavior redundand, since this is already part of RFC5246:

Section 7.4.1.4:
    There MUST NOT be more than one extension of the same type.

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

Agreed.

Nasko

---

From: Marsh Ray <[email-masked]>
Date: Mon, 21 Dec 2009 12:46:41 -0600

>     There MUST NOT be more than one extension of the same type.

Oh yeah. It's also in RFC 3546 'TLS Extensions'. I looked for it the
other day but didn't see it. Now I can't find where it says what to do
when it happens.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 21 Dec 2009 12:58:03 -0800

>> and an RI extension is to interpret the RI as usual and ignore the

As Nasko pointed out, we don't need to talk about multiple RI extensions.
So this could collapse into something like:

   Clients MAY send SCSV in all ClientHellos, even when also sending
   an RI extension (either empty or containing data).  Servers MUST
   ignore SCSV when the client has also sent RI.

>> has similar semantics as an empty "renegotiation_info" extension.

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.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Mon, 21 Dec 2009 15:20:44 -0600

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

>   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:

// to:

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Tue, 22 Dec 2009 10:23:11 +0200

>> and an RI extension is to interpret the RI as usual and ignore the

I like that (with or without Nasko's suggestion)

>> has similar semantics as an empty "renegotiation_info" extension.

We might want to specify what a client should do if the server chooses the SCSV cipher suite.  Obviously, close the connection, but with what alert?