Subject: [TLS] Record layer padding

From: JCA <[email-masked]>
Date: Thu, 24 Jan 2008 20:17:03 -0800

I am trying to become thoroughly familiar with the TLS
specification, and I have reached a point at which I have a doubt that
the spec does not seem to dispel. Or, if it does, I have been unable
to find where. My apologies in advance for that.

   My questions are to do with record layer padding. The spec
describes how to do it when using a block cipher. What is not clear
from the spec is the following:

   What happens when the length of the record layer data to be
encrypted happens to be a multiple of the block cipher's block size?
Does one have to add a padding block the same size as the cipher's
block size, or is one to set the closing padding length byte to zero,
without adding any explicit padding? I'd be inclined to do the former,
but I do not know if this is what the spec intended.

   Also, what happens to record layers put together before encryption
kicks in? Is one supposed not to use the padding length byte at all?
That's what I would do myself but, again, I am not sure.

   Any feedback will be most welcome.

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

---

From: <[email-masked]>
Date: Fri, 25 Jan 2008 08:34:09 +0200

JCA ([email-masked]) wrote:
> specification, and I have reached a point at which I have a doubt
> that the spec does not seem to dispel. Or, if it does, I have been
> unable to find where. My apologies in advance for that.
> 
> block size, or is one to set the closing padding length byte to
> zero, without adding any explicit padding? I'd be inclined to do the
> former, but I do not know if this is what the spec intended.

The data-to-be-encrypted consists of the actual record layer content
(GenericBlockCipher.content), the MAC, the padding (zero or more
bytes) and the padding_length byte. The sum of these has to be a
multiple of the block size (and the padding_length byte is always
present).

So, for example, if you're using AES_128_CBC_SHA, and have 27
bytes of actual content, you could set padding_length to 0 
(since 27+20+1 = 48 = 3*16)

>    Also, what happens to record layers put together before
> encryption kicks in? Is one supposed not to use the padding length
> byte at all?  That's what I would do myself but, again, I am not
> sure.

Each TLS record is encrypted separately, and the padding_length
byte is present in each of them. (If you e.g. combine several
handshake messages in one TLS record -- well, that's done
before the record layer, so it's just one record then.)

Best regards,
Pasi

---

From: JCA <[email-masked]>
Date: Fri, 25 Jan 2008 08:29:46 -0800

> (since 27+20+1 = 48 = 3*16)

    Thanks, that clarifies it. In fact, on rereading the relevant part
of the spec that seems to be implied. I would also seem to be implied
that one is free to add as many padding blocks as one wishes (and fit
the bill,) provided the padding length is less than 256 bytes, right?
Even more: If I am understand it correctly, implementations are
encouraged to do so in order to foil traffic analysis-based cracking
attempts.

> before the record layer, so it's just one record then.)

   Hmm.... I am not sure I follow here. My understanding is that all
TLS data will be exchanged encapsulated within TLS record layers. From
this it would seem that messages in the same record must be either
encrypted or unencrypted, but not both. That is, what one encrypts (or
not) are whole records, not individual messages. And analogously for
the MAC computation. Is this what the spec means?

   To answer my own question, again on rereading the spec my take is
that unencrypted records are just records encrypted with the Null
cipher - which, according to the spec (and just like stream ciphers)
does not require padding, and therefore no padding length byte.

   Thanks very much for your feedback.

---

From: <[email-masked]>
Date: Fri, 25 Jan 2008 20:05:01 +0200

> the bill,) provided the padding length is less than 256 bytes, right?

Yes.

> encouraged to do so in order to foil traffic analysis-based cracking

Well, "encouraged" is perhaps an overstatement: as far as I know,
most existing TLS implementations don't this. (When some versions
of GnuTLS shipped with this feature enabled, it was discovered
that Symbian TLS implementation didn't like receiving that 
extra padding -- a bug that hadn't been discovered in probably 5+
years, suggesting that nobody else sends such records. There were
some messages on the list back in November, I think.)

> TLS data will be exchanged encapsulated within TLS record
> layers. From this it would seem that messages in the same record
> must be either encrypted or unencrypted, but not both. That is, what
> one encrypts (or not) are whole records, not individual
> messages. And analogously for the MAC computation. Is this what the
> spec means?

Yes, you encrypt and MAC whole records, not individual messages.
But the relationship between records and e.g. TLS handshake messages
is loose: one TLS handshake message can be split to multiple records,
and one record can contain more than one handshake message.

> does not require padding, and therefore no padding length byte.

Yes, you're right -- unencrypted records don't have the padding length
byte, because they don't use the GenericBlockCipher structure.

Best regards,
Pasi

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 31 Jan 2008 09:49:03 +0100

> some messages on the list back in November, I think.)

GnuTLS still pad records randomly, for security reasons, and has done so
since basically forever as far as I know.  I see no reason to disable it
by default.  There has been relatively few reports about problems caused
by this, and only from Symbian TLS users.

What has changed since it was discovered that record padding was
problematic in some environments is that we offer a mechanism for
applications to disable it.  We recommend that application authors use
the defaults (i.e., record padding enabled), and only that users disable
it on their own initiative, and further, that they only do so on a
per-IP or per-account basis if possible.

I would encourage all implementers to enable record padding.

/Simon