- From: Roberto Peon <grmocg@gmail.com>
- Date: Tue, 19 Nov 2013 17:03:35 -0800
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Mark Nottingham <mnot@mnot.net>, James M Snell <jasnell@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CAP+FsNcNtdo9amaboDDDWbMGz47DgCed6q-BS_zLB275Y_MN4w@mail.gmail.com>
I don't buy the argument that you're screwed anyway so don't worry about it. I do agree that it is sometimes good to allow other entities to route one's opaque bytestreams-- terminating the transport at various locations within the path can help reduce the effects of packet loss on lossy segments, reducing jitter and increasing throughput/goodput. Exposing the framing/length of things that would be in an encrypted-by-TLS bytestream today, however, does worry me-- it makes BEAST/CRIME-like attacks significantly more difficult to protect against. -=R On Tue, Nov 19, 2013 at 4:54 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote: > In message <A2FCBC5B-CD83-4373-A80F-08AD860FAFD6@mnot.net>, Mark > Nottingham wri > tes: > > >For me, one of the key questions about this general approach is whether > >the extra information leakage will be acceptable. I.e., an attacker will > >now know the "shape" of messages -- request and response -- on the wire, > >including their timing, size, relationships, etc. > > I think those are only relevant concerns in the 'targeted attack' > model, in which case, based on what we have learned, you're likely > totally screwed, even if you use TOR. > > I think this is a much better model for HTTP in the long run, since > it opens the door to protected traffic sharing connections with > unprotected traffic, for instance between outgoing proxies and > servers, and it has the potential to only protect the bits which > really matter, at the level of protection they need. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > >
Received on Wednesday, 20 November 2013 01:04:04 UTC