Subject: [TLS] assert TLSext in renego-ServerHello instead of disable renego

From: Martin Rex <[email-masked]>
Date: Mon, 9 Nov 2009 21:35:57 +0100 (MET)

Maybe a patched Server (one with support for secure renegotiation)
should ALWAYS assert this extension in a renegotiation TLS handshake
_with_ the verify_data of both server.finished and client.finished
in the ServerHello -- including when the client didn't send the
extension (maybe because the client didn't dare confusing an SSLv3 server).

If we recommend the Server to no longer perform insecure renegotiation,
we could instead recommend that the server unconditionally asserts the
ServerHello extension for the renegotiation handshake.  

This would even allow clients to agree to a secure renegotiation,
which did not dare proposing it (because of an interoperability
constraint with some legacy SSLv3 servers that choke on TLS extensions).

Those clients that propose the secure renegotiation may need a
fallback to a vanilla SSLv3 ClientHello.  Such a fallback would have
to be made at the apps level and is a significant change.  Allowing
server to assert this particular TLS extension in the ServerHello
of a _renegotiation_handhshake_ without having received it in the
ClientHello would obviate the need for the client to add a
TLS extension to the ClientHello, and therefore may obviate the
necessity of a re-connect fallback.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Mon, 09 Nov 2009 14:44:41 -0600

Martin Rex wrote:
> Allowing
> ClientHello

What's going to check it?

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Mon, 9 Nov 2009 21:59:07 +0100 (MET)

> What's going to check it?

The client will have to check it, of course -- or abort with
a handshake failure.

It is not very nice to drop the entire responsibility on the client
(which could be silently ignoring the server hello extension), I agree.
Such a semantics would change an opt-in for secure renegotiation into
an opt-out.

The underlying scenario, that we are looking at, is that the server
is asking the client whether it takes responsibility for the contents
of the previous session.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 9 Nov 2009 22:19:19 +0100 (MET)

> is asking the client whether it takes responsibility for the contents

Thinking about it, it is probably too daring to interpret the
absence of an error as the confirmation of intent.

How about an alternative HelloRequest, a "SecureHelloRequest",
that signals to the client it is supposed to assert the
secure renegotiation TLS extension on the renego ClientHello
including the verify_data of the last client.finished
or the server will abort the handshake.

I'm wondering what a Server with an existing SSLv3 (0x03,0x00) session
can do if it wants either a secure renegotiation or abort.

Since SSLv3 does not define a "no_renegotiation" alert, a server that
sends a HelloRequest and the determination to abort on insecure
renegotiation could as well send a SecureHelloRequest in order
to "encourage" a client that is only configured to send SSLv3
ClientHellos for maximum connectivity (and no app-level fallback).

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 09 Nov 2009 14:15:11 -0800

At Mon, 9 Nov 2009 21:35:57 +0100 (MET),
> extension (maybe because the client didn't dare confusing an SSLv3 server).

This is forbidden by RFC 4366: servers can only send what the client
offers:

   Note that for all extension types (including those defined in the
   future), the extension type MUST NOT appear in the extended server
   hello unless the same extension type appeared in the corresponding
   client hello.  Thus clients MUST abort the handshake if they receive
   an extension type in the extended server hello that they did not
   request in the associated (extended) client hello.

-Ekr

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 10 Nov 2009 04:43:59 +0000

> ServerHello extension for the renegotiation handshake.

That's not necessary. Suppose that the client sent an SSLv3 ClientHello
with client_version = 3.1 (or higher). Assuming the server supports TLS,
then TLS will be negotiated. So when the client sends the renegotiation,
it knows that it is safe to send extensions. The attack is prevented as
long as the renegotiating handshake uses the extension; it is not necessary
for the initial handshake to have used it.

However, the draft is not clear enough on that last point. It should
clarify that, while including a zero-length Renegotiation_Info implies
that the extension is supported (by either the client or server), the
converse is not true: lack of a Renegotiation_Info extension on the first
handshake does not imply that the extension isn't supported.

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

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 09 Nov 2009 21:18:44 -0800

> Suppose that the client sent an SSLv3 ClientHello

The problem is that your initial handshake *is* the renegotiation!
(from the server's point of view)

A client needs to send an empty Renegotiation_Info so that the server
can ascertain whether an attack is taking place.  Otherwise it may be
configured to let you "re"negotiate for practical reasons, and you just
bought someone a pizza.

The scary thing is that a truly paranoid client can't connect to any
unpatched server that asks for credentials immediately.

Mike

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 10 Nov 2009 05:44:29 +0000

Michael D'Errico wrote:
>> long as the renegotiating handshake uses the extension; it is not
>> necessary for the initial handshake to have used it.
> 

I may well be confused, but: a handshake is a renegotiation if-and-only-if
it is encrypted. Initial handshakes are in the clear. So there is no
ambiguity, from either party's point of view, about whether a handshake
is a renegotiation.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 10 Nov 2009 05:53:00 +0000

David-Sarah Hopwood wrote:
> it is encrypted.

Well, except when the ciphersuite specifies no encryption. I should have
said "if-and-only a ciphersuite other than TLS_NULL_WITH_NULL_NULL is in
effect".

> Initial handshakes are in the clear. So there is no

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 09 Nov 2009 22:00:56 -0800

> ambiguity, from either party's point of view, about whether a handshake

Your initial handshake is in the clear from you to the MITM, but it gets
sent over the already-secure connection from the MITM to the server, so
from the server's perspective you are renegotiating.  This is why you
have to send the Renegotiation_Info extension -- it let's the server
know that *you* think you are performing an initial handshake.  It can
then shut down the connection and save you from the attack.

Mike

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 10 Nov 2009 06:24:14 +0000

> ambiguity, from either party's point of view, about whether a handshake

Actually this is not quite right, although not in a way that affects my
main point.

A handshake is a renegotiation from the server's point of view
if-and-only-if a ciphersuite other than TLS_NULL_WITH_NULL_NULL is
in effect. It is possible that an initial handshake by a client that
was sent in the clear, could be encrypted by an attacker and appear to
the server as a renegotiation. In that case, the server can reject the
renegotiation if the ClientHello doesn't contain a correct (and non-empty)
Renegotiation_Info.

It is also possible that, if a client that does not support the extension
requests a renegotiation on a session with the attacker, then the attacker
can decrypt it and present it to the server as an initial handshake.
But this only applies to clients that do not support the extension at all.
If a client does support it and sends it only when renegotiating, then
this variant of the attack is still prevented.

So, I was right in my original statement that "the attack is prevented
as long as the renegotiating handshake uses the extension." Note that
both clients and servers must avoid renegotiating without using the
extension; it isn't sufficient for only servers to avoid doing so.
As long as that is the case, for a client does support the extension,
failing to send the zero-length Renegotiation_Info in an initial handshake
does not enable an attack.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 10 Nov 2009 06:33:42 +0000

Michael D'Errico wrote:
>> I may well be confused, but: a handshake is a renegotiation
>> if-and-only-if it is encrypted. Initial handshakes are in the clear.
>> So there is no ambiguity, from either party's point of view, about
>> whether a handshake is a renegotiation.
> 

If from the server's perspective you are renegotiating, and it doesn't see
a non-empty and correct Renegotiation_Info, then it should shut down the
connection anyway. The server doesn't need to know whether the client
supports the extension; to avoid the attack, it has to shut down the
connection whether the client supports the extension or not.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 10 Nov 2009 06:49:50 -0800

At Tue, 10 Nov 2009 05:44:29 +0000,
David-Sarah Hopwood wrote:
> 
> [1.1  <text/plain; UTF-8 (quoted-printable)>]
> Michael D'Errico wrote:

That's not true if you're under attack. Remember that the attacker is
proxying the client's messages over its own encrypted channel.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 10 Nov 2009 06:50:17 -0800

At Tue, 10 Nov 2009 06:33:42 +0000,
> connection whether the client supports the extension or not.

Yes, that's correct.

-Ekr

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 10 Nov 2009 09:08:20 -0800

A client that wants protection from this attack MUST send the extension
in its initial handshake.  Why don't you want to do that?

The attack being discussed happens on the client's *initial* handshake.
The server sees it as a renegotiation, so the client needs to be able to
tell the server that it thinks it is performing an initial handshake.
That is exactly what this extension provides.  If you don't send the
extension on an initial handshake you are risking being attacked.

All servers SHOULD disable renegotiation to protect clients, but it's
been said that this is impractical.  A server may be configured to allow
renegotiation even though it understands the new extension.  Thus by not
sending the extension in your initial handshake, you are just as
vulnerable, even though you could have prevented an attack.

And it is actually secure for a client to renegotiate even if the server
does not support the Renegotiation_Info extension.  If the client has
verified the server's certificate in the initial handshake, there is no
MITM.

Mike

---

From: Martin Rex <[email-masked]>
Date: Tue, 10 Nov 2009 20:28:16 +0100 (MET)

> in its initial handshake.  Why don't you want to do that?

If there were only well-behaved servers out there, there would not
be any problem.

The default configuration of MSIE6 on WinXP to disable TLSv1.0, as well
as newer browsers providing a reconnect fallback to SSLv3-only ClientHello
indicate that there is an installed base of TLS servers that either
predates the SSLv3 internet-draft from Nov,18th 1996 or is defective.

There used to be a draft draft-pettersen-tls-interop-experience-xx.txt
(I have archived a -00 that expired oct-2006), which describes the
mess around spec non-compliance.  TLS-extensions are covered in section 4.

What it seems to indicate, in essence, is that the for maximum
interoperability with the installed base of (broken) servers out there,
you use a SSLv3 ClientHello with (0x03,0x00) in the client.version
and _no_ TLS extensions.

So conservative clients that do not want to implement reconnect
fallbacks may have a problem with the recommendation to always
use a TLS extension.

There are a number of things we would like to achieve with a fix:

  - provide a method for secure renegotiation in the future

  - deprecate the traditional renegotiation

  - provide a secure base for the (previously flawed) assumptions
    of servers when performing a renegotiation to request a
    client certificate.

in oder to achieve this, we should probably make the following
recommendations:

  - if a TLS client (any protocol version, including SSLv3) performs
    renegotiation (i.e. sends a ClientHello over an established
    TLS session with a ciphersuite other than TLS_NULL_WITH_NULL_NULL),
    then it SHOULD always and unconditionally use the TLS extension
    Renegotiation_Info containing the verify_data of the client.finished
    handshake message from the active TLS session,
    The TLS client should do that even when it did not send the
    TLS extension Renegotiation_Info with and empty extension data
    in the initial TLS handshake on a connection!

    Lacking application level re-connect provisions for forward-incompatible
    SSL/TLS servers, a TLS client might not want to sent the TLS extension
    in the initial ClientHello of a connection.

    If the presence of the TLS extension Renegotiation_Info causes the
    server to abort the TLS connection, then that
    server is not capable of secure renegotiation, and the TLS client
    should abort the Handshake with an error and close the connection
    in order to protect the client and the clients credential from
    abuse with servers that are still vulnerable to the TLS
    renegotiation problem.

 -  A TLS server (any protocol version, including SSLv3) should require
    the presence of a TLS extension Renegotiation_Info for _every_
    renegotiation handshake.

    If the TLS extension Renegotiation_Info is absent from the ClientHello
    received on an active TLS session, the server should abort the
    connection. (add Alert here)

    If the TLS extension Renegotiation_Info is present, then the TLS server
    MUST verify the contained verify_data of the client.finished message
    as known to the client with its own memorized client.finished
    message from the SecurityParameters of the current TLS connection state.

    If the comparison of the verify_data from the client.finished
    messages fails, the server MUST abort the connection.

    When the client's and the server's notion of the verify_data from
    the previous TLS session compare equal, the server MUST send back
    the TLS extension RenegotiationInfo with in a ServerHelloExtension
    containing the verify_data from the client.finished message and
    the verify_data from the server.finished message.

 -  A TLS client (any protocol version, including SSLv3) that receives
    the TLS extension Renegotiation_Info in a ServerHello extension
    must compare the extension data with its own SecurityParameters
    in the TLS connection state.

    If the Renegotiation_Info with empty extension_data is received
    on a client's initial TLS handshake, everything is fine

    If the Renegotiation_Info with empty extension_data is received
    on an active TLS session, the client MUST abort the handshake
    with an error and close the connection.

    If the Renegotiation_Info with non-empty extension_data is received
    on a client's initial TLS handshake, the client MUST abort the handshake
    with an error and close the connection.

    If the Renegotiation_Info with non-empty extension_data is received
    on a client's renegotiation handshake, the client MUST compare the
    contained verify_data of the server-memorized client.finished and
    server.finished messages with its own memorized verify_data for
    both finished messages in the SecurityParameters of the TLS connection
    state for the current session.
      - if they compare equal, everything is fine
      - if they do not match, the client MUST abort the handshake and
        close the connection.

It is possible that a TLS client may not want to assert the TLS extension
Renegotiation_Info in an initial ClientHello because of interoperability
concerns with an installed base of not-quite-spec-compliant servers.

What other strategies could be used on the initial handshake on a 
connection with lesser side effects that a TLS extension Renegotiation_Info
with empty extension_data?

Overloading ("abusing") the semantics of other regular elements
of an SSL/TLS handshake that have a lesser likelihood to upset
legacy servers.

   - Assign one (or two) specific ciphersuite IDs that the client
     can include in the ciphersuites list which signal the clients
     notion of the connection state (initial vs. renegotiation)
     to the server.

   - Assign one (or two) compression algorithm IDs that the client
     can include in the supported compression algorithms list which
     signal the clients notion of the connection state (initial vs.
     renegotiation) to the server.

I assume that a Client->Server signalling through a special cipher suite
might be the easy to implement for clients and expect that it has the
least side effects on handshakes with old servers.

Fancy compression algs might be less digestable to old servers.

Both of these (one or two fany ciphersuites in the ciphersuite
list of the client) can only be used for signalling from client
to server, not in the direction server to client.

What could be used to signal from the server to the client that the
client should send the TLS extension Renegotiation_Info in the
ClientHello of a renegotiation handshake if the client does not
want to send the TLS extension in the initial handshake of a
connection?

We could define a new TLS handshake message "RenegotiationRequest"
to be sent instead of a "HelloRequest".  This would be an option for
those servers, that will abort the handshake and connection
if the client does not send the TLS extension Renegotiation_Info.

The purpose of a RenegotiationRequest would be to encourage clients to
send the TLS extension Renegotiation_Info, in order to keep existing
usage scenarios usable.  The message itself is not protected, but
that doesn't matter.  The servers decision for success or failure
of the renegotiation depends only and entirely on the use of
the TLS extension Renegotiation_Info in the renegotiation handshake
and successful verification of the verify_data from the 
client.finished handshake message of the active TLS session.

-Martin

---

From: Steve Dispensa <[email-masked]>
Date: Tue, 10 Nov 2009 13:37:27 -0600

>     in the initial ClientHello of a connection.

This was discussed a bit at the Sept. 29 meeting. I had originally suggested
that the extension need not be present during initial negotiations at all,
but it was pointed out that network management systems might want to
inventory patched clients and servers.

> of an SSL/TLS handshake that have a lesser likelihood to upset

This is an interesting potential solution to the network monitoring problem,
if nothing else. 

 -Steve

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Nov 2009 14:32:46 -0600

> inventory patched clients and servers.

I guess we'll see whether the need to interop with broken servers (which
are probably broken forever, and therefore vulnerable forever) is
important enough that implementors will have to include a knob for
whether to send this extension on initial negotiations.  I consider the
fact that it will break such broken servers a feature, but one must be
realistic also.

Nico
--

---

From: Yair Elharrar <[email-masked]>
Date: Tue, 10 Nov 2009 22:52:03 +0200

> inventory patched clients and servers.

This could backfire. It would allow hackers to detect unpatched clients, and focus their attacks on them.

Yair
--

This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.

If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 10 Nov 2009 12:58:59 -0800

> concerns with an installed base of not-quite-spec-compliant servers.

Then it will end up buying a lot of pizza.

Simply finishing the *initial* handshake completes the attack!  (The
server saw it as a renegotiation, not the client.)

To protect against this, the only thing that a client can do is include
the empty renegotiation info extension.  If the server returns it and
the handshake completes, there is no MITM.  In fact if you were to then
renegotiate, you wouldn't need the extension (!) because you are already
certain that the handshake was with the server and not the MITM.

There are a few possible results of sending the extension:

     a) the server responds with the extension
     b) the server responds without including the extension
     c) the server "crashes" because of the extension

