Subject: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV

From: Martin Rex <[email-masked]>
Date: Wed, 9 Dec 2009 21:20:56 +0100 (MET)

Here is my analysis of the requirements and implementation efforts
for TLS extension RI with magic cipher suites value (MCSV), based on my
recent experiences from implementing draft-mrex-tls-secure-renegotiation-03
in OpenSSL-0.9.8l and looking at the early implementation of draft-rescorla
in the OpenSSL-0.9.8-snapshot.

The purpose of the MCSV is:

  - provide interop with installed base of old, extensions-intolerant
    servers (original&correct SSLv3 and "defective" TLSv1.0)

  - provide protection from downgrade attacks
    (extension-less ClientHello or SSLv2 ClientHello)

  - provide protection in backwards interop scenarios
    (renegotiation requested by old servers).

in order to reliably provide this,

  - MCSV is defined to represent an empty TLS extension RI

  - MSCV MUST be included in *ALL* initial ClientHello handshakes
    messages _plus_ all renegotiation ClientHellos in backwards
    interop scenarios (independent of full handshake or session resume).

  - empty TLS extension RI MUST NOT be sent, ever!

  - TLS extension RI with Client.Finished.verify_data in ClientHello
     - MUST NOT be sent on renegotiation handshakes in backward
       interop scenarios with old servers which could otherwise break
     - MUST be sent in all other renegotiations

If the spec would require that an empty TLS extension RI in a
ClientHello MUST be completely ignored, then _everyone_ can save 5-10 LoC.

There is a significant difference between extensions-tolerant and
extensions-support.  Extensions tolerant means, that a server
will not choke on a ClientHello handshake message, but instead
simply ignore all data following compression methods compliant
to the provision in the updated-but-never-published SSLv3,
TLSv1.0 and TLSv1.1 specs.

In order to implement secure renegotiation with TLS extension RI
a "generic" TLS extensions parser (~150 LoC) is necessary to
find the TLS extension RI among other extensions, process it
and create and process the TLS extension RI reply.  Support
for other TLS extensions and API-level access to TLS extensions
is completely out-of-scope for the following.

Adding MCSV to ClientHello on the client and parsing MCSV from
the ClientHello on the server will typically be <10 LoC each.

Creating an processing an empty TLS extension RI on the ServerHello
is also typically <10 LoC each for extension-less implementations.

Types of TLS peers in the current installed base:

1.)  old TLS client, no extensions, no renegotiation

2.)  old TLS client, no extensions,    renegotiation

3.)  old TLS client,    extensions, no renegotiation

4.)  old TLS client,    extensions,    renegotiation

5.)  old TLS server, extensions-intolerant, no renegotiation 

6.)  old TLS server, extensions-intolerant,    renegotiation 

7.)  old TLS server, no extensions,         no renegotiation 

8.)  old TLS server, no extensions,            renegotiation 

9.)  old TLS server, extensions,            no renegotiation

10.) old TLS server, extensions,               renegotiation

The server patches that are currently applied in the field are
(6)  -> (5)
(8)  -> (7)
(10) -> (9)

Additional types of TLS peers when TLS extension RI is implemented:

11.) updated TLS client, RI-minimal,    no renegotiation

12.) updated TLS client, RI-only,          renegotiation 

13.) updated TLS client,    extensions, no renegotiation

14.) updated TLS client,    extensions,    renegotiation 

15.) updated TLS server, RI-minimal,    no renegotiation

16.) updated TLS server, RI-only,          renegotiation

17.) updated TLS server,    extensions, no renegotiation

18.) updated TLS server,    extensions,    renegotiation

Effect of requiring MCSV on implementation effort
-- for non-renegotiating servers:

If we require MSCV on _every_ ClientHello
then the update (5),(6),(7),(8) -> (15) amounts to ~20 LoC
     the update        (9),(10) -> (17) amounts to ~40 LoC 

If we do not require MCSV on _every_ ClientHello
then the update (5),(6),(7),(8) -> (15) amounts to ~80 LoC
     the update        (9),(10) -> (17) amounts to ~60 LoC

Effect of requiring MCSV on implementation effort
-- for non-renegotiating clients:

If we require MCSV on _every_ ClientHello,
then the update (1),(2) -> (11) amounts to ~20 LoC
                (3)     -> (13) amounts to ~40 LoC

If we do not require MCSV on _every_ ClientHello,
then the update (1),(2) -> (11) amounts to ~80 LoC
                (3)     -> (13) amounts to ~60 LoC

guestimates about secure rengotiation efforts:

Servers: these are independent of whether MCSV is required
(10)     -> (18)  maybe ~180 LoC
(6),(8)  -> (16)  maybe ~200 LoC
(6),(8)  -> (18)  maybe ~250 LoC

Clients: these are independend of whether MCSV is required.
(4)  -> (14)  maybe ~180 LoC
(2)  -> (12)  maybe ~200 LoC
(2)  -> (14)  maybe ~250 LoC

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Wed, 09 Dec 2009 15:47:58 -0600

Martin Rex wrote:
> for TLS extension RI with magic cipher suites value (MCSV), based on
>  my recent experiences from implementing 
> draft-mrex-tls-secure-renegotiation-03 in OpenSSL-0.9.8l and looking
>  at the early implementation of draft-rescorla in the 
> OpenSSL-0.9.8-snapshot.
> 

The draft-freier-ssl-version3-02.txt says to ignore data after the
Client Hello, which implies extension-intolerant SSLv3 servers are
defective, too. Not that it really matters at this point. Had you
mentioned something about an earlier version not saying that?

> - provide protection from downgrade attacks (extension-less 
> ClientHello or SSLv2 ClientHello)

It enables clients which choose to send an SSLv2-compatible Client Hello
to do so and indicate support for RI.

> - provide protection in backwards interop scenarios (renegotiation 
> requested by old servers).

It will never be safe to conduct renegotiation with a remote party in
the absence of negotiated RI.

The expectation is that clients and servers will be transitioned into
"strict mode" at the earliest opportunity.

> messages _plus_ all renegotiation ClientHellos in backwards interop 
> scenarios (independent of full handshake or session resume).

MCSV or an empty RI extension should be sent in

> - empty TLS extension RI MUST NOT be sent, ever!

No, you just shouldn't send it if you prefer to interop with old, broken
servers. Lots of clients (browsers, etc) currently do send extensions on
Client Hello, so they may never choose to send MCSV on those connections.

It is hoped that at some point in the future, extension-intolerant (and
-ignorant) servers will be insignificant and the MCSV can stop being
sent by clients.

Yes, the MCSV is a work-around for old broken servers. This work-around
does not constitute the endorsement of brokenness by anyone. It's simply
that in this one bugfix we are choosing to be extra accommodating.

> - TLS extension RI with Client.Finished.verify_data in ClientHello -
>  MUST NOT be sent on renegotiation handshakes in backward interop 
> scenarios with old servers which could otherwise break

They are already broken. It's better to break them in a way that doesn't
represent a vulnerability.

There's no safe way to renegotiate with a remote party that doesn't
properly use RI on all handshakes.

To the extent that both parties have an interest in ensuring the
connection is secure against MitM attacks, it's not even safe to
complete an initial handshake and set up a connection with a remote
party that doesn't properly use RI on all handshakes.

Realistically, people will need a temporary "compatible mode" in place
during deployment of the patch. But you don't gain much actual security
in that mode.

> - MUST be sent in all other renegotiations

All renegotiations.

> ClientHello MUST be completely ignored, then _everyone_ can save 5-10

Why would you want to ignore that a client is attempting to negotiate
the use of RI?

> extensions-support.  Extensions tolerant means, that a server will 
> not choke on a ClientHello handshake message, but instead simply 
> ignore all data following compression methods compliant to the 
> provision in the updated-but-never-published SSLv3, TLSv1.0 and 
> TLSv1.1 specs.
> 
> In order to implement secure renegotiation with TLS extension RI a 
> "generic" TLS extensions parser (~150 LoC) is necessary to find the 
> TLS extension RI among other extensions, process it and create and 
> process the TLS extension RI reply.  Support for other TLS extensions
>  and API-level access to TLS extensions is completely out-of-scope 
> for the following.

Yep. They have to write a few lines of code to implement a tiny part of
the June 2003 RFC 3546 on TLS extensions.

> Adding MCSV to ClientHello on the client and parsing MCSV from the 
> ClientHello on the server will typically be <10 LoC each.
> 

So you're saying that an implementor who has let their code rot for the
last 6.5 years could save 140 LoC?

Personally, I don't find that to be a primary consideration.

> 1.)  old TLS client, no extensions, no renegotiation

* Vulnerable to injection when talking to an unpatched or
compatible-mode server which allows renegotiation.
* Vulnerable to credential stealing when supplying client auth and
routed by the attacker to an unpatched or compatible-mode server which
allows renegotiation.

> 2.)  old TLS client, no extensions,    renegotiation

* Vulnerable to injection when talking to an unpatched or
compatible-mode server which allows renegotiation.
* Vulnerable to credential stealing when supplying client auth and
routed by the attacker to an unpatched or compatible-mode server which
allows renegotiation.
* Possibly vulnerable to a client-side renegotiation attack.

> 3.)  old TLS client,    extensions, no renegotiation

* Vulnerable to injection when talking to an unpatched or
compatible-mode server which allows renegotiation.
* Vulnerable to credential stealing when supplying client auth and
routed by the attacker to an unpatched or compatible-mode server which
allows renegotiation.

> 4.)  old TLS client,    extensions,    renegotiation

* Vulnerable to injection when talking to an unpatched or
compatible-mode server which allows renegotiation.
* Vulnerable to credential stealing when supplying client auth and
routed by the attacker to an unpatched or compatible-mode server which
allows renegotiation.
* Possibly vulnerable to a client-side renegotiation attack.

> 5.)  old TLS server, extensions-intolerant, no renegotiation

* Broken according to every spec published in the last 13 years.
* Possibly vulnerable to a client-side renegotiation attack.

> 6.)  old TLS server, extensions-intolerant,    renegotiation

* Broken according to every spec published in the last 13 years.
* Vulnerable to injection when talking to an unpatched or
compatible-mode client.
* Possibly vulnerable to a client-side renegotiation attack.

> 7.)  old TLS server, no extensions,         no renegotiation

* Possibly vulnerable to a client-side renegotiation attack.

> 8.)  old TLS server, no extensions,            renegotiation

* Vulnerable to injection when talking to an unpatched or
compatible-mode client.
* Possibly vulnerable to a client-side renegotiation attack.

> 9.)  old TLS server, extensions,            no renegotiation

* Possibly vulnerable to a client-side renegotiation attack.

> 10.) old TLS server, extensions,               renegotiation

* Vulnerable to injection when talking to an unpatched or
compatible-mode client.
* Possibly vulnerable to a client-side renegotiation attack.

> The server patches that are currently applied in the field are (6) ->
>  (5) (8)  -> (7) (10) -> (9)

Reasonable to assume.

> 11.) updated TLS client, RI-minimal,    no renegotiation

Could you explain what you mean by RI-minimal, RI-only, and "extensions".

> Effect of requiring MCSV on implementation effort -- for 
> non-renegotiating servers:
> 
> If we require MSCV on _every_ ClientHello then the update 
> (5),(6),(7),(8) -> (15) amounts to ~20 LoC the update        (9),(10)
>  -> (17) amounts to ~40 LoC
> 
> If we do not require MCSV on _every_ ClientHello then the update 
> (5),(6),(7),(8) -> (15) amounts to ~80 LoC the update        (9),(10)
>  -> (17) amounts to ~60 LoC

> Effect of requiring MCSV on implementation effort -- for 
> non-renegotiating clients:
> 
> If we require MCSV on _every_ ClientHello, then the update (1),(2) ->
>  (11) amounts to ~20 LoC (3)     -> (13) amounts to ~40 LoC
> 
> If we do not require MCSV on _every_ ClientHello, then the update 
> (1),(2) -> (11) amounts to ~80 LoC (3)     -> (13) amounts to ~60 LoC

Those tiny LoC differences are not significant, especially considering
the margin of error for those types of things. Usually you're lucky to
get within a factor of two.

They certainly don't give a realistic indication of "level of effort".

> Servers: these are independent of whether MCSV is required (10) -> 
> (18)  maybe ~180 LoC (6),(8)  -> (16)  maybe ~200 LoC (6),(8)  -> 
> (18)  maybe ~250 LoC
> 
> Clients: these are independend of whether MCSV is required. (4)  -> 
> (14)  maybe ~180 LoC (2)  -> (12)  maybe ~200 LoC (2)  -> (14)  maybe
>  ~250 LoC

I think the conclusion that we can draw from those numbers is that it's
more code than fixing a missing semicolon, and less code than a
medium-sized coding project.

Looks pretty reasonable for a bug fix to me. Looks like a lucky break
considering the depth at which the problem lies.

Thanks for working out all those estimates.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 10 Dec 2009 00:09:16 +0100 (MET)

> mentioned something about an earlier version not saying that?

The official SSLv3 spec doesn't say that!

The IETF archives do not know freier-ssl-version3-02  (only -00 and -01)
freier-ssl-version3-02 is probably what is known as
draft-ietf-tls-ssl-version3-00.txt -- a document which the TLS WG
chose _NOT_ to publish as informational, and which Netscape did
_NOT_ see as an official spec, otherwise they would have updated
their much more prominently offered versions of the SSLv3 spec
based on the freier -01 draft _without_ the extensibility option.

> the absence of negotiated RI.

That is wrong.  An old server (potentially an extensions-intolerant one)
does only mean that renegotiation with _that_ old server will remain
unprotected.

What secure TLS renegotiation should protect from is a downgrade attack,
that an MitM acts as an old extensions-intolerant server and then
proxies an updated clients renegotiation with an presumably old server
into the handshake of a backwards-compatible updated server.

Only MCSV can provide this protection.  TLS extension RI on
renegotiation will break interop with all old servers that request
renegotiation.

> "strict mode" at the earliest opportunity.

You seem to entirely ignore the transition period.
We can not shut down the entire internet, wait for 6 or 12 months
until everybody has updated every client and server, and then
re-launch the internet.

If we do not provide provisions for smooth interop for at least the
transition period, it will hurt _everyone_!

Users and admins will _not_ install client-side patches if these
are disruptive to some usage scenarios (it's mostly a server problem).
And when clients are not updated, then Server operators that need
that functionality and do not want to loose significant sales
can not disable old renegotiations on their servers.

> Client Hello, so they may never choose to send MCSV on those connections.

Several hundred millions clients do _not_ send extensions on ClientHello.

> -ignorant) servers will be insignificant and the MCSV can stop being

5-10 years.

> that in this one bugfix we are choosing to be extra accommodating.

No, MCSV is _not_ only a necessesity for a few broken TLSv1.0 servers,
it is also a necessity for a number of fully compliant SSLv3 servers
_and_ it is an enabler to _relief_ old servers (including extensions-tolerant)
from having to add 5x the amount of code to their code base which has
nothing to do with the underlying security problem.

> represent a vulnerability.

The client can easily abort when it doesn't like the server's answer,
so there is absolutely _no_ justification for the client to send
data that will cause interop problems.  For an updated server in
an MitM attack scenario, the presence of the MCSV is sufficient to
realize that it is talking to an updated client that is probing.

> properly use RI on all handshakes.

You're confused.  This requirement is about protection from MitM-attacks,
it is _NOT_ about successful secure renegotiations (which are not
possible when talking to an old server in backwards interop mode).

> Why would you want to ignore that a client is attempting to negotiate

Simple answer: to facilitate testing and QA.  Make sure that every
client is correctly sending MCSV.  We do not need two signaling
mechanisms where one is perfectly sufficient.  Besides, MCSV is
3-5 octets less on the wire and you need the code for MCSV anyway--
so the most reasonable solution is to make it mandatory to use.

> Personally, I don't find that to be a primary consideration.

Rot for 6.5 years?  What are you talking about?

There is even brand new code under active maintenance without
support for TLS extensions.  TLS extensions is purely optional, not
part of the vulnerability and does not need to be part of the solution.

Besides, in those cases where it is about code that has been mostly
unchanged for 6+ years, it is not "implementers" who will have to
add the secure renegotiation patch, it will often be "maintainers"
with little knowledge about the code -- and then, it makes perfect
sense to ask them for only 20 lines of code instead of 150+

> Could you explain what you mean by RI-minimal, RI-only, and "extensions".

RI-minimal client (one which does not implement renegotiation):

  sends MCSV on ClientHello, tolerates ServerHellos with extra data
  following compression-method, i.e. will complete handshake
  if that extra data is 7 octets long and resembles an empty extension RI

    0x00 0x05 0xFF 0x01 0x00 0x01 0x00

  and abort the handshake otherwise.

RI-minimal server (one which does not implement renegotiation):

  searches MCSV in ClientHello, ignores TLS extensions completely
  sends back the above 7 octets extra data after compression_method
  in ServerHello when MCSV was found.

RI-only client (one which does not implement TLS extensions in general
  but adds secure renegotiation with TLS extension RI):

  minimalistic TLS extensions support, only for TLS extension RI,
  sends MCSV in initial ClientHellos,
  sends TLS extension RI with Client.Finished.verify_data on renegotiation
  can parse TLS extension RI in ServerHello,
  and in order to reliably recognize updated Servers on renegotiation,
  it must be able to find TLS extension RI among other ServerHello
  extensions (or abort if there are others)

RI-only server (one which does not implemet TLS extensions in general
  but adds secure renegotiation with TLS extension RI):

  minimalistic TLS extensions support, only for TLS extension RI,
  can find and parse TLS extension RI in ClientHello between other
  extensions,
  will send back fixed 7-octet string above on initial handshakes
  and TLS extension RI with content on renegotiation handshakes
  when the ClientHello contains MCSV or TLS extension RI.

> get within a factor of two.

20 LoC vs. 80 LoC can be a HUGE difference for old code that one
doesn't know.

~20 LoC is  1 day implementing, 1 day testing.
~80 LoC is  3 day implementing, 5 day testing.

> They certainly don't give a realistic indication of "level of effort".

I've been doing development, support, maintenance and QA for mission
critical software for the past 14 year, and I can assure you, they
do give a pretty good picture about the effort.

If you're providing free and open source software, you might not
worry about trial-and-error.

If you are a software vendor that charges for maintenance, then it
is a completely different issue.  You do not change any code that
has been in extended maintenance mode for a few years, and the
original authors of that code are likely not the ones who will
have to patch the code.  There are software logistic procedures
in place that make it extremely expensive and extremely unlikely
that you make code changes that break interoperability "unintentionally".

Have you worked for a software company with 5000+ software developers
during the last three years?

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 10 Dec 2009 01:18:34 +0100 (MET)

> the absence of negotiated RI.

As I wrote a while ago, the name "TLS_RENEGO_PROTECTION_REQUEST"
was chosen _not_ as a requst for secure renegotiation (which it is NOT),
but as a request for _protection_ from the vulnerability through
old TLS renegotiation.

There are two different issues that the fix needs to provide:

  - secure renegotiation between updated clients and servers
    directly talking to each other

  - protection from MitM attacks in all 3 attack scenarios

  - protection from MitM attacks for communication between
    updated clients and updated servers even when both allow
    old renegotiation for backwards interop.

The secure renegotiation is provided by "authenticating" the
verify data from the previous finished messages.  TLS extension RI
performs the authentication with memcmp() on data exchanged
through a TLS extension in the renegotiation handshake.

The protection is provided through negotiating/signaling with the
peer that one is updated.

TLS extension RI does both with the same piece of data in the
handshake message (TLS extension RI), and it seems that some people
fail to understand the difference between the two things.

Previously, I wrote that draft-mrex-tls-secure-renegotiation-03.txt
is a "nanny spec", because it does _not_only_ describes how to perform
secure renegotiation, but it _also_ describes how to implement
backwards interop securely.  This discussion here sugggests that
this difference is unclear to at least some people, and therefore
should be better explained in the draft-ietf-tls-renegotiation-02
as well!

-Martin

---

From: Michael Gray <[email-masked]>
Date: Thu, 10 Dec 2009 12:16:24 +1000

>   - empty TLS extension RI MUST NOT be sent, ever!

This looks good to me, the only thing I would change is I think MUST NOT
would be better as SHOULD NOT as the later requires that the implementer
examine the conditions and implications etc to make the best decision.  We
know that many current browsers always send extensions and for that use
case there is no need to change due to this specification.  However we also
know that there is a large installed base of SSL consuming applications
that are not browser related that have never had any requirement process
extensions and therefore do not support extensions or are extension
intolerant.

> and create and process the TLS extension RI reply.

We used 177 LoC for a generic parser and another 106 LoC for the RI
specific logic.  However our experience is that additional effort to back
port into unfamiliar old code is far more costly in time than one would
expect based on LoC count even when considering we have current code that
supports extensions.

Additionally a large problem is testing this in code bases that do not
support extensions.  Manual testing can be done, but that is prone to
error, is costly, and time consuming each time we release code, which means
we will need to spend a lot more time developing automated testing.

> Support

Agree

> the ClientHello on the server will typically be <10 LoC each.

Agree

> The server patches that are currently applied in the field are

These are very good numbers and closely match an internal analysis I have
made.

