Subject: [TLS] TLS 1.3 Record Layer Format

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 6 Mar 2017 10:11:58 +0100

Hi all,

at the Seoul IETF meeting it was mentioned that the record layer format
may be simplified (by removing unused fields) if deployment tests real
no problems.

Sorry if I missed information about the outcome of these deployment
tests but the current spec version still has the old record layer format.

As I mentioned in previous meetings I believe that such a record layer
simplification would be quite useful for environments where link layer
technologies provide very small MTU sizes.

Ciao
Hannes

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 6 Mar 2017 17:55:17 +0200

> tests but the current spec version still has the old record layer format.

Yeah, I haven't seen those results either.
 
> technologies provide very small MTU sizes.

AFAIK, one can save 3 bytes from the header for encrypted records
in TLS 1.3. Won't go well with SRTP mux tho.

(2 octet encoding for such record headers:

+-+---------------+
|1|Length(15 bits)|
+-+---------------+

These won't overlap with other TLS 1.3 records, as all others
always have MSB of first octet clear).

-Ilari

---

From: Adam Langley <[email-masked]>
Date: Mon, 6 Mar 2017 10:04:38 -0800

> Yeah, I haven't seen those results either.

We have not yet gotten around to doing those tests and, given the
amount of problems that resulted from a test of TLS 1.3 without any
record-header changes, we are wondering whether it's worth doing those
tests.

(We're not yet ready to share details of the deployment problems that
we have encountered so far, but I hope to do so in the coming weeks.)

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 6 Mar 2017 10:42:07 -0800

We (Firefox) have been running an experiment to measure this, but we don't
yet have
anything to share about it. I expect by IETF, however. Not saying that
these results
will be dispositive, but I should have something.

-Ekr

On Mon, Mar 6, 2017 at 10:04 AM, Adam Langley <[email-masked]>
wrote:

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 8 Mar 2017 11:25:26 +0100

Hi Ilari,

yes, I am exactly talking about these bytes that are useless to send
around in some deployment environments.

I would expect to at least provide the option of not sending the data in
some cases would be useful.

Ciao
Hannes

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 8 Mar 2017 15:27:48 -0600

> some cases would be useful.

I would not expect us to provide that option.  The cost of introducing a
negotiation mechanism and interop headaches does not seem worth the gain
of three octets per encrypted record.

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Mar 2017 13:46:43 -0800

FWIW, I think DTLS 1.3 should just do this (and other header shortening
stuff).
I don't know of any evidence that there are policy enforcement boxes for
DTLS

-Ekr

On Wed, Mar 8, 2017 at 1:27 PM, Benjamin Kaduk <[email-masked]> wrote:

> negotiation mechanism and interop headaches does not seem worth the gain of
> three octets per encrypted record.
>
> -Ben
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 Mar 2017 08:50:23 +1100

> I don't know of any evidence that there are policy enforcement boxes for

Definitely.  I also think that DTLS 1.3 could stand to lose a few
sequence number and epoch octets at the same time.  We have some
lessons from QUIC that will help there (for instance, we only need to
signal three epoch values, and two octets of sequence number space is
probably too lean).