(a) is fine as long as the extension is empty.
(c) could be simulated by the MITM, so be careful -- falling back to a
     less-secure mode can play into their hands
(b) continue at your own risk -- a client could hold off on sending a
     certificate (if requested) and not send any Cookies.  The HTTPS
     request will fail, but the client can just reissue it after the
     failure -- possibly after renegotiating to send its certificate
     (this is secure if the client has verified the server's cert).

>      renegotiation) to the server.

I would not like to see this kind of solution.  If code has to change,
Do The Right Thing.

> if the client does not send the TLS extension Renegotiation_Info.

Again, the attack happens on the client's *initial* handshake, so it
never receives a HelloRequest.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Tue, 10 Nov 2009 15:17:28 -0600

> fact that it will break such broken servers a feature, but one must be

It's one thing to say, realistically, some client applications may elect
to put their users at risk for the sake of continuing to work with
defective servers.

It's something else entirely to propose that an IETF spec's official
language and recommended practice for implementors should be weakened in
consideration for these noncompliant systems.

Perhaps those responsible for such systems will take this opportunity to
update them?

Yair Elharrar wrote:
> This could backfire. It would allow hackers to detect unpatched
> clients, and focus their attacks on them.

There are plenty of ways for to attackers to fingerprint clients (looked
at a user-agent string lately?) and it doesn't make sense to make life
difficult for those who have a legitimate need for the data.

Again, where there are trade-offs affecting security and
interoperability, let us favor the side of implementations that will
follow the specs and recommendations over those which do not.

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Nov 2009 15:21:02 -0600

> consideration for these noncompliant systems.

Indeed.  And I don't propose the latter.  Instead, if we must say the
sky will now be <color other than blue> we should also caveat that it
will likely continue to be blue for a long time.

> Perhaps those responsible for such systems will take this opportunity to

One should hope so.

> difficult for those who have a legitimate need for the data.

Agreed.  Also, looking vulnerable and being vulnerable are not the same
thing.

---

From: Martin Rex <[email-masked]>
Date: Tue, 10 Nov 2009 23:25:13 +0100 (MET)

> Then it will end up buying a lot of pizza.

What you're asking for is to discontinue talking to the entire installed
base of SSL&TLS implementations.  i.e. clients should only talk to
updated servers (which means they must be updated clients).

What about a transistion period?
(A world-wide "SSL/TLS flag day" is probably unlikely) 

How do you determine the end of the transition period, i.e.
the point in time where clients discontinue to servers that were
not updated?

> server saw it as a renegotiation, not the client.)

But you do realize that it is an attack on the server?

And do you further realize, that it is a problem of the server
that request or at least allow renegotiation -- those that reject
renegotiation are _not_ vulnerable.

The MITM only makes you talk to someone.

Considering how careless some security folks invent means to coerce
someones software to talk to someone else (e.g. certificate URL TLS extension,
AIA in X.509 certs), I don't feel it is fair to hold the TLS clients
responsible for the problem.

What you're asking for means that the Browsers should discontinue
their re-connect fallback with a SSLv3 ClientHello, because the
MITM could be able to coerce the browsers to do it.

> certain that the handshake was with the server and not the MITM.

HUH?  The Renegotiation_Info is required for cryptographic binding
during the renegotiation handshake.  Without it, there is zero protection.

>      c) the server "crashes" because of the extension

You have forgotten
       d) the server sends a fatal handshake alert
       e) the server closes the network connection

> I would not like to see this kind of solution.  If code has to change,

The IETF should provide solutions to the _real_ world.
Limiting our solutions to an ideal world of academic purity will
hurt the entire community of end users around the world.

To me it looks like the TLS WG did not sufficiently care and push
that implementations support the "official" extensibility provided
already in the SSLv3 protocol (ClientHelloExtension), therefore
we may have to resort to (ab)using the purpose of other
extensibility options provided in the protocol that have a
significantly higher interoperability among implementations.

Assigning a ciphersuite IDs for the purpose of signaling
support for TLS extension Renegotiation_Info in a initial
handshake on a connection (as seen by the client) and
including that ID in the ciphersuites list offered by the
client might offend/confuse less of the old servers than a TLS
client extension or a client.version != 0x03,0x00

It might be OK for an updated client to always send the
TLS extension Renegotiate_Info with the verify_data from
the client.finished message on a renegotiation handshake.
In that case, we would not need to signal the clients
notion of "initial vs. renegotiate" with an additional
re-purposed ciphersuite ID.

Even if _you_ can update all _your_ clients and server that
you are using, this does not make the other non-patched (but also
not vulnerable) servers go away.  The problem that were facing
right now is not caused by those servers.  It's _our_ fault
(Netscape and the IETF TLS WG), because _we_ created this problem
with a design flaw in the protocol.  So if _we_ are not trying to
provide a solution in a fashion that breaks the least amount of
the installed base, then we're not acting responsibly.
That would amount to shifting blame / passing the buck, it would
not be the engineering solution that the community expects from us.

When thinking about re-purposing other areas of the exiting protocol,
our concerns should be more along the lines: what will break if
we do that?  who might be confused by this change, and what problems
may arise from such confusion?  can the re-purposing lead to a new
security problem by itself?  How good can we interop-test this?

Personally, I think that religious beliefs about protocol purity
are much more important for new protocol design and forward
interoperability issues.  They are at most marginal when
trying to fix a problem that is more than 14-years old would
require then entire world to update in order to protect
a small amount of people against a small amount of servers
that will irresponsibly continue to make assumptions accross
TLS session boundaries of an unprotected TLS renegotiation.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 10 Nov 2009 16:35:24 -0800

> updated servers (which means they must be updated clients).

I'm not asking for that.  People seem confused about who sees the
renegotiation.  The client *does not* see a renegotiation in the MITM
attack.  It simply connects once giving its credentials, and the attack
is complete.

> (A world-wide "SSL/TLS flag day" is probably unlikely) 

Yes, very unlikely.

> But you do realize that it is an attack on the server?

I just learned of the "confused deputy" attack and it appears that this
is an example of that, with the server acting as the confused deputy.

The server is attacked, but the client is also a victim because they
need to spend the time and energy convincing their credit card company
they didn't order something.

> renegotiation are _not_ vulnerable.

Agreed.

> responsible for the problem.

They are not responsible, but they need to be given a defense mechanism.
If they choose not to use the mechanism (i.e. by not sending the extension
on initial connect), they are not going to be protected by that mechanism.

> MITM could be able to coerce the browsers to do it.

He can indeed.  This is a really bad flaw.  I'm saying that it's risky to
fall back, but I'm sure that won't stop everyone from doing it.

> during the renegotiation handshake.  Without it, there is zero protection.

 From just the client's perspective, all it needs is for its initial
handshake to have sent and received an empty renegotiation info extension.
Once that handshake completes, it knows that there is no MITM.  From then
on, it doesn't need secure renegotiation; it can only be talking to the
same server.

 From the server's perspective, though, it does need the cryptographic
binding since it can't tell if a renegotiation is real or proxied.

>        e) the server closes the network connection

(e) is the same as (c), and (d) can be forged too.

> hurt the entire community of end users around the world.

If it's not possible to Do The Right Thing, then I am onboard with
doing whatever it takes.  Hijacking a ciphersuite number wouldn't
be the end of the world.

Mike

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 Nov 2009 01:58:14 +0100 (MET)

> attack.  It simply connects once giving its credentials, and the attack

It doesn't see one in the scenarios described by Marsh.

The client will see an renegotiation in the scenario I posted to this list.

> on, it doesn't need secure renegotiation; it can only be talking to the

So if I mount the attack I described on your client, and use the
empty TLS extension in the sess1 handshake between your client and
my MITM, then your client is going to renegotiate blindly with the
server to which I'm connecting it?  Not good.  Your fix is incomplete.

Here's a mean out-of-context quote from RFC-5246:    :-D

   D.4.  Implementation Pitfalls

      [...]

   TLS protocol issues:

      [...]

   -  Do you support renegotiation, both client and server initiated?

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 10 Nov 2009 17:42:33 -0800

> server to which I'm connecting it?  Not good.  Your fix is incomplete.

I don't remember exactly your version of the attack, but if my client
connects to a MITM, it will notice that the server certificate is
wrong.  I don't support DH_anon if that was required in your attack.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Tue, 10 Nov 2009 21:59:36 -0600

Michael D'Errico wrote:
> I'm not asking for that.

Even if Michael were, is there a choice? Is it even that unprecedented?

Many endpoints no longer talk SSLv2. Presumably there was at least some
software that once spoke earlier variants.

Why were they abandoned, was it for saving bytes? Probably not. Did it
make or save anybody much money? Probably not, SNI would long have been
adopted if money were a sufficient motivator.

No, earlier versions were abandoned because they were found to be
less-than-ideal in the security department.

This weakness is one of the last nails in the coffin for SSLv3, doomed
from the start due to its lack of proper extensibility. It seems
appropriate since it was 3.0 that quietly introduced this renegotiation bug.

>> (A world-wide "SSL/TLS flag day" is probably unlikely) 

In some sense, SSLv3 was given the "legacy" label in January 1999, the
date on RFC 2246 defining TLS 1.0. Who can complain after having been
given 11 years' notice?

For fixing TLS, there will certainly be a transition period the length
of which will be determined by vendors, admins, and users as always.

> []

It's an attack on a protocol which both parties are counting on for
secure communications. There's nothing inherent in it that favors the
security of one side over the other.

>> renegotiation are _not_ vulnerable.

What if variants of the attack allow MITM to renegotiate with the client
and inject data towards it?

Doesn't the server application have just as much an interest in the
integrity of the message as the client app does? Would you want to
exchange critical secret documents with someone who was known to fall
for simple email scams?

> fall back, but I'm sure that won't stop everyone from doing it.

I believe the key is correct information at the appropriate times.

I personally would expect my browser to warn me if it was falling back
to a less secure communication path. Users should expect to be given
both complete raw information and synthesized recommendations such that
they can 1) make an informed decision, 2) not be talked-down to, 3)
learn something if they're in that mood.

>>> I would not like to see this kind of solution.  If code has to change,

A simple 'renegotiating' flag has been proposed several times, but I
don't think it adequately addresses the problem (binding the sessions
over a single connection).

Now MITM just has to put the client in some state such that the client
believes he's renegotiating (without losing the connection crypto state
or having some private key). It's certainly allowed for a conformant TLS
client to be willing to renegotiate with MITM. I believe there are
actual applications that may do that (intentionally or not).

Perhaps it could be useful for SSLv3 though.

Really though, we need to smuggle as much content as we can from the
previous Finished messages. For example, probably no one would mind if
we used some of those bottom bits of the GMT time in the ClientHello
"random". We could probably put a few bits in the random area, too.
After all, if they were willing to throw away 30+ bits of entropy (13%
of it!) just to send the current time, surely we could use some space
for verify data. Just 10 bits could make the attack 1000x harder.

The same trick could be used to smuggle Finished verify data in the
Server Hello as well.

Thinking about it, the Hello messages are passed under the same crypto
params as the verify data was originally, so it's not disclosing
anything new. They also cannot be manipulated to assume certain values
without breaking the hash in way that would be catastrophic even without
renegotiation. They are statistically psuedorandom.

One thing is that the Finished verify data is longer than the
Hello.Random. Go figure. So we might take a subset of its bits, or they
could be distributed as a statistical "watermark" on top of actual
random data. For a worst-case estimate we could assume verify data are
altogether free of entry. Even then we could make the MITM's job about a
billion times harder at the cost of only another 13% of entropy from the
random pool.

Seems like something along these lines might work. This may be
cryptographically dumb in some obvious way. I haven't thought about it
much until just now and obviously it would need review.

>> hurt the entire community of end users around the world.

There are many, many deployments of TLS that will upgrade both endpoints
to the most secure version the millisecond it becomes available from
their vendors. They are very much in the real world.

- Marsh

---

From: <[email-masked]>
Date: Wed, 11 Nov 2009 10:05:20 +0100

Martin,

I think we should provide *some* way to make this secure while still
allowing "fallback to less advanced TLS handshakes" (e.g. from "TLS
1.2 with extensions" to "TLS 1.0 without any extensions", or even
"SSLv3 without any extensions" -- the specifics vary from one
implementation to another, but I think "without extensions" is
one common part). Those fallbacks aren't going to go away any time 
soon...

Of the possibilities listed in your email, my preference would to
allocate a cipher suite number that means "I support the renegotiation
extension, but chose not to include it" (perhaps because an earlier
connection with the extensions failed -- which could have been caused
by the attacker).

