Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Dec 2009 12:17:14 +0200

On Nov 30, 2009, at 10:38 PM, <[email-masked]> <[email-masked]> wrote:

> <wearing Area Director hat>

<snip/>

> 
>> As you say, no approach today is totally extension less, so the big
>> difference remaining IMO is:
>> 
>> 1) The fail-unsafe approach based on sending verify_data in extensions.
>> 
>> 2) The Fail-safe approach based on injecting varify_data into the
>> handshake hash calculation, but not sending them over the
>> wire. (This approach uses extensions for signaling but with absent
>> data)
>> 
>> Everything else is more or less the same.
> 
> This surprised me a bit (but possibly the surprise is a positive one).
> I would be interested in hearing from folks who've earlier opposed the
> use of extensions whether this reflects their current views, too.

I think there should be some form of extension-less signaling from client to server, at least for SSLv3 and TLS 1.0 on the initial handshake. I also think that it's a good idea to have some kind of server to client signaling to show that no renegotiations are supported, but servers that support the new, safe renegotiation should reply with an extension. Since the client proposed it in the magic ciphersuite, the response extension is not unsolicited. 

> If it does, I think we've made a lot of progress, and can still tweak
> the final difference (whether to send verify_data over-the-wire or not) 
> based on discussion during the IETF last call.
> 
> I do not claim that a large majority currently strongly prefers
> sending the old verify_data over-the-wire in the extension data. Much
> smaller number of people (compared to the signalling issue) have
> expressed any opinions about this, and also, I would expect that a
> smaller number of people care very strongly either way.

The signaling issue may harm connectivity, and that's a hot button issue. verify_data over the wire has not-well-understood security implications, and is mostly an implementation detail, so it generates less fervor.

Still, I believe that anything that makes it harder for implementers to mess up on security is a good thing, so I do care very strongly about it.

> 
> And BTW, in this question I agree that counting opinions expressed
> much more than a week ago probably isn't that good. So if someone
> (any reader of this message) cares very strongly either way, 
> I would suggest saying so on the list (if you haven't done so
> already recently).

Just did.

Yoav

---

From: <[email-masked]>
Date: Fri, 4 Dec 2009 14:29:50 +0100

Yoav Nir wrote:

> > This surprised me a bit (but possibly the surprise is a positive
> > one).  I would be interested in hearing from folks who've earlier
> > opposed the use of extensions whether this reflects their current
> > views, too.
> 
> I think there should be some form of extension-less signaling from
> client to server, at least for SSLv3 and TLS 1.0 on the initial
> handshake. 

The current draft has exactly this (as far as I can tell) -- so
are you OK with that part (and agree that the remaining issue
is sending-or-not-sending verify_data over-the-wire), or are
you proposing changes to the signalling part, too? 

(From your other email on the same day, I got the impression
you were not happy with the signalling part either...) 

Best regards,
Pasi

---

From: <[email-masked]>
Date: Fri, 4 Dec 2009 14:29:53 +0100

Best regards,
Pasi

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Dec 2009 15:07:06 +0100 (MET)

> you proposing changes to the signalling part, too? 

Mine does,

TLS extension RI doesn't.

Think about the following scenario:

Updated TLS client establishes session with _old_ server.  The old server
requests renegotiation and were still early in the transition period,
so the user really wants his client to allow that.

What should the TLS client send on the renegotiation ClientHello to
that old server?  What if the client used an extension-less ClientHello
for the initial handshake?  what if that old server is actually
extensions-intolerant?

So: what should that client send on the renegotiation handshake
with that server?  Does the answer differ based on which kind of
old server that is?  

The answer for my proposal is obvious, described in my document
and fully interoperable with the entire installed base.

The answer for TLS extension RI is not in that document, non-obvious
and will either be insecure or break interop for some scenarios.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Fri, 04 Dec 2009 11:18:58 -0600

Martin Rex wrote:
> that old server?

Awesome, thanks for bringing this up. It needs to be addressed in the draft.

He SHOULD send the full RI extension with the most recent verify_data,
even if he did not negotiate the use of RI in the initial handshake.

If he sends just the MCSV, then the splicing-across-two-renegotiations
attack is possible, even if the other target server is patched and in
strict mode!

If he sends nothing, the splicing-across-two-renegotiations attack is
possible if the other target server is patched and in compatible mode.

So the sentence applies equally to renegotiations: "If clients wish to
ensure that such attacks are impossible, they MUST terminate the
connection immediately upon failure to receive the extension without
completing the handshake."

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Dec 2009 18:38:55 +0100 (MET)

> even if he did not negotiate the use of RI in the initial handshake.

And this will break the backwards interop with the extensions-intolerant
old server.

The problem I have with this is:
  - it needs to be addressed in the TLS extenion RI draft,
    like a number of other special cases.
  - it breaks backwards interop
  - it's neither obvious nor documented in the current document

I currently believe that this situation:
  - doesn't need to be special cased in my proposal
  - is fully covered by the existing description in my proposal
  - my proposal remains fully interoperable with old servers

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Dec 2009 09:42:16 -0800

At Fri, 04 Dec 2009 11:18:58 -0600,
> even if he did not negotiate the use of RI in the initial handshake.

I agree with this.

Yes, this will cause interop failures with the small number of 
(insecure) extensions intolerant servers who want to renegotiate.
I'm not convinced that that's unacceptable.

> attack is possible, even if the other target server is patched and in

I actually don't think this is correct: 

Let's say you send MCSV...

1. If you're not being attacked then:
   - A handshake with an unupgraded server will succeed (it will
     ignore the MCSV)
   - A handshake with an upgraded server will fail [This should never
     happen because it should have responded with the extension
     initially.]

2. If you are being attacked (this would require the server's identity
   to change, of course):
   - If the server thinks this is a rehandshake it will reject the
     handshake right away.
   - If the server thinks this is an initial handshake it will accept
     the ClientHello but return an empty RI in ServerHello which will
     then be rejected by the client because the client is expecting
     to see the previous verify_data.

What am I missing?

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Dec 2009 18:55:17 +0100 (MET)

> I'm not convinced that that's unacceptable.
 
My proposal doesn't have that shortcoming, besides being *MUCH* easier
to implement and failSAFE.

> Let's say you send MCSV...

Which is less drastic to interop.

