Tommy Pauly Presenting
3rd revision, getting closer. We have however added a dependency.
Richard: Are we done yet?
Tommy: Close.
Incremental header field is the dependency; it is a HTTPbis WG I-D.
Kasuho, Tommy, and Martin are authors.
Richard: Why is this a dep?
Tommy: It doesn't have to be. Do the old trick about yelling at your
relay. If this was already an RFC we would SHOULD it.
Richard: Seems like maybe this could be an informative reference.
Tommy: We can work it out later.
Jonathan: Has this been through security analayis? This blows up my
security model.
Tommy: Last thing we need to do is get help with the analysis.
J&T agree: Interleaving responses has very different properties.
Tommy: for the purpose of analysis: do chunking without interleaving.
?: While intermediaries almost never buffer the resppons. Does this make
it easier for you?
Tommy: Not sure that is universally true; we saw examples that buffered.
?: If we are using the incremental, then that's the most interesting
property.
Tommy: If you want to block it you need to explicitly say don't use it.
Martin: There's been some information analysis. There is the
interactivity question. We need some clear guidance on that. Getting
interactivity is a bit of a miss-feature.
Tommy: Leaning towards SHOULD NOT with a lot of warnging about dragons!
One could see a world where the request processing and timing is based
on response chucking. Some middle ground that collides. So lots of
different properties ...
Lucas: Is this about the header or the whole concept?
Tommy: I think it's the whole concept.
Jonathan: ....
Ben: (covering old ground) This seems much less privacy preserving than
OHTTP. Advantages over existing tunneling TLS seem small. Timing attacks
are particularly bad. Not sure what to do, but some recognition is
needed about the protections you have lost.
Tommy: 50 chunks to one and 20 to another. Assuming low enough traffice
that you can see that from outside ...
Ben: Accidently there is some difficulty in figure out which response
was between gateway. ...
Tommy: You are attacking the gateway ....
See transcript
Ben: THe loss of privacy here if you add chunks it makes it much easier,
i.e., exponential. We should be scared.
Tommy: Don't entirely agree. Some of the concerns are already in the
base RFC.
Timo (?): Draft mentioned incremental header is one bit. Will the header
evolve or be different between request/response.
TOmmy: Exactly if it changes then it's a problem.
Timo: If there are more headers does this change the security
properties.
Martin: Ben's concern is real. The cause of that concern is misplaccd.
Incremental is the problem. Malicious gateways can do this whether it is
incremental or not. It might be that your response is that the relay has
to buffer, but that kills the I-D. Can it be abused yes, but you can't
say that it shouldn't be used just because of that if it can be used
effectively.
Tommy: There is a class that you can work for fingerprinting based on
timing.
Yarslov: Base RFC says gateway can add padding. Could you use that?
Maybe chunked should require it?
Tommy: A good thought, and yeah we could solve Ben's issue. We should
prevent that from happening but we're not going to do that.
Reaming issues:
Ted: Have you registered the media-type.
Tommy: NO.
Ted: Can you have a fragment identifier? Would be possible to use this
media type where the nonce is referenced bby the fragment identifier ...
and this would be horrible. As them what incantation is that says these
media type isn't fragmented.
Tommy: Great point. Put in the notes.
Martin: 65K is quite large. Pick 16K to match with TLS.
Tommy: Seems fine.
No comments.
Richard: Solicit comments?
Tommy: Let's get through the 3 issues before asking for additional
review.