Subject: [Unbearable] Renegotiation info extension

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Aug 2016 16:54:31 +1000

I know that this is probably old news, but there is an alternative to
using the renegotiation info extension.  That is to forbid
renegotiation entirely.  We're at the point now where lots of
implementations do this and some of them are not including the RI
extension at the same time.

For TB, rather than requiring RI, can we instead prohibit the use of
renegotiation if RI is not negotiated?

---

From: Andrei Popov <[email-masked]>
Date: Mon, 8 Aug 2016 19:46:22 +0000

Yes, we can rephrase the security consideration in this more nuanced way.

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Sunday, August 7, 2016 11:55 PM
To: [email-masked]
Subject: [Unbearable] Renegotiation info extension

I know that this is probably old news, but there is an alternative to using the renegotiation info extension.  That is to forbid renegotiation entirely.  We're at the point now where lots of implementations do this and some of them are not including the RI extension at the same time.

For TB, rather than requiring RI, can we instead prohibit the use of renegotiation if RI is not negotiated?

_______________________________________________
Unbearable mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/unbearable

---

From: Nick Harper <[email-masked]>
Date: Mon, 8 Aug 2016 14:19:47 -0700

Chrome's Token Binding implementation takes the approach of forbidding
renegotiation entirely. I would be in support of only allowing one of token
binding or renegotiation on a connection, and then this consideration about
RI becomes a moot point.

On Mon, Aug 8, 2016 at 12:46 PM, Andrei Popov <[email-masked]>
wrote:

> using the renegotiation info extension.  That is to forbid renegotiation
> entirely.  We're at the point now where lots of implementations do this and
> some of them are not including the RI extension at the same time.
>

---

From: Andrei Popov <[email-masked]>
Date: Mon, 8 Aug 2016 21:24:44 +0000

IE/IIS use renegotiation a lot, so Chrome’s approach would not work for us, but Martin’s nuanced language does.

From: Nick Harper [mailto:[email-masked]]
Sent: Monday, August 8, 2016 2:20 PM
To: Andrei Popov <[email-masked]>
Cc: Martin Thomson <[email-masked]>; [email-masked]
Subject: Re: [Unbearable] Renegotiation info extension

Chrome's Token Binding implementation takes the approach of forbidding renegotiation entirely. I would be in support of only allowing one of token binding or renegotiation on a connection, and then this consideration about RI becomes a moot point.

On Mon, Aug 8, 2016 at 12:46 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
Yes, we can rephrase the security consideration in this more nuanced way.

-----Original Message-----
From: Unbearable [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Martin Thomson
Sent: Sunday, August 7, 2016 11:55 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Unbearable] Renegotiation info extension

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable

---

From: Nick Harper <[email-masked]>
Date: Mon, 8 Aug 2016 14:44:55 -0700

If we want to support TB and renego, there are several things that need to
be considered and clarified in the spec:

