On 22 August 2015 at 19:28, Dave Garrett <davemgarr...@gmail.com> wrote: > 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 have a not-very-hidden motive in not having it be negotiable: I want to enable clients to want to send padding be able to do so to any server, even if that server does not want to pad. (They can just discard.) If it's negotiated, the server may say "I don't support padding" and clients who want to use it out out of luck. I do like solutions where the use or non-use of padding is hidden, but I think in many cases it will be obvious, so the above goal comes before this goal for me. I don't believe the topic of encrypting the content type is completely resolved, but that is a separate proposal: https://github.com/tlswg/tls13-spec/pull/51 > 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 t o be largely unused. In general, developing good padding approaches is relatively easy for well defined application protocols, and difficult for extremely generic ones like "Browsing the Internet". If one was developing an application for twitter, google maps, XMPP chat - developing a good padding mechanism to hide specific actions or data would not have the same issues. There's been a number of padding strategies developed by academic researchers studying traffic correlation/confirmation attacks - I don't expect any of them is drop-in-good-enough for a generic browser implementation... but it would be _amazing_ if browser vendors enabled browser extension authors to choose the padding strategy for individual origins. Then we can crowdsource the effort. -tom _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
