Re: [TLS] extended headers for (D)TLS (and their use with connection-id)

[Adam Langley]

On Wed, Jan 24, 2018 at 8:25 AM, Fossati, Thomas (Nokia -
GB/Cambridge, UK)  wrote:
> Do you think this is likely to cause havoc?  Or, in your experience,
> middle-boxes tend to not interfere after the TLS channel is up?

I expect so. There was a move, early in TLS 1.3, to drop the
superfluous version in the record header. I think that was reverted
for the same reason, although I don't recall exactly what data that
was based on.

(I'm also assuming that this is much more useful for DTLS than TLS
since you know that each packet will have a record header in it. With
TLS, the kernel might keep retransmitting some part of the
half-connection's data that doesn't include the connection id at all.)


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] extended headers for (D)TLS (and their use with connection-id)

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

On 24/01/2018, 15:53, "alang...@gmail.com on behalf of Adam Langley" 
 wrote:
> On Wed, Jan 24, 2018 at 6:31 AM, Fossati, Thomas (Nokia -
> GB/Cambridge, UK)  wrote:
> >
> > A few months ago, Nikos (can't remember if on this list or on a side
> > conversation) came up with this thought of a generic way to extend
> > the TLS/DTLS record header.  So, I've stolen his idea and written it
> > up in [1] with the intention of using it to make room for the
> > connection-id.
> 
> Our experience with middleboxes suggests that this is likely to fault
> afoul of many flaws in these products if deployed with TLS on the
> wider internet.

Thanks for the insight.

I have thought a bit about this possibility when doing the write-up and
the "MUST NOT be used during handshake" was meant exactly to minimise
the possible impact of middle-boxes during session establishment.

So, the chances to survive handshake should be the same as usual.

After session establishment, the only thing that might look suspicious
to an on-path box is the invalid length.

Do you think this is likely to cause havoc?  Or, in your experience,
middle-boxes tend to not interfere after the TLS channel is up?

cheers

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] extended headers for (D)TLS (and their use with connection-id)

[Adam Langley]

On Wed, Jan 24, 2018 at 6:31 AM, Fossati, Thomas (Nokia -
GB/Cambridge, UK)  wrote:
>
> A few months ago, Nikos (can't remember if on this list or on a side
> conversation) came up with this thought of a generic way to extend the
> TLS/DTLS record header.  So, I've stolen his idea and written it up in
> [1] with the intention of using it to make room for the connection-id.

Our experience with middleboxes suggests that this is likely to fault
afoul of many flaws in these products if deployed with TLS on the
wider internet.

DTLS might survive, though, and the cited motivation
(https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-00) is
DTLS-only. Probably this draft needs to be too.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] extended headers for (D)TLS (and their use with connection-id)

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

How to make the existence of a connection id explicit on the wire?

We have looked at a few different approaches - in reverse hackery order:
defining new content types, using an invalid length and bumping the
version number.

Each of them comes with its small or big complications but, irrespective
of that, the basic trouble we have here is that the lack of spare bits
in the record header forces us to override semantics of existing fields
in a way that smells wrong.

A few months ago, Nikos (can't remember if on this list or on a side
conversation) came up with this thought of a generic way to extend the
TLS/DTLS record header.  So, I've stolen his idea and written it up in
[1] with the intention of using it to make room for the connection-id.

At a first glance, it seems to work quite smoothly and has a pretty
compact encoding (see [2] for the details), which would make it my first
choice over all other candidates.

Please have a look (the draft shouldn't take more than 5-10 minutes of
your time) and provide feedback if you feel like.

Thanks, cheers

[1] https://tools.ietf.org/html/draft-fossati-tls-ext-header-00
[2] https://tools.ietf.org/html/draft-fossati-tls-ext-header-00#section-3.4

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls