Input on renegotiation behaviour

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Input on renegotiation behaviour

Matt Caswell-2
I recently implemented some tests for renegotiation that turned up a
discrepancy between the way TLS and DTLS work.

If a server sends a HelloRequest to the client, then the client responds
by initiating a renegotiation handshake.

We support two forms of renegotiation handshake: normal and abbreviated.
The abbreviated form was added in OpenSSL 1.0.1. Basically the
difference is whether we can do session resumption in a reneg handshake
or not. With the normal form, we never do: with the abbreviated form we
will do if possible.

In TLS from 1.0.1, when a HelloRequest is received from the server, the
client will always attempt an abbreviated reneg handshake, i.e. it will
send through a session id in the ClientHello.

In DTLS (and TLS before 1.0.1) it never attempts an abbreviated reneg
handshake, i.e. it will always send through an empty session id in the
ClientHello.

This behaviour goes all the way back to when abbreviated reneg handshake
support was first added in this commit:

commit 48ae85b6ffe85e327f63c59d8de6a94a8b8f2d3b
Author:     Dr. Stephen Henson <[hidden email]>
AuthorDate: Thu Aug 26 14:22:40 2010 +0000
Commit:     Dr. Stephen Henson <[hidden email]>
CommitDate: Thu Aug 26 14:22:40 2010 +0000

    PR: 1833
    Submitted By: Robin Seggelmann <[hidden email]>

    Support for abbreviated handshakes when renegotiating.


Looking at that commit, it appears to me that the intention was that the
"default" behaviour would remain unchanged. This was just a new feature
that you could use if you want. That would suggest that the DTLS
behaviour was what was intended to happen in this scenario, and the
change of default TLS behaviour was a bug. Reading through the original
RT ticket for this patch there is no suggestion that default behaviour
was going to change...it reads like this is optional new functionality.

The question is: what to do now?

The current behaviour is not *wrong* either for TLS or DTLS, but the
discrepancy is quite weird and confusing. Should we:

1) Change TLS to behave like it used to, and like DTLS still does

2) Change DTLS to be consistent with the TLS behaviour

3) Keep it as it is and retain the current inconsistency

And if we change things, should we just change it in the current dev
branch - or backport it as a bug fix?

Thoughts?

Matt
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Input on renegotiation behaviour

Benjamin Kaduk
On 09/28/2016 03:27 AM, Matt Caswell wrote:
The current behaviour is not *wrong* either for TLS or DTLS, but the
discrepancy is quite weird and confusing. Should we:

1) Change TLS to behave like it used to, and like DTLS still does

2) Change DTLS to be consistent with the TLS behaviour

3) Keep it as it is and retain the current inconsistency

And if we change things, should we just change it in the current dev
branch - or backport it as a bug fix?

Thoughts?


I don't think any change should be backported --it's potentially disruptive, and if the behavior (change) has gone unnoticed for so long, it hardly seems urgent to normalize between DTLS and TLS.

It seems like the abbreviated handshake would save some computational resources; on the flip side, it would not have the opportunity for a fresh DH exchange to stir the key material.  If anything, that would almost suggest a

(4) change DTLS to default to abbreviated handshakes and change TLS to default to normal handshakes

since the DTLS server could be sending a HelloRequest because it had to dump state, but the TLS/TCP connection is persistent and the potential need for key update greater there.

That said, I do prefer consistency between DTLS and TLS, so would lean towards option (2), myself, for the resource savings.

-Ben

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Input on renegotiation behaviour

Matt Caswell-2


On 28/09/16 21:40, Benjamin Kaduk wrote:

> On 09/28/2016 03:27 AM, Matt Caswell wrote:
>> The current behaviour is not *wrong* either for TLS or DTLS, but the
>> discrepancy is quite weird and confusing. Should we:
>>
>> 1) Change TLS to behave like it used to, and like DTLS still does
>>
>> 2) Change DTLS to be consistent with the TLS behaviour
>>
>> 3) Keep it as it is and retain the current inconsistency
>>
>> And if we change things, should we just change it in the current dev
>> branch - or backport it as a bug fix?
>>
>> Thoughts?
>>
>
> I don't think any change should be backported --it's potentially
> disruptive, and if the behavior (change) has gone unnoticed for so long,
> it hardly seems urgent to normalize between DTLS and TLS.
>
> It seems like the abbreviated handshake would save some computational
> resources; on the flip side, it would not have the opportunity for a
> fresh DH exchange to stir the key material.  If anything, that would
> almost suggest a
>
> (4) change DTLS to default to abbreviated handshakes and change TLS to
> default to normal handshakes
>
> since the DTLS server could be sending a HelloRequest because it had to
> dump state, but the TLS/TCP connection is persistent and the potential
> need for key update greater there.
>
> That said, I do prefer consistency between DTLS and TLS, so would lean
> towards option (2), myself, for the resource savings.

Thanks Ben. Option 2 still gives the server the opportunity to not
resume the session if it so wishes (and in the scenario we are talking
about the server has initiated this), so perhaps that is the more
flexible route anyway.

Any one else have any thoughts on this?

Matt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Input on renegotiation behaviour

Short, Todd
+1 for making DTLS behavior like TLS in terms of attempting an abbreviated handshake. (2)
--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."

On Sep 29, 2016, at 4:40 AM, Matt Caswell <[hidden email]> wrote:



On 28/09/16 21:40, Benjamin Kaduk wrote:
On 09/28/2016 03:27 AM, Matt Caswell wrote:
The current behaviour is not *wrong* either for TLS or DTLS, but the
discrepancy is quite weird and confusing. Should we:

1) Change TLS to behave like it used to, and like DTLS still does

2) Change DTLS to be consistent with the TLS behaviour

3) Keep it as it is and retain the current inconsistency

And if we change things, should we just change it in the current dev
branch - or backport it as a bug fix?

Thoughts?


I don't think any change should be backported --it's potentially
disruptive, and if the behavior (change) has gone unnoticed for so long,
it hardly seems urgent to normalize between DTLS and TLS.

It seems like the abbreviated handshake would save some computational
resources; on the flip side, it would not have the opportunity for a
fresh DH exchange to stir the key material.  If anything, that would
almost suggest a

(4) change DTLS to default to abbreviated handshakes and change TLS to
default to normal handshakes

since the DTLS server could be sending a HelloRequest because it had to
dump state, but the TLS/TCP connection is persistent and the potential
need for key update greater there.

That said, I do prefer consistency between DTLS and TLS, so would lean
towards option (2), myself, for the resource savings.

Thanks Ben. Option 2 still gives the server the opportunity to not
resume the session if it so wishes (and in the scenario we are talking
about the server has initiated this), so perhaps that is the more
flexible route anyway.

Any one else have any thoughts on this?

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev