On Sunday, May 17, 2015 05:29:51 pm Tom Ritter wrote: > On 17 May 2015 at 14:32, Dave Garrett <davemgarr...@gmail.com> wrote: > > Is it really necessary to have a separate application_data_padded content > > type? It'd be simpler to just keep using existing types but amend it with a > > padding field and require it always be used at minimum to pad up to the > > nearest multiple of N-bytes. (something low for the default) Additional > > padding would be optional, but all data would get some minimum. > > That was the first proposal, but the extra bytes on every message for > people who weren't using padding were deemed to be prohibitive.
Wouldn't it be simpler to just have an optional padding vector that exists only if padding is negotiated? (we already have one optional field with extensions in the hello messages) A simple method to negotiate would be to add a new HandshakeType with a couple flags, one to indicate that the endpoint will be sending padded messages and another to indicate that it's willing to receive padded messages. Endpoints could declare padding with this message and use it until its peer sends a message requesting otherwise. This sort of scenario would have the additional benefit of not stating the existence of padding in the clear. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
