Re: [TLS] A question for TLS middle-box/middleware vendors/implementers

[Yoav Nir <[e-mail]>]

> On 27 Jan 2018, at 18:30, Fossati, Thomas (Nokia - GB/Cambridge, UK) <[e-mail]> wrote:
> 
> Hi TLS middle-box/middleware folks,
> 
> If length's MSB in a D?TLS{Ciphertext,Plaintext,Compressed} record is
> set, how does your software react?
> 
> Is it going to drop the session/record or not bothering at all?
> 
> I'm trying to understand a bit better whether and when it'd be safe to
> grab that bit and give it new semantics (e.g., for signalling the
> presence of a DTLS connection-id, an ext-header, or anything else
> really) and your answers would help shedding some (*) light on the
> matter.
> 
> Based on previous experience on similar (but not identical) changes to
> the record format, Adam ([1], [2]) suggested that this bit is likely to
> have already ossified in TLS, whereas DTLS might be still OK.  So, I'm
> curious to hear from those who own the boxes' logics if they share the
> same opinion - in particular if DTLS is in better shape than TLS?
> 
> Thanks in advance for your time.
> 
> (*) I'm pretty sure not every TLS middle-box vendor on earth is
> subscribed to this list and, even among those who are, not everyone
> might be willing or able to share this information with the wider
> community.  This is to say that I'm aware of the limited value a poll
> like this has, but I'm not in a position to do a large-scale measurement
> campaign at the moment, so better start from somewhere... OTOH, I think
> there is a valuable discussion to be had in cases like this with folks
> that don't own the endpoints but are going to (or have already) put
> their logics on the e2e path, so hopefully I'm not wasting everyone's
> time :-)
> 
> cheers, t
> 
> [1] https://www.ietf.org/mail-archive/web/tls/current/msg25299.html
> [2] https://www.ietf.org/mail-archive/web/tls/current/msg25304.html <https://www.ietf.org/mail-archive/web/tls/current/msg25304.html>

Hi, Thomas.

I don’t work for a middlebox vendor anymore, although I did only 8 months ago. This answer is not based on recently looking at code.

The length field is byte-aligned. So any implementation of a TLS parser or TLS proxy will do one of two things:

1. Consider the MSB to be a must-be-zero bit and drop any length field that has it set as faulty.

2. Ignore text about limits on length and assume the record is that big. Depending on what field that is, this may cause a drop on some other sanity check.

As always there’s option #3 (crash), but the industry is getting better at avoiding that.

You seem to want the behaviour that the middlebox masks out the must-be-zero bits and considers only the relevant length bits. I don’t think that would pass code review at my former employer.

HTH

Yoav