> On Aug 25, 2015, at 2:22 AM, Tom Ritter <t...@ritter.vg> wrote: > > 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’m not sure having one side send a continuous stream of large record buys you much if the other side doesn’t. Suppose an HTTPS server has 100 resources, each with a different size, it won’t help if the client obscures the identity of the resource it’s asking for if the resource can be identified by its size. Same goes for the existence of traffic. If the server stays quiet until there’s an actual request, the client’s continuous stream of padding-only records is just wasted effort. IMO this is an argument for negotiation, although even with negotiation we can never be assured that the other side is doing TFC well. Yoav _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