(If I recall right, some tests I run around 2006 suggested that
some servers didn't like ClientHello's proposing non-NULL compression
algorithms -- so a magic compression algorithm number might lead
to interop problems, too. But AFAIK all servers properly ignore 
cipher suite numbers they don't support...)

Best regards,
Pasi
(speaking as individual contributor, not wearing any hats) 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Martin Rex
> Sent: 10 November, 2009 21:28
> To: Michael D'Errico
> Cc: [email-masked]
> Subject: [TLS] TLSrenego - current summary of semantics and
> possibilities
> 
> Michael D'Errico wrote:
> >
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 Nov 2009 20:16:55 +0100 (MET)

> appropriate since it was 3.0 that quietly introduced this renegotiation bug.

I think you might be barking up the wrong tree.

This MITM-susceptibility is _not_ a problem specific to SSLv3.
It is a problem that affects the entire installed base of
TLS v1.0, TLS v1.1 and TLS v1.2 in _exactly_ the same fashion.

What I do NOT want to happen is that we kill the entire installed
base of TLS-servers now (including TLS v1.2 servers), which is what
will be doing if we disable our clients to talk to servers that
are not updated -- completely independent whether these servers
are actually vulnerable.

As far as upgrading/fixing is concerned: I do _not_ see an issue
the SSLv3 spec that would prevent the proposed fix to be used
even for sessions negotiated with protocol version 0x03,0x00.

There is, however, the problem with killing interoperability
to an installed base by having the client unconditionally send
a TLS extension in each initial ClientHello.

The issue of interoperability with that installed base seems to
have been sufficiently severe, that at least one Browser vendor
decided to implement a re-connect retry logic with a fallback
to extension-free SSLv3 ClientHello.

Do you really want to say "nice work -- we want you to remove
or disable the fallback and ignore your customers complaints" --
and not because that fallback is bad or because their clients
have a vulnerability -- but because we believe there is going
to remain a small amount of unfixed servers where the attack will
remain possible (but affecting only the users/customers
of that servers).

> 
> >> What about a transition period?

What I meant was the transition period to an area of fixed servers.

We need to ship clients capable of secure renegotiation before we
can disable the old renegotiation on the servers.

And we need to upgrade servers to secure renegotiation before we
can suggest updated clients to discontinue talking to old servers.

And this is again, totally independent of the protocol version
implemented by those clients and servers, it affects all of
them in the exact same fashion and with the exact same severity.
(actually, the likelyhood of servers implementing or agreeing
 to renegotiation might increase with the supported TLS version,
 TLS v1.1 servers are more likely to be vulnerable to MITM than
 SSLv3 servers, because more of them implement renegotiation).

> learn something if they're in that mood.

Servers performing a traditional SSL handshake is _not_ a security
problem.  Servers performing a traditional renegotiation is a likely
a security problem.

Clients can not currently notice what the server is doing, and the
problem exists, because a clients initial handshake can be proxied
into a servers renegotiation.

A client that is performing an initial handshake does _not_ know
whether there is a security problem, therefore I'm very reluctant
to suggest clients to warn users when performing a traditional
initial handshake.  It is going to be unfair to an ever-growing
number of servers.

> for verify data. Just 10 bits could make the attack 1000x harder.

Doing the secure renegotiation through the TLS extension in an
official renegotiation is not the problem.  Fixing means that the
code will have to be changed.  If the change is sufficiently small,
it can be added with a relative small amount of work to servers
at all protocol levels, including SSLv3.

> The same trick could be used to smuggle Finished verify data in the

The most interesting piece is actually a signaling from the server
to the client that it is performing an _initial_ handshake.  That is
an important information that the client does not currently have.
And adding such a signal might be the easiest for old servers that
need neither renegotiation and neither new TLSv1.x protocol features.

In principle, every element in the vanilla ServerHello might be a
candidate for such signaling.  But unless the client provides an
indication for understanding and accepting a protocol change
through a signal in ClientHello, we are extremely limited.

That signaling from server to client that it is doing an initial
handshake should be
 - fully backwards compatible with oldest clients
 - very very very low number of false positives

Looking at SSL/TLS handshake messages from Server to Client:

   ServerHello (always sent)
       struct {
           ProtocolVersion server_version;
           Random random;
           SessionID session_id;
           CipherSuite cipher_suite;
           CompressionMethod compression_method;
       } ServerHello;

  ServerHelloDone (not sent on Session resume, empty)
      struct { } ServerHelloDone;

  ChangeCipherSpec (not a handshake message, unprotected, empty)

  Finished (always sent)
       struct {
           opaque verify_data[12];
       } Finished;

Looking at the ServerHello contents in detail, what elements
could be re-purposed in a _completely_ backwards compatible fashion:

   ProtocolVersion   -  no
   Random            -  potentially
   SessionID         -  not really 
   CipherSuite       -  no
   CompressionMethod -  no

and looking at Random in detail:

           struct {
              uint32 gmt_unix_time;
              opaque random_bytes[28];
           } Random;

       gmt_unix_time
       The current time and date in standard UNIX 32-bit format (seconds
       since the midnight starting Jan 1, 1970, GMT) according to the
       sender's internal clock. Clocks are not required to be set
       correctly by the basic TLS Protocol; higher level or application
       protocols may define additional requirements.

   random_bytes
       28 bytes generated by a secure random number generator.

So the smallest possible change to a server that could be used
to signal to ANY client that it believes to be doing an initial
handshake might be to set the most significant octet of the
gmt_unix_time to zero in order for a server to signal in an
extremely backward compatible fashion to the client that it
is performing an initial TLS handshake on a connection.

Unaware of how many server out in the wild do this by accident,
or how many forget to use network byte order for this value
(and would cause an accidental gmt_unix_time collision every
 256 seconds), all of the sensible old implementations out there
are going to always signal the initial handshake to conservative
clients that still do not send a TLS extension in year 2106.

The remaining 28 octets of the random still provide "some"
amount of collision resistance against accidental challenge reuse.

This change is so small, that it might even be considered for
very old code in very constrained environments, e.g. like
a 10+ year old satellite in orbit -- I would really like to
hear from folks with such constraints think about implementing
renegotiation protection with the TLS extension -- because
they might have an actual need for rekeying (rather than
requesting client certs) through renegotiation.

The purpose of this minimalistic change is that _one_day_
we will really be able to recommend to clients/browsers that they
warn when they encounter servers that do _not_ indicate when they're
doing an initial handshake (either because they're old und unchanged
or because someone is trying an MITM on one of the few remaining old
servers that has neither been fixed nor renegotiation reliably disabled).

-Martin

---

From: Yair Elharrar <[email-masked]>
Date: Wed, 11 Nov 2009 21:43:09 +0200

> is performing an initial TLS handshake on a connection.

It would probably be better if the entire 32-bit gmt_unix_time was set to one of two predefined magic values: one indicating an initial connection ('INIT'), the other indicating a renegotiation ('RNEG').
A client receiving 'RNEG' on an initial handshake would know the session is under attack.
A client receiving 'INIT' on an initial handshake would know the session is safe.
Any other value would indicate the server is running an insecure implementation.

--

---

From: Marsh Ray <[email-masked]>
Date: Wed, 11 Nov 2009 13:49:30 -0600

Yair Elharrar wrote:
> Martin Rex wrote:
> 
> It would probably be better if the entire 32-bit gmt_unix_time was
> set to one of two predefined magic values:

Do you know that nothing cares about the actual time encoded?

Why burn 32 bits of entropy to represent one bit?

> one indicating an initial
> connection ('INIT'), the other indicating a renegotiation ('RNEG'). A
> client receiving 'RNEG' on an initial handshake would know the
> session is under attack. A client receiving 'INIT' on an initial
> handshake would know the session is safe. Any other value would
> indicate the server is running an insecure implementation.

The problem still exists between sessions (2,3) (3,4) and so on.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 Nov 2009 21:09:08 +0100 (MET)

Yair Elharrar wrote:
> set to one of two predefined magic values: one indicating an initial
> connection ('INIT'), the other indicating a renegotiation ('RNEG').
>

 asctime(gmtime("INIT")) = Sun Dec 21 13:49:08 2008  GMT

 asctime(gmtime("RNEG")) = Fri Oct  4 04:34:15 2013  GMT

In theory, 28 random octets provide sufficient room for
probabilistic collision resistance, unless the server
has a real shortage of randomness or a very poorly implemented
function to produce the Random for the ServerHello.

> Any other value would indicate the server is running an

I really do not like to label these an _insecure_.

Any other value gives the client no clue whether the server
is doing an initial or renegotiation handshake, because
it does not contain this change.

-Martin

---

From: Yair Elharrar <[email-masked]>
Date: Wed, 11 Nov 2009 22:07:28 +0200

> The problem still exists between sessions (2,3) (3,4) and so on.

I'm not suggesting to remove the new extension altogether; only from initial ClientHellos.
Once the client knows the server is patched, it will use the extension in renegotiations.
The server should never allow renegotiations without the new extension.

Yair
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 Nov 2009 21:15:06 +0100 (MET)

> Why burn 32 bits of entropy to represent one bit?

Yair's suggestion is actually 3 states (~1.5 bits)
   initial, renegotiation, unknown

but other than that, it also seems like waste to me to re-purpose
the _entire_ 32-bits.

> The problem still exists between sessions (2,3) (3,4) and so on.

New clients should not renegotiate with servers that lack the
secure renegotiation extension.  There is no problem with clients
participating an initial handshake with these, provided that they
can distinguish initial from renegotiation handshakes performed
by the server.

-Martin

---

From: "Rob P Williams" <[email-masked]>
Date: Wed, 11 Nov 2009 15:21:42 -0500

Hi,

I have a different suggestion for keeping SSLv3 safe.

The problem for SSLv3 and TLS1~1.2 was created here:

5.6.9 Finished

handshake_messages         All of the data from all handshake messages
                           up to but not including this message.  This
                           is only data visible at the handshake layer
                           and does not include record layer headers.

If ALL handshake messages were used - this problem would not exist.
Implementations have treated 'all' as 'from the current handshake'.
(TLS1.0 cemented this problem).

By changing the way the Finished message is calculated - you can make
SSLv3 safer.

Approach:

    For initial handshakes - keep the calculation the same.

    For subsequent handshakes - 
        append extra information to 'handshake_messages' before being
hashed.
        This could be as simple as a counter. 
        This could be the finished data from the previous handshake.

	I've attempted to draw a table of what would happen when
renegotiating;

	OC = old client
	NC = new client
	OS = old server
	NS = new server

            OS   | NS
           ------+-----
      OC  |  .   | fail
      NC  | fail | good

OC-NS failure - is useful - 
    it shows the attack being mitigated.
NC-OS failure - is ALSO useful.
    By attempting to renegotiate - you can verify if you are talking to
an OS or NS.

--
rob | Software Developer
Certicom Corp. | A susbidiary of Research In Motion Limited

main | +1 905-507-4220
direct | +1 905-501-3887

[email-masked]
www.certicom.com

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 11 Nov 2009 22:25:09 +0200

I disagree that it's a waste to repurpose the entire 32-bit value.  Sure we could use only the top two bits (00 for initial, 01 for reneg - it's after 2004, so all times have MSB=1), but then you can't tell the difference between a patched TLS implementation and an implementation with its system clock not set properly.

A 32-bit magic value (the date of the first chartering of the TLS WG and the date of the vulnerability being published?) will reduce the likelihood of error to negligible. Two bits won't

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Martin Rex [[email-masked]]
Sent: Wednesday, November 11, 2009 22:15
To: Marsh Ray
Cc: [email-masked]
Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3

---

From: Marsh Ray <[email-masked]>
Date: Wed, 11 Nov 2009 14:43:20 -0600

> TLS v1.0, TLS v1.1 and TLS v1.2 in _exactly_ the same fashion.

Yes, but TLS >= 1.0 can be fixed properly with
https://datatracker.ietf.org/drafts/draft-rescorla-tls-renegotiation/

> even for sessions negotiated with protocol version 0x03,0x00.

SSL 3.0 doesn't seem to allow extensions on Server and Client Hello
messages.

> a TLS extension in each initial ClientHello.

TLS allows extensions and specifies when they should be ignored.

> to extension-free SSLv3 ClientHello.

Maybe that was one of those "we've always done it that way" decisions
that needs to be revisited.

