Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

[Eric Rescorla <[e-mail]>]

On Wed, Dec 2, 2015 at 7:34 AM, Jacob Appelbaum <[e-mail]> wrote:

> On 12/2/15, Eric Rescorla <[e-mail]> wrote:
> > On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford <[e-mail]>
> wrote:
> >
> >> On 02 Dec 2015, at 06:02, Martin Thomson <[e-mail]>
> >> wrote:
> >> > On 1 December 2015 at 08:22, Bryan A Ford <[e-mail]>
> >> > wrote:
> >> >> The 2-byte length field in each record's header no longer indicates
> >> >> the length of the *current* record but instead indicates the length
> of
> >> >> the *next* record.
> >> >
> >> > Ensuring that you know the length of the *next* record is difficult
> >> > and could dramatically degrade latency, or adding extra bogus padding
> >> > or extra bogus records.  For instance, I can always send in bursts of
> >> > two packets, a one octet packet that promises the remainder of the
> >> > burst and one that promises a single octet packet.  At that point, I
> >> > get to do what I've always done and you have gained little other than
> >> > an increase in packet size of around 19 octets (best case).
> >>
> >> That type of inefficiency is extremely easy to avoid; please read the
> >> rest
> >> of my proposal where I discussed exactly that at length.  Yes, a
> >> particularly stupid implementation could send everything in bursts of
> two
> >> packets, but it’s ridiculously easy for a slightly smarter
> implementation
> >> to avoid doing that.  And what you’ve gained is complete encryption and
> >> integrity-checking of the whole TLS record before any part is
> >> interpreted,
> >> which seems like a nontrivial security improvement.
> >
> >
> > It's not really clear to me what the anti-traffic-analysis benefit of
> your
> > proposal
> > is over and above just padding everything to a fixed size. That's
> certainly
> > far
> > easier for the implementation to do, especially in typical stacks where
> the
> > application just calls SSL_Write (or whatever) and so there's no obvious
> > API point to provide the "next length", so as a practical matter the
> stack
> > will very often if not always be in "last block" mode.
> >
>
> I think that it eliminates all static distinguisher in the protocol
> for all data covered by the encryption. That is a fantastically
> wonderful benefit.


Wouldn't that benefit be equally achieved by simply padding all records
to a fixed length? You could do this with no protocol change and, as I
said, it's far easier for the implementation.


> -Ekr
> >
> > [0] This issue doesn't apply to DTLS because the stack will just move
> onto
> > the next UDP datagram.
>
> An off-path attacker can't do much with DTLS, if designed correctly.
> Especially if they only see some packets - they'd only get the UDP
> headers and then the rest should be uniformly distributed random data,
> no?


DTLS records do in fact contain a length field because it's possible to
pack >1 record into a single UDP datagram. In practice, I think that
most stacks do 1:1 except perhaps during the handshake. They also
contain a sequence number to aid in reconstruction (important
in this case because TLS 1.3 uses the sequence number to
form the AEAD nonce).

However, as you suggest, an attacker can't DoS DTLS connections by
injecting a small number of packets because the DTLS stack will just
reject bogus packets.


-Ekr