Subject: [TLS] Why is padding still actively being used?

From: Jeffrey Walton <[email-masked]>
Date: Sat, 16 May 2015 20:24:52 -0400

Integrated Encryption Schemes, like ECIES and DHAES, don't pad in the
Data Encapsulation Mechanism (DEM) or Key Encapsulation Mechanism
(KEM). In the case of a KEM, they fill the parameter to the size of
the underlying field, and then use a derivation function to digest it.

Removing the padding simplifies the proofs and removes the oracles
related to the padding.

When possible, why does TLS still pad and backfill with 0's rather
than filling to the underlying field size and/or digesting?

(And I understand block ciphers need padding, so sometimes padding is
required in the IES equivalent of a DEM).

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 17 May 2015 08:29:36 +0300

> than filling to the underlying field size and/or digesting?

Are you talking about leading zero stripping in Diffie-Hellman key
exchange?

I think many bignum libs perform that kind of thing, which is a
good source of bugs (especially in big-endian).

However, if using dedicated arithmetic (generic bignums are not
safe) for fields available in TLS 1.3, that kind of stripping is
just extra complexity and source of bugs.

Thinking about padding, I think there should be some sort of
payload padding under AE, fro those applications that want to hide
lengths of messages.

In TLS 1.2, it could easily be added as new "compression" mechanism,
but those are not supported in TLS 1.3.

-Ilari

---

From: Dave Garrett <[email-masked]>
Date: Sun, 17 May 2015 11:50:24 -0400

> but those are not supported in TLS 1.3.

We could recycle/rename the "compression" field into "encoding", have existing codepoints for compression reserved and prohibited, and add new codepoints for padding schemes to use.
https://www.iana.org/assignments/comp-meth-ids/comp-meth-ids.xhtml#comp-meth-ids-2

This would let endpoints negotiate different padding levels, which might be useful.

Dave

---

From: Tom Ritter <[email-masked]>
Date: Sun, 17 May 2015 13:33:05 -0500

> payload padding under AE, fro those applications that want to hide

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

I believe this had achieved rough consensus in the March interim.

-tom

---

From: Dave Garrett <[email-masked]>
Date: Sun, 17 May 2015 15:32:30 -0400

> I believe this had achieved rough consensus in the March interim.

Is it really necessary to have a separate application_data_padded content type? It'd be simpler to just keep using existing types but amend it with a padding field and require it always be used at minimum to pad up to the nearest multiple of N-bytes. (something low for the default) Additional padding would be optional, but all data would get some minimum.

Dave

---

From: Tom Ritter <[email-masked]>
Date: Sun, 17 May 2015 16:29:51 -0500

> Is it really necessary to have a separate application_data_padded content type? It'd be simpler to just keep using existing types but amend it with a padding field and require it always be used at…

That was the first proposal, but the extra bytes on every message for
people who weren't using padding were deemed to be prohibitive.

-tom