Subject: [TLS] encrypted content type and padding

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 21 Sep 2015 00:02:47 -0700

Hey TLS folks--

apologies for the delay in sending these pull requests.

encrypted content type:
-----------------------

https://github.com/tlswg/tls13-spec/pull/51

This should be uncontroversial, and just needed freshening against the
current draft.

padding:
--------

We're now proposing that handshake padding should be offered by
introducing a new HandshakePadding message.  I've avoided any sort of
padding negotiation in the handshake in favor of making padding always
available in TLS 1.3 and up.  Life is simpler this way.

There are two approaches available for application data padding which we
failed to select from at Prague (possibly because this is a bikeshed).

My preferred approach is to use a standard tls opaque field for
application data padding:

https://github.com/tlswg/tls13-spec/pull/249

But if anyone is interested, i've also mocked up using a "padding is all
0x00 up to the first 0x01" approach:

https://github.com/tlswg/tls13-spec/pull/250

This last approach is unlike anything else in TLS data structures, but
it does give the sender the ability to pad with only one octet.

There may be a slight sidechannel difference between offsetting by the
size of the TLS opaque padding object (PR #249) when compared to running
memchr(cleartext, '\001', cleartext_length) (PR #250), but i suspect
that timing difference is small compared to the difference incurred by
whatever is processing the cleartext (though if the cleartext processor
was designed to be constant time itself, the padding timing sidechannel
might be noticable).

i personally prefer PR #249 because it is more inline with the
traditional layout of TLS data elements, and lacks additional risk of
timing differences.  Its main downside is its inability to pad by
anything less than two octets, which slightly complicates calculations
of how much to pad when padding algorithmically.

See you all in the morning,

    --dkg

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 21 Sep 2015 03:19:30 -0400

> apologies for the delay in sending these pull requests.

:)

> available in TLS 1.3 and up.  Life is simpler this way.

Padding can create oracles and complicates proofs.

When sending data that needs to be padded during key exchange, then
fill it up with random data and digest it in HKDF- like fashion.

When sending data that needs to be padded during bulk transfer, then
don't do it. Use GCM, CTR, etc.

Why make life more complicated then it needs to be?

Jeff

---

From: Watson Ladd <[email-masked]>
Date: Mon, 21 Sep 2015 07:43:27 -0400

> Why make life more complicated then it needs to be?

Is this actually true in the second pull request? No: a moment of
actually reading reveals that the string is inside an AEAD encrypted
packet. There is no way in which this padding could be modified for
use in a side-channel attack.

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

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 21 Sep 2015 07:06:44 -0700

> use in a side-channel attack.

In both pull requests, the padding is inside the AEAD encrypted packet.
The intent, after all, is to create a mechanism that provides
uncertainty about the length of the cleartext.

See, for example:

 I Know Why You Went to the Clinic: Risks and Realization of HTTPS
 Traffic Analysis
 
 by  Brad Miller, Ling Huang,  A. D. Joseph, and J. D. Tygar

 http://arxiv.org/abs/1403.0297

     --dkg

---

From: Dave Garrett <[email-masked]>
Date: Mon, 21 Sep 2015 13:36:10 -0400

> encrypted content type:

Basing the padding PR(s) on top of this might be a good idea, seeing as it's desired to do this correctly.

One thought about doing this with a separate record type, though. It might be better to generalize it by reserving the top bit in the type as a padding flag, thus allowing padding variants of all other types. Record type values would just be the unpadded value plus 128. Implementations could check for padding by simply ANDing a mask to check for the flag. The remaining 7 bits is plenty for the record types field. This could be used for the handshake messages instead of adding a separate handshake padding message. No special type value registration would be needed to add any future padded types.

> of how much to pad when padding algorithmically.

I agree. Simpler is probably better here.

Dave