It is likely there will be Servers in critical production environments that
can not be patched (e.g. vendor no longer in business) and they will have
to be fully replaced, as time, planning and evaluation allows (as I noted
here :  http://www.imc.org/ietf-tls/mail-archive/msg11082.html)

I think the fact that Clients may concurrently interact with Servers of
types 5 to 10, means that the MCSV ONLY proposal is the best solution for a
low risk deployment.

> (2)  -> (14)  maybe ~250 LoC

My guess is that at least five times the effort will be required to add
testing of this into existing auto test harnesses for code levels that do
not support extensions.  Interestingly this vulnerability fix is the only
reason these old code levels now need to support extensions.

Given this large test impact I find the
draft-mrex-tls-secure-renegotiation-03 alternate solution (which does not
require full extension implementation) to be preferable.

- Mick

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

---

From: Marsh Ray <[email-masked]>
Date: Thu, 10 Dec 2009 02:04:52 -0600

Replies to three emails in one.

Apologies in advance if this doesn't all get quoted perfectly.

Martin Rex wrote:
> The IETF archives do not know freier-ssl-version3-02  (only -00 and
> -01) freier-ssl-version3-02 is probably what is known as 
> chose _NOT_ to publish as informational, and which Netscape did _NOT_
> see as an official spec, otherwise they would have updated their much
> more prominently offered versions of the SSLv3 spec based on the
> freier -01 draft _without_ the extensibility option.

That is interesting information. Would you happen to have a copy of the
last "official" spec you can send me?

I probably got draft-freier-ssl-version3-02.txt from:
http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt
I don't know if that implies anything "official" past or present.

The IETF's DNS seems to be inoperative, but Google has a cached version of:
http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00

It has the same "it is permitted for a client hello message to include
extra data after the compression methods" language.

>> It will never be safe to conduct renegotiation with a remote party
>> in the absence of negotiated RI.
> 
> That is wrong.  An old server (potentially an extensions-intolerant
> one) does only mean that renegotiation with _that_ old server will
> remain unprotected.

And clients that care about the security of the connection had better
refuse to connect to it at all!

Servers receiving an initial connection request without a request for RI
will soon know some things:
1. The client software is not patched for security.
2. There's a good chance the client is vulnerable to one or more
variants of this basic attack.

Clients receiving a request for renegotiation without having previously
negotiated RI can expect that the server is vulnerable to MitM and they
may have already been pwned on this connection state.

Servers receiving a client-initiated renegotiation without having
previously negotiated RI can not know that it is the same party they
have on the current connection state.

Sure you can point to some combinations of (client renegotiates)x(server
renegotiates)x(specific protocol)x(specific implementation) that is not
vulnerable, but a fundamental guarantee of TLS is missing and most
setups are vulnerable to one or more attacks. Mix in the possibility of
application data between the handshake messages and it's just plain not
there.

Starting soon, the absence of RI on a hello is going to be an
increasingly strong indicator of "broken and insecure". Eventually, it
will just be discarded along with SSLv1 and v2.

> What secure TLS renegotiation should protect from is a downgrade
> attack, that an MitM acts as an old extensions-intolerant server and
> then proxies an updated clients renegotiation with an presumably old
> server into the handshake of a backwards-compatible updated server.

This is only a problem while you run in compatible mode.

> Only MCSV can provide this protection.

I'm missing something. How can MCSV fix "updated clients renegotiation
with an presumably old server"?

> TLS extension RI on renegotiation will break interop with all old
> servers that request renegotiation.

That's the least of your problems as a client. Your connection may have
already been pwned.

Before the renegotiation, you could have held out some hope that the
server would never renegotiate at all. But now that you know the server
does renegotiation it's like realizing that you've just sent your online
banking credentials to an unmaintained Debian Etch system.

How could one conduct a secure renegotiation without first establishing
that the initial negotiation was secure?  The server has an unknown
amount of evil buffered state and may be just waiting for you to supply
the credentials to act on it.

>> The expectation is that clients and servers will be transitioned
>> into "strict mode" at the earliest opportunity.
> 
> You seem to entirely ignore the transition period. We can not shut
> down the entire internet, wait for 6 or 12 months until everybody has
> updated every client and server, and then re-launch the internet.

Oh no, we mustn't shut down the entire internet!

> transition period, it will hurt _everyone_!

If you really want to renegotiate with old, broken, unpatched, and
extension-intolerant servers so badly that you're willing to do it
insecurely <em>then don't send them the freaking extension</em>!

Sending them an MCSV is at best going to be ignored by such a server, no
matter what semantics some document attaches to it.

Just don't expect an IETF I-D in 2010 to magically make something secure
that's been nominally obsolete since January 1999 (RFC 2246 TLS 1.0)
without having to add more than 20 lines of code!

> Users and admins will _not_ install client-side patches if these are
> disruptive to some usage scenarios (it's mostly a server problem). 
> that functionality and do not want to loose significant sales can not
> disable old renegotiations on their servers.

+10

>> Lots of clients (browsers, etc) currently do send extensions on 

Not relevant. What matters is the number of servers that hang in a slow
fail condition when sent an extension.

>> It is hoped that at some point in the future, extension-intolerant
>> (and -ignorant) servers will be insignificant and the MCSV can stop
>> being sent by clients.
> 
> 5-10 years.

I intend to still be capturing packets at that time.

>> Yes, the MCSV is a work-around for old broken servers. This
>> work-around does not constitute the endorsement of brokenness by
>> anyone. It's simply that in this one bugfix we are choosing to be
>> extra accommodating.
> 
> No, MCSV is _not_ only a necessesity for a few broken TLSv1.0
> servers, it is also a necessity for a number of fully compliant SSLv3
> servers

I believe you, but I can't find a copy of this SSLv3 spec anywhere on
the web. However, I don't think there are many on this list who place
much weight on the compliance to a spec that appears to have been
abandoned 11 years ago. What matters is what's in the field at this point.

> _and_ it is an enabler to _relief_ old servers (including
> extensions-tolerant) from having to add 5x the amount of code to
> their code base which has nothing to do with the underlying security
> problem.

Look, SSLv3 is broken. Everyone here did their best, but no one could
come up with a palatable solution that did not require the use of a
protocol extension, even if just for the S->C signaling. Therefore,
SSLv3 needs to either be completely deprecated or it needs to have added
minimal support for this one extension.

Vendors can choose to fix their old SSLv3 implementations if they want
to. There are real concessions to interoperability in the proposals. But
the fact that the fix to this long-abandoned protocol spec might take
100 lines of code instead of 20 is not going to drive the design.

> The client can easily abort when it doesn't like the server's answer,
And it must if it needs proper SSL/TLS security.

> so there is absolutely _no_ justification for the client to send data
> that will cause interop problems.

Sure there is: some clients get a positive benefit from the use of
extensions. How to manage the tradeoff between that benefit vs.
potential interactions with intolerant servers is something app
developers and admins/users currently manage.

> For an updated server in an MitM attack scenario, the presence of the
> MCSV is sufficient to realize that it is talking to an updated client
> that is probing.

Right. After that initial Client Hello with the MCSV, the server knows
that the client is patched and responds with an extension. From that
point on, the client knows he can send extensions. And both endpoints
now must send the extension on every single hello on that connection,
because they will have nonempty verify_data.

> You're confused.

Wouldn't be the first time.

> This requirement is about protection from MitM-attacks, it is _NOT_
> about successful secure renegotiations (which are not possible when
> talking to an old server in backwards interop mode).

Sorry, which requirement was that?

Again, full protection from these attacks (i.e. effective TLS) involves
refusing to handshake with an unpatched remote.

>> Why would you want to ignore that a client is attempting to
>> negotiate the use of RI?
> 
> client is correctly sending MCSV.

Or the RI extension.

> We do not need two signaling mechanisms where one is perfectly
> sufficient.

I don't think one is perfectly sufficient. Keep in mind the attacker
generally gets to choose which handshake is presented where. If you
allow conformant servers to not look for and validate the RI extension
on every single Client Hello they receive, it makes it possible for a
patched client's renegotiation handshake to be presented to a patched
server which doesn't validate it.

So MCSV only needs to be sent on the initial Client Hello, and then only
if you aren't sending extensions for any other reason and don't want to
upset an unpatched extensions-intolerant server.

The client must then validate the emptiness of the RI returned on the
Server Hello.

Patched clients and servers must validate the content of the (now
required to be present and nonempty) RI extension received on subsequent
Hellos. The MCSV field on subsequent Client Hellos is now redundant in
all cases (both valid and attack).

You can save three octets by not sending the MCSV when you're also
sending the RI extension.

> Besides, MCSV is 3-5 octets less on the wire and you need the code
> for MCSV anyway-- so the most reasonable solution is to make it
> mandatory to use.

That's a pretty weak argument, I know because I'm usually the one making it.

I'll take the cost of five extra octets over a phony cipher suite hack
any day.

>> So you're saying that an implementor who has let their code rot for
>> the last 6.5 years could save 140 LoC?
>> 

RFC 3546 TLS Extensions June 2003

> There is even brand new code under active maintenance without support
> for TLS extensions.

Well, guess what! The protocol now needs to be extended.

> TLS extensions is purely optional, not

s/is/were/

> part of the vulnerability and does not need to be part of the

No one came up with any other less-impactful way to do the required S->C
signaling, and not for lack of trying.

> unchanged for 6+ years, it is not "implementers" who will have to add
> the secure renegotiation patch, it will often be "maintainers" with
> little knowledge about the code -- and then, it makes perfect sense
> to ask them for only 20 lines of code instead of 150+

There's no 20 line fix for this. Neither is there a (palatable) solution
which does not use extensions. Last I checked,
draft-mrex-tls-secure-renegotiation used an extension.

> following compression-method, i.e. will complete handshake if that
> extra data is 7 octets long and resembles an empty extension RI
> 

OK, but it better do more than tolerate that data, it better require it.

By the way, do you of any TLS implementations that do not "implement
renegotiation"?

I'm sure they exist, but in general renegotiation seems to fall
naturally (hmmm, a bit too naturally) out of a straightforward
implementation.

> searches MCSV in ClientHello, ignores TLS extensions completely sends
> back the above 7 octets extra data after compression_method in
> ServerHello when MCSV was found.

If you write the spec that way, the world is married to the MCSV
forever. And we waste three bytes on every handshake. All for the sake
of some unknown-but-small number of servers which fail badly when sent a
modern Hello and will probably be put away for their own protection any
time now.

> RI-only client (one which does not implement TLS extensions in
> general but adds secure renegotiation with TLS extension RI):
> 
> minimalistic TLS extensions support, only for TLS extension RI, sends
> MCSV in initial ClientHellos, sends TLS extension RI with
> Client.Finished.verify_data on renegotiation can parse TLS extension
> RI in ServerHello, and in order to reliably recognize updated Servers
> on renegotiation, it must be able to find TLS extension RI among
> other ServerHello extensions (or abort if there are others)

Nothing wrong with that.

> minimalistic TLS extensions support, only for TLS extension RI, can
> find and parse TLS extension RI in ClientHello between other 
> extensions, will send back fixed 7-octet string above on initial
> handshakes and TLS extension RI with content on renegotiation
> handshakes when the ClientHello contains MCSV or TLS extension RI.

Nothing wrong there.

Nobody said you had to add general support for extensions.

All you have to do is iterate a list of TLVs looking for one type by number.

>> Those tiny LoC differences are not significant, especially
>> considering the margin of error for those types of things. Usually
>> you're lucky to get within a factor of two.
> 
> ~20 LoC is  1 day implementing, 1 day testing. ~80 LoC is  3 day
> implementing, 5 day testing.

I have heard of these teams which produce less than a screenful of code
a day.

Oh heaven forbid, somebody writes 80 lines of code.

Work three days? Do you know how many all-nights and all-weekends I did
to get a working test case going for this bug so I could fully
characterize it and give the most complete info to people who needed it
so they could come up with a workable solution in the shortest period of
time to minimize the risk of public disclosure? Every TLS implementation
that we could think of and get a non-disclosure agreement with has known
about this tentative proposal and the need to implement extensions since
the end of September! Most have experimental implementations already.

> critical software for the past 14 year, and I can assure you, they do
> give a pretty good picture about the effort.
> 
> If you are a software vendor that charges for maintenance, then it is
> a completely different issue.  You do not change any code that has
> been in extended maintenance mode for a few years, and the original
> authors of that code are likely not the ones who will have to patch
> the code.  There are software logistic procedures in place that make
> it extremely expensive and extremely unlikely that you make code
> changes that break interoperability "unintentionally".
> 

No, would you like me to write the 80 LoC for you?.

Martin Rex wrote:
> Marsh Ray wrote:
>> 
>> In order for this example to be a problem, the legitimate client
>> would have to renegotiate specifically for the purpose of dropping
>> certain cert credentials. This would seem to imply that the
>> application code was expecting cert changes.
> 
> The above code sample provide by Pasi is about client-side code, as
> indicated by "openTlsConnection" and the comparison 
> "conn.getPeerCert().getName() != expected_name"

Right.

> So this is more about server certificates changing then clients using
> different credentials.  And it is about apps coding above TLS, and
> not about details of TLS implementations.

So why would a legitimate server renegotiate a connection and switch
certificates in a way that could surprise a client and be manipulated
for evil? The renegotiation fix proves it's the same server with no
MitM. The last certificate is properly validated and accepted by the
client. By extension, this proves the previous connection states were
with the trusted server, too, with no interference from a MitM. Whatever
such a trusted server wanted to do to the client, he could also do
without involving the complexities of a renegotiation.

The reverse case applies equally for client certs but seems potentially
more plausible because of the way server certs are currently tied to
listening IP addresses.

> Since a non-negligible amount of clients will need allow old
> renegotiation for a little while, one might want to think about
> mitigating unexpected changes the server certificate.

Again, something bad could possibly happen but nobody's produced an
actual scenario. Perhaps something involving multiple sites behind a
confused reverse proxy?

> There are a lot of applications scenarios where this either doesn't 
> make any sense or will cause endless problems, support calls and confusion.
> Would you want your browser to send *ALL* your WWW-authenticate 
> credentials to every server and let the server pick (AFAIK the 
> protocol doesn't even allow that).
> In most Audit log facilities, you can only log *ONE* identity for 
> which an operation was attempted (and failed or succeeded), and not 
> an arbitrary set of identites.
> As soon as you have larger distributed systems, your TLS endpoint 
> might be a reverse proxy at the perimeter of the backend server farm.
> The reverse proxy [...] For HTTPS, a client that shows a different
> cert after renegotiation just doesn't make any sense most of the
> time.

My point wasn't that it was useful most of the time, or even any of the
time. My point was that these were the trust relationships implied by
the crypto as I understood it. I wouldn't mind being shown to be wrong,
but don't really care if you think it's useful or not.

> If the client wants to use a different cert, he should open a
> new network connection.

I do not believe that's not how all https servers work. Usually it's the
server asking for a different client cert. For example, Apache will
renegotiate for different crypto requirements as the connection
traverses different parts of the site. This has been demonstrated with
using an .htaccess file to trigger server-initiated renegotiation.

> If the reverse proxy or the backend wants to mitigate
> session-id-stealing it might employ a memcmp() on the certificates
> forwarded by the reverse proxy, and will rightfully abort if that
> changes.

Sure it might do that. Whether it's rightful or not depends on the
application protocol.

> A client architecture which allows the use of different client 
> certificates on different connects and does not reliably distinguish 
> TLS sessions established with different client properties (anonymous,
> client cert A, client cert B, ...) is probably broken.

Probably, but only because it seems few were aware of the hidden
potential (and pitfalls) provided by TLS renegotiation.

>> With renegotiation fixed, credentials supplied on different
>> handshakes may legitimately be treated as additive. This is how
>> https client certificates often work: an initial anon-client
>> connection adds a client cert to the connection by renegotiating.
> 
> Nope, that is not how it works.

You'll have to do better than that.

> A client that has not been previously
> authenticated performs a client cert authentication.  That is a
> highlander operation.

I'm not familiar with that term. Searching for it results in some NSA
wiretapping gone wrong.
http://www.wired.com/threatlevel/2008/10/kinne/

> Which of the TLS implementation actually keeps
> a set of certs/cert-chains for a TLS peer crowd created through
> renegotiation and has API calls to iterate through them? The
> implementations that I know have only APIs to request "THE" peer
> certificate.

I believe that list could be maintained by app code using the existing
APIs. Better that you don't do it as
"getJustTheMostRecentOneRemotePartyCert()" of course.

> So if there actually are apps today that can handle a multitude of
> client identites on a SSL/SecurityContext handle, they will likely 
> have to implement that at the app layer, because very few, if any TLS
> implementations provide "a set of TLS peers".

Well, tell me why it's flawed or I shall have to find an interesting use
for it!

>> It will never be safe to conduct renegotiation with a remote party
>> in the absence of negotiated RI.
> 
> As I wrote a while ago, the name "TLS_RENEGO_PROTECTION_REQUEST" was
> chosen _not_ as a requst for secure renegotiation (which it is NOT), 
> but as a request for _protection_ from the vulnerability through old
> TLS renegotiation.

Sure.

> - secure renegotiation between updated clients and servers directly
> talking to each other

Yes.

> - protection from MitM attacks in all 3 attack scenarios

Between which of
  ((patched|unpatched)x(compatible|strict))**2
x (client-side-renego | server-side-renego | dual-renego)

> - protection from MitM attacks for communication between updated
> clients and updated servers even when both allow old renegotiation
> for backwards interop.

Yes

> The secure renegotiation is provided by "authenticating" the verify
> data from the previous finished messages.

I wouldn't describe it that way. It's just checking that two values are
in agreement. These values were authenticated by the previous handshake
process.

Sides have the same, but independent, interests in thwarting MitM. It's
natural that they would cooperate to do the checking, but it's not
mutual authentication. Each side says "this is who I thought you were,
please look after me". Either side could lie when they send the RI data,
or fail to check when they receive it, but would gain nothing by doing so.

> TLS extension RI performs
> the authentication with memcmp() on data exchanged through a TLS
> extension in the renegotiation handshake.
> 

The negotiation is only necessary to enable the option of a compatible
but insecure mode, it's not part of the security. "Opportunistic
security" you might call it, but I hope it is only very temporary.

> is a "nanny spec", because it does _not_only_ describes how to
> perform secure renegotiation, but it _also_ describes how to
> implement backwards interop securely.  This discussion here sugggests
> that this difference is unclear to at least some people, and
> therefore should be better explained in the
> draft-ietf-tls-renegotiation-02 as well!

There are definitely some subtle points here.

- Marsh

---

From: "Dieter Bratko" <[email-masked]>
Date: Thu, 10 Dec 2009 14:33:27 +0100

> require full extension implementation) to be preferable.

+1

In environments where you already do a lot of implementation tricks to save
code any LoC saving is more than welcome. We have two SSL/TLS
libraries, one for J2SE (Java Standard Edition) and one (client-side) for
J2ME (Java Micro Edition). Whereas the J2SE version supports TLS extensions,
the J2ME version does not (not requested so far). One major goal of our J2ME
edition was (and is) to keep its size as small as possible (because this is 
the
main concern of our customers).
After implementing and comparing both alternative fixes
(for our J2SE library), we would prefer draft-mrex-tls-secure-renegotiation
(smaller code size increase, less bandwidth, easier to integrate into SSL
and extension-less TLS implementations, therefore less error prone,
less test amount and faster deployment).

- Dieter

---

From: Martin Rex <[email-masked]>
Date: Thu, 10 Dec 2009 17:13:03 +0100 (MET)

> last "official" spec you can send me?

Netscape's official SSLv3 spec as of 2005:
http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC.HTM

> extra data after the compression methods" language.

As obvious from it's name that spec is a product of the TLS WG and
the TLS WG decided to completely abandon (instead of publishing as
informational RFC) that document so that it expired and vanished
from the I-D repository 6 month later.

> variants of this basic attack.

If that is the impression that the current draft-ietf-tls-renegotiation-01
leaves with you, then this draft needs MAJOR updates of the description,
because it is not correct.

One obvious problem with draft-ietf-tls-renegotiation-01.txt is that
is extremely underspecified.  The TLS extension RI is overloaded in
semantics, and the spec doesn't spell it out.

In the original definition (without MCSV) TLS extension RI conveys
three distinct pieces of information:

  1.) indication that the TLS peer is updated for secure renegotiation
      (1 bit of information)

  2.) indication of whether the TLS peer is performing an initial
      or a renegotiation handshake
      (1 bit of information)

  3.) identification of the previous TLS session the TLS peer
      assumes to be renegotiating

