Hey TLS folks-- apologies for the delay in sending these pull requests.
encrypted content type: ----------------------- https://github.com/tlswg/tls13-spec/pull/51 This should be uncontroversial, and just needed freshening against the current draft. padding: -------- We're now proposing that handshake padding should be offered by introducing a new HandshakePadding message. I've avoided any sort of padding negotiation in the handshake in favor of making padding always available in TLS 1.3 and up. Life is simpler this way. There are two approaches available for application data padding which we failed to select from at Prague (possibly because this is a bikeshed). My preferred approach is to use a standard tls opaque field for application data padding: https://github.com/tlswg/tls13-spec/pull/249 But if anyone is interested, i've also mocked up using a "padding is all 0x00 up to the first 0x01" approach: https://github.com/tlswg/tls13-spec/pull/250 This last approach is unlike anything else in TLS data structures, but it does give the sender the ability to pad with only one octet. There may be a slight sidechannel difference between offsetting by the size of the TLS opaque padding object (PR #249) when compared to running memchr(cleartext, '\001', cleartext_length) (PR #250), but i suspect that timing difference is small compared to the difference incurred by whatever is processing the cleartext (though if the cleartext processor was designed to be constant time itself, the padding timing sidechannel might be noticable). 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. See you all in the morning, --dkg _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
