RE: [TLS] Record layer padding

[<Pasi.Eronen@xxxxxxxxx>]

JCA (1.41421@xxxxxxxxx) wrote:

>     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?

Yes.

> Even more: If I am understand it correctly, implementations are
> encouraged to do so in order to foil traffic analysis-based cracking
> attempts.

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

> > > 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?

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.

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

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

Best regards,
Pasi


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