Re: [TLS] Record layer padding

[JCA <1.41421@xxxxxxxxx>]

On Jan 24, 2008 10:34 PM,  <Pasi.Eronen@xxxxxxxxx> wrote:
> JCA (1.41421@xxxxxxxxx) wrote:
> >
> >    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.
>
> 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)

    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.

> >    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.)

   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.


_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls