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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
