Re: [TLS] encrypted content type and padding

[Dave Garrett <[e-mail]>]

On Monday, September 21, 2015 03:02:47 am Daniel Kahn Gillmor wrote:
> encrypted content type:
> -----------------------
> 
> https://github.com/tlswg/tls13-spec/pull/51

Basing the padding PR(s) on top of this might be a good idea, seeing as it's desired to do this correctly.

One thought about doing this with a separate record type, though. It might be better to generalize it by reserving the top bit in the type as a padding flag, thus allowing padding variants of all other types. Record type values would just be the unpadded value plus 128. Implementations could check for padding by simply ANDing a mask to check for the flag. The remaining 7 bits is plenty for the record types field. This could be used for the handshake messages instead of adding a separate handshake padding message. No special type value registration would be needed to add any future padded types.

> i personally prefer PR #249 because it is more inline with the
> traditional layout of TLS data elements, and lacks additional risk of
> timing differences.  Its main downside is its inability to pad by
> anything less than two octets, which slightly complicates calculations
> of how much to pad when padding algorithmically.

I agree. Simpler is probably better here.


Dave