On Saturday, August 22, 2015 03:36:21 pm Russ Housley wrote: > > 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?
Toggling solves the undesired bandwidth use concern stated by Tom by making it fully optional on both sides. The even simpler route of just having to check if there's bytes in the encrypted fragment other than the payload would avoid a little bit of complexity, but with no way for an endpoint to say no to increased bandwidth usage that it doesn't want to or can't handle. Given this constraint, I'd favor either easily toggleable or always-on, rather than a middle-ground where implementations won't know what they're going to get and can't do anything about it. A footnote: Negotiating via an extension is probably not a good idea because client extensions will generally be in the clear. That's why I suggest a simple message instead. (there's no need to pad the cleartext hello, so it's fine to wait until record protection is available) Note that I don't think allowing this to be decided after the handshake is a good idea. A more generalized way to handle throttling padding would be to set a low default and require each endpoint to send a message with a different value, in max bytes per record (or second, or both) of padding permitted, in order to use a different amount. Each endpoint could easily arbitrarily throttle its downstream padding bandwidth independently, if need be. I'm curious as to how much of a range would actually be useful, though. For actually good protection, you'd really want to pick a stable bandwidth and essentially hold it; keep up/download rates constant or following some consistent pattern with a combination of possibly throttled data and padding such that the data length and time is completely protected and the stream is 100% opaque to an observer. I wouldn't expect this to be all that popular, though, as it would be a bandwidth hog in many cases. A middle-ground might involve also specifying a max bytes allowed in between data bursts to hide the peaks, but now we're getting more complicated than I think we want here if we go any further. (and beyond what I know anything about) The current proposal says that padding algorithms are outside of the scope here, but I think adding this as a built-in feature without coming up with some easily usable default (even if not particularly advanced) is a mistake that will cause this feature to be largely unused. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
