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

Martin Thomson <martin.thomson@gmail.com> Thu, 12 March 2015 00:31 UTC

MIME-Version: 1.0
In-Reply-To: <D126211F.8BD8%d.holmes@f5.com>
References: <D126211F.8BD8%d.holmes@f5.com>
Date: Wed, 11 Mar 2015 17:31:10 -0700
Message-ID: <CABkgnnUTbwj5qijhyj5HuXdku3e+kDUX+Dry=tq3c-5-gfANaQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: David Holmes <d.holmes@f5.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/KjppLOyb4Jnb8j4XAXr4SqCA1MA>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 - ignoring version values in record protocol header
Precedence: list

On 11 March 2015 at 16:43, David Holmes <d.holmes@f5.com> wrote:
> In draft 5, if the version bytes are still included in the AEAD
> 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.

[TLS] TLS 1.3 - ignoring version values in record… David Holmes
Re: [TLS] TLS 1.3 - ignoring version values in re… Dave Garrett
Re: [TLS] TLS 1.3 - ignoring version values in re… Martin Thomson