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

Re: Fwd: New Version Notification for draft-nottingham-http2-encryption-00.txt

From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Date: Tue, 1 Oct 2013 11:20:38 +0200
Message-ID: <8960497e3cd16c7653af5ddd82861908.squirrel@arekh.dyndns.org>
To: "Mark Nottingham" <mnot@mnot.net>
Cc: "ietf-http-wg@w3.org WG" <ietf-http-wg@w3.org>

Le Mar 1 octobre 2013 02:54, Mark Nottingham a écrit :
> Everyone,

Hi,

> This is a draft put together based upon my observations of our discussions
> about encryption and HTTP/2.0, both before and after Berlin, along with a
> fair dose of help from reviewers (thanks again!).
>
> It proposes a way to optimistically encrypt communication for http:// URIs
> that is resistant to passive attacks, but is not (yet) resistant to active
> attacks. Full details are in the draft.

A few quick remarks:

1. your headers really need a lifetime declaration, like HSTS or DNS entries

2. you're making the web client an implicit proxy. Seems proxies are
useful after all:). However you really need to generalize the concept and
make it work with any proxy layer, be it the web client, some local OS
proxy lib, or a remote proxy. In particular any proxy will want to
consolidate all accesses to a single path to maximize caching

3. therefore the draft needs to clarify how the endpoint establishes trust
with a (possibly remote) proxy and how you avoid a situation where each
network layer tries to consolidate on a different network path

4. please make it explicit what granularity of caching do you allow. Is a
cacheable element identified by the network path used? Any network path
used? If I get an object from path foo, and then site bar tells me I am
authorized to use foo to fetch some objects, can I serve them from my foo
cache? Even if foo told me nothing before?

5. mirror and cdn people will really want a syntax that permits them to
tell all proxy layers they can use indiscriminately any mirror node for a
mirrored file (so they'll declare lots of http alternatives)

6. in case all the alternatives are not 100% trusted (sad fact of life),
can you define a method which which a downstream node can request a
checksum of the expected answer from the primary path? Like "you tell me I
can fetch this 4GiB file in http-tls from evilsite.com, can you at least
give me the checksum of the payload evilsite.com will serve me?" (and
possibly a list of checksums if it is known lots of elements are usually
processed together)

7. When given a list of alternate paths, I'd really like some hint on the
preferred paths according to my original contact (even if I choose to
ignore the hints for my own reasons). Load balancer people will want this

Regards,

-- 
Nicolas Mailhot
Received on Tuesday, 1 October 2013 09:21:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC