Subject: [TLS] TLS 1.3 - ignoring version values in record protocol header

From: David Holmes <[email-masked]>
Date: Wed, 11 Mar 2015 23:43:11 +0000

On day 1 of the Seattle TLS 1.3 working group, it was questioned what to
do with the TLS version bytes in record protocol. Send but ignore seemed
to be the consensus, with ³pin to [3,4] forever"

In draft 5, if the version bytes are still included in the AEAD
computation, they shouldn¹t be ignored, right?

If we keep the record protocol version bytes, the most straightforward
action is to [continue with the tradition of having them] match the
version of TLS negotiated in the handshake. In this case [3,4].

6.2.2 Record Payload Protection

struct {
          ContentType type;
          ProtocolVersion version;
          uint16 length;
          opaque nonce_explicit[SecurityParameters.record_iv_length];
          aead-ciphered struct {
             opaque content[TLSPlaintext.length];
          } fragment;
} TLSCiphertext;

Š

additional_data = seq_num + TLSPlaintext.type + TLSPlaintext.version

Š

AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext, additional_data)

---

From: Dave Garrett <[email-masked]>
Date: Wed, 11 Mar 2015 20:24:31 -0400

Record layer version number freezing & ignoring is in latest PR #107:
https://github.com/tlswg/tls13-spec/pull/107/files

Proposal to just remove the field from encrypted records is now issue #144:
https://github.com/tlswg/tls13-spec/issues/144

Reviewing #107 is in EKR's work queue.

#144 hasn't gotten much discussion yet.

Dave

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Mar 2015 17:31:10 -0700

> computation, they shouldn¹t be ignored, right?

This is largely conjecture without proper analysis, but would like to
suggest the following:

1. We make the version number part of the PRF (HKDF) info string
(i.e., "TLS 1.3" or something that is unique to this protocol is part
of all expansion phases.  That will make the keying material dependent
on the version number.

2. Content type be moved from the AD to the actual data so that it is
not just authenticated, but also encrypted.

3. And then, since the sequence number was agreed to comprise the
entirety of the IV (the 5116 nonce) with zero pad to the requisite
size, it too can be removed.

... that means that ALL of the AD can be removed.

Yes, this could mess up middleboxes, but the sense I got was that we
might try this out and see how much damage this really does.