Since all of this information is carried in the same TLS extension,
a correct spec and a correct implementation is a little complex.

Since the current document does not make this clear, the decision
what to send, in particular for backwards interop scenarios,
is non-obvious -- and obviously some people on this list, which
I believe to be experienced engineers, seem to have gotten this wrong.

The reason why my proposal is actually much simpler to explain
in full detail and simpler to implement, is that it uses two
completely seperate mechanisms to convey (1) and to achieve (3)
and it doesn't do (2) at all.  (Not doing 2 means that MitM attacks
can not be distinguished from other finished MAC errors im my I-D).

For interop scenarios with old servers, and as currently used by
conservative clients and reconnect fallbacks (extension-less ClientHellos,
SSLv3 ClientHellos and SSLv2 ClientHellos), sending a TLS extension
in the initial ClientHello would be a change with a significant
disruptive potential.  Not sending any indiciation of the update
for TLS renego protection leaves vulnerabilities, therefore MCSV
is used.

>From the server reply (ServerHello), the client can determine whether
it is talking to an old or an updated server--the updated Server will
return a TLS extension RI in ServerHello.

When the client has established a TLS session with a presumably
old server, and that server asks for renegotiation for whatever
reason (or maybe the client wants renegotiation for client identity
protection), then TLS extension RI is of *NO* use at all.

The only thing that TLS extension RI on the renegotiation ClientHello
with an old server is interop problems.  But not sending anything
would make the renegotiation vulnerable to a "downgrade attack"
with an updated server.  Therefore we need to use MCSV for the
renegotiation with an old server.  MCSV will allow an updated
server in an MitM scenario to prevent a renegotiation handshake
from succeeding.

If the updated server receives the MCSV on an initial handshake,
it will reply with an empty TLS extension RI, which will allow
the client to determine whether his renegotiation with an
presumably old server is proxied into the initial handshake
of an updated server, so the client MUST abort.

If the updated server receives the MCSV in a renegotiation handshake,
but no accompanying TLS extension RI with the client_verify data,
then the server MUST abort the renegotiation handshake because
this is likely an updated's clients initial handshake that is
proxied into the renegotiation handshake of an updated server.

> may have already been pwned on this connection state.

The client should not try to rationalize what and what not a server
might be doing.  The client should look at the handshake reply,
look at its policy/configuration and either abort the handshake
or continue.

> have on the current connection state.

Similarly, servers should not try to rationalize about clients, but
instead rely on policy/configuration and implement behaviour that
is mostly failsafe.

If an updated server receives a ClientHello on a renegotiation handshake
that carries an MCSV, but lacks the TLS extension RI containing the
Client.Finished.verify_data, then that server MUST abort the handshake.

> will just be discarded along with SSLv1 and v2.

Nope, it will be an MitM on backwards interopble clients, and many
of those clients will be updated and capable to send MCSV.

> matter what semantics some document attaches to it.

You're _not_ sending the MCSV for use by that old server,
you're including it so that this ClientHello can not be diverted/proxied
into the handshake of an updated server and result in a successful
handshake if that server is backwards interoperable.

> fail condition when sent an extension.

During my tests with openssl-0.9.8l I noticed that a client sending
a renegotiation ClientHello to openssl-0.9.8l will hang.  An openssl-0.9.8l
server seems to _not_ reply to this ClientHello (with a no_renegotiation
alert), but instead completely ignore the handshake message.  Not good.

> Look, SSLv3 is broken.

SSLv3 isn't broken.  It was just _not_ designed to be extensible.
If you look at TLS, it is not that much better.  It took them 7 years
to define extensibility.  They could have simply added a 4-octet bitfield
for future assignment as the first piece of TLS extensions right into
the TLSv1.0 spec.  If all you need to convey is a single bit of information,
then a single bit in a relatively fixed location of a handshake message
is _so_ much easier to use than the generic TLS extensions carriage.

> developers and admins/users currently manage.

As long as there are extensions-intolerant servers still in use,
only clients that have a re-connect fallback mechanism can benefit.

You may ship completely new products without fallbacks, but if
you are a software vendor, you definitely can not hotfix disruptive
changes into the installed base unless it is absolutely unavoidable
and your customers are willing to accept this.

For secure TLS renegotiation, the use of TLS extensions in a
disruptive fashion is easily and clearly avoidable.

> because they will have nonempty verify_data.

... I actually wrote about an MitM attack scenario here, where the
description of the further communication should describe which of
the peers should at which point realize that it is an attack and
abort -- and not how they would securely renegotiate.  ;-)

> Wouldn't be the first time.

I assume I am simply writing too much and make it difficult for
others to follow my line of thought that way.

I'm sorry for that.  It is not my intention to confuse.

> Sorry, which requirement was that?

Sending the MCSV on _every_ ClientHello (initial *AND* renegotiations).

> generally gets to choose which handshake is presented where.

One signaling mechanism (MCSV) to for conveying Client->Server that the
client is updated is perfectly sufficient.

For signaling that a client is performing a secure renegotiation
with an updated server and for identifying the previous TLS session
that the client presumes to be renegotiating, that is what
TLS extension RI containing Client.Finished.verify_data is about.

> all cases (both valid and attack).

No, it isn't.  It enables RI-minimal implemementations of old TLS servers
to detect proxied handshakes with updated MitMs.

You might want to take the position, that it is the client who is
being fooled, so only the client needs to be aware of the attack,
but *I* think that would be an incomplete fix.  

> Well, guess what! The protocol now needs to be extended.

No, it doesn't.  It needs to be fixed!

> > TLS extensions is purely optional, not part of the vulnerability
> > and does not need to be part of the solution.
> 

Plain Wrong.  My proposal works without TLS extensions, that is
clearly explained.  It just happens to use a S->C signaling scheme
that looks like TLS extensions to TLS-extensions aware implementations
and can be parsed with TLS extensions parsers, for those who prefer
to do it that way.

But my draft explains clearly how to do it without TLS extensions,
and the OpenSSL patch I posted contains an extension-less implementation
of the signaling -- and the Client side of the extension-less code
is actually used for server_version==SSL3_VERSION.

> draft-mrex-tls-secure-renegotiation used an extension.

Oh yes, there is.

Look at the last two paragraphs of Section 4.4 which describe
how extension-less clients and extension-less servers can implement
this with <10 LoC each.  And my openssl-patch contains exactly
that code.