> remain possible (but affecting only the users/customers

To the extent TLS is about delivering on its stated and implied security
guarantees.

That may or may not meet the requirements of any specific application.

> can suggest updated clients to discontinue talking to old servers.

The proposed draft-rescorla-tls-renegotiation "RI extension" provides a
solution which restores the security of connections where both endpoints
implement it.
There is probably no way to restore that security without patching both
endpoints.

The RI extension also maintains backwards compatibility with existing
conformant TLS endpoints. There are reports of some non-conformant
servers that might not like seeing an extension on TLS, we can hardly
ask the world to forever abandon the idea of Hello message extensions as
a result!

The timeframe over which users and admins move to configure their
applications to deny connections with unpatched endpoints ("secure
mode") is up to each individual, in conjunction with their vendors. I
have opinions about it, but it really is a situation which will need
informed judgement on a case-by-case basis.

The timeframe over which the default settings of new installations (and
late-patched existing deployments) migrates to secure mode is largely up
to the TLS implementation and application vendors.

> problem.

There are some attacks in which the client sees the renegotiation and
the server only sees one connection.

> into a servers renegotiation.

Which is particularly bad when the client is willing to provide client
cert authentication in that handshake.

> initial handshake.

The client can determine if he is handshaking with an unpatched TLS
server when he sees the Server Hello message without the RI extension.
It sounds reasonable to me that the client might indicate this
potentially-insecure situation in whatever UI or log facility the client
application provides.

> It is going to be unfair to an ever-growing
> number of servers.

No, the number of unpatched servers in the world will begin shrinking as
soon as the fix becomes available.

> at all protocol levels, including SSLv3.

So SSLv3 would be retroactively given hello extensions? Sounds like a
breaking change. Wouldn't it be easier to just use TLS?

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Wed, 11 Nov 2009 15:23:14 -0600

> By changing the way the Finished message is calculated - you can make

I think this is a good idea for SSLv3. (the proposed extension is better
for TLS)

>         This could be the finished data from the previous handshake.

It has to be something that MITM cannot prep the client or server into
matching. A 'renegotiating' bit is not sufficient, even a counter may
not be (M just renegotiates that same number of times before splicing).

Is it possible to define this in terms of what already exists? E.g.
simply "don't reset the handshake MAC state for renegotiations" ?

> 	I've attempted to draw a table of what would happen when

Well, if the remote endpoint allows you to initiate a renegotiation. MS
IIS for example responds with a TCP RST, other implementations may be
less direct.

- Marsh

---

From: "Rob P Williams" <[email-masked]>
Date: Wed, 11 Nov 2009 17:04:12 -0500

> not be (M just renegotiates that same number of times before
splicing).

The counter option would mitigate this attack, the client is at
'initial', the server is at one when the splice is attempted. The hashes
in the Finished message will be different.

An attacker would require both ends to handshake the same number of
times (and be in sync) to make the splice possible. 

A client that would handshake with the attacker (to match the counter)
would be susceptible to a proxy...

Adding the previous finished data to the hash offers similar features to
the TLS extension proposal. Instead of transmitting the channel binding
explicitly, they are being compressed by MD5 and SHA1.

> simply "don't reset the handshake MAC state for renegotiations" ?

I feel that keeping the digests themselves (the bytes, or the finished
data, or the counter), and not the state of the SHA1 and MD5 (which may
never be used) is less resource intensive.

However, keeping them running would match the 'ALL' handshake messages
point above...

> IIS for example responds with a TCP RST, other implementations may be

Good point! 

An attacker could just hang up on a (current or new) client to make them
think they are using a renegotiation proof IIS instance... 

Only seeing a correct renegotiation with a new server would verify that
you are talking to a new server.

main | +1 905-507-4220
direct | +1 905-501-3887

[email-masked]
www.certicom.com

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 11 Nov 2009 16:35:25 -0800

> potentially-insecure situation in whatever UI or log facility the client

A MITM could remove the extension from the ServerHello to trick you into
thinking the server doesn't support it.  Unless you finish the handshake,
you won't know.  But if you do finish it, you could be attacked.  Very
insidious!

Mike

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 12 Nov 2009 14:22:23 +1300

Yoav Nir <[email-masked]> writes:

>I disagree that it's a waste to repurpose the entire 32-bit value.  Sure we
>could use only the top two bits (00 for initial, 01 for reneg - it's after
>2004, so all times have MSB=1), but then you can't tell the difference
>between a patched TLS implementation and an implementation with its system
>clock not set properly.

... or an implementation that sees advertising your machine's clock skew to
the world as a security weakness (which it is when it starts interacting with
PKI) and sets the time field to a random value.

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 12 Nov 2009 03:28:50 +0200

Implementations actually do that?  

Probably makes sense, I guess.
________________________________________
From: pgut001 [[email-masked]] On Behalf Of Peter Gutmann [[email-masked]]
Sent: Thursday, November 12, 2009 03:22
To: [email-masked]; [email-masked]; Yoav Nir
Cc: [email-masked]
Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 12 Nov 2009 14:44:39 +1300

>Implementations actually do that?

I know of at least two that do, so it's at least a nonzero result :-).  There
may be a lot more, since no-one checks the time and there's no obvious reason
to include it in the nonce it's quicker and easier for an implementation not
to bother (quite apart from any security concerns).

Peter.

---

From: Martin Rex <[email-masked]>
Date: Thu, 12 Nov 2009 06:12:44 +0100 (MET)

> https://datatracker.ietf.org/drafts/draft-rescorla-tls-renegotiation/

There is nothing in that draft that prevents its use for SSLv3

> SSL 3.0 doesn't seem to allow extensions on Server and Client Hello

That is wrong.  The SSLv3 spec has the exact same provisions for
TLS extensions as the TLSv1.0 and TLSv1.1 specs.

TLS extensions became a standard part of the protocol in TLSv1.2 only.

Compare the specs and you will see.

> that needs to be revisited.

Breaking installed base just for the sake of the fun of it
sounds like a pretty bad idea.

> There is probably no way to restore that security without patching both

This is a misrepresentation.
There is _NO_ known security problem with a full TLS handshake if
_no_ renegotiation is performed. 

I'm perfectly OK with fixing TLS to provide a secure basis for the
previously flawed assumptions of several servers, provided that all
servers that want to use renegotiation in the future are updated.

I have a very significant problem with any recommendation, let alone
a requirement to brick perfectly valid and secure installed base
that does not contain this TLS enhancement, but also doesn't contain
renegotiation and there is not vulnerable.

Especially since this is completely unnecessary!

> the server only sees one connection.

So what?  The vulnerability is only an entirely with the part that
performs the insecure renegotiation.  The reliable fix (without upgrade)
is to disable renegotiation of that component.

> breaking change. Wouldn't it be easier to just use TLS?

Huh?

SSLv3 is perfectly OK with hello extensions.  Btw., quite a lot of
sessions established with protocol version SSLv3 (0x03,0x00) might
actually be between implementations of TLS that just use conservative
defaults because they don't have a reconnect fallback to and
extension-less SSLv3 handshake.

It would be good to stop confusing people.  Adding TLS support to
an existing SSLv3 implementation is >5x the work than adding
the proposed TLS extension RI.  And you're still just as vulnerable.

What we need is that the installed base out there needs to discontinue
using the insecure renegotiation with TLS.  JUST THAT.

This means either adding the TLS extension RI or reliably disable
renegotiation.

Please every stop suggesting upgraded to TLS v1.something.
That will cause more harm than good, because it gives a completely
wrong impression about what needs to be done.

I'm fine with requiring a proper TLS extension in the renegotiation(!)
handshake to transfer the verify_data of the finished messages.
It's clean and still very simple, and fits SSLv3 just as nicely as
it does TLSv1.0.  This may even help to make SSLv3 implementations
to improve their SSLv3 spec compliance and interop with clients
proposing TLS extensions.

There may be lots of good reasons why upgrading or completely
replacing an implementation of SSLv3 is simply not an option,
but adding the TLS extension RI is.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Nov 2009 07:59:09 +0200

At Tue, 10 Nov 2009 09:08:20 -0800,
> extension on an initial handshake you are risking being attacked.

I don't see that that's the case: you're risking being attacked in
any case if the server is not upgraded.

> vulnerable, even though you could have prevented an attack.

I don't really agree with this: servers which allow renegotiation without
this extension are unwise.

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Thu, 12 Nov 2009 01:50:13 -0600

> Compare the specs and you will see.

Very enlightening, it's even more complicated than you said. No wonder
these things don't interoperate quite so well.

Here's what I find:

SSL 3.0 draft-freier-ssl-version3-02.txt

   "In the interests of forward compatibility, it is
   permitted for a client hello message to include
   extra data after the compression methods."

RFC 2246 TLS 1.0 (Jan 1999)

   "In the interests of forward compatibility, it is permitted for a
   client hello message to include extra data after the compression
   methods. This data must be included in the handshake hashes, but
   must otherwise be ignored. This is the only handshake message for
   which this is legal; for all other messages, the amount of data
   in the message must match the description of the message precisely."

RFC 3546 TLS Extensions (June 2003)
   Updates 2246 (TLS 1.0)

   "The extensions described in this document may be used by TLS 1.0
   clients and TLS 1.0 servers.  The extensions are designed to be
   backwards compatible - meaning that TLS 1.0 clients that support the
   extensions can talk to TLS 1.0 servers that do not support the
   extensions, and vice versa."
   "Note that the extended server hello message is only sent in response
   to an extended client hello message.  This prevents the possibility
   that the extended server hello message could "break" existing TLS 1.0
   clients"
   "The extended server hello message format MAY be sent in place of the
   server hello message when the client has requested extended
   functionality via the extended client hello message"

RFC 4346 TLS 1.1 (April 2006)

   "In the interests of forward
   compatibility, it is permitted that a client hello message include
   extra data after the compression methods. This data MUST be included
   in the handshake hashes, but must otherwise be ignored. This is the
   only handshake message for which this is legal; for all other
   messages, the amount of data in the message MUST match the
   description of the message precisely.

RFC 4366 TLS Extensions (April 2006)
   Updates 4346 (TLS 1.1)
   "The document therefore updates TLS 1.0 [TLS] and TLS 1.1"
   "The extended server hello message format MAY be sent in place of the
   server hello message when the client has requested extended
   functionality via the extended client hello message"

RFC 5246 TLS 1.2

   "Clients MAY request extended functionality from servers by sending
   data in the extensions field.  The actual "Extension" format is
   defined in Section 7.4.1.4."
   "[server] A list of extensions.  Note that only extensions offered
   by the client can appear in the server's list."

------
My interpretation:

SSL 3.0  Allows room at the end of Client Hello for extra data.
         Is silent on extra data after Server Hello.
         No standard defines anything to be passed here.

TLS 1.0  Allows room at the end of Client Hello for extra data
         Forbids extra data after Server Hello.
         Possibly went four years with no extensions defined,
         so early implementations were untested in this.

June 2003

RFC 3546 Uses room defined in TLS 1.0 to grow ClientHello into
         ExtendedClientHello.
         Defines a new ExtendedServerHello message without assigning
         it a new HandshakeType. This is probably OK. SSL proxying
         and monitoring may have been confused by this contradiction
         of the spec with no version number bump.

TLS 1.1  Reiterates that only ClientHello can have extra data.
         No provision for ExtendedServerHello.

RFC 4366 Updates TLS 1.0 and 1.1 to re-allow extensions.
         This was simultaneous to 1.1 spec, so just an update.

TLS 1.2  Defines extensions as part of the main TLS spec.

------
Conclusions:

Nothing defines extensions for SSL 3.0, how such servers will react when
sent extra ClientHello data is somewhat unpredictable.

Perfectly-conforming implmentations since spec of Jan 1999 should, in
theory, not be broken.

In practice, TLS server implementations designed before about 2004
probably had no compliant clients with which to test that would send any
data after the traditional ClientHello. Such systems probably shipped
for quite some time afterwards. For example, all pre-Vista Windows OS's
may be in this category based on design date.

There are a large number of TLS implementations that are not currently
extension-aware which will have to retrofit at least primitive support
in order to benefit from this security fix.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 12 Nov 2009 15:01:06 +0100 (MET)

>    extra data after the compression methods."

I would suggest the following document for SSLv3 from 18-Nov-1996:

http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00

   Forward compatibility note:
                  In the interests of forward compatibility, it is
                  permitted for a client hello message to include
                  extra data after the compression methods.  This data
                  must be included in the handshake hashes, but must
                  otherwise be ignored.

> in order to benefit from this security fix.

I think it is OK to encourage interoperability with ExtendenClientHello
and ExtendendServerHello in order to implement Eric's proposal for
the TLS extension Renegotiation_Info.  ClientHello extensibility
has been in the spec for very long, and really is not that much
to implement.

I would appreciate if Eric's draft would precisely describe
what exact elements of TLS extension (rfc4366 or what got integrated
into rfc5246) is necessary to implement this draft.
(ExtendenClientHello, ExtendendServerHello, correct hashing of
handshake message, creation and parsing of extension_data).

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 12 Nov 2009 09:33:12 -0800

> any case if the server is not upgraded.

My point was that if the server *is* upgraded and the client does not
send the extension on its initial handshake, it is taking an unnecessary
risk.  It is relying on the server to not continue with an insecure
renegotiation.  While this is the recommended advice, it might not be
followed for practical reasons (as others have pointed out).  Therefore,
the client has just shot itself in the foot -- it had the knowledge of
how to avoid the attack but didn't use it.

> this extension are unwise.

Right, but it will take a (long?) while before everybody can behave
according to the recommendations.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Thu, 12 Nov 2009 12:30:55 -0600

> according to the recommendations.

The primary factor is not how long it takes for "everybody" to update.
Maybe that never happens.

What matters is more that there is a significant set of clients and
servers in the world that _will_ gain the protections of the fix because
their users and admins are conscientious and will update quickly when
the patch is available.

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Nov 2009 12:18:45 -0600

> these things don't interoperate quite so well.

Indeed.

And I should add that the re-negotiation channel binding can be achieved
_without_ ServerHello extensions!  If that means improved odds for
interop, then you should consider it.

How?  Here's two options:

Option 1: All-or-nothing binding (no support negotiation)

 - The client sends a ClientHello extension saying it _will_ add the
   outer connection's client Finished message to the inner connection's
   Finished message PRF inputs, but the extension does not include that
   data;

 - The server either knows the extension or doesn't:

    - If the server knows the extension, it will modify its Finished
      message computations in the same way as the client, and if both
      have the same outer connection's client Finished message at hand,
      then the handshake will succeed, else it will fail (i.e., the
      inner connection's Finished messages will not check out);

    - If the server does NOT know the extension then it will proceed as
      usual and so... will fail to verify the client's Finished message,
      and the client will fail to verify server's Finished message.

Option 2: Secure negotiation (client can securely detect if the server
	  supports binding, and can choose to forego channel binding if
	  the server doesn't)

 - The client sends a ClientHello extension that includes the outer
   connection's client Finished message;

 - The client will add the outer connection's server Finished message to
   the inner connection's _server_ Finished message PRF inputs (but not
   to the inner connection's _client_ Finished message PRF inputs);

 - The server either knows the extension or doesn't:

    - If the server knows the extension, it will modify its Finished
      message computations in the same way as the client, and if both
      have the same outer connection's server Finished message at hand,
      then the handshake will succeed, else it will fail (i.e., the
      inner connection's Finished messages will not check out);

    - If the server does NOT know the extension then it will proceed as
      usual and so... will fail to verify the client's Finished message,
      and the client will fail to verify server's Finished message.

Note that in either case the ClientHello extension is "non-critical" (in
one sense), there's no ServerHello extension, but the client reliably
finds out if the server understood the extension.  There's no reflection
attack.  The server cannot be implemented incorrectly (that is, it can't
parrot something the client sent).

In option (2) the client gets to reliably discover whether the server
supports the extension, but in a way such that the only way that an MITM
can fool the client is if the negotiated cipher suite does not
authenticate the server (if a server cert is used, then the MITM is
out unless the MITM has the private keys to that cert).  But even if
such a cipher suite had been negotiated, the MITM cannot leverage the
client's user cert authentication to authenticate to the server.

In neither option can the MITM get away with stripping the extension
from the client's Hello, nor can the MITM cause the outer connection's
channel bindings data to match on the client and server side.

The nice thing here is that option (2) could be implemented even by
SSLv3 clients and servers (supposing anyone would bother to patch
those).

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 12 Nov 2009 21:36:09 +0100 (MET)

> interop, then you should consider it.

They could have, from the beginning of SSLv3...

With other words:

Currently  Finished is defined for both, initial and renegotiate as:

      struct {
          opaque verify_data[verify_data_length];
      } Finished;

      verify_data
         PRF(master_secret, finished_label, Hash(handshake_messages))
            [0..verify_data_length-1];

      finished_label
         For Finished messages sent by the client, the string
         "client finished".  For Finished messages sent by the server,
         the string "server finished".

If the original design had instead distinguished initial and
renegotiation like this, the problem would not exist:

      verify_data for initial handshakes:
         PRF(master_secret, finished_label, Hash(handshake_messages))
            [0..verify_data_length-1];

      verify_data for renegotiation handshakes:
         PRF(master_secret, finished_label, verify_data_of_previous_session,
             Hash(handshake_messages)) [0..verify_data_length-1];

The whole effort with the TLS RI extension is to securely distinguish old from
updated communication peers--provided they do not choke on TLS extensions.

Forward signaling client->server that the client is updated through a
special ciphersuite ID in the ciphersuite list of the ClientHello
is still fairly easy and probably quite interoperable.

Backwards signaling server->client that the server is updated is
a little more difficult because one would have to repurpose an element
of the ServerHello.  If there really are SSL implemenations that fill
the unix_gmt_time with all random data (instead of just fuzzing the
lower bits of it), then that part requires a less "pure" approach.

Maybe by confiscating a currently unused bit of the more tightly
controlled value ranges of other members of the ServerHello handshake
message (server_version.major, cipher_suite or compression_method).

Of course, the server would then only signal back to use the
secure finished message calculation for renegotiation handshakes,
for which the client had indicate to understand that protocol
change by including that special ciphersuites ID in the
cipher_suites list of the ClientHello handshake message.

...but actually, we wanted to Last Call Eric's proposal, didn't we? 

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Nov 2009 14:38:47 -0600

> message (server_version.major, cipher_suite or compression_method).

The whole point of my post was to point out that there is a way to do
the server->client signaling without changing a single bit on the wire
-- just the Finished message computations.

Interestingly, that approach could even be used on initial connections
to detect if the server will support secure re-negotiation _before_ the
client ever tries it.

> ...but actually, we wanted to Last Call Eric's proposal, didn't we? 

Yes.  That's why I wrote "[i]f [my alternative proposal] means improved
odds for interop, then you should consider it".

If we have consensus that EKR's fix is sufficient, then we should just
move forward with it.

(I've not followed all of the SSLv3 sub-threads, so I'm not sure if my
proposal would help w.r.t. SSLv3.  I leave that to you to figure out.)

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 13 Nov 2009 08:00:04 +0200

At Thu, 12 Nov 2009 09:33:12 -0800,
Michael D'Errico wrote:
> risk.

The issue isn't whether the client sends it. Of course the client
sends it. It's whether the client aborts the connection of the server
doesn't return it.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 13 Nov 2009 10:22:35 +0200

At Thu, 12 Nov 2009 14:38:47 -0600,
> to detect if the server will support secure re-negotiation _before_ the

I don't see that. AFAICT both your options involve the client generating a 
hello extension, so this does affect the bits on the wire. Obviously
there are approaches which don't require that, but they don't provide
detection of server capabilities on initial negotiation. By contrast
your message of 1854 doesn't allow the client to probe the server 
AFAICT.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Fri, 13 Nov 2009 16:34:59 +0100 (MET)

> your message of 1854 doesn't allow the client to probe the server 

Nico an I are talking about slighty different things.

I will try to reexplain my most recent mind model of how this should
be solved, and you will see that the cryptographic properties are
almost identical to the TLS extension RI.  My most recent model
will actually grow naturally into TLS v1.3 and become invisible.

The cryptographic concept behind the actual fix:

I. Initial SSL/TLS Handshake on a connection

    Here we want to achieve three things:

     a) Securely signal from client to server that client is updated
     b) Securely signal from server to client that server is updated
        (provided that client has indicated that it will understand
         this information)
     c) Signal that this is an initial handshake so that it can not
        be proxied into a renegotiation handshake

   in an abstract fashion, the protocol update looks like this:

   Initial SSL/TLS handshake on a connection

       Traditional:         Updated:

       ClientHello          ClientHello + ProtocolUpdateIndicatorC2S
       ServerHello          ServerHello + ProtocolUpdateIndicatorS2C
           -- all further handshake messages unchanged ---

    TLS extension RI:

       (1a) + (1c) For the TLS extension RI, the ProtocolUpdateIndicatorC2S
       is a ClientHelloExtension "RI" with empty data

       (1b) + (1c) For the TLS extension RI, the ProtocolUpdateIndicatorS2C
       is a ServerHelloExtension "RI" with empty data

       Both ProtocolUpdateIndicators have no special cryptographic
       properties.  They're part of the handshake messages so that
       can not be stripped from an MITM without breaking the
       MAC-check by the Finished messages.

    My (revised) proposal:

       My proposal is to use two other ProtocolUpdateIndicators
       instead that can be added to all existing protocol versions
       with significantly less pain an suffering, and in a fully fowards
       compatible fashion so that this ProtocolUpdate will grow out
       naturally with the next TLS protocol update (TLSv1.3)

       (1a) assign a special ciphersuites ID as ProtocolUpdateIndicatorC2S
       that is to be included in the ciphersuites list of the ClientHello
       and extremely backwards compatible with installed base servers
       that implement SSLv3->TLSv1.2  (0x03,0x00) -> (0x03,0x03).

       (1c) change the computation of the finished mac for all renegotiation
       handshakes

       (1b) increase the major number of the protocol version by one as the
       ProtocolUpdateIndicatorS2C, which means:

          0x03,0x00  SSLv3, unpatched        0x04,0x00  SSLv3 patched
          0x03,0x01  TLSv1.0, unpatched      0x04,0x01  TLSv1.0 patched
          0x03,0x02  TLSv1.1, unpatched      0x04,0x02  TLSv1.1 patched
          0x03,0x03  TLSv1.2, unpatched      0x04,0x03  TLSv1.2 patched

          (0x03,0x04  TLSv1.3 only for client_version)
                                             0x04,0x04  TLSv1.3

       (1a2) A client that sends a ClientHello with a client_version
             that is >=0x03,0x04 also indicates that it will used the
             changed computation of finished mac calculation for
             the renegotiation handshake.

II. Renegotiation SSL/TLS handshake on a connection

    Here we want to achieve:

       a) cryptographic binding of the renegotiation handshake to the
          previous session by adding the verify_data of the previous
          finished messages as known to the client into the handshake
          message hash (->ClientVerify, ->Finished)

       b) cryptographic binding of the renegotiation handshake to the
          previous session by adding the verify_data of the previous
          finished messages as known to the server into the handshake
          message hash (->ClientVerify, ->Finished)

    Renegotiation SSL/TLS handshake on a connection

       Traditional:         Updated:

       ClientHello          ClientHello + ClientsPreviousVerifyData
       ServerHello          ServerHello + ServersPreviousVerifyData
           -- all further handshake messages unchanged ---

    TLS extension RI:

       (2a) adds the clients verify_data from previous client.finished
            message into ClientHelloExtension RI

       (2b) adds the servers verify_data from previous (client.finished and)
            server.finished message into ServerHelloExtension RI

       The Handshake Messages MAC will roughly receive the following data:

         ClientHello
         FF 01 00 01 0C
         <verify_data of client's previous client.finished>
         ServerHello
         FF 01 00 01 18
         <verify_data of server's previous client.finished>
         <verify_data of server's previous server.finished>
         -- all further handshake messages unchanged ---

    My (revised) proposal:

      (2a)+(2b) effectively change the computation of the finished macs
        by redefining what goes into the handshake message hash if the
        updated protocol is used.  The verify_data of the previous
        client.finished and server.finished messages are defined to
        be handshake messages that are _not_ sent in the current
        handshake (think of it as carryover from the previous handshake).

       The Handshake Messages MAC will roughly receive the following data:

      Client-side:

       ClientHello
       ServerHello
       <verify_data of client's previous client.finished>
       <verify_data of client's previous server.finished>
       -- all further handshake messages unchanged ---
     
      Server-side:

       ClientHello
       ServerHello
       <verify_data of server's previous client.finished>
       <verify_data of server's previous server.finished>
       -- all further handshake messages unchanged ---

      The verify_data should become a "virtual handshake message"
      _after_ the ServerHello, when client and server both know
      that they're really using the updated protocol.

      To me, it looks like this approach and TLS extension RI are
      very similar in their cryptographic properties.

      By adding the verify_data to the handshake message MACs (but
      not the message stream) always after ServerHello, they are also
      covered by the clients signature in the ClientVerify message --
      in case that cert-based SSL/TLS client authentication is used.
      This property is also similar to TLS extension RI.

      If the clients memories about the previous session differ from
      those of the server, the finished messages of the renegotiation
      handshake will differ.  If client cert authentication is used,
      the signature verification of ClientVerify will already fail.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 13 Nov 2009 08:10:52 -0800

