W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: New Version Notification for draft-snell-httpbis-keynego-01.txt

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 19 Nov 2013 17:03:35 -0800
Message-ID: <CAP+FsNcNtdo9amaboDDDWbMGz47DgCed6q-BS_zLB275Y_MN4w@mail.gmail.com>
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>
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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:20 UTC