Dave: > 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.
I like the idea that the presence or absence of padding in the ciphertext is hidden in your proposal. Is there really an need to toggle it on and off? Russ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