If the state of extended master secret changes, what should happen? (I
don't think this should be allowed)
What's allowed to change in terms of Token Binding key params during a
renegotiation? I think that it must stay the same - if Token Binding is
negotiated, the same key param must be negotiated on both handshakes;
inversely if Token Binding is not negotiated in the first handshake, then
it must not be negotiated in the second.

Even more details needs to go to what EKM value should be signed at any
given point. Renegotiation can technically interleave with application
data, so this seems quite ill-defined for what a TokenBindingMessage should
include for a signature if it is sent in application data in the middle of
a renegotiation.
Suppose a renegotiation happens between a client's http request and the
server's response (as is I believe the case for IIS with http/1.1). The
client's request would contain a TokenBindingMessage with a signature over
the original EKM, but when the server is sending the response the
connection now has a new EKM, so the server needs to remember the old EKM
to verify the signature. I imagine things get much more complicated with
http2.

On Mon, Aug 8, 2016 at 2:24 PM, Andrei Popov <[email-masked]>
wrote:

> *From:* Nick Harper [mailto:[email-masked]]
> *Sent:* Monday, August 8, 2016 2:20 PM
> *To:* Andrei Popov <[email-masked]>
> *Cc:* Martin Thomson <[email-masked]>; [email-masked]
> *Subject:* Re: [Unbearable] Renegotiation info extension
>
>
>

---

From: Andrei Popov <[email-masked]>
Date: Mon, 8 Aug 2016 22:27:27 +0000

Ø  If the state of extended master secret changes, what should happen?
EMS is required when TLS <=1.2 is used with TB, see TBPROTO section 8.5, so EMS state cannot change.

Ø  What's allowed to change in terms of Token Binding key params during a renegotiation?
The client uses the token_binding extension in each TLS handshake, so at least in theory any TB parameters can change.

Ø  Suppose a renegotiation happens between a client's http request and the server's response (as is I believe the case for IIS with http/1.1). The client's request would contain a TokenBindingMessage with a signature over the original EKM, but when the server is sending the response the connection now has a new EKM, so the server needs to remember the old EKM to verify the signature.
If TB is negotiated as part of the renegotiation handshake, the client needs to send the TB message in the newly established TLS session, using the new EKM.

Sent: Monday, August 8, 2016 2:45 PM

If we want to support TB and renego, there are several things that need to be considered and clarified in the spec:

If the state of extended master secret changes, what should happen? (I don't think this should be allowed)
What's allowed to change in terms of Token Binding key params during a renegotiation? I think that it must stay the same - if Token Binding is negotiated, the same key param must be negotiated on both handshakes; inversely if Token Binding is not negotiated in the first handshake, then it must not be negotiated in the second.

Even more details needs to go to what EKM value should be signed at any given point. Renegotiation can technically interleave with application data, so this seems quite ill-defined for what a TokenBindingMessage should include for a signature if it is sent in application data in the middle of a renegotiation.
Suppose a renegotiation happens between a client's http request and the server's response (as is I believe the case for IIS with http/1.1). The client's request would contain a TokenBindingMessage with a signature over the original EKM, but when the server is sending the response the connection now has a new EKM, so the server needs to remember the old EKM to verify the signature. I imagine things get much more complicated with http2.

On Mon, Aug 8, 2016 at 2:24 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
IE/IIS use renegotiation a lot, so Chrome’s approach would not work for us, but Martin’s nuanced language does.

From: Nick Harper [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, August 8, 2016 2:20 PM
To: Andrei Popov <[email-masked]<mailto:[email-masked]>>
Cc: Martin Thomson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Unbearable] Renegotiation info extension

---

From: Martin Thomson <[email-masked]>
Date: Tue, 9 Aug 2016 08:58:28 +1000

> EMS is required when TLS <=1.2 is used with TB, see TBPROTO section 8.5, so

Yes.  Note that this is a requirement in the EMS RFC.  You can't
resume or renegotiate and then disable EMS.  NSS at least has checks
for that and I imagine other implementations will do as well.

> If TB is negotiated as part of the renegotiation handshake, the client needs
> to send the TB message in the newly established TLS session, using the new
> EKM.

I agree.  New requests need to use the new EKM.

There's a potential race here, so issue 64 might apply
(https://github.com/TokenBinding/Internet-Drafts/issues/64).

---

From: Nick Harper <[email-masked]>
Date: Mon, 8 Aug 2016 16:02:54 -0700

On Mon, Aug 8, 2016 at 3:27 PM, Andrei Popov <[email-masked]>
wrote:
> The client uses the token_binding extension in each TLS handshake, so at
> least in theory any TB parameters can change.
>

Why not require that TB parameters must be the same? This would simplify
implementations insofar as the TB key would remain the same for the client.

>
>
> Ø  Suppose a renegotiation happens between a client's http request and
> the server's response (as is I believe the case for IIS with http/1.1). The
> to verify the signature.
> If TB is negotiated as part of the renegotiation handshake, the client
> needs to send the TB message in the newly established TLS session, using
> the new EKM.
>

I agree that the new EKM needs to be used; my concern is about
implementation difficulty in getting this right. In this case, the client's
request was sent before the renegotiation handshake, so it can only contain
a signature of the old EKM. (The client didn't know renego was going to
happen until after it sent the request.) The server's response is after the
renegotiation handshake. Is the server going to try to use the old EKM or
the new EKM when processing the client's request? Is the server going to
process the request before or after requesting renego? If the server is
processing the request after the renegotiation handshake occurs, is it
going to remember the old EKM?

This is a fairly straightforward example (client sends http request, server
requests renego, client+server do renego handshake, server sends http
response). If there are other interleavings, how do you propose a client
and server synchronize the state of the TLS handshake with the application
data that they're writing?

> *Sent:* Monday, August 8, 2016 2:45 PM
>

---

From: Andrei Popov <[email-masked]>
Date: Tue, 9 Aug 2016 00:03:50 +0000

Ø  Why not require that TB parameters must be the same? This would simplify implementations insofar as the TB key would remain the same for the client.
Once the TLS handshake is complete, a client receives the negotiated TB parameters, retrieves the appropriate TB key, and generates the TB message. Adding a verification step that requires the client to distinguish renegotiations and remember previous TB settings does not look like a simplification to me.

Ø  In this case, the client's request was sent before the renegotiation handshake, so it can only contain a signature of the old EKM.
True, but it does not matter because the client is unauthenticated in this TLS session, so the server initiates renegotiation.

Ø  The server's response is after the renegotiation handshake. Is the server going to try to use the old EKM or the new EKM when processing the client's request?
TB is not established until the client sends the TB message in the new TLS session and the server validates it. So the server will use the current EKM at the time of TB message validation, i.e. the new one.

Sent: Monday, August 8, 2016 4:03 PM

On Mon, Aug 8, 2016 at 3:27 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

>  What's allowed to change in terms of Token Binding key params during a renegotiation?

Why not require that TB parameters must be the same? This would simplify implementations insofar as the TB key would remain the same for the client.

>  Suppose a renegotiation happens between a client's http request and the server's response (as is I believe the case for IIS with http/1.1). The client's request would contain a TokenBindingMessage with a signature over the original EKM, but when the server is sending the response the connection now has a new EKM, so the server needs to remember the old EKM to verify the signature.

I agree that the new EKM needs to be used; my concern is about implementation difficulty in getting this right. In this case, the client's request was sent before the renegotiation handshake, so it can only contain a signature of the old EKM. (The client didn't know renego was going to happen until after it sent the request.) The server's response is after the renegotiation handshake. Is the server going to try to use the old EKM or the new EKM when processing the client's request? Is the server going to process the request before or after requesting renego? If the server is processing the request after the renegotiation handshake occurs, is it going to remember the old EKM?

This is a fairly straightforward example (client sends http request, server requests renego, client+server do renego handshake, server sends http response). If there are other interleavings, how do you propose a client and server synchronize the state of the TLS handshake with the application data that they're writing?

---

From: Nick Harper <[email-masked]>
Date: Mon, 8 Aug 2016 17:19:50 -0700

On Mon, Aug 8, 2016 at 5:03 PM, Andrei Popov <[email-masked]>
wrote:

> Ø  Why not require that TB parameters must be the same? This would
> simplify implementations insofar as the TB key would remain the same for
> the client.
>
> Once the TLS handshake is complete, a client receives the negotiated TB
> parameters, retrieves the appropriate TB key, and generates the TB message.
> Adding a verification step that requires the client to distinguish
> renegotiations and remember previous TB settings does not look like a
> simplification to me.
>
>
>
> Ø  In this case, the client's request was sent before the renegotiation
> handshake, so it can only contain a signature of the old EKM.
>
> True, but it does not matter because the client is unauthenticated in this
> TLS session, so the server initiates renegotiation.
>

The client is still going to send a Sec-Token-Binding header in that
request before the renego. Is the server completely ignoring the cookies
(and the sec-token-binding header) in the request pre-renego? Unless the
spec is going to add this restriction, I still think it should be
considered.

>
>
> Ø  The server's response is after the renegotiation handshake. Is the
> server going to try to use the old EKM or the new EKM when processing the
> client's request?
>
> TB is not established until the client sends the TB message in the new TLS
> session and the server validates it. So the server will use the current EKM
> at the time of TB message validation, i.e. the new one.
>

I'm imagining this flow:
1. Client sends http req
2. Server asks for renego
3. Client and server do renego handshake
4. Server sends http response (to req in #1)

I'm assuming you're not saying that in step 4, the server is using the new
EKM to validate the TB in request 1?

If there are any other interleavings of the renegotiation handshake with
application data that are possible, you should consider how TB will work in
those cases, or forbid those cases.

I'm curious how all of the use cases of renego with IE/IIS work with HTTP/2
(which forbids renego). Can we do the same thing for Token Binding?

---

From: Andrei Popov <[email-masked]>
Date: Tue, 9 Aug 2016 17:19:23 +0000

I think, based on the current specs, the flow would look like this:

1.       Client sends http requests with TB message;

2.       Server validates TB using the current EKM (A), TB established.

3.       Server processes HTTP request, triggers renegotiation;

4.       Renegotiation handshake.

5.       Server sends http response (unbound, as TB is not established in this TLS session until the client sends a new TB message).

Sent: Monday, August 8, 2016 5:20 PM

>  In this case, the client's request was sent before the renegotiation handshake, so it can only contain a signature of the old EKM.

The client is still going to send a Sec-Token-Binding header in that request before the renego. Is the server completely ignoring the cookies (and the sec-token-binding header) in the request pre-renego? Unless the spec is going to add this restriction, I still think it should be considered.

>  The server's response is after the renegotiation handshake. Is the server going to try to use the old EKM or the new EKM when processing the client's request?

I'm imagining this flow:
1. Client sends http req

I'm assuming you're not saying that in step 4, the server is using the new EKM to validate the TB in request 1?

If there are any other interleavings of the renegotiation handshake with application data that are possible, you should consider how TB will work in those cases, or forbid those cases.

I'm curious how all of the use cases of renego with IE/IIS work with HTTP/2 (which forbids renego). Can we do the same thing for Token Binding?