> By the way, do you of any TLS implementations that do not "implement

There are two possibilities with the same effect:
Do not implement it in the fashion of "have never contained it"
and do not implement it in the fashion that it is hardwired to disabled.

openssl-0.9.8l is one of the latter.

What you currently see is a lot of customers asking for patches
that reliably disable renegotiation for the servers, because most
servers do _not_ need it.

And once you've come to the conclusion that you don't really need
it, there is no use to implement full secure TLS renegitiation.
RI-minimal  would be just fine, and much easier to test and ship
as a hotfix for an old installed base.

> forever. And we waste three bytes on every handshake.

Cipher suite values in SSLv3/TLS are two bytes,  and if you're really
concerned about that, you should go for draft-mrex-tls-secure-renegotiation,
because it will need even less bytes on every handshake, in particular
on the renegotiation handshakes.

If TLS extension RI specifies to NOT send an empty TLS extension RI
on the initial handshake EVER, only MCSV, and additionally include
MCSV on every renegotiation handshake, then you save 3-5 bytes
on every initial handshake and pay 2 bytes extra on every
renegotiation.  That means for >95% of the usage scenarios you
will save.

> the end of September! Most have experimental implementations already.

I can imagine that it takes quite some time to implement an MitM attack
on TLS renegotiation.

I'm sorry for just thinking about it for an hour, checking the TLS spec
for flaws in my line of thought for 20 minutes and then posting it
publicly to [email-masked] that TLS renegotiation is susceptible
to MitM attacks.

> No, would you like me to write the 80 LoC for you?.

I don't have problems with writing that code.  But you certainly
could help me with the weeks of paperwork and automated test-cases
necessary to get official permission to ship that change into an
installed base in maintenance mode.

Some 10 LoC changes require 300+ LoC test tools.  If you look at
my openssl patch, it does not create a lot of new code pathes
that can only be reached with test tools.  98% of that new
code is fully covered during regular use/interop, and works
in a failsafe fashion -- i.e. if it didn't work as designed, it
would result in interop problems.

> MitM.

It _only_ proves there is no MitM acting without consent of that
server.  If that server changes his certificate during renegotiation,
it is DEFINITELY not the same server as before.  Depending on what
the new cert looks like, the client may accept this change, but
the assumption that a client must not care is flawed, and can
by itself become a security problem for some situations.

If you're doing security-related stuff, it is extremely important
that you are staying clean at the abstract level.  Some of the
risks that one creates by sloppiness at the abstract level may
lead to mostly theoretical vulnerabilities (like adding arbitrary
data to the handshake message hash instead of handshake messages),
and sometimes it can create very practical risks (like ignoring
identity changes).

> more plausible because of the way server certs are currently tied to

There are some apps on top of TLS that "tie" certs to hostnames, but
as previously discussed, that is entirely an apps issue, and the
TLS implementation can _NOT_ force re-authentication on the application
caller!

> actual scenario. Perhaps something involving multiple sites behind a

In the IETF security area we try to avoid this kind of approach:
worrying about vulnerabilities only when exploits have been published.

We want to move away from MD5 in online authentication even though
nobody has demonstrated real-time second preimage attacks against MD5 yet.

> http://www.wired.com/threatlevel/2008/10/kinne/

You mean the term "highlander"?

Look here: http://en.wikipedia.org/wiki/Highlander_%28film%29

"in the end, there can be only one."

> Well, tell me why it's flawed or I shall have to find an interesting use

To have more than one client cert listed for an authenticated TLS session
would be a pretty dumb idea.

There are platforms that offer such mechanisms more like a feature
of the "Trusted Computing Base", which allows to pass of ACL checks
in a Posix-ACL style to the underlying OS (ImpersonateSecurityContext()).

These functions would likely have difficulties dealing with a set-of
instead of a single client identity, and they would be faced with the
problem that Access Control and auditing/audit logs can deal only
with a single Access Token (identity).

> in agreement. These values were authenticated by the previous handshake

That is what is supposed to happen.  I know that TLS extension RI
uses an unconventional way to perform this authentication -- it
exchanges the data in an integrity-protected fashion and needs to
memcmp() the contents.  Which is why TLS extension RI is not failSAFE.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Thu, 10 Dec 2009 16:01:52 -0600

> http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC.HTM

Thanks.

That's pretty clear, SSLv3 did not have a provision for extending Client
Hello.

> from the I-D repository 6 month later.

Seems like SSLv3 was simultaneously one of the most critical protocols
for net security and orphaned.

> because it is not correct.

I meant "request for RI" in the general sense which also includes MCSV.

> semantics, and the spec doesn't spell it out.

You're way overstating it. Sure, there will be a few things added to the
next version.

Yes.

>       assumes to be renegotiating

These are not separate. "The ID of the previous state on the connection"
is quite naturally expressed as a zero length renegotiated_connection field.

This is not overloading.

> I believe to be experienced engineers, seem to have gotten this wrong.

Oh good grief.

> completely seperate mechanisms to convey (1) and to achieve (3)

I just don't see that as a big deal.

> can not be distinguished from other finished MAC errors im my I-D).

This is not any advantage, in fact it is a disadvantage.

MitM clearly knows who's doing renegotiation and who's not. Aside from
the fact that he's the one orchestrating it all, it's observable from
unencrypted data on the wire.

The only parties who can't determine that there is a MitM attack going
on are the legitimate client and server under attack!

That's bad, they would be better off if they could log or alert about
that sort of thing.

> old server,

That was their first mistake. Hope they weren't using TLS for anything
important.

> and that server asks for renegotiation

Now they know their connection is vulnerable and if they supplied a
client cert it may have been forwarded.

> for whatever

Neither is MCSV of any use with an unpatched server. What's your point?

> with an old server is interop problems.

Then don't send it if you prefer interop to security. You had the chance
to negotiate it interoperably on the first handshake.

> But not sending anything
> renegotiation with an old server.
>
> MCSV will allow an updated

You do raise an interesting case here. One which does seem to support
the idea of sending MCSV on every Client Hello.

There are still multiple ways that its security is broken though, so I'm
hesitant to agree that it's a significant improvement.

> proxied into the renegotiation handshake of an updated server.

This is the standard use of MCSV in every proposal I've seen.

> look at its policy/configuration and either abort the handshake

OK, I'll put it differently.

A vendor, admin, or user who configures a client implementation of TLS
to operate in "compatible mode" is still insecure when connecting to
unpatched systems. They are making a conscious decision that
interoperability with unpatched systems is more important to them
obtaining the security guarantees advertised by SSL/TLS.

We must not judge them for that.

However, neither can we give them security on renegotiation which was
not present on the initial handshake. Suggesting that we do that somehow
could be quite misleading.

There might be room for multiple opinions on this though.

> Client.Finished.verify_data, then that server MUST abort the handshake.

Agreed, I believe that will be in the next version the draft.

> of those clients will be updated and capable to send MCSV.

I meant "request for RI" in the general sense which also includes MCSV.

> handshake if that server is backwards interoperable.

I get what you're saying now. I tend to dismiss that case because it's
already fundamentally broken in multiple ways.

Are there useful "degrees of brokenness" in this kind of case?

It's an interesting philosophical and practical question.

> alert), but instead completely ignore the handshake message.  Not good.

Wasn't 0.9.8l the version patched to simply disable client-initiated
renegotiation?

> SSLv3 isn't broken.

I think I've proven that it is.

> It was just _not_ designed to be extensible.

That's proving to be a big problem now. The best thing would be to just
retire it, except we want to be kind and accommodating to implementors.

> If you look at TLS, it is not that much better.

It is infinitely better in the extensibility department.

> It took them 7 years
> to define extensibility.

They made a spot for it from the beginning.

> They could have simply added a 4-octet bitfield

Yes, I would have probably done it that way (in addition to extensibilty
via TLVs).

In my experience though, no matter how well you document how certain
bits should be initialized and how they should be ignored, some
implementors are just going to doing wrong.

This is not an argument against doing it and documenting it well,
however. It just says you shouldn't have naive expectations about how
smooth it will go when it comes down to it.

> only clients that have a re-connect fallback mechanism can benefit.

Three web browsers are the only clients I'm aware of that implement
fallback reconnect and they would love to dump it. There are probably more.

My impression is that many modern TLS clients get by just fine without
catering to extension-intolerant servers.

> disruptive fashion is easily and clearly avoidable.

Apparently, you feel that any use of TLS extensions would be "disruptive"?

> I'm sorry for that.  It is not my intention to confuse.

It's not necessarily you, this material is inherently difficult.

> Sending the MCSV on _every_ ClientHello (initial *AND* renegotiations).

OK. There is new wording expected in the next draft. Probably something
like this:

vvvvvvvvvvvvvvvvv
5.  Requirements for Sending and Receiving

TLS clients which support this draft MUST generate either the
"renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST
cipher suite with every ClientHello.

TLS servers which support this draft MUST generate the
"renegotiation_info" extension in the ServerHello in response to any
client which offers either "renegotiation_info" or Client Hello
TLS_RENEGO_PROTECTION_REQUEST in the ClientHello.

Note that these requirements still apply even after previous handshakes
of the same the connection or session did not negotiate the use of RI.
Every handshake is to be treated independently in this respect.
^^^^^^^^^^^^^^^

Does this address your point?

> client is updated is perfectly sufficient.

I have found it tricky to think in terms of "the client is this" or "the
server is that", because the essence of these attacks is that MitM
breaks your assumption about who you are talking to across a renegotiation.

> to detect proxied handshakes with updated MitMs.

By "RI-minimal" I take you to mean "one which does not implement
renegotiation".

Do you have any examples of these servers which are proven to never
renegotiate?

> but *I* think that would be an incomplete fix. 

No, I have said repeatedly that both the client and server have a
critical interest in the security of the protocol.

That is why I haven't spent much time thinking about scenarios where a
client is willing to operate in compatible mode.

> No, it doesn't.  It needs to be fixed!

Your proposal uses an extension whether you admit it or not.

Pretending that it's not only leads to partial implementations of
extension handling which do things like depend on the order and number
of total extensions. Maybe today in a few cases you can show that
variations can't happen.

It's trivial to implement correctly so there is absolutely no gain to
not doing so.

On the contrary, we've all seen the cost of having half-assed protocol
implementations build up over time.

> Plain Wrong.  My proposal works without TLS extensions, that is

Baloney.

> and can be parsed with TLS extensions parsers, for those who prefer

That must be why my extension parsing code parses the example out of
your document just fine.

Tell me, how can I fix my extension code so that it correctly identifies
your non-extension as not an extension?

By that logic, "renegotiation_info" described in
draft-ietf-tls-renegotiation isn't an extension either.

Or is it just "extra bytes that look like TLS extensions" on Server
Hello that aren't extensions?

> is actually used for server_version==SSL3_VERSION.

No, what you have is a half-baked minimally-compatible extension
mechanism in denial.

It only works because of the long chain of reasoning required to prove
that it will never be asked to share the protocol space with real
extensions.

It will break as soon as someone else does the same thing, thinking they
can make assumptions about number and ordering on extensions appearing
on certain Hello messages. If your design can't tolerate the possibility
of someone else reasoning the exact same way, it's not very good is it?

Protocol designers and implementers have been through this a countless
number of times.

Just admit you're extending the Hello message and use the standard and
interoperable mechanism like everyone else. The only global-scope
coordination it requires for correctness is handled through the IANA and
they seem to do a decent job of it.

> this with <10 LoC each.  And my openssl-patch contains exactly

It is exactly this kind of foolish false economy that has put SSL/TLS
interoperability in the state it is in today.

> openssl-0.9.8l is one of the latter.

Yes, it's an emergency patch that is not suitable for everyone.

> it, there is no use to implement full secure TLS renegitiation.

Again, do you know of any modern, maintained TLS implementations that
have decided that they do not need to ever support renegotiation?

> Cipher suite values in SSLv3/TLS are two bytes,

Well it changed a while back, would be interesting to know why.

> and if you're really

No.

> renegotiation.  That means for >95% of the usage scenarios you