> sends it. It's whether the client aborts the connection of the server

I'm in agreement with you that the client should send the extension.  But
there have been messages suggesting that a client doesn't need to send it
on its initial connection, only when renegotiating.  I've been trying to
convince them that the client must send it especially in its first handshake
in order to avoid being attacked.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Fri, 13 Nov 2009 10:15:11 -0600

Michael D'Errico wrote:
> But there have been messages suggesting that a client doesn't need to
> send it on its initial connection, only when renegotiating.  I've
> been trying to convince them that the client must send it especially
> in its first handshake in order to avoid being attacked.

Yes, that's the basis of the main attack: the client doesn't realize
that he's renegotiating.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Fri, 13 Nov 2009 17:39:45 +0100 (MET)

Two inaccuracies in my last posting:

>          -- all further handshake messages unchanged ---

Mike quite helpfully pointed out that I got the length fields wrong
in my illustration for the TLS extensions, they would rather look like
   FF 01 00 0D 0C
   FF 01 00 19 18

>        -- all further handshake messages unchanged ---

Any in my (revised) proposal, the ClientHello and ServerHello would
contain the signaling C->S (special ciphersuite ID) and S->C (protocol
version with 0x04 major number) in both handshakes, initial and
renegotiation.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Nov 2009 10:46:09 -0600

On Fri, Nov 13, 2009 at 10:22:35AM +0200, Eric Rescorla wrote:
> At Thu, 12 Nov 2009 14:38:47 -0600, > Nicolas Williams wrote:

The post with message-ID <[email-masked]>, subject
"Comments on draft-rescorla-tls-renegotiate", sent at 18:54:19 -0600
yesterday most certainly described no Hello extensions, only a Finished
message verify_data computation change.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 13 Nov 2009 19:37:06 +0100 (MET)

>From what Nico said in earlier messages about the Programming Model
for Microsoft's TLS implementation (schannel SSP), the code above
SSPI must know an implement a lot of TLS message flow.

According to that sketch, performing a TLS handshake requires a significant
amount of code above SSPI, and performing a TLS renegotiation requires
an awful huge amount of code above SSPI.  I have never used schannel
myself (and haven't found programming examples yet), but it seems
that the app on top of SSPI _must_ know whether incoming data is
application data, protected application data or handshake messages
and pass each of them to distinct SSPI calls or get an error.
The return calls of those SSPI functions probably indicate which
call to do next (or which kind of data to expect next).

So an app on top of SSPI using the schannel SSP might not expect
the client to request rekeying at arbitrary times during communication
and that unexpected (protected) ClientHello handshake message is then
passed to a Message-unprotection call of SSPI where it is rejected.
When that happens, the server seems to terminate the session
(delete the security context) and close the socket/connection,
which might be the reason why you receive a TCP RST.

Nico also mentioned, that with SSPI, the renegotiation context
uses a different/seperate context handle that the original context.

Which seems to imply, that for a TLS renegotiation by the app on top
of SSPI, the app has to call the message protection/unprotection
calls of the previous context for the initial handshake messages
of the new context -- until the Interator Function(s) indicate
that this is no longer necessary (because ChangeCipherSpec has
been sent).

If TLS renegotiation actually works like this in SSPI, then
an SSPI app is actually playing the MITM-Attack every time
that it renegotiates (i.e. it would perform the MITM-Attack on
its own TLS stack).

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Fri, 13 Nov 2009 23:37:03 +0200

Actually, there have been messages suggesting that clients sending this (or any other) extension, may have their session terminated, especially if using SSLv3 and even with some TLS 1.0 servers. If that is true for even a small minority of servers (say, 1%) we can't realistically expect browser vendors to add this, except buried deeply in some advanced menu.

I wish we had some hard data on this, but if this is true, we may need to find other ways for the client to signal support, or to signal re-negotiation.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Michael D'Errico [[email-masked]]
Sent: Friday, November 13, 2009 18:10
To: [email-masked]
Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego

Mike

---

From: Dr Stephen Henson <[email-masked]>
Date: Fri, 13 Nov 2009 22:59:12 +0000

> I wish we had some hard data on this, but if this is true, we may need to find other ways for the client to signal support, or to signal re-negotiation.

After OpenSSL enabled TLS extensions by default it initially included them in
SSLv3 client hello's too. We did have quite a few reports of problems so this
was disabled in the latest snapshots. Anything using an SSLv3 compatible client
hello (i.e. says it supports TLSv1 or later but will also accept SSLv3) has the
same potential problem and the deprecated SSLv2 compatible client hello is of
course a non-starter.

Not sure if this has been mentioned before but a dummy ciphersuite should be
acceptable to any server. That is we allocate one unused ciphersuite to have the
special meaning of "client supports renegotiation extension". Those so inclined
could include it in an SSLv2 compatible client hello too.

How a server signals support then becomes a problem. You can't send back an
extension in the server hello without violating the protocol rules as they
currently stand.

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 14 Nov 2009 01:08:16 +0200

At Fri, 13 Nov 2009 10:46:09 -0600,
> message verify_data computation change.

Yes, and it doesn't allow you to probe in a compatible way.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Sat, 14 Nov 2009 02:05:32 +0100 (MET)

Nasko Oskov wrote:
> 
> Martin Rex wrote:
> >
> > I have never used schannel myself (and haven't found programming
> > examples yet).

Nasko helpfully pointed me to Sample Code in the Microsoft PlatformSDK
(there is a WebServer and WebClient in Samples\Security\SSPI\SSL)

There is a difference between IETF GSS-API an Microsoft SSPI here.
In GSS-API, it is not possible to restart negotiation on an established
security context (handle).

As Nasko explained to me, it is possible to restart a handshake on
an existing security context handle in Microsoft SSPI (schannel SSP).
So the transfer of state from the current TLS session to the newly
renegotiated one does not require code changes above SSPI.

> That is not entirely true.
> 
> It is the return codes from the different APIs that tell you whether
> you should go back go negotiation or not. The application itself should
> never look at the actual packets and make decisions on their own.
>
> The way it works is that message protection/unprotection returns
> a special error code instructing the application to start handshaking
> again, using the same context.
>
> If a client wants to renegotiate, they just call the proper API with
> the current context, which emits renegotiation and handshaking begins.

Thanks for that clarification, Nasko.

I'm sorry.  I got somewhat confused by Nicos comments on SSPI.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 14 Nov 2009 09:41:31 +0200

Martin,

I agree that these have similar properties cryptographically,
but I don't agree that it is really an improvement overall.

As I understand your proposal, the advantage that it offers
over RI is that with RI an attacker can simulate an extension
processing failure. This leaves the client unable to distinguish
between:

- A server which does not support RI (and therefore is potentially
  though not definitely vulnerable to a renegotiation attack)
- An attacker who is blocking RI.

By contrast, with your proposal the client can reliably distinguish
these two, because additional unknown ciphersuites do not cause
failures. I have two observations about this:

1. I'm not sure that differentiating these two cases is that 
   interesting.

   - For the foreseeable future, the majority of servers will
     not support RI, so clients can't really do anything useful
     with the information that the server doesn't support it.
     Remember that implementations which DO support RI really
     should not be allowing renegotiation without it, in
     which case if a client is fooled into thinking that
     the server doesn't do RI, the likely result is that
     the client can't renegotiate, not an unsafe renegotiation
   - Non-support of RI is not necessarily an indicator of 
     vulnerability since many servers will simply patch 
     to the point where they don't renegotiate but not add
     RI support.
   - Any implementation of SSL/TLS which is so downrev that it
     cannot properly process extensions most likely has other
     serious security vulnerabilities so a client which wishes
     to be careful and not deal with servers which don't support
     RI should probably not connect to it in any case. IOW,
     the attacker can just force a paranoid client not to
     connect at all.

2. If you're interested in differentiating these cases in an
   unspoofable way, there's a compromise method which doesn't require
   a covert version upgrade that is signalled by the client in the
   cipher suite but not in the version number (contrary to the
   ordinary TLS style).

   Under ordinary conditions you offer TLS as usual with RI. If
   you get an error and are forced to fall back to SSLv3 or
   otherwise remove RI, *then* you signal an additional fake
   cipher suite whose only semantics are:
   "I tried to do RI but I was forced to downgrade." Servers
   which support RI can then simply generate an error if they
   ever see this cipher suite. [Alternately, you could always
   include the cipher suite, which makes the client logic
   simpler and the server logic slightly more complicated
   because the error becomes conditional.]

   This design has the advantage that it retains the ordinary
   TLS extension mechanism as the "main" code path and only
   uses the fake cipher suite as a fallback to detect inline
   downgrade. This is very much in the spirit of the existing
   TLS belt-and-suspenders defenses (e.g., the 030303... padding
   in the RSA when downgraded to SSL version 2). It also doesn't
   screw up our versioning scheme if/when we want to do 
   TLS 1.3. As far as I can tell, the major disadvantage 
   vis-a-vis the scheme you propose is that it requires one
   more pass with servers which don't support extensions, 
   but IMO given that modern browsers now offer SNI, we're
   beyond the point where we have to be afraid of routinely
   offering extensions and falling back if necessary.

-Ekr

   

At Fri, 13 Nov 2009 16:34:59 +0100 (MET),
>        The Handshake Messages MAC will roughly receive the following data:
<>        <verify_data of client's previous client.finished>
>       not the message stream) always after ServerHello, they are also
<>       covered by the clients signature in the ClientVerify message --

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 14 Nov 2009 02:28:13 -0600