>    - A handshake with an unupgraded server will succeed (it will

agree.

> 2. If you are being attacked (this would require the server's identity

It is an entirely flawed assumption that the identity of the server will
change!  There are attacks where it doesn't, and they're much more
plausible than the accidental collision of non-predictable verify_data
which you considered so scary (before I patched that).

>    - If the server thinks this is a rehandshake it will reject the

agree.

>      to see the previous verify_data.

So you start to rely entirely on the client do check for a special
case that you haven't even documented.

Scary.

It's much safer when both peers can determine in a failSAFE fashion
that an MitM attack is performed.  As in my proposal.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Dec 2009 10:03:55 -0800

At Fri, 4 Dec 2009 18:55:17 +0100 (MET),
> which you considered so scary (before I patched that).

Well, this was just a note. However, how do you think the situation
you are describing happens in an attack case without the server
identity changing?

> case that you haven't even documented.

As I said, I think the correct behavior is to send RI. I was merely
observing that even if you sent MCSV the handshake would still
fail, as expected.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Dec 2009 19:51:19 +0100 (MET)

> you are describing happens in an attack case without the server

The obvious one is this:
http://www.ietf.org/mail-archive/web/tls/current/msg05127.html

but as you can see from the other discussion threads, there may be
a number of additional options based on some people's and some
application's flawed assumptions about "same identity".

But coming back to the original problem:
The TLS WG has been asked to provide a secure renegotiation.

I don't think TLS WG should ship an solution where we need a list
of special cases, and where some of that actually involve mitigation
strategies that the application has to implement, like a check
that the identity of the remote peer doesn't change.

> observing that even if you sent MCSV the handshake would still

I'm just looking at openssl-0.9.8-stable-SNAP-20091203.
It doesn't seem to contain MCSV yet.

The amount of code there to deal with the TLS extension RI is
quite impressive.  There is a whole seperate source file "t1_reneg.c"
to deal with the contents of the TLS extension alone and contains
11 situations with comparisons where the handshake is aborted.

There's more code in t1_lib.c to do the parsing of the extensions list
to actually find that extension.  That parser is far from trivial,
and only implementations that already have it don't need to add that code.

A quick glance suggests that you can append up to 3 arbitrary octets to the
end of the TLS extensions list and OpenSSL will entirely ignore them.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Dec 2009 11:00:18 -0800

At Fri, 4 Dec 2009 19:51:19 +0100 (MET),
> that the identity of the remote peer doesn't change.

As I said, this was just a note, not a requirement for RI to
be secure in this case.

Best,
-Ekr

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Dec 2009 20:21:08 +0100 (MET)

> As I said, this was just a note, not a requirement for RI to

Excuse me while I panic.

You mean that you do not care the slightest if you're shipping
a defective renegotiation protection that will allow an intruder
or disgruntled admin in posession of the server credentials
to inject data and splice TLS sessions in a fashion that
will look like perfectly valid requests from the unsuspecting
client/customer to all of the audit systems in the backend?

Well, I do care.

I do _not_ want the IETF to provide to malfeasants the perfect
digital crow bar that doesn't leave any traces.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Dec 2009 11:35:44 -0800

At Fri, 4 Dec 2009 20:21:08 +0100 (MET),
> digital crow bar that doesn't leave any traces.

Oh, I'm terribly sorry, that must be about my worst writing ever.

What I meant to say was rather:

(a) I believe that RI is secure in the case you suggest.
(b) I do not believe that checking for an identity change is 
    required in order for (a) to be true.
(c) I was merely noting that I believed identity would change.

Sorry for the confusion.

Best,
-Ekr

---

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

> observing that even if you sent MCSV the handshake would still

To summarize, I think a valid point here is that a client implementation
that didn't negotiate the use of RI on the initial handshake might not
realize the need send the appropriate RI on every renegotiation, too.
Even more possible is he might not consider the need to be looking for
RI responses from the "server" and checking them against his
expectations whenever they arrive.

Here's some wording (use it if it helps):

>    Upon receipt of the "renegotiation_info" extension, both client and
>    server implementations which support the extension MUST verify that
>    it contains the correct contents as specified above.  If the contents
>    are incorrect, then it MUST generate a fatal "handshake_failure"
>    alert and terminate the connection. This allows two implementations
>    both of which support the extension to safely renegotiate without
>    fear of the above attack.

This requirement to validate any received RI extension still applies
even after previous handshakes on the same the connection or session did
not negotiate the use of RI. Every handshake must be treated
independently in this respect because the attacker may attempt to make
an initial handshake appear as a renegotiation handshake or vice-versa.

> 5.  Requirements for Sending and Receiving
> 
>    TLS clients which support this draft MUST generate either the
>    "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST
>    cipher suite with every ClientHello.
>
>    TLS servers which support this draft MUST generate the
>    "renegotiation_info" extension in the ServerHello in response to any
>    client which offers either "renegotiation_info" or
     Client Hello
>    TLS_RENEGO_PROTECTION_REQUEST in the ClientHello.

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

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Sun, 6 Dec 2009 23:03:33 +0200

> you were not happy with the signalling part either...) 

I would like the signaling to be applicable in more situations (up to and including TLS 1.0 at least, even if the Client Hello is proposing an upgrade to TLS 1.2 or higher), but I agree that this should not delay publication as long as this is available when you begin with SSLv3.

---

From: <[email-masked]>
Date: Mon, 7 Dec 2009 13:32:56 +0100

Martin Rex wrote:
> Updated TLS client establishes session with _old_ server.  The old
> server requests renegotiation and were still early in the transition
> period, so the user really wants his client to allow that.
> 
> So: what should that client send on the renegotiation handshake with
> that server?  Does the answer differ based on which kind of old
> server that is?
> 

I agree that the answer is not in the document, and it's non-obvious,
so something needs to be changed in the document.

Best regards,
Pasi