It's not worth one bit of extra complexity to me.

To me, the MCSV hack and your proposed subset of the current extension
mechanism are extra complexity.

> publicly to [email-masked] that TLS renegotiation is susceptible

Well I did the same thing initially, but my process was to bug it
internally. Not being an expert, I felt I had to prove it thoroughly
before I went around making (what I saw as) extraordinary claims.

> installed base in maintenance mode.

I suspect that your paperwork increases sub-linearly with LoC.

> would result in interop problems.

That's all good.

It would certainly be simpler to just break interop with SSLv3 and
broken TLSv1 servers. That's a form of fail-safe.

> server.

There's no such thing as an attack with the consent of the server. The
server can do anything he wants without involving the complexity of a
3rd party MitM.

> If that server changes his certificate during renegotiation,
> it is DEFINITELY not the same server as before.

If that were the case, you would be unable to say "server changes his
certificate".

"Server" is an increasingly nebulous term, what with shared IP load
balancing, "cloud", "ssl offload", and all.

Here's what one relevant RFC says it is:
> The server is the application entity that responds to requests for
>       connections from clients.  See also under client.

I wouldn't go around saying it "DEFINITELY" is this or that.

> Depending on what

I'm saying you have some unsubstantiated assumptions and "unclean
abstractions".

> TLS implementation can _NOT_ force re-authentication on the application

Until the SNI extension can be made mandatory, in practice a TLS server
can't present different server certs from the same IP and port. That's
all I was saying.

> worrying about vulnerabilities only when exploits have been published.

I'm saying it's probably not a protocol vulnerability if it was a
documented feature of the protocol.

There need to be seriously good reasons before removing functionality in
a protocol spec.

That a few knowledgeable people have found it surprising on first glance
is relevant, but not persuasive.

Finding an actual system that misinterpreted the spec and plausibly had
a vulnerability would be even more useful.

Finding many systems which were vulnerable to having made the same
mistake interpreting the spec would make it worth considering removing
or restricting the protocol feature.

But so far nobody has described even a hypothetical (but plausible) example.

> nobody has demonstrated real-time second preimage attacks against MD5 yet.

You'd better be looking to move away from SHA-1 as well.

> Look here: http://en.wikipedia.org/wiki/Highlander_%28film%29

OK, I remember hearing about that movie/TV show. I didn't watch it.

> "in the end, there can be only one."

Only in your preconceptions. It's not in any TLS protocol spec I've seen.

> would be a pretty dumb idea.

Just because you can't imagine how it might be useful doesn't make it a
dumb idea.

> with a single Access Token (identity).

So what?

> uses an unconventional way to perform this authentication -- it

Which is why I wouldn't describe it as authentication.

> memcmp() the contents.  Which is why TLS extension RI is not failSAFE.

Where fail = crypto code is buggy.

It's probably not what any of us would designed if we could do it from a
clean sheet, but we don't have that option. On balance, I think it's an
effective fix and is the most deployable on an urgent basis.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 Dec 2009 01:49:55 +0100 (MET)

> This is not any advantage, in fact it is a disadvantage.

Primarily at first look.  It is a characteristic of the TLS handshake
that tampering with the handshake will result in a Finished MAC failure
and maybe the optional CertificateVerify verification failure.

It would be helpful when those who are vulnerable would log attacks,
but unfortunately, they don't (can't).  For those who are _not_ vulnerable,
that information is no longer this much different from other tampering
with the TLS handshake messages.

In recent years several previously distinct error situations were
re-specified to make the finished MAC fail rather to point to an
implementiation bug with a distinct Alert message (wrong protocol
version in rsa premaster secret is one of those).

> unpatched systems.

Only if one of them (or both) allow old _renegotiation_.  Most "interesting"
scenarios that users/consumers worry about currently require the server
to be the one offering old renegotiation.

> Are there useful "degrees of brokenness" in this kind of case?

It is a _possible_ scenario.  My proposal fixes all possible scenarios,
and does _NOT_ need to iterate them.  If you have to iterate through
scenarios, then your solution is more complex than necessary.

> Wasn't 0.9.8l the version patched to simply disable client-initiated

I'm not sure.  To me it looks like it disables renegotiation in general.
Although it tests for a flag value in the session flags, there is
only a control-function to retrieve that flags value, but the function
to set these flags seems to be missing.

The problem is that openssl-0.9.8l fails to return an SSL alert.
So the client who has sent a ClientHello is waiting for a ServerHello,
and the server also seems to get stuck (s_server and s_client).

> retire it, except we want to be kind and accommodating to implementors.

SSLv3 was the enabling technology for TLS.

Sounds like murdering your parents silently and collecting their pension.

The ethical behaviour is to wait until it dies of age all by itself.

> They made a spot for it from the beginning.

Nope, that beginning was in November 1996.  TLS WG decided to
leave forward extensibility an unused and untested protocol
feature for several years.  There would not be any broken TLSv1.0
servers if that protocol feature had been appropriately tested.

> implementors are just going to doing wrong.

Documenting it is insufficient.  The three most important things
that you need is  Testing, Testing and Testing.

You need that to check a spec for consistency, and you need that
to check implementations for interoperability and compliance.  And writing
good test tools can be more work than implementing the technology itself.

> catering to extension-intolerant servers.

Many modern TLS clients get by just fine without sending TLS extensions.

But we're not talking about what the fix means for "modern" clients.

We're talking about what this fix means for "old" clients and servers,
which outnumber the "modern" clients by a factor of at least 50x (probably
500x if you count all the individual codelines under maintenance).

> Apparently, you feel that any use of TLS extensions would be "disruptive"?

Yup, definitely.  For a large amount of the installed base it
will would be a backwards incompatible change with *known* interop
problems to suddenly have clients send TLS extensions.

And a lot of software vendors can not afford to put a change with
such a disruptive potential into a hotfix for the installed base.

> Every handshake is to be treated independently in this respect.

No, unfortunately not.

Conforming TLS clients MUST include the TLS_RENEGO_PROTECTION_REQUEST
on _every_ ClientHello they send.  TLS clients SHOULD NOT include
an empty TLS extension RI in a ClientHello.  TLS clients MUST NOT send
an renegotiation_info extension containing Client.Finished.verify_data
in a renegotiation ClientHello in backwards interoperability situations
when (a) old renegotiation is permitted and (b) no TLS extensions had
been sent in the ClientHello that established the enclosing TLS session.

> breaks your assumption about who you are talking to across a renegotiation.

I'm sorry, I can not follow at the moment.
The MitM attack has no influence on whether you are client or server.

> Do you have any examples of these servers which are proven to never

Proven to not need it?  All of the servers that we shipped so far.
Proven to not accidentally provide it.  Less than the previous.

> Your proposal uses an extension whether you admit it or not.

I admit that what my proposal uses is fully compatible with
TLS extensions.  You may remeber that I do care for all existing
usage scenarios.  That includes scenarios that use TLS extensions today.
Therefore I insisted when adding anything into ServerHello behind
compression_method that it be gentle to real TLS extensions that
may need to get stuffed there.

For simplicity, I even refer to this signal as a TLS extension
in my document.  It is just sufficiently simple that it not
more complicated to implement than re-purposing a bit from server_version
or compression_method -- for those old or constrained implementations
that do not have any TLS extensions code.

> implementations build up over time.

I'm sorry that I'm more worried about hundreds of old implementations
that _only_ need to get fixed, by maintenance persons who are sometimes
just vaguely familiar with the code, rather than the two dozen
modern full-fledged TLS implementations where the maintainers are
in best training, constantly experimenting with the newest features
and no installed base to worry about.

My approach is conservative and pragmatic.

> of someone else reasoning the exact same way, it's not very good is it?

My design can tolerate that perfectly well.  If you need more than
one extension to be carried, you'll have to implement TLS extensions,
that is obvious.

If that extra data in those other situations is not compatible
with TLS extensions, then that other data is a half-assed protocol
extension, and it wouldn't fly with TLS extension RI either.

I never claimed that my approach was perfect.  I only claimed
it was less complex than TLS extension RI, less code to implement,
less testing necessary and highly interoperable with installed base.

> they seem to do a decent job of it.

I admit that I'm extending ServerHello with a TLS extension for
everyone that implements TLS extensions, that should be rather obvious
from "4.4 New protocol elements" and "6. IANA considerations".

For extension-less implementations, it's a simple 6-octet binary
appendix to ServerHello that is used for Server->Client signaling
and trivial to implement, this is what the last two paragraphs
of section "4.4 New protocol elements" describe.

What it is therefore depends on your point of view.

UTF8 can be interpreted as Unicode for Unicode-aware applications,
can be interpreted as US-ASCII for applications that only store
US-ASCII characters in there, and can be treated like traditional
0-terminated strings by string-functions of ANSI/ISO-C (c89).

> interoperability in the state it is in today.

Nope.  It is the lack of testing!  If those guys who developed TLSv1.0
had spent their time on developing test suites and getting the installed
base fixed while that software was still under maintance, or had performed
a security review on the design of the renegotiation, then we would not
be in the current situation, having to patch 14 years back into the past.

Many protocols in the IETF have seen a huge feature creep over the
past 10 years, meaning that the recycled the IETF process at
"proposed" with several revisions instead of fixing the defects
in the specs, getting the implmenentations to interoperate on all
specified protocol features and advancing the protocol to
draft standard.  TLS is definitely one of those.

> mechanism are extra complexity.

Having MCSV adds complexity.  Mandating its use actually reduces
complexity--you don't need a conditional for adding it -- that
obviates an extra test case.

> I suspect that your paperwork increases sub-linearly with LoC.

The paperwork is linear with the number of additional test cases
for each new code path.  This is why I prefer to _not_ add new
code pathes, but instead only modify existing code pathes
-- in which case the existing test cases cover the changed
functionality already.

How may test cases do you need to verify the implementation of
a secure hash functions?   Very few.  A few test vectors and
some invalid input parameter calls are sufficient.  It is
extremely unlikely to get a correct results for a certain
amount of test vectors by "accident".
A kind of implicit fail-safe design.

> broken TLSv1 servers. That's a form of fail-safe.

I don't have a problem if you do _not_ add backwards interop into
your implementation.  I will leave that to "market pressure".

However I do have a problem if you insist on a spec that makes
backwards interop difficult for _me_, because I'm paid to provide
that interoperability for the installed base.

> can't present different server certs from the same IP and port. That's

I looked at the SNI spec, and that thing is a big mess!  It appears
to be an completely out-of-sync proposal.

The first thing that should have been done is define a standard
how to perform server authentication.  One could have used rfc-2818
(HTTP over TLS, informational), which itself refers to PKIX
X.509 subjectAltName dNSName and iPAddress.

dNSName is an IA5String
iPAddress is an OctetString, but there are canonical string
representations in some specs.

The hostname in SNI is defined as UTF8String which looks pretty weird!

The client should send exactly that canonical hostname that it
will use to verify the ServerCertificate.  In order to implement
SNI correctly, a TLS implementation will _now_ need to implement
transforms of UTF8Hostnames into the thing that you find in
Server Certificates -- which could have been completely avoided,
since the client MUST ALSO implement this, and could have been
passing the _result_ of this operation to the server instead!

There's simple rule that says: If you have one clock, you
are pretty confident to know which time it is.  If you have
two clocks, you are unsure.  The SNI design looks like poor
engineering to me.

And explicitly prohibiting literal iPAddresses in rfc3546
without _ANY_ kind of justification while their use in
rfc2818 is explicitly permitted for HTTP over TLS seems
also a little strange/inconclusive.

> You'd better be looking to move away from SHA-1 as well.

We can not drop SHA-1 that easily.  First we must upgrade the
installed base to support something better than SHA-1, then we
must migrate the users to use that better-than-SHA-1 hash,
and then we can think about disabling SHA-1 support.

> >>> A client that has not been previously authenticated performs a
> >>> client cert authentication.  That is a highlander operation.
> > 

On the contrary, it is in all of the specs.  Each peer in
the TLS handshake can send at most one Certificate handshake message
within one handshake.

This is probably why none of the implementations I know uses an
aggregate set of certificates of TLS peers.

And as we all know by now, TLS renegotiation results in an entirely
independent session.  :-/   So you can not claim that TLS renegotiation
supports a change in the identity.  TLS renegotiation has been a
completely new and independent handshake all the time.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 Dec 2009 03:08:28 +0100 (MET)

Michael Gray wrote:
> examine the conditions and implications etc to make the best decision.

You are right.  I'm sorry.  I got a little carried away.

A SHOULD NOT for sending _empty_ TLS extension RI is more appropriate.

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 10 Dec 2009 18:22:53 -0800

> require full extension implementation) to be preferable.

Of course, neither does draft-ietf-tls-renegotiation-01.txt require full
extension implementation, so the absence of that requirements is not a
basis for preference of one over the other.

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 10 Dec 2009 18:39:36 -0800

> for net security and orphaned.

Stop right there.  Don't be led down the garden path.

Look at the parent page.  Look at
http://web.archive.org/web/20050205162914/wp.netscape.com/eng/ssl3/

It clearly says that "The most recent Draft SSL 3.0 specification, an
Internet Draft dated November 1996, may be viewed here. It is an ASCII
document".  It is a link to http://wp.netscape.com/eng/ssl3/draft302.txt
which is draft-freier-ssl-version3-02.txt, now seen at
http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt

That parent page also says:  "The previous draft of the SSL 3.0
Specification, dated March 1996, may be viewed in this HTML document."
which is a link to
http://web.archive.org/web/20050206124632/wp.netscape.com/eng/ssl3/ssl-toc.html
which in turn has a link to the page Martin cited above.

You'll find my name in some of those pages, too.  Don't let a non-Netscape
person tell you what was, and what was not "official" at Netscape.

Netscape never orphaned 3.0.  It kept the "most recent draft" alive for
the rest of its days, and is still kept alive today at Mozilla.org, which
runs NSS code which is a direct descendant of Netscape's original code.

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 Dec 2009 03:55:14 +0100 (MET)

> http://web.archive.org/web/20050205162914/wp.netscape.com/eng/ssl3/

As I previously explained, I went to the Netscape WebServer in 2000
(when we acquired our OEM SSL implementation and I got the job to
make it accessible to our application), and the Netscape site search
sent me straight to the "pretty" SSLv3 spec (HTML and Postscript).

When I found a reference to a SSLv3 spec from November a few
weeks later, google did NOT find the 302 document.

So I searched through the archives of the IETF TLS mailing list,
where I finally found the document, because it had been posted
there in full.

The IETF internet-drafts repository in 1995-1998 kept only the
most recent version of a draft (deleted all previous documents),
and deleted an I-D when it expired.  The possibility to access
old internet draft versions through tools.ietf.org is something
I learned a few weeks ago.

Keeping an old version of a specification around in a MUCH
MORE promentiently fashion for 9 years tells a lot about what
Netscape thought of the draft-302.txt document.

After all, Netscape originally would have loved the IETF to
rubber stamp the original SSLv3 spec -- just that the IETF TLS WG
didn't like the rubber stamping idea in 1995/1996 -- and instead
insisted on defining a protocol named TLS backwards interoperable
with SSLv3.

So the draft302.txt document represents the start of TLSv1.0,
and not the final spec of SSLv3.

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 10 Dec 2009 19:08:14 -0800

> Netscape thought of the draft-302.txt document.

It's not "much more prominent".  It's merely HTML.  Prettier, perhaps.

It amuses me that you tell me what Netscape did and didn't do with those
pages, because *I* was the Netscape employee who maintained that section
of the web site from 1998-2005, beginning when I implemented TLS 1.0
in Netscape's NSS.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Fri, 11 Dec 2009 03:43:49 +0000

> A SHOULD NOT for sending _empty_ TLS extension RI is more appropriate.

Why? What is the point of allowing the client to send an empty extension,
when a patched client MUST send the MSCV, and a patched server MUST use
*only* the MSCV to determine whether the client is patched? You'd just be
adding the option to send an extension that has no defined meaning.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

---

From: Michael Gray <[email-masked]>
Date: Fri, 11 Dec 2009 17:05:11 +1000

> basis for preference of one over the other.

To be clear: draft-ietf-tls-renegotiation-01.txt requires data exchange by
the RI extension whereas draft-mrex-tls-secure-renegotiation-03 does not.

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 Dec 2009 15:58:25 +0100 (MET)

> It's not "much more prominent".  It's merely HTML.  Prettier, perhaps.

Let's see:

The following URL says "SPEC":
http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC.HTM

This URL says "Draft":
http://web.archive.org/web/20050206122938/wp.netscape.com/eng/ssl3/draft302.txt

and includes an _explicit_ expiration of May 1997.

And concerning extensibility of SSLv3, here's a statement
from Tom Weinstein, listed in the Authors section of the
Nov 18th, 1996 draft as a Netscape employee from
10-Oct-1996:

http://www.imc.org/ietf-tls/mail-archive/msg00325.html

  The lack of a general extension mechanism in SSL v3 is a feature, not a
  bug.  This is a security protocol, and so susceptibility to analysis is
  a good thing.  Simplicity and rigidity are features here.  SSL does
  provide for forwards compatibility by allowing version negotiation and
  protection from version rollback attacks.

  -Tom Weinstein, Netscape, 10-Oct-1996, Co-Author of draft302.txt

So as far as Netscape's SSLv3 is concerned it didn't not contain
extensibility.  What is in that November draft is something the
TLS WG wanted for TLSv1.0.

Keep in mind that in mid of 1996, SSLv3 was not under development,
it was already widely deployed.

> of the web site from 1998-2005, beginning when I implemented TLS 1.0

You could have removed the explicit expiration notice on draft302.txt
and you could have renamed it to "3.0 final SPEC", you could have
removed the version that you condered outdated--or at least clearly
marked it as outdated _in_the_document_ if that was what you or
Netscape intended it to be.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 Dec 2009 16:11:03 +0100 (MET)

> adding the option to send an extension that has no defined meaning.

I have mixed feelings about this.  Maybe we do need a MUST to make
things clear.

There *IS* no point in doing that (which is why I lightheartedly wrote
MUST NOT).  An implementation that is sending it will just waste
code and network bandwidth.

As far as I understand there seem to be architectures where the
ServerHello extensions parser will only search for replies to
TLS extensions it requested (and ignore others).  Now for the
RENEGO_PROTECTION to reliably work against downgrade attacks in
backwards interop scenarios, that code MUST be changed to process
a TLS extension RI reply in ServerHello in cases where it did _NOT_
send an empty TLS extension RI in ClientHello--otherwise there
would be no downgrade MitM attack protection.

Therefore a mere SHOULD NOT might lead to defective/vulnerable
implementations in case these implementations allow backwards
interoperability or extension-less SSLv3 ClientHellos
or SSLv2 ClientHellos.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Fri, 11 Dec 2009 10:33:28 -0600

> adding the option to send an extension that has no defined meaning.

I would like for the decisions we make today to allow the MCSV hack to
be retired at some point in the future. MCSV represents extra complexity
that we added as a concession for interoperability with obsolete and
out-of-spec systems. We all have to make compromises in life and
protocol design, but it is better to do it in such a way that they
eventually pass into history rather than build up over time.

Today there are many clients which never interoperate with
extensions-intolerant servers. If at all possible, these should have the
option of not sending the MCSV hack from the beginning.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 Dec 2009 17:57:52 +0100 (MET)

> option of not sending the MCSV hack from the beginning.

Today there are many car owners that are not involved in car accidents,
we should get rid of liability insurances for cars.

The problem with this reasoning is, that you only know _after_ the
fact whether you needed it or not.

You're actually suggesting that Browser vendors split their codebase
in two (one with backwards interop and one without) for the gigantic
gain of saving 10 LoC in one of the then two different lines of code?

When browser vendors emphasize they know exactly when the last pre-trusted
RootCA cert they're shipping is dropped from their distribution, then
they boldly assume this is the time when no-one needs MD5-support anymore,
completely ignoring the much higher numbers of non-commercial CAs that a
lot of companies are using, self-signed certs, certs installed on
devices and more.  MD5 may be bad, but it is still better than nothing.

Removing vital functionality in a knee-jerk reaction just because
some implementer sees no more use for it in his personal environment
might not be a very good idea.

OK, if you're working for a software vendor and are looking for an
extremely extended Xmas vacation, this might be an option to make
it happen...

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Fri, 11 Dec 2009 18:11:23 +0000

> and includes an _explicit_ expiration of May 1997.

This is really reaching. They are both *draft* *specifications*.

Yes, the former should have been removed from the site, or marked as
obsolete. That's water under the bridge now.

---

From: "tom.petch" <[email-masked]>
Date: Fri, 11 Dec 2009 11:27:33 +0100

----- Original Message -----
From: "Nelson B Bolyard" <[email-masked]>
Sent: Friday, December 11, 2009 3:39 AM

> http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt

Weirder and weirder.  Yes, you are right (of course) and I now have a copy of
-02.

But....  When I go to tools.ietf and ask for draft-freier, it produces -01; if I
ask explicitly for -02, it produces -01.

Go to Watersprings (which I always do before using tools.ietf) and it tells me
of -00 and -01 and that the last was superseded by draft-tls-...

So both the ietf archive and the Watersprings archive deny knowledge of -02,
which, in any other circumstance, I would take as proof beyond reasonable
doubt that there never was a -02.

Ah well, they never said the security was easy.

Tom Petch

---

From: Nelson B Bolyard <[email-masked]>
Date: Fri, 11 Dec 2009 14:41:12 -0800

> and includes an _explicit_ expiration of May 1997.

Yes, all the drafts expired, including the one that says "spec".

>   -Tom Weinstein, Netscape, 10-Oct-1996, Co-Author of draft302.txt

Tom and I shared a cubicle.  His brother Jeff sat in the next cubicle over.
One of my first mistakes in working on NSS's SSL code was changing the code
for handling received client hellos to require that the length of the
message be exact, with no extra.  Tom caught this mistake in his review of
my patch.  That was one of my first lessons learned in working on SSL in
1997.

> extensibility.

In your opinion.  If you wish, you may continue to try to get the last word
in on this subject, but I think the group decision will not be based on
who gets the last word.

> Netscape intended it to be.

I consciously chose to make NO changes at all to any of those documents,
lest anyone accuse Netscape of continuing to try to revise the SSL 3.0
specification rather than (or in parallel with) adopting the TLS 1.0
specification.

---

From: Martin Rex <[email-masked]>
Date: Sat, 12 Dec 2009 00:07:40 +0100 (MET)

> Yes, all the drafts expired, including the one that says "spec".

Nope.  The one calles SPEC does NOT have an expiration.

When I complained to the supplier of our OEM SSL implementation about
an interop problem with TLS (not extension, only { 0x03, 0x01 }) in
August 2000, then they told me that the behaviour was according to
the SSLv3 spec.

I asked them for their spec document, and it was the March document.
So I went to www.netscape.com and used their "Site Search", and the
only document it found was the pretty (short) version of the SSLv3 spec.

Then I saw the reference to a Nov 18th document in the TLSv1.0 spec
(but not the slightest hint where to find it), and thats when I
downloaded the ietf-tls discussion list archive and found the document
attached to a posting from Win Treese (that attachment seems to have
been stripped in the current archive, it was attached to this message.

http://www.imc.org/ietf-tls/mail-archive/msg00422.html

And although Win wrote this:
"For a variety of reasons, it's important to have this draft for the record."

neither TLS WG nor Netscape did anything substantial to keep
this document on record.

When I found that draft, I sent it to our supplier, so they would
use it.  But I could not blame them for not being aware of a newer
document, because it was obviously a big mess and no one cared.

> my patch.

I do believe that.  If you look at the TLS mailing list archives,
Tom was flamed violently for making such a statement.  He sure hadn't
forgotten that.   But as you can see in the referenced message above,
Barb Fox (Microsft) clearly points out that _NONE_ of the installed
base of SSLv3 in Oct-1996 was extensible and neither was there
an SSLv3 spec available providing this extensibility.

> specification rather than (or in parallel with) adopting the TLS 1.0

Regrettably you did _NOT_ remove the expiration tag from the draft302
and did _NOT_ take down the outdated draft either.

You should have put up the "Beware of the Leopard" sign on your
overview page to make the picture complete.

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Fri, 11 Dec 2009 15:18:11 -0800

> August 2000, then they told me that the behaviour was according to

They were mistaken about that, of course.  There never was ANY doubt or
controversy about how version negotiation was supposed to work.  Some
vendors just got it wrong.

> overview page to make the picture complete.

Just call me "Pounce". :)