> Yes, and it doesn't allow you to probe in a compatible way.

No, that's not correct.  On initial connection there's no need to do
anything special (sure, it's nice to know that your peer doesn't have
this vuln, but you don't have to).  On re-negotiate you unconditionally
want non-vulnerable behavior, thus there's nothing to negotiate, nothing
to probe for.

It's only when you're willing to re-negotiate in a vulnerable way that you
should probe/negotiate.  That may be useful as part of a transition
strategy.  However, if the negotiation itself causes breakage, then it
may not be feasible.

I repeat: "[this proposal is to] be ingored if the use of protocol
extensions in draft-rescorla-tls-renegotiate is deemed to not be a
problem".

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 14 Nov 2009 11:05:18 +0200

At Sat, 14 Nov 2009 02:28:13 -0600,
Nicolas Williams wrote:
> this vuln, but you don't have to).

Well, I don't know what "have to" means. Some clients may have
the policy of not connecting to servers that aren't upgraded.
The existing proposal allows that. Yours does not.

-Ekr

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 14 Nov 2009 03:14:05 -0600

> The existing proposal allows that. Yours does not.

Indeed, though I'm not too concerned by that.  For me that is a
trade-off to make w.r.t. complications raised by using extensions in the
first place (bear with me, please).

IIUC the arguments about SSLv3, there's an installed base of SSLv3 and
TLS 1.0-with-bugs that is more likely to get patched to fix this and
only this than to get upgraded t TLS 1.1+ or to have all their bugs
patched.  I'm not sure that that's true.  IF it is true, then we have to
consider the possibility of designing the fix so that it's easier to
patch those.

In any case, I think it's more important to behave correctly than to
also signal that intend to -- the former is required, the latter is a
bonus.

Nico
--

---

From: Nasko Oskov <[email-masked]>
Date: Fri, 13 Nov 2009 19:00:41 +0000

Martin Rex wrote:
>Marsh Ray wrote:
>> 
>> Well, if the remote endpoint allows you to initiate a renegotiation. 
>> MS IIS for example responds with a TCP RST, other implementations may 
>> be less direct.
>
>From what Nico said in earlier messages about the Programming Model for Microsoft's TLS implementation (schannel SSP), the code above SSPI must know an implement a lot of TLS message flow.
>
>According to that sketch, performing a TLS handshake requires a significant amount of code above SSPI, and performing a TLS renegotiation requires an awful huge amount of code above SSPI.  I have never used schannel myself (and haven't found >programming examples yet), but it seems that the app on top of SSPI _must_ know whether incoming data is application data, protected application data or handshake messages and pass each of them to distinct SSPI calls or get an error.
>The return calls of those SSPI functions probably indicate which call to do next (or which kind of data to expect next).

It is the return codes from the different APIs that tell you whether you should go back go negotiation or not. The application itself should never look at the actual packets and make decisions on their own.

>So an app on top of SSPI using the schannel SSP might not expect the client to request rekeying at arbitrary times during communication and that unexpected (protected) ClientHello handshake message is then passed to a Message-unprotection call of >SSPI where it is rejected.
>When that happens, the server seems to terminate the session (delete the security context) and close the socket/connection, which might be the reason why you receive a TCP RST.
>
>
>Nico also mentioned, that with SSPI, the renegotiation context uses a different/seperate context handle that the original context.

That is not entirely true. If a client wants to renegotiate, they just call the proper API with the current context, which emits renegotiation and handshaking begins.

>Which seems to imply, that for a TLS renegotiation by the app on top of SSPI, the app has to call the message protection/unprotection calls of the previous context for the initial handshake messages of the new context -- until the Interator Function(s) >indicate that this is no longer necessary (because ChangeCipherSpec has been sent).

The way it works is that message protection/unprotection returns a special error code instructing the application to start handshaking again, using the same context.

>If TLS renegotiation actually works like this in SSPI, then an SSPI app is actually playing the MITM-Attack every time that it renegotiates (i.e. it would perform the MITM-Attack on its own TLS stack).

It doesn't work this way, so you don't have to play the MiTM game itself. All the details are hidden behind the SSPI APIs and one has to just react based on return values.

Nasko

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 14 Nov 2009 18:42:44 +0200

At Sat, 14 Nov 2009 03:14:05 -0600,
> consider the possibility of designing the fix so that it's easier to

As I said, clients offer extensions already and know how to fall
back to not using extensions. I don't see that there is a problem
here.

-Ekr

---

From: Nelson B Bolyard <[email-masked]>
Date: Sat, 14 Nov 2009 11:13:23 -0800

On 2009-11-13 08:46 PDT, Nicolas Williams wrote:
>>> Interestingly, that approach could even be used on initial
>>> connections to detect if the server will support secure
>>> re-negotiation _before_ the client ever tries it.
>>
>> I don't see that. AFAICT both your options involve the client
>> generating a hello extension, so this does affect the bits on the wire.
>> Obviously there are approaches which don't require that, but they don't
>> provide detection of server capabilities on initial negotiation. By
>> contrast your message of 1854 doesn't allow the client to probe the
>> server AFAICT.
> 

EKR and Marsh Ray and some others will recall that I proposed essentially
the same proposal that Nico is now proposing in the meeting meeting in
Mountain View on September 29, 2009 to which Marsh Ray invited EKR, myself
and numerous others from this working group.

I proposed that a change in the computation of the TLS Finished message
to include some value derived from the master secret previously in use on
the connection before the current renegotiation (such as the Finished
message contents or some other value "extracted" from the master secret)
would avoid the overhead of the new extensions on the wire.  My goal was
to avoid the extra bandwidth and memory cost of those extensions, which
might be deemed too costly in certain low memory or bandwidth constrained
applications.

Others in the meeting responded that changing the definition of the
computation of the Finished messages was a change to the base protocol
specification (which adding an extension is not), and thus the change
I proposed would make TLS become (say) TLS 1.3.

The proposed new extension could be implemented as a patch to an extant
implementation of TLS 1.0, but an implementation of TLS 1.3 would presumably
require the implementation of all the changes in TLS 1.1 and
1.2 first, which would be a much bigger and slower undertaking for many
TLS implementations.

So, for the sake of hasty implementation, we abandoned the approach that
redefines the Finished message and went with the new extension.

But perhaps we should regard the new extension as a short term expedient,
and plan to change the definition of the Finished message in TLS 1.3,
so that the extension will no longer be necessary at some point in the
future (when TLS 1.3 has become common place, maybe 10 years hence).

Does the Working Group share interest in redefining the Finished message
computation for TLS 1.3?

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 14 Nov 2009 15:33:53 -0600

> I proposed would make TLS become (say) TLS 1.3.

All things considered, I bet that the finished message verify_data
computation change is the simplest one to make.  Saying that because it
falls outside the spectrum of extensions that can be considered in TLS
1.0-1.2 it can't be considered is a bit of a stretch.  Imagine if we had
no client hello extensions, or that we couldn't use them because in
practice support for them was very spotty, then we'd have to resort to
this approach and no one would say "but we can't unless we call it TLS
1.3"!

That said, I don't think we need to change EKR's proposed fix.  My
purpose in throwing it out, with the big caveat that I included, was to
get those who are worried about SSLv3 to provide specific rationales for
why an extension-less approach should be preferable.  I.e., I was trying
to condense the SSLv3 sub-threads.

> future (when TLS 1.3 has become common place, maybe 10 years hence).

There's a certain, er, desire for something like a "secure bit" that can
be used to passively detect broken implementations.  With EKR's fix we
get that bit.  I don't really care for that bit: servers should be
patched, period, rejecting re-negotiations from unpatched clients, and
clients should be patched and should refuse to complete re-negotiation
with unpatched servers and complain _loudly_ about them -- that is the
least that we need, and IMO also all we need.

> Does the Working Group share interest in redefining the Finished message

I doubt it.  Once the use of hello extensions is demonstrated to work
even for critical cases and when server hello extensions are needed,
then there's no need to change to using an unsignalled fix as in your/my
proposals.

However, I personally very much like the idea of a generic channel
binding facility in TLS, not so much for the purpose of channel binding
TLS to other channels (since EKR's fix takes care of the one case where
we need that) but for providing support to StartTLS-style applications
for authenticating pre-StartTLS negotiations.  For that, your/my
proposals will do (only using application-provided data as the "channel
bindings").

Nico
--

---

From: Nelson B Bolyard <[email-masked]>
Date: Sat, 14 Nov 2009 14:48:50 -0800

> then there's no need to change to using an unsignalled fix as in your/my

Well, I'd consider use of the version number 0x0304 (for SSL 3.4, which
is TLS 1.3) in the client hello to be an effective signal.

I hope there will be more responses, so that we can get a sense of consensus
for or against this idea.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 14 Nov 2009 23:40:46 +0000

> is TLS 1.3) in the client hello to be an effective signal.

If you mean that TLS 1.3 would add the verify_data to renegotiating
handshakes implicitly, but previous versions would rely on the extension:
I think that would just create additional code paths, greater complexity,
and more opportunities for implementors to screw up in ways that introduce
forward compatibility problems.

---

From: Martin Rex <[email-masked]>
Date: Sun, 15 Nov 2009 01:15:12 +0100 (MET)

> back to not using extensions. I don't see that there is a problem

I think you're mistaken.

The common Web Browsers may have such a fallback, but there are
much more users of TLS than just Web Browsers.  The majority of
programmatic clients don't use such a fallback.  Remember, that
this fallback is entirely an apps thingy -- you can not put it
into TLS itself.  So you will need to patch every app using
TLS to add a reconnect fallback in order to be able to use
TLS extension RI and not loose connectivity.

The reconnect fallback is a performance problem by itself,
and requires a significant of code added to the app.

I'm sorry, but I don't like this idea at all.

If the problem was so severe that all Browsers added the reconnect
fallback, that it is possibly to big to ignore it now.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Sun, 15 Nov 2009 02:45:35 +0100 (MET)

Eric,

Maybe you remember my privat Email to Steve and Marsh (you were cc)
3 hours after I had posted my observation about the MITM susceptibility
of the TLS renegotiation:

  An approach to fixing the situation would be to use a TLS extension
  to securely identify the session that is to be renegotiated.

  Fixed clients would have to identify the TLS session that they
  want to renegotiate.  Once the fixed clients are shipped, the
  fixed servers can require clients to identify the to-be-renegotiated
  session and abort if they don't.

  In the initial in-the-clear TLS-handshake, the clients should indicate
  with this extension (and and empty extension data) that the clients
  supports secure renegotiation, so that the server may defer the
  sending of a ClientCertificateRequest in the initial handshake
  to a later renegotiation.

This matches the TLS extension RI that you published the next day.

Cryptographically, the approach of the TLS extension RI looks fine,
but I having thought about it for a few days, I really dislike
how this fix is integrated into the protocol.

The lack of protection of the renegotiation is a flaw of the SSL/TLS
base protocol, and so it REALLY should be fixed there.  If the
original SSL protocol had used different finished calculations for
initial and renegotiate handshakes, then we wouldn't have the
problem that a clients initial handshake can be proxied into the
renegotiation of the server.

Now that we know that this was a stupid mistake, we should not
continue with this mistake.  The original TLS renegotiation is
a security problem and should be entirely abandoned.

Changing the finished message calculation for the TLS renegotiation
by virtually adding the verify_data from the currents session finished
messages to the handshake messages (hashes) of the renegotiation
handshake is the most natural solution.  There really is no point
in wasting the network bandwith and send the verify_data over the
network.

What we should add to the protocol is the signaling of this protocol
change Client->Server and Server->Client through the ClientHello
and ServerHello handshake messages.  The most interoperable signaling
C->S is a specially assigned ciphersuites ID, we probably do not need
to discuss that.  I'm open to sugestions for the S->C signaling.
Since the Server will signal only when he sees the clients signal
in the ClientHello, you could at that point actually change the
ServerHello message.  Changing the ServerHello is NOT going to
break anything here!

IMNSHO the IETF should _NOT_ continue to support the insecure original
TLS renegotiation, the implementors can decide themselves whether they
want to or need to offer their customers that configuration option
and use the original Finished message calculation if the negotiation
(=signaling C->S and S->C) indicates that at least one of the peers
has not been updated.  

TLS v1.3 should REALLY require that only the modified finished
message calculation may be used for TLS renegotiation.  Supporting
the original TLS renegotiation in TLS v1.3 would be unreasonable,
and if we use the TLS extension RI, then we would have to keep
that band-aid forever wasting network bandwidth.

And all those vendors and implementors who have added a reconnect-fallback
to their TLS clients,

  - I do not want the IETF recommend them to trash this fallback
  - I do not want the IETF leave the fallback handshake unprotected

If we do NOT use the TLS extension RI on the initial handshake, but
instead a different signaling, then both of this is unnecessary,
the vendors can have their TLS client still signal and use the
protected renegotiation, encounter less connection drops and the
ability to produce better error messages.

I do admit that tunneling the Finished Messages through TLS extensions
in ClientHello and ServerHello into the Handshake message hash might
require ~20 lines of code less for TLS implementations that already
implement the extensions code.  Personally, I think the un-usability
that comes with a strict requirement for TLS extensions and the
uncertainty for the fallbacks, the impaired error reporting and
the waste of network bandwidth saves the consumers of this
technology MUCH MUCH more every day in the future.

And every implementer that doesn't have TLS extensions all of the codebase
that he maintains will have to add much more for tls extensions than
for the actual fix.

I guess, I will have to write an I-D so that we can let the
community decide (this probably is no longer an TLS WG internal
decision, because it affects the internet as a whole).

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 14 Nov 2009 19:53:57 -0600

> is TLS 1.3) in the client hello to be an effective signal.

Well, yes, but that wasn't your proposal on Sept 29, and it wasn't mine
this past week.

> for or against this idea.

I think the consensus is probably to go with EKR's fix as is.  Note that
my proposed fix could actually also be deployed for SSLv3 systems, IF it
makes sense that they could get patched more easily than upgraded (which
I doubt, but then, I've no data to go on).

Once EKR's fix is deployed there will be no point to do a TLS 1.3 just
to have an alternative fix -- why bother?

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Sun, 15 Nov 2009 03:13:57 +0100 (MET)

> back to not using extensions. I don't see that there is a problem

There are still millions of Web Browsers in use out there that
do not contain a fallback reconnect at the application level.
MSIE 6 comes to mind (I use it on 4 different machines).

A fix that only changes a small amount of code in schannel.dll is
probably easy.  But you're suggesting that MSIE6 needs to be enhanced
with a fallback reconnect in order to allow the TLS renego patch to
be applied without impairing connectivity/interoperability of MSIE6
with a part of the installed base.

That sounds like poor engineering to me.

We can fix this entirely in TLS in a highly interoperable fashion
by using and existing protocol element in the ClientHello handshake
message rather than a relatively new optional feature like TLS
extensions that has demonstrated to cause significant interop problems.

Personally I would not mind if in 6 months my Browser would start
to warn me if I'm connecting to an unpatched server.  But in order
to do that, we MUST have a negotiation which will determine this
reliably through ServerHello.  Making assumptions why a connection
was simply closed by the server (silently or with a fatal alert)
will NOT provide this information.  The TLS extension RI is unable
to provide this information, and that is a significant shortcoming.

-Martin

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sun, 15 Nov 2009 02:17:13 +0000

Martin Rex wrote:
>>> only this than to get upgraded to TLS 1.1+ or to have all their bugs
> much more users of TLS than just Web Browsers.

Yes, of TLS. Not so much of SSL. Most specifications for carrying
other protocols started with TLS, not SSLv3. There may still be some
instances of extension-intolerant servers other than web servers,
but I'm not aware of any evidence that there are enough to consider
that a significant problem.

> The majority of

No, not at all. The idea that server bugs need to be addressed by
complicated workarounds in clients is primarily a "feature" of the web
(or more precisely the cultural and technical biases of web client
implementors). In most other contexts, a more appropriate response
to a server being broken, is to fix the server.

In any case, the extension draft can and should be specified in such
a way that even if a client does not send the extension on an *initial*
handshake, a connection to a patched server will not be vulnerable.
(The server does not *know* that the vulnerability has been avoided,
but in fact it has.)

> I'm sorry, but I don't like this idea at all.

Which idea? I didn't read Eric's post as recommending that all TLS
clients should implement the fallback, or saying that they need to.
(For stateful protocols, reconnection wouldn't necessarily work,
anyway.) His point was that since web clients already implement
the fallback, they won't fail to interoperate. For non-web clients,
TLS- or extension-intolerance have not been demonstrated to be a
significant issue.

---

From: Martin Rex <[email-masked]>
Date: Sun, 15 Nov 2009 03:30:28 +0100 (MET)

> I proposed would make TLS become (say) TLS 1.3.

Well, we have a security flaw in the base spec, specifically in the
computation of the Finished messages for the TLS renegotiation, because
it fails to provide a cryptographic binding to the session that is
replaced.

The correct approach to fix a defect in the base protocol is, of course,
to fix the base protocol.  The defect is specific to the TLS renegotiation
and is so severe, that the IETF ought to strongly discourage any future
use of the defective protocol feature.  The negotiation will provide
sufficient information to vendors and implementors to decide on their
own whether and when to still support the defective protocol feature.

TLS extensions are fairly new, cause interop problems and are purely
optional protocol features.  TLS extensions are _not_ part of the base
spec of SSLv3, TLSv1.0 and TLSv1.1.  

The fix for this defect in the TLS renegotiation should be as close to
mandatory as it can be and for all implementations of SSL/TLS independent
of their protocol levels (SSLv3,TLSv1.0,TLSv1.1,TLSv1.2).

The more I think about it, the more I'm opposed to using
TLS extensions to wrap this fix.  It's just to urgent and serious
to spend such an amount of time on a fancy wrapping.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 14 Nov 2009 19:01:14 -0800

> to spend such an amount of time on a fancy wrapping.

I'm OK with whatever the fix becomes, but just want to point out
that changing the Finished message calculation for renegotiations
does not protect a patched client when talking to an unpatched
server.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Sat, 14 Nov 2009 21:07:29 -0600

Michael D'Errico wrote:
> changing the Finished message calculation for renegotiations

A patched client in 'secure' mode will have to refuse to handshake with
an unpatched server.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Sun, 15 Nov 2009 04:22:29 +0100 (MET)

> I doubt, but then, I've no data to go on).

There simply may not be an upgrade available.

The OEM SSL implementation that we have been shipped to our customers
for the last 8 years is SSLv3 only.

The next library that we are going to ship, and which I am currently
validating, contains TLSv1.0 (still no extensions).  We ordered
this "upgrade" 1.5 years ago in order to be able to use GOST ciphersuites
for customers in Russia.  The library will provide a plugin interface
for the GOST TLS ciphersuite(s), that plugin must be from a local
provider and certified by authorized agencies.

Switching to a different provider for the SSL implementation is not an
option for us.  The API architecture and credentials management is
"proprietary" / specific to this software.

One of our advantages is, that we have 100% backwards compatibility
for all the improvements during the last 8 years and for the future,
i.e. all of our customers get and use the same library (single codebase)
independent of the Release of our application that they're using.

The shared library/DLL is therefore compiled and tested on >40 different
Platform variants (2-3 OS Releases per vendor, 32- and 64-bit). 
(that is part of my work).

I know pretty well how much effort it is to upgrade a codebase from
SSLv3 only to SSLv3+TLSv1.0, because I've been doing review and
validation of those changes, changes in our app to allow configuration
of the new features, interop testing, etc.

Besides SSLv3, that library contains PKI-stuff, X.509 cert handling,
GSS-API (SPKM-like), PKCS#7, PK credentials and trust anchor management,
the crypto stuff for WS-Security.

Our app does have programmatic clients that use SSL to access
third party web-servers.  The app doesn't have an re-connect fallback
(what for -- since we have been supporting only SSLv3 all the time).

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sun, 15 Nov 2009 03:38:25 +0000

> A patched client in 'secure' mode will have to refuse to handshake with

Yes, but Michael's point was that changing the Finished message
calculation alone does not allow the client to know that it is
communicating with an unpatched server. The client's handshake is
initial, so it does not include the verify_data in the Finished
hash calculations, and neither does the server.

That's why a separate indication of patched status is needed
if you want to support the policy of refusing to connect to an
unpatched peer. OTOH, if you change the Finished message calculation
then this signalling is *only* needed to support that policy.

---

From: Marsh Ray <[email-masked]>
Date: Sat, 14 Nov 2009 21:46:09 -0600

> That's why a separate indication of patched status is needed

Hi All,

It's clear we're going to have to take a fresh look at this thing.

I've worked up some additional requirements that we've come to
understand. To follow in its own email.

When I get some time (probably tomorrow) I'll try to summarize the
approached people have come up with to address the implementation
challenges.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Sun, 15 Nov 2009 04:49:39 +0100 (MET)

> does not protect a patched client when talking to an unpatched

The negotiation (=signaling C->S and more importantly S->C) in
ClientHello and ServerHello is what clients can use to protect
themselves.  They can warn or decide to not talk to servers
that are not patched at some point in the future.

An warning popup is a suitable method to apply market pressure.

A lack of interoperability is not a suitable method,
it is rather a sign of poor engineering.

All Browsers that added newer TLS versions and the TLS extension SNI
also had to add an app-level reconnect fallback because of the
resulting interop problems.

If we wrap this fix into a TLS extension, then every recipient of that
fix will encounter the very same interop problems as the Browser
vendors/implementors.

This will result in annoyed customers, many support calls,
some apps will be enhanced to also add re-connect fallbacks,
but overall it will significantly slow down the adoption of
the patch -- instead, the workaround to take countermeasures
to TLS renegotiation will then effectively kill renegotiation.

I think it is neither reasonable nor justified to cause so much
pain when it is possible to fix the problem with significantly
less resulting interop problems by _NOT_ using a TLS extension.

Side note: I do think we should add 1 page of guidance to
implementors in the final document outlining what implementors
should really check and fix when they touch code in order to
implement the fix for TLS renegotiation.

  - how to correctly process a ClientHello with additional data
    (all protocol version SSLv3->TLSv1.2)

  - how to correctly process the protocol version fields in
    the handshake messages and record protocol.

(but really only 1 page).

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 14 Nov 2009 20:08:35 -0800

Here's a crazy idea: we could define a completely incompatible change
to the way Finished messages are calculated even on initial handshakes.

A client can initially try connecting using the new Finished message
calculation, and if that fails, fall back to the original (if it's
willing to risk talking to an unpatched server).

The server has the advantage of receiving the client's Finished message
before it needs to send its own, so it can compute both the new and the
old versions to see which the client supports.  Then it can decide
whether to continue with the handshake or abort.  This also thwarts any
tampering by a MITM since neither calculation would match if messages
were altered.

For session resumption, each side would need to remember whether the
new or the old Finished calculation was used.

Just throwing the idea out there....

Mike

---

From: Marsh Ray <[email-masked]>
Date: Sat, 14 Nov 2009 22:18:02 -0600

> to the way Finished messages are calculated even on initial handshakes.

Or it could be as simple as flipping one bit in the verify_data.

> willing to risk talking to an unpatched server).

We can't change the app code.

> Just throwing the idea out there....

We need all the ideas we can get.

Really, I think the harder problem is signaling in the initial hellos,
particularly the server hello. We need one unambiguous bit in each
direction, with a consistent default from unpatched endpoints.

- Marsh

---

From: Nelson B Bolyard <[email-masked]>
Date: Sat, 14 Nov 2009 20:50:05 -0800

> It's clear we're going to have to take a fresh look at this thing.

What makes that clear?

There will always be people with new/additional ideas, and always
people who grumble about the chosen answer.  Have we found an
insurmountable obstacle?  There are now something like 5 known
interoperable implementations of EKR's draft.  I think those of us with
those implementations are essentially just waiting now for an official
code point for the RI extension to be allocated by the IANA.  Do we
really want to toss all that for plan B?

> understand. To follow in its own email.

OK, will read with interest.

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 14 Nov 2009 20:51:14 -0800

There could be an initial roll-out of patched servers, configured to
respond to both patched and unpatched clients, but to not perform
renegotiation with unpatched clients.  Once sufficient time has
passed, patched clients can be rolled out, followed by turning off
compatibility mode in servers.

Clients that currently do not have reconnect logic would not need to
add it.

Mike

---

From: Yoav Nir <[email-masked]>
Date: Sun, 15 Nov 2009 12:24:00 +0200

Well, there was a suggestion a while back to use magic values for the gmt_unix_time field. Peter Guttman added an important data point, that some implementations already randomize this field, to avoid revealing their incorrect system clock.

This can definitely be used for S-->C signaling, while C-->S signaling can either use the same field, or a special cipher-suite. (I'm wary of using the gmt_unix_time field because there's only one of them - we can't use it again for the next security bug)

So yes, we can meet Marsh Ray's requirement that the signaling be done without extensions.

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 15 Nov 2009 11:31:57 -0600

> to the way Finished messages are calculated even on initial handshakes.

Not on initial.  My proposal is to do it only on re-negotiate.

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 15 Nov 2009 10:23:57 -0800

> Compare the specs and you will see.

Can you be more specific?

The "Client hello" section in RFC2246 (i.e., for TLS 1.0) includes a  
"Forward compatibility note": "In the interests of forward  
compatibility, it is permitted for a client hello message to include  
extra data after the compression methods."  This is the provision that  
allows clients to try using extensions without having to know whether  
a specific server has extension support.

I can't spot something like that in draft-freier-ssl-version3-01.txt.   
What wording in what specification are you referring to?

Bodo

---

From: Marsh Ray <[email-masked]>
Date: Sun, 15 Nov 2009 12:36:20 -0600

Bodo Moeller wrote:
> allows clients to try using extensions without having to know whether a
> specific server has extension support.
> 

This language only seems to be in the definition of the Client Hello,
not the v3 Server Hello.

- Marsh

> Transport Layer Security Working Group                  Alan O. Freier
> INTERNET-DRAFT                                 Netscape Communications
> Expire in six months                                    Philip Karlton
>                                                Netscape Communications
>                                                         Paul C. Kocher
>                                                 Independent Consultant
>                                                      November 18, 1996
> 
>                           The SSL Protocol
>                             Version 3.0
> 
> 
>                   <draft-freier-ssl-version3-02.txt>
[...]

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 15 Nov 2009 10:39:12 -0800

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Marsh Ray
> Sent: Sunday, November 15, 2009 10:36 AM
> To: Bodo Moeller; [email-masked]
> This language only seems to be in the definition of the 
> Client Hello, not the v3 Server Hello.
> 
[Joe] The server is not allowed to send an extension if the client does
not send it.  I don't see a spec problem here.  

> >                                                Netscape 
> Communications
> >                                                 Independent 
> Consultant

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 15 Nov 2009 10:39:35 -0800

> Not on initial.  My proposal is to do it only on re-negotiate.

Doing it on initial is necessary to protect clients when the server is
not patched.

Remember that the attack happens on the client's INITIAL handshake!
We need to protect that handshake, and no other proposal does that
reliably.  Simply finishing the initial handshake completes the attack.

Modifying the Finished calculation provides protection, but the best
part is that an upgraded server can reliably detect the following three
cases:

    1) client is unpatched
    2) client is patched
    3) a MITM tampered with the handshake

The server calculates both the old and the new client verify_data to
see which one matches.  If it matches the old (current) calculation, then
the server knows the client is not upgraded (case 1) and it will not allow
any renegotiations -- if this handshake IS a renegotiation, then there is
a MITM possible, so the renegotiation is refused.

If the client's verify data matches the new Finished calculation, then
the handshake is allowed to complete whether it is an initial handshake or
a renegotiation.  (The new verify_data would incorporate channel binding
info akin to the proposed RI extension.)

If neither matches, then there was tampering by a MITM.

Problems with RI:

The RI extension is attackable in many ways by a MITM.  It can be stripped
from the ClientHello or stripped from ServerHello.  If one side or the
other makes decisions based on the presence or absence of the extension,
then the MITM can control your behavior.  The MITM can simulate a server
"crash" by not forwarding the ServerHello, forging a fatal alert, or just
closing the connection.

And as has been pointed out there are numerous problems with requiring an
implementation to add support for extensions, and may not be possible if
the code only does SSLv3.

Changing the Finished calculation is much better since there is no other
change to the handshake, and does not modify anything about the bits on
the wire.  This is much more resistant to tampering by a MITM, and the
server can reliably detect it!

I think this is not such a crazy idea and should be given consideration.

Mike

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 15 Nov 2009 10:39:54 -0800

> extra data after the compression methods."  This is the provision  
> that allows clients to try using extensions without having to know  
> whether a specific server has extension support.
>
> I can't spot something like that in draft-freier-ssl- 
> version3-01.txt.  What wording in what specification are you  
> referring to?

Oh, never mind, I've seen some pointers in Marsh's follow-up message  
(under a different "Subject" header) -- the forward compatibility note  
was added after that -01 draft.

Curiously, tools.ietf.org doesn't know of draft-freier-ssl- 
version3-02.txt, but has draft-ietf-tls-ssl-version3-00.txt from the  
same date (November 18, 1996).  (For reference, draft-freier-ssl- 
version3-01.txt is from March 1996; draft-freier-ssl-version3-00.txt  
is from December 1995.)

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 15 Nov 2009 11:13:46 -0800

> I proposed would make TLS become (say) TLS 1.3.

In that proposal, would there have been any explicit indicator sent by  
the client and server to indicate that they intend to use the the  
modified Finished message?

One way to avoid most of the overhead from the current ID would be to  
keep the extension *always* empty.  If the client and server both send  
it during any given handshake, then the Finished messages concluding  
that handshake will be computed mostly in the standard way, but if  
it's a renegotiation handshake, including the previous handshake's  
Finished messages in the handshake_messages that will be hashed.   
[Open question: Where should they go?  Maybe the easiest is to always  
hash them at the end; client first, server second.]

This has the same security properties as  draft-rescorla-tls- 
renegotiation-00.txt, but saves 40 plaintext bytes (or 28 over the  
obvious variant of that ID where you remove the non-functional  
overhead, i.e. the server's copy of the client's verify_data.)

The step up to TLS 1.3 will be easy: Just make the modified Finished  
computation the default for the new protocol (i.e., no longer  
requiring the extension-based negotiation).

Bodo

---

From: Marsh Ray <[email-masked]>
Date: Sun, 15 Nov 2009 13:30:40 -0600

> not send it.  I don't see a spec problem here.  

I certainly see the logic in that. This is a very interesting point.

The SSLv3 spec says Client Hello can contain extra data. In theory, we
should be able to add client hello extensions and servers which don't
interpret them will ignore them. Servers which do interpret them may
respond with a Server Hello extension which is undefined by this spec,
but that's OK because it doesn't happen unless the client asked for it.

But there was no structure defined for that extra data and there were no
major implementations to put anything there. Even if a client did want
to use it, there was no type-length-value layout defined for it, so
there was no way to send more than one extension. This effectively shut
off that facility for experimental or vendor-specific use. The only
party who could safely put any data there was the IETF, and that didn't
seem to happen until RFC 3546 TLS Extensions (June 2003), which defined
five specific extensions (and only for TLS 1.0 not SSLv3).

Until then, there was no client implementation that sent extensions, and
it was not possible for implementors to add their own in an
interoperable way. Probably new development on SSLv3 had all but stopped
by then. This effectively meant that server implementations were not
tested to ignore extensions (or process them) until quite recently.

So in practice, in order for a protocol structure to be usable in the
future there has to have been some way to develop and test against it
from the beginning.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Sun, 15 Nov 2009 20:31:51 +0100 (MET)

> hash them at the end; client first, server second.]

My suggestion: always after ServerHello.  At that point, servers
and clients know whether they need to fallback to the old behaviour
or not, provided that their policy/configuration should allow that.

They should definitely go before the CertificateVerify message, so that
the signature with the client certificate is also securely
cryptographically bound to the channel (I don't like the idea to
have the CertificateVerify succeed on a MITM attack and only the finished
mac fail, if we can easily make both fail.

> requiring the extension-based negotiation).

Correct!  There really is no need to keep the old, unprotected
negotiation around in TLS v1.3.  If TLSv1.3 is proposed by the client
and agreed to by the server, no additional signaling is necessary
anymore.  This is why adding the verify_data to the handshake messages
hashes (my suggestion, always after ServerHello)

-Martin

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 15 Nov 2009 11:36:07 -0800

> sends it. It's whether the client aborts the connection of the server

Why make a client send it on the initial handshake if that client  
wouldn't have plans to abort the connection if the server doesn't  
acknowledge it?  Interoperability seems easier if you don't send it.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 15 Nov 2009 11:53:13 -0800

> mac fail, if we can easily make both fail.

That's a very good point!

So we'd actually be changing the handshake_message definition not just  
for purposes of the Finished messages, but also for purposes of the  
CertificateVerify message.  We'd always pretend that the previous  
Finished messages occur in the present handshake after both Hello  
messages are done.

[Do you agree with "client Finished first, server Finished second"?   
This is the obvious order if the previous handshake was a full  
handshake -- in case if was an abbreviated handshake (i.e., resuming a  
session), however, these messages would actually have been exchanged  
in the opposite order.  *Not* following the original order in this  
case seems easier.]

> hashes (my suggestion, always after ServerHello)

By the way, it would even be possible to specify more signals that  
could be used to switch to this modified handshake_message (and thus,  
Finished.verify_data) specification.  If we assume that the extension  
is one way to enable this behavior, and the protocol version will be a  
second way, a magic ciphersuite number that new servers are expected  
to look out for could be a third option.

Bodo

---

From: Marsh Ray <[email-masked]>
Date: Sun, 15 Nov 2009 14:02:28 -0600

> acknowledge it?  Interoperability seems easier if you don't send it.

Network monitoring, intrusion detection, firewall systems.

It seems client and server aren't the only parties to the protocol anymore.

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 15 Nov 2009 13:56:33 -0600

> reliably.  Simply finishing the initial handshake completes the attack.

True.  The server can always screw the client anyways, so the client has
to trust server correctness, but, atleast in this case it'd be nice to
have a critical indication in the initial handshake.  That can be done
with or without extensions, but if without extensions then clients will
need to do the ugly fallback dance.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Sun, 15 Nov 2009 21:13:31 +0100 (MET)

> [Do you agree with "client Finished first, server Finished second"?   

Yes.  See my proposal in the first message of the thread
"Protected Renegotiation -- refined proposal"

> to look out for could be a third option.

I would strongly recommend against several different methods of
signaling.  It will be more work for implementors, more to interop-test
more to get wrong.  Just one signal for existing protocol specs
SSLv3 -> TLSv1.2 is perfectly sufficient.  Implied new behaviour
with TLSv1.3 is fine.

-Martin

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 15 Nov 2009 12:16:47 -0800

> It seems client and server aren't the only parties to the protocol  

I've seen this line of argument in the discussion before.  However, I  
don't think it strongly suggests a particular answer to this question:

Arguably I'd rather have monitoring tell me about clients that will  
*tolerate* a handshake with a server that doesn't support the  
extension (not so much about clients that don't support the extension  
at all).  In that case, I wouldn't want these clients to send the  
extension on the initial handshake.

Bodo

---

From: Marsh Ray <[email-masked]>
Date: Sun, 15 Nov 2009 14:22:02 -0600

Bodo Moeller wrote:
> *tolerate* a handshake with a server that doesn't support the extension
> (not so much about clients that don't support the extension at all).  In
> that case, I wouldn't want these clients to send the extension on the
> initial handshake.

Good point.

These systems will probably spot unsafe renegotiations happening.

It may be that we need two bits: 'endpoint patched' and 'endpoint
configured secure'.

- Marsh

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 15 Nov 2009 12:30:46 -0800

On Nov 15, 2009, at 12:22 PM, Marsh Ray wrote:
>> extension

How would they do that?  Everything is supposed to be encrypted then.

> It may be that we need two bits: 'endpoint patched' and 'endpoint

I don't think the protocol should too much be designed around making  
monitoring systems happy.  You can't do this for all interesting  
issues that client or server implementations might have anyway.  Here  
we have a vulnerability that's easy to fix in such a way that  
monitoring systems can see some fix deployment information, so why  
not.  Adding extra flags just for monitoring's sake, I'm not so sure.

Bodo

---

From: Yair Elharrar <[email-masked]>
Date: Sun, 15 Nov 2009 22:35:57 +0200

What if we just change the definition of the server's FINISHED message a bit; instead of sending
    Hash(handshake_msgs)
to the client, the server will send
    Hash(handshake_msgs || verify_data)
using the session's previous verify_data.
There's no change to initial handshakes, of course, as there's no previous verify_data.

This means:
1. Patched client and patched server: renegotiation is safe.
2. Patched client, unpatched server: the client can calculate Hash(handshake_msgs) and tell that the server is unpatched. It is up to the client to decide whether to abort the session or not.
3. Unpatched client, patched server: renegotiation will fail, as it should.

Yair
--

---

From: Marsh Ray <[email-masked]>
Date: Sun, 15 Nov 2009 14:38:33 -0600

> How would they do that?  Everything is supposed to be encrypted then.

They will notice handshake messages after the initial handshake. The
record content type field is never encrypted.

> monitoring systems happy.  You can't do this for all interesting issues
> that client or server implementations might have anyway.  Here we have a
> vulnerability that's easy to fix in such a way that monitoring systems
> can see some fix deployment information, so why not.  Adding extra flags
> just for monitoring's sake, I'm not so sure.

Many, many sites will configure their stateful firewalls to shoot down
any potentially-unsafe renegotiations. Without plaintext indicators,
that will mean all renegotiations.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Sun, 15 Nov 2009 21:43:10 +0100 (MET)

> It may be that we need two bits: 'endpoint patched' and 'endpoint

Do you really need more?

If you see the client's signal in the ClientHello that it is updated
and no signal for the new behaviour in the ServerHello, then you can
distinguish configured secure (Client closes network connection with
or without sending a fatal alert) from configured insecure (handshake
continues).

If your idea is about being able to "check" client's configuration on
_any_ TLS connection, that is not something that TLS is designed
(or supposed) to provide.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Sun, 15 Nov 2009 15:04:39 -0600

> or without sending a fatal alert) from configured insecure (handshake

Good point. The info may be available without the need to be stated
explicitly. But only after an insecure handshake gets underway.

> (or supposed) to provide.

We're dealing with something that's already outside of the original
design, so we can't afford to be too principled. These protocol bits
have to satisfy the installed base.

Is it all that different than sending GMT instead of random data?

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Sun, 15 Nov 2009 23:04:38 +0200

That would mean that RFC-compliant clients just don't work. A change like that is fine for a future version, like 1.3, but changing the behavior of 1.0 in a non-compliant way is just wrong. You really have to signal it.

Of course, once you have a new version like 1.3, you don't need both old and new behavior.  There's jut the new, TLS 1.3 way of calculating the Finished message.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Yair Elharrar [[email-masked]]
Sent: Sunday, November 15, 2009 22:35
To: [email-masked]
Subject: Re: [TLS] A not-so crazy idea

This means:

Yair
--

---

From: Nelson B Bolyard <[email-masked]>
Date: Sun, 15 Nov 2009 13:47:09 -0800

On 2009-11-13 13:37 PDT, Yoav Nir wrote:
> Actually, there have been messages suggesting that clients sending this 
> (or any other) extension, may have their session terminated, especially 
> if using SSLv3 and even with some TLS 1.0 servers.

That is true.  There definitely is some small fraction of SSL/TLS servers
out there that will not complete a handshake if the client hello has any
extensions whatsoever.

> If that is true for even a small minority of servers (say, 1%) we can't
> realistically expect browser vendors to add this, except buried deeply in
> some advanced menu.

By that logic, you might assume that browsers would not use extensions at
all today, "except buried deeply in some advanced menu", but that is not
the case at all.  Browsers DO use extensions when attempting to negotiate
TLS today, but not when attempting to negotiate SSL 3.0 (only).  Some
browsers have a "fall back" strategy that lets them try SSL 3.0 after a
TLS handshake attempt fails.  Whether that strategy will remain viable
going forward remains to be seen.  But don't expect use of TLS hello
extensions to stop because of it.

> I wish we had some hard data on this, but if this is true, we may need
> to find other ways for the client to signal support, or to signal 
> re-negotiation.

There is no objection among browsers to using this extension.

/Nelson Bolyard
Developer of TLS library used by Firefox

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 15 Nov 2009 15:36:28 -0800

> record content type field is never encrypted.

Oh, so you meant *potentially* unsafe renegotiations.

>> issues

Not sending the extension when you don't intend to abort if the server  
doesn't echo it back and don't intend to renegotiate seems right then.

Bodo

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2009 01:35:09 +0200

At Sun, 15 Nov 2009 11:36:07 -0800,
> acknowledge it?  Interoperability seems easier if you don't send it.

Agreed. I've rethought this point since I wrote it.

-Ekr

---

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

> Agreed. I've rethought this point since I wrote it.

I see value in extension-less signaling on initial handshake,
because it will immediately provide protection to updated clients
when the server is updated even when both, client and server still
support the insecure renegotiation (i.e. very early in the
transition period) or the client still allowys a reconnect
fallback with an extension-less ClientHello.

-Martin

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 15 Nov 2009 19:29:31 -0800

> fallback with an extension-less ClientHello.

Thanks, I can see your point.

My assumption was that we wouldn't mind breaking legacy renegotiation  
handshakes (we'd expect all servers that allow renegotiation to be  
updated such that they *never* allow legacy renegotiation), and that  
we'd just want *initial* handshakes to continue to work between  
updated clients and current servers.  That's just enough backwards  
compatibility such that client-side users can actually update their  
software without having to wait for all servers to get updated first.

I'm not convinced that we'd want updated servers to offer legacy  
renegotiation, but if we do, then using a pseudo ciphersuite seems  
fine to let the client indicate that it doesn't want legacy  
renegotiation (i.e., the present handshake is not a renegotiation  
handshake, and if the servers sees it as one, it should abort the  
connection immediately because it's with a MitM).

Bodo

---

From: Nelson Bolyard <[email-masked]>
Date: Tue, 17 Nov 2009 15:31:08 -0800

Bodo Moeller wrote:
> On Nov 16, 2009, at 12:11 PM, Nelson B Bolyard wrote:
>> On 2009-11-15 11:13 PDT, Bodo Moeller wrote:
>> Yes, the protocol version number.
> 
> Well, obviously -- I was asking about the proposal *before* others had
> suggested that this would require a new protocol version.
> 
> I gather that there was no other indicator, and *thus* they thought the
> protocol version would have to change.

I had something else in mind, but I never presented it, because I concurred
with the assessment that it was a base protocol change and really deserved
a new protocol version number.