Subject: [TLS] Handshake padding in TLS 1.3 (PR #147)

From: Henrik Grubbström <[email-masked]>
Date: Wed, 18 Mar 2015 18:42:20 +0100

Hi.

I've taken a look at the feasibility of adding handshake padding as
currently drafted in PR #147 to my implementation of TLS 1.3.

>From the PR draft:

> handshake_messages
>
> : All of the data from all messages in this handshake up to, but not including,
> this message. This is only data visible at the handshake layer and does not
> include record layer headers. For encrypted handshake records, the hash
> includes the two bytes specifying the length of the padding, as well as any
> padding present. handshake_messages is the concatenation of all the
> Handshake structures as defined in {{handshake-protocol}}, exchanged thus
> far. {:br }

The above seems to assume that packet breaks (ie the places where
padding is inserted) and handshake message breaks align. This is not
true in the general case, and the above is a protocol layering
violation.

The problem shows up clearly if you have distinct layers of code for
handling coalescing (and apparently padding) of packets and the
handling of handshake messages, and the higher layer is about to send
a Finished message; to be able to calculate the payload for the
packet, it needs to know in advance where the lower layer will break
the packets, and what padding it will insert as this will affect the
handshake_messages hash.

The recipient also runs into trouble, as it can no longer just add all
handshake packet payloads to a buffer from which it extracts a message
at a time, as it also needs to keep track of any padding (which may
appear in the middle of messages).

Adding such complexity is likely to frustrate implementators and lead
to even buggier implementations.

I believe that the easiest way to reduce the complexity while still
retaining the features of padding, would be to move the padding from
the handshake packet layer to the handshake message layer. Ie
introduce a handshake_padding message (allocated from HandshakeType)
which may be sent at any point in the handshake, and which only
affects the handshake_messages hash.

This would be trivial to implement on the recipient side, have no
overhead if padding isn't used, and be reasonably simple to implement
on the sender side. The down side is that the minimum padding would be
4 bytes and not 2.

/grubba

-- 
Henrik Grubbström                                       [email-masked]
Roxen Internet Software AB                              [email-masked]