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) < thomas.foss...@nokia.com> wrote: > On 20/03/2018, 16:38, "TLS on behalf of John Mattsson" < > tls-boun...@ietf.org on behalf of john.matts...@ericsson.com> 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 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
