Subject: Re: [TLS] Connection ID in TLS

From: "Fossati, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Tue, 20 Mar 2018 17:15:01 +0000

On 20/03/2018, 16:38, "TLS on behalf of John Mattsson" <[email-masked] on behalf of [email-masked]> wrote:
> At the Monday afternoon TLS session, it was stated that Connection ID
> in TLS was unemployable in the wild due to middleboxes. Couldn't that
> be solved by placing the cid field after the length field?

Are you referring to slide 13 of [1]?

If so, the problem is not CID-specific.  It's more generally what
could happen if we try and reuse the top bit of the length field
for other purposes.

Yoav brought up the case of an intercepting middlebox - one that needs to
pretend to be a fully-fledged TLS server.  That kind of box might
either:
- let the extension that enables repurposing the length's MSB pass
  through, and subsequently choke on the invalid length [HARD FAIL];
- eat up the unknown extension and therefore break the feature
  negotiation [SOFT FAIL].

Cheers

[1] https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessb-record-header-extensions-for-dtls-00

---

From: Richard Barnes <[email-masked]>
Date: Tue, 20 Mar 2018 17:37:01 +0000

I don't think Connection-ID is really required for ATLS.  As Carsten and
Owen mentioned in the side meeting, there are a few ways to use HTTP to
correlate the relevant messages.

On Tue, Mar 20, 2018 at 5:15 PM, Fossati, Thomas (Nokia - GB/Cambridge) <
[email-masked]> wrote:

> On 20/03/2018, 16:38, "TLS on behalf of John Mattsson" <
> [email-masked] on behalf of [email-masked]> wrote:
> [1] https://datatracker.ietf.org/meeting/101/materials/slides-
> 101-tls-sessb-record-header-extensions-for-dtls-00
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: John Mattsson <[email-masked]>
Date: Tue, 20 Mar 2018 23:29:09 +0000

I don’t think it is required either, the mechanisms in draft-schmertmann-dice-codtls and draft-friel-tls-over-http clearly wotks, but Hannes Tschofenig brought it up as a new mechanism that can be used to simplify things in ATLS, I tend to agree. I don’t think we should invent new mechanism for ATLS if we can use Connection ID.

From: "[email-masked]" <[email-masked]>
Date: Tuesday, 20 March 2018 at 17:37
To: "Fossati, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Cc: John Mattsson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Connection ID in TLS

I don't think Connection-ID is really required for ATLS.  As Carsten and Owen mentioned in the side meeting, there are a few ways to use HTTP to correlate the relevant messages.

On Tue, Mar 20, 2018 at 5:15 PM, Fossati, Thomas (Nokia - GB/Cambridge) <[email-masked]<mailto:[email-masked]>> wrote:

Cheers

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 20 Mar 2018 18:55:05 -0500

> I don’t think it is required either, the mechanisms in draft-schmertmann-dice-codtls and draft-friel-tls-over-http clearly wotks, but Hannes Tschofenig brought it up as a new mechanism that can be…

My personal opinion is that it will be easier for ATLS to use DLS
natively than to produce a reliable in-order stream abstraction for
TLS's use.  (I say, as someone who is not going to be doing the
work, so take that for what it is.)

-Ben