---

From: Steve Checkoway <[email-masked]>
Date: Fri, 11 Dec 2009 19:34:37 -0800

> Nope.  The one calles SPEC does NOT have an expiration.

Not that this matters at all for the purposes of fixing TLS, but in what way does it not have an expiration? The first paragraph establishes that the document is an Internet-Draft. The second paragraph reminds readers that Internet-Drafts expire after six months. <http://web.archive.org/web/*/http://wp.netscape.com/eng/ssl3/3-SPEC.HTM> makes clear that this document is more than six months old. That draft has expired.

-- 
Steve Checkoway

---

From: "tom.petch" <[email-masked]>
Date: Sun, 13 Dec 2009 10:43:00 +0100

----- Original Message -----
From: "Marsh Ray" <[email-masked]>
To: "David-Sarah Hopwood" <[email-masked]>; <[email-masked]>
Sent: Friday, December 11, 2009 5:33 PM
Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV

> option of not sending the MCSV hack from the beginning.

I was going to say that that logic leads me to conclude that we
should not send the empty extension either.  In a future version -
someone suggested 3.7 :-) - the binding of renegotiation to negotiation is
built in to the protocol and so no signalling - no MCSV, no RI, -
nothing extra is needed in ClientHello.

But while any server not supporting that version would fall back to TLS
1.somethingLess (which is the patched protocol we are now developping)
and would signal in whatever way we now decide that is supports the patch,
it would still need to know that this client with a version number it has
never heard of also supports the patch, so the client will have to go
on signalling in perpetuity.  In effect, we are digging ourselves a black
hole.

There is a solution.  We should require, as part of this patch, that upgraded
stacks treat a version number that is greater than some specified value as
also being a signal that the peer is upgraded.  Then we will be able to drop
the MCSV and/or RI as a signal from the '3.7' ClientHello. But we do need
to include this now.

Tom Petch

---

From: Michael Gray <[email-masked]>
Date: Mon, 14 Dec 2009 12:35:10 +1000

> adding the option to send an extension that has no defined meaning.

This shows how hard it is to harmonize the two proposed specs.  What I want
to avoid is a change to the on the wire protocol being used in production
environments due to applying this fix.

I see two use cases here;

A. Existing implementations that send extensions today and are therefore
are fine to add this additional extension.  Note: this means they are
already sending extensions, not just extension capable.  By applying this
fix nothing changes with the protocol being used.

B. Existing implementations that do not send any extensions today and as
such they must not change the protocol due to this fix, which means they
can only safely use the MCSV as the signaling method.

It seems to me that we simply need the appropriate wording to allow
implementers to decide the best strategy that needs to adopted based on
risk factors to deployed production environments rather than mandate A
which will break some production environments or mandate B which means that
extension using systems must use the CipherSuite method.

Naturally requiring only one signaling method is simpler and preferable
from an implementation and testing point of view.

- Mick

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 14 Dec 2009 03:39:14 +0000

> extension using systems must use the CipherSuite method.

What is the disadvantage of extension-using systems having to use the
CipherSuite method? I've heard only vague aesthetic objections so far;
nothing concerned with more substantive factors such as code complexity,
security, or interoperability.

> from an implementation and testing point of view.

Precisely.

---

From: Michael Gray <[email-masked]>
Date: Mon, 14 Dec 2009 14:55:08 +1000

> security, or interoperability.

Yes, I do not believe a technical objection to the CipherSuite method has
been presented, but rather it seems to me to be a question of technical
preference.

- Mick

---

From: <[email-masked]>
Date: Mon, 14 Dec 2009 09:31:32 +0100

Martin Rex wrote:

> > That is interesting information. Would you happen to have a copy
> > of the last "official" spec you can send me?
> 

No, it's not. If you look at the "SSL 3.0 Specification page" 
back then:

http://web.archive.org/web/20050210100922/http://wp.netscape.com/eng/ssl3/

It says the "most recent draft SSL 3.0 specification" is 

which includes the "must ignore extra data" text. The version your
link points to is called "previous draft of the SSL 3.0
specification".

However, I don't think it's very important or interesting what
Netscape considered "official" back then (and in any large company,
it's quite possible that multiple opinions exist...). Much more 
important is what the implementations still in active use do....

Best regards, 
Pasi 
(not wearing any hats)

---

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

> the MCSV and/or RI as a signal from the '3.7' ClientHello. But we do need

In theory, you are correct.

This would, however, require us to effectively standarize the secure
TLS renegotiation for TLSv1.3 (or some specific TLS version in the future)
ahead of time.  

The decision for the server would be easy, since it knows both protocol
version values (the ClientHello.client_version and his own max. supported
value) after processing ClientHello.  The decision for the client is
more difficult on the initial connect, when it doesn't know yet
whether the server will understand it, and this problem remains
on the renegotiation handshake, where an MitM attacker might proxy
the renegotiation handshake into an initial or renegotiation handshake
of an older server.

One could define my draft-mrex-tls-secure-renegotiation-03 to become
standard with TLSv1.3 and have it grow out of the installed base
naturally, because it changes the handshake message hash, and
prevents you from proxying a new (both initial and renegotiation) handshake
from proxying into handshakes of old servers.

TLS extension RI, on the other hand, does _not_ change the handshake
message hash, so you will have to keep that band-aid around for as long
as you _allow_ interop with TLSv1.2 or below, no matter what TLS WG
defines and implements in newer protocol versions.  Therefore
TLS extension RI is tomorrows cruft.

-Martin

---

From: <[email-masked]>
Date: Tue, 15 Dec 2009 11:41:18 +0100

Martin Rex wrote:
> tom.petch wrote:
> >
> > There is a solution.  We should require, as part of this patch,
> > that upgraded stacks treat a version number that is greater than
> > some specified value as also being a signal that the peer is
> > upgraded.  Then we will be able to drop the MCSV and/or RI as a
> > signal from the '3.7' ClientHello. But we do need to include this
> > now.
> 
> TLS renegotiation for TLSv1.3 (or some specific TLS version in the
> future) ahead of time.

I don't think this is what Tom was proposing. I understood his
proposal to be something like

  if negotiated_version <= 1.2 then:
     if (CH has MSCV) or (CH has RI) or (CH.proposed_version>1.2):
         client_supports_secure_renegotiation = True
         include RI in ServerHello
     else:
         client_supports_secure_renegotiation = False
  else:
     # do what the future spec says -- we don't know yet 
   
Or in other words: including a version >1.2 in ClientHello would mean
the same thing as MSCV or empty RI _when_ the negotiated version is
<=1.2. (But we wouldn't have to specify the behavior for negotiated
version >=1.3 at this time.)

I agree with Tom that if we want to drop MCSV and RI from the
ClientHello some day, we would need to specify this behavior now.  But
today it would be just more code (and unused code) on the server + an
extra test case or two.... so there are both pros and cons.
(And at this time, I'm not going to take an opinion either way.)

Best regards,
Pasi
(not wearing any hats)

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Dec 2009 04:53:13 +0100 (MET)

[email-masked] wrote:
> ClientHello some day, we would need to specify this behavior now.

That would only help to drop the signaling on the initial ClientHello,
but for the renegotiation ClientHello, the TLS extension RI band-aid
will going to be with us for more than 20 years (considering that
SSLv3 is still around after 14 years, and >90% of the installed
base is at TLSv1.0 (close to 100% of the servers) today, almost
10 years after TLSv1.0.

MCSV from draft-mrex-tls-secure-renegotiation-03 could start
disappearing from _ALL_ ClientHellos with the deployment of
TLSv1.3 capable Clients.

>
> But today it would be just more code (and unused code) on the server
> + an extra test case or two.... so there are both pros and cons.

Since such an option can not be covered in "regular" interop testing
at the moment, I tend to agree that it is not worth trying, given
the (lack of) interoperability track record of untested TLS protocol
features.

-Martin

---

From: Bill Frantz <[email-masked]>
Date: Tue, 15 Dec 2009 23:38:33 -0800

>the (lack of) interoperability track record of untested TLS protocol

I would think any test suite for TLS would include a client that indicates
it could accept a minor protocol number one larger than the latest
standard, and screams loudly should that number be accepted. Testing
version negotiation would seem a necessary for any test suite. YMMV.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"After all, if the conventional wisdom was working, the
408-356-8506       | rate of systems being compromised would be going down,
www.periwinkle.com | wouldn't it?" -- Marcus Ranum

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Dec 2009 16:30:00 +0100 (MET)

Marsh Ray wrote:
> out-of-spec systems.

MCSV is a very plain and simple backwards interoperability option,
and it will, in fact, make implementations easier (less code),
less bits-on-the-wire and more robust.

There is not only the wire-protocol to consider, but also the semantics
that TLS implementations have been providing to applications in the
installed base.  When an application has been requesting SSLv3 from
its TLS implementation in the past, then it probably did not distinguish
it's motivation for doing so -- whether it's a desire to _not_ use
TLS extensions, whether it's a desire to not use a higher protocol
version in the ClientHello, or whether the application knows that
it is trying to connect to an extensions-intolerant server.

The fact is, that we have established a specific semantic and
level expectation for such a request from the application,
and it would be very unwise to lightheartedly change such behaviour
in the installed base of largely unknown usage scenarios.

Doing the negotiation about updated implementations with
MCSV + ServerHelloExtension only will have the least amount
of impact on semantics and expectations in the installed base,
while providing all the functionality we need to protect
unsuspecting communication peers.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Wed, 16 Dec 2009 09:49:50 -0600

> less bits-on-the-wire and more robust.

For the record, I have never supported using MCSV as a way for
implementors to avoid properly handling extensions or to save bits. I
have only supported it to help implementors and applications that did
not want to lead off the initial handshake with an extension due to the
fact that some servers in the wild enter into a slow fail condition.

Allowing receivers of a protocol element to make an assumption (because
the sender is supposed to send redundant signals) does not usually end
up making things more robust.

--- switching to another thread here ---

Martin Rex wrote:
>> - The current draft doesn't clearly say what should be included in
>> legacy (insecure) renegotiation ClientHellos. I am not sure if we have
>> enough clear opinions to call consensus, but keeping it aligned with
>> the initial ClientHello (either MSCV or extension) seems to be one
>> simple approach (but I hope to see the actual text).
>
> Again, the choice is obvious: MCSV, *NO* extension.
>
> Anything else just makes no sense and may obviously cause interop
> problems for some backwards interop scenarios, because it is
> a backwards-incompatible change.

Martin is right about one thing here.

MCSV and/or the extension MUST be sent even on renegotiation hellos in
order to avoid a specific attack. It's a scenario that's already broken,
but nevertheless it is an attack involving two patched endpoints that
can be prevented.

>    cipher suite with every ClientHello.

I am hoping that a future revision will reinforce that it applies to
even supposed renegotiation hellos in compatible-insecure mode.

It's not so obvious to me that extension should not be sent though.
Spec'ing that would amount to blessing the behavior of old broken
systems. Elsewhere we have left that up to implementors whether or not
to send extensions.

> About the backwards interop scenarios in general:
>
> Can we please discontine the misleading terminology "lenient
client/server"
> and instead refer to the specific backwards interop scenarios that
> we address with a recommendation?
>
> (1)  updated client allowing initial handshakes with old servers
> (2)  updated client allowing renegotiation handshakes with old servers
> (3)  updated server allowing initial handshakes with old clients
> (4)  updated server allowing renegotiation handshakes with old clients

"Lenient" is the nice word for it, all four of those "backwards interop"
scenarios are just plain insecure.

- Marsh