Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

The IESG

The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document:
- 'Hypertext Transfer Protocol version 2'
  <draft-ietf-httpbis-http2-16.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[hidden email] mailing lists by 2015-01-14. Exceptionally, comments may be
sent to [hidden email] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This specification describes an optimized expression of the semantics
   of the Hypertext Transfer Protocol (HTTP).  HTTP/2 enables a more
   efficient use of network resources and a reduced perception of
   latency by introducing header field compression and allowing multiple
   concurrent messages on the same connection.  It also introduces
   unsolicited push of representations from servers to clients.

   This specification is an alternative to, but does not obsolete, the
   HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/ballot/


The following IPR Declarations may be related to this I-D:

   http://datatracker.ietf.org/ipr/1737/
   http://datatracker.ietf.org/ipr/2122/
   http://datatracker.ietf.org/ipr/1692/
   http://datatracker.ietf.org/ipr/2506/




Reply | Threaded
Open this post in threaded view
|

Comments about draft-ietf-httpbis-http2-16 : Connection reuse

Aeris
Sorry to speak about this only now, but I notice the following problem only
few days ago when I activate SPDY on a TLSA protected domain.

§9.1.1 about connection reusage on HTTP/2 say

        Connections that are made to an origin servers MAY
        be reused for requests with multiple different URI authority
        components.  A connection can be reused as long as the origin server
        is authoritative (Section 10.1).
        For "https" resources, connection reuse additionally depends on
        having a certificate that is valid for the host in the URI.

In my opinion, this behaviour leads to 2 huge problems in term of security and
1 in term of usability/maintenability of HTTP/2.

1- X.509 certificate is not trustable by itself and need real content for
validation

There are some extensions completing the certificate validation, as DANE/TLSA
(RFC6698) or websec-key-pinning (currently IETF draft).
For both, guessing A certificate validity for B domain can’t be done just with
the A certificate fetched from the A domain.
In case of TLSA, you need the real B certificate to check if this is the one
declared in the DNS. For PKP, you need the real B content to check the
HTTP header.

So current specification of HTTP/2 can break TLSA and PKP, by badly guessing
that A certificate can be reuse on B domain, instead of using the real B
certificate.

This is actually the case with current SPDY implementation (Firefox or
Chrome). Having a A content including B content on the same IP with a A
certificate valid for B domain but not for B TLSA, SPDY reuse the A channel for
B content, and Firefox/Chrome display warning or block the content because
TLSA error.

2- TLS is not only X.509 certificate. It’s also a lot of other things.

The current HTTP/2 specification restrict TLS to only the certificate it use.
If A domain use RSA 1024 bits key but B domain use ECC 571 bits key, reusing
the A channel for B content reduce a lot the security compared to the case
with 2 differents channels. Same problem if you enable different ciphers (saying
NULL cipher for static content and AES256-GCM for critical content), or
perfect forward secrecy ciphers for one and not for the other.
Can be the case if you use weak but fast config for your static content and
strong but slow one for the critical content.
Same trouble in case of some downgrade attack on static content.
If HTTP/2 use the weakest channel for both, there is a big security problem.

421 error code is not usable in this case to reject a channel reusage, because
the required checks can’t be done application-side (TLS client context and
server config not available) and even server-side, is extremly complicated (if
even doable)…

3- Channel reuse leads to « systemd-for-the-web » if done cleanly.

Given the 2 points above, doing channel reuse cleanly require for HTTP/2 to
become a systemd-like monster.
« cleanly » means « no difference compare to 2 channels usage », so take into
account real B TLS context : certificat, key type and size, TLSA entry and
corresponding DNSSec validation, TLS version, selected cipher, PKP HTTP
header, key pinning (hardcoded in browser, pinned by user, pinned by plugin
(HTTPS Everywhere / Certificate Patrol)) and virtually any others things a
overall TLS ecosystem can have to manage, including not built-in or
custom/non-standard.
TLSA is a good example for this point because not browser built-in but
available through plugin, PKP because not currently a standard, and
HTTPSEverywhere/CertificatePatrol because interfering with browser built-in
config.

To choose if you can reuse or not a A channel for a B domain, HTTP/2 must be
aware of many things, perhaps neither built-in nor even standardized.
Changing or adding a new step of verification on TLS will require rebuild of
HTTP/2 client, hooks on plugins for not-built-in features, plugins need to be
notified if HTTP/2 is in use or not…
Everything will be aware of HTTP/2 and HTTP/2 will be aware of everything. New
SystemD on the road…

And even if done cleanly, channel reusing choice will be more expensive than
just open a new channel (and worse, require a new channel in all cases for
protocol/cipher/key/certificate/PKP/TLSA verification…).

So, HTTP/2 must reject connection reusage, and respect real wills of system
administrator if they declare 2 differents TLS contexts for 2 domains, but
behind the same IP. This kind of config decision must no be done or worse
changed client-side.
On a post-Snowden era, don’t sacrifice security for speed… :'(

Regards (and happy new year :)),
--
Aeris

Protect your privacy, encrypt your communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

Ryan Hamilton
On Wed, Dec 31, 2014 at 4:04 PM, Aeris <[hidden email]> wrote:
Sorry to speak about this only now, but I notice the following problem only
few days ago when I activate SPDY on a TLSA protected domain.

§9.1.1 about connection reusage on HTTP/2 say

        Connections that are made to an origin servers MAY
        be reused for requests with multiple different URI authority
        components.  A connection can be reused as long as the origin server
        is authoritative (Section 10.1).
        For "https" resources, connection reuse additionally depends on
        having a certificate that is valid for the host in the URI.

In my opinion, this behaviour leads to 2 huge problems in term of security and
1 in term of usability/maintenability of HTTP/2.

1- X.509 certificate is not trustable by itself and need real content for
validation

There are some extensions completing the certificate validation, as DANE/TLSA
(RFC6698) or websec-key-pinning (currently IETF draft).
For both, guessing A certificate validity for B domain can’t be done just with
the A certificate fetched from the A domain.
In case of TLSA, you need the real B certificate to check if this is the one
declared in the DNS. For PKP, you need the real B content to check the
HTTP header.

So current specification of HTTP/2 can break TLSA and PKP, by badly guessing
that A certificate can be reuse on B domain, instead of using the real B
certificate.

This is actually the case with current SPDY implementation (Firefox or
Chrome). Having a A content including B content on the same IP with a A
certificate valid for B domain but not for B TLSA, SPDY reuse the A channel for
B content, and Firefox/Chrome display warning or block the content because
TLSA error.

​Chrome does not support TLSA so I'm not sure how the current Chrome SPDY implementation could be breaking TLSA.
 
2- TLS is not only X.509 certificate. It’s also a lot of other things.

The current HTTP/2 specification restrict TLS to only the certificate it use.
If A domain use RSA 1024 bits key but B domain use ECC 571 bits key, reusing
the A channel for B content reduce a lot the security compared to the case
with 2 differents channels. Same problem if you enable different ciphers (saying
NULL cipher for static content and AES256-GCM for critical content), or
perfect forward secrecy ciphers for one and not for the other.
Can be the case if you use weak but fast config for your static content and
strong but slow one for the critical content.
Same trouble in case of some downgrade attack on static content.
If HTTP/2 use the weakest channel for both, there is a big security problem.

421 error code is not usable in this case to reject a channel reusage, because
the required checks can’t be done application-side (TLS client context and
server config not available) and even server-side, is extremly complicated (if
even doable)…

3- Channel reuse leads to « systemd-for-the-web » if done cleanly.

Given the 2 points above, doing channel reuse cleanly require for HTTP/2 to
become a systemd-like monster.
« cleanly » means « no difference compare to 2 channels usage », so take into
account real B TLS context : certificat, key type and size, TLSA entry and
corresponding DNSSec validation, TLS version, selected cipher, PKP HTTP
header, key pinning (hardcoded in browser, pinned by user, pinned by plugin
(HTTPS Everywhere / Certificate Patrol)) and virtually any others things a
overall TLS ecosystem can have to manage, including not built-in or
custom/non-standard.
TLSA is a good example for this point because not browser built-in but
available through plugin, PKP because not currently a standard, and
HTTPSEverywhere/CertificatePatrol because interfering with browser built-in
config.

To choose if you can reuse or not a A channel for a B domain, HTTP/2 must be
aware of many things, perhaps neither built-in nor even standardized.
Changing or adding a new step of verification on TLS will require rebuild of
HTTP/2 client, hooks on plugins for not-built-in features, plugins need to be
notified if HTTP/2 is in use or not…
Everything will be aware of HTTP/2 and HTTP/2 will be aware of everything. New
SystemD on the road…

And even if done cleanly, channel reusing choice will be more expensive than
just open a new channel (and worse, require a new channel in all cases for
protocol/cipher/key/certificate/PKP/TLSA verification…).

So, HTTP/2 must reject connection reusage, and respect real wills of system
administrator if they declare 2 differents TLS contexts for 2 domains, but
behind the same IP. This kind of config decision must no be done or worse
changed client-side.
On a post-Snowden era, don’t sacrifice security for speed… :'(

Regards (and happy new year :)),
--
Aeris

Protect your privacy, encrypt your communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

Reply | Threaded
Open this post in threaded view
|

Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

Yoav Nir-3
In reply to this post by The IESG
Not substantive, just an administrative comment.

Only two weeks?  Beginning on December 31st.  I would think that the most popular protocol on the Internet would deserve a longer last call period.

Yoav


Reply | Threaded
Open this post in threaded view
|

Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

Aeris
In reply to this post by Ryan Hamilton
> ​Chrome does not support TLSA so I'm not sure how the current Chrome SPDY
> implementation could be breaking TLSA.

As for Firefox, TLSA support is currently provided by a plugin on Chrome :
        https://www.dnssec-validator.cz/
        https://chrome.google.com/webstore/detail/tlsa-validator/gmgeefghnadlmkpbjfamblomkoknhjga

Regards,
--
Aeris

Protect your privacy, encrypt your communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

Patrick McManus-3
In reply to this post by Aeris
Hi Aeris,

As you've discussed with Ryan and Adam (on spdy-dev) I don't really think there is a problem with the specification here - it requires that the connection be considered authoritative for the request.

Neither Firefox nor Chrome support TLSA so the h2 stacks don't consider it in the authoritative determination. In each case an extension can provide some of that functionality - but as in this case it appears that the extension, and likely the extension framework too, aren't quite up to date. I'm happy to work with you in the mozilla bug tracker or network mailing lists to close the gap in the best way for your extension.

-Patrick


On Thu, Jan 1, 2015 at 7:53 AM, Aeris <[hidden email]> wrote:
> ​Chrome does not support TLSA so I'm not sure how the current Chrome SPDY
> implementation could be breaking TLSA.

As for Firefox, TLSA support is currently provided by a plugin on Chrome :
        https://www.dnssec-validator.cz/
        https://chrome.google.com/webstore/detail/tlsa-validator/gmgeefghnadlmkpbjfamblomkoknhjga

Regards,
--
Aeris

Protect your privacy, encrypt your communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

Reply | Threaded
Open this post in threaded view
|

Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

Aeris
> As you've discussed with Ryan and Adam (on spdy-dev) I don't really think
> there is a problem with the specification here - it requires that the
> connection be considered authoritative for the request.

On the current spec, the authority is check only (§9.1.1 and §10.1) by the
certificate content (subject/alt-subject and RFC2818). Seems not talking about
TLSA, PKP or everything else.
Or the spec just list some examples of what « authoritative » means, and in
this case, maybe it will better to clarify this, and/or be more precise on the
definition, currently very fuzzy.
Actually, the HT2 behaviour about connection reusage is totally implementation
dependant, with possibly the 2 extrem behaviour : very weak implem checking
only sub/alt-sub and IP, very strong implem always reopening, with middle
implem checking for TLSA/PKP/DNSSec/whatever combination…

> but as in this case it appears that the
> extension, and likely the extension framework too, aren't quite up to date.

This is one of my fear for HTTP/2 : must re-dev all extension or HT2 stack
just to handle new TLS case… :'(

> I'm happy to work with you in the mozilla bug tracker or network mailing
> lists to close the gap in the best way for your extension.

With TLSA or PKP or anything, the fix is very easy : just don’t reuse
connection :P Because it’s slower/require new channel.

- Verifying for TLSA need DNSSec validation of the TLSA DNS entry and the real
certificate if such entry. If you have already do all those check, you
*already* need a new channel open, to fetch the certificate.
- Verifying for PKP need the real content. Same, need a new channel too if any
PKP header to fetch the real certificate. And using the first channel to check
for PKP header is possibly insecure if PKP exist and don’t match the cert.
- Verifying for key pinning is not possible without real cert. New channel
needed too.
- Even if any TLS extension, in *ALL* case, verifying for protocol, ciphers,
key and certificate to verify this is *exactly* (at least key/cert, better to
check proto/cipher too) the same as the primary channel require a new channel.
For key and cert, if domain B declare different key/cert than A, A is *not*
authoritative for B (not distinguishable to MITM attack if it’s the case).

So in all cases, checking for connection reuse is more expensive/less
secure/require reopen  than just reopen a channel.

Regards,
--
Aeris

Protégez votre vie privée, chiffrez vos communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

Ilari Liusvaara
On Fri, Jan 02, 2015 at 03:25:42PM +0100, Aeris wrote:
> > I'm happy to work with you in the mozilla bug tracker or network mailing
> > lists to close the gap in the best way for your extension.
>
> With TLSA or PKP or anything, the fix is very easy : just don’t reuse
> connection :P Because it’s slower/require new channel.
>
> - Verifying for TLSA need DNSSec validation of the TLSA DNS entry and the real
> certificate if such entry. If you have already do all those check, you
> *already* need a new channel open, to fetch the certificate.

Err, why isn't just validating the current certificate against fetched TLSA
records and then opening a new channel if that fails (DNS caches should be hot)
sufficient?

> - Verifying for PKP need the real content. Same, need a new channel too if any
> PKP header to fetch the real certificate. And using the first channel to check
> for PKP header is possibly insecure if PKP exist and don’t match the cert.
> - Verifying for key pinning is not possible without real cert. New channel
> needed too.

HPKP is nastier, especially in the non-pinned case.


Another interaction between connection reuse and HPKP: Potentially having to
deal with server trying to pin the reused connections (foo.example pinning
bar.example, when foo.example and bar.example share a connection).


-Ilari

Reply | Threaded
Open this post in threaded view
|

Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

Aeris
> Err, why isn't just validating the current certificate against fetched TLSA
> records and then opening a new channel if that fails (DNS caches should be
> hot) sufficient?

Oops. Yes, will be good this way.

> HPKP is nastier, especially in the non-pinned case.

Yep, it’s the worst case. Need new channel in all case, even if not HPKP at
the end.
Same for proto/ciphers check.

> Another interaction between connection reuse and HPKP: Potentially having to
> deal with server trying to pin the reused connections (foo.example pinning
> bar.example, when foo.example and bar.example share a connection).

Could be tricky…

It shows than connection reusage is not trivial at all, and suffer of very deep
implication on TLS ecosystem and overall security.
Even if fully specified, the code necessary to handle all cases correctly will
just be a bunch of spaghetti and depends of hundred of parameters (some
totally external to HTTP2 stack or to browser built-in features), with no
insurance of better perf or (at least) same security compare to no reusage at
all.

--
Aeris

Protégez votre vie privée, chiffrez vos communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

Ryan Hamilton
The requirement to reuse a TLS connection is that the cert is "valid". This does not simply mean that the cert contains a matching Subject-Alt-Name, it means that all the validity checks are satisfied. For a User-Agent that supports TLSA it must check TLSA (Chrome does not support TLSA so I'm not familiar with what they are). In the case of Public Key Pinning, the must check that the pins are satisfied. Chrome does support pinning and so if you look at the code which checks to see if an existing connection can be used for a new hostname, you'll see that it explicitly verifies the pins:


I think that the requirement in 9.1.1 is sufficient.

On Fri, Jan 2, 2015 at 7:21 AM, Aeris <[hidden email]> wrote:
> Err, why isn't just validating the current certificate against fetched TLSA
> records and then opening a new channel if that fails (DNS caches should be
> hot) sufficient?

Oops. Yes, will be good this way.

> HPKP is nastier, especially in the non-pinned case.

Yep, it’s the worst case. Need new channel in all case, even if not HPKP at
the end.
Same for proto/ciphers check.

> Another interaction between connection reuse and HPKP: Potentially having to
> deal with server trying to pin the reused connections (foo.example pinning
> bar.example, when foo.example and bar.example share a connection).

Could be tricky…

It shows than connection reusage is not trivial at all, and suffer of very deep
implication on TLS ecosystem and overall security.
Even if fully specified, the code necessary to handle all cases correctly will
just be a bunch of spaghetti and depends of hundred of parameters (some
totally external to HTTP2 stack or to browser built-in features), with no
insurance of better perf or (at least) same security compare to no reusage at
all.

--
Aeris

Protégez votre vie privée, chiffrez vos communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

Reply | Threaded
Open this post in threaded view
|

Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

Aeris
> The requirement to reuse a TLS connection is that the cert is "valid". This
> does not simply mean that the cert contains a matching Subject-Alt-Name, it
> means that *all* the validity checks are satisfied.

List *all* those validity checks is impossible, because depends of tons of
parameters, RFCed or not, built-in or not, custom or not. This is not just a
case of X.509, TLSA or PKP.
For example, I (and I hope everybody) consider invalid the fact of using a A
certificate (even if totally X.509 valid) for B domain in case of B domain
would use B cert if no reusage. With or without PKP/TLSA/whatever. Cause it’s
the definition of what is MITM TLS attack.
Same if weak protocol or cipher are reuse instead of new strong ones. Cause
it’s the same behaviour as downgrade attack.

Either IETF allow channel reusage and in this case, must ensure client
behaviour with strong definition of when reuse and when not reuse, to be able
to judge if this is at least as secure as TLS without reusage and know very
well what new TLS attack will be possible. Or more simply to allow an admin
sys to understantd very well what TLS strength he will have on each content
(right now taking into account not only the content but also the origin, and
worse actually, the user-agent the user will use…) he serv.
Or IETF must reject channel reusage, for security purpose.

And even with strong definition, all the chance we have to consider HTTP2 as a
not secure protocol because reduce overall security or bypass some TLS related
principle. Cause such strong definition is in fact impossible to find without
reducing TLS scope/extensibility.
The only strong, testable, not implem dependant, extendable definition is
« reuse the channel if and only if there is no difference with no reusage ».
And means impossible to achieve without a real opening to compare current
parameters with the next ones.

> https://code.google.com/p/chromium/codesearch#chromium/src/net/spdy/spdy_ses
> sion.cc&sq=package:chromium&l=568&rcl=1420152226

This is exactly what I say : this « CanPool » method will become just a
monster with a bunch of spaghetti code, addressing tons of use case, needing
hooks for browser plugins… And currently with not the same behaviour for all
user-agent because no precise definition of what « valid » means.

Regards,
--
Aeris

Protégez votre vie privée, chiffrez vos communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

Martin Thomson-3
On 2 January 2015 at 10:10, Aeris <[hidden email]> wrote:
> List *all* those validity checks is impossible, because depends of tons of
> parameters, RFCed or not, built-in or not, custom or not. This is not just a
> case of X.509, TLSA or PKP.

Ultimately, clients will determine what requirements need to be met in
order to consider an origin authenticated.  There are RFCs to guide
that process, and those aim to establish a baseline (2818 or 6125 +
5280 perhaps being that baseline) but the choice of which RFCs ensures
that there are - as you say - a virtually infinite number of choices.

That is why the draft states that the server needs to be considered
authoritative, and then relies on the definition of that from RFC
7230.

The HTTP/2 draft simply states the conditions under which connections
can be reused.  This is different from HTTP/1.1, which is probably the
source of your angst.

Of course, we have also defined several ways to avoid this happening
if that doesn't suit you.  The 421 status code.  The HTTP_1_1_REQUIRED
error code.

Reply | Threaded
Open this post in threaded view
|

Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

Aeris
> Of course, we have also defined several ways to avoid this happening
> if that doesn't suit you.  The 421 status code.  The HTTP_1_1_REQUIRED
> error code.

Yep. Or you can disable all HTTP/2 too.
Cases I mention can’t be detected application-side or with very difficulty
server-side. Simpler/more secure to disable all the HT2 stack.

But HTTP/2 is good for speed and the difference is very noticable.
Too bad the overall security will be such there is no way to use it on a post-
snowden era and/or with critical content…

--
Aeris

Protégez votre vie privée, chiffrez vos communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

Martin Thomson-3
On 2 January 2015 at 11:06, Aeris <[hidden email]> wrote:
> Too bad the overall security will be such there is no way to use it on a post-
> snowden era and/or with critical content…

For the record, I disagree with that assessment.  There are strict
security improvements in HTTP/2.  Connection reuse can also provide
non-trivial privacy advantages.

As others have stated, the issues you describe are rooted in
implementation concerns: TLSA validation not being integral, not being
able to assess the security properties of a request, etc...  These
don't require standardization to fix.

Reply | Threaded
Open this post in threaded view
|

Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

Aeris
> For the record, I disagree with that assessment.  There are strict
> security improvements in HTTP/2.

Yep, requiring TLS1.2+ and strong ciphers is cool :)

About this, why requiring P256 elliptic curve [FIPS186] support, which is
*not* safe (see http://safecurves.cr.yp.to/) and not the safe Curve25519 curve
for example ?

> Connection reuse can also provide
> non-trivial privacy advantages.

If it means same behaviour as MITM or downgrade attack…
And currently, I don’t see any of those non-trivial advantages. Do you have
some example ?

What about TLS client auth with connection reusage ?
If dom A don’t require TLS client auth but B does, how the connection reusage
will handle this case ? Without TLS renegociation for domain B, the HT2 user-
agent won’t be able to see there is a client certificate to send, no ?

Regards,
--
Aeris

Protégez votre vie privée, chiffrez vos communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

Ryan Hamilton
To back up for a second, remember that a server administrator can prevent connection reuse at will by either:

1) Changing the hostname -> IP mapping so that hosts which should not share connections are on different address
2) Serving certificates which are not valid for hosts which should not reuse connections to the current host

As such, any server administrator who is concerned about connection reuse can simply configure their servers to prevent it from happening.

On Sat, Jan 3, 2015 at 2:22 AM, Aeris <[hidden email]> wrote:
> For the record, I disagree with that assessment.  There are strict
> security improvements in HTTP/2.

Yep, requiring TLS1.2+ and strong ciphers is cool :)

About this, why requiring P256 elliptic curve [FIPS186] support, which is
*not* safe (see http://safecurves.cr.yp.to/) and not the safe Curve25519 curve
for example ?

> Connection reuse can also provide
> non-trivial privacy advantages.

If it means same behaviour as MITM or downgrade attack…

​If you can exploit Chrome's connection reuse behavior to lead to a MITM attack, that would be a critical security bug which we would jump on immediately. Please let me know if you are able to do so.
 
And currently, I don’t see any of those non-trivial advantages. Do you have
some example ?

What about TLS client auth with connection reusage ?
If dom A don’t require TLS client auth but B does, how the connection reusage
will handle this case ? Without TLS renegociation for domain B, the HT2 user-
agent won’t be able to see there is a client certificate to send, no ?

​In Chrome, we prevent connection reuse to hosts which request client certificates. HTTP/2 prohibits TLS renegotiation in section 9.2.1.

Cheers,

Ryan
Reply | Threaded
Open this post in threaded view
|

Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

Aeris
> To back up for a second, remember that a server administrator can prevent
> connection reuse at will by either:
>
> 1) Changing the hostname -> IP mapping so that hosts which should not share
> connections are on different address

Not usable on IPv4. There is no more available IPv4, or very expensive.
Currently can’t have 50 IPv4, one for each of my sub-domain…

> 2) Serving certificates which are not valid for hosts which should not
> reuse connections to the current host

Not available for all CA.
For example StartCom add *always* DNS:domain.com on issued CA, so I can’t
generate a certificate only valid for A.domain.com and not for domain.com on
this CA.
Or in my case, have 2 wildcard cert issued by different CA for each domain.

> As such, any server administrator who is concerned about connection reuse
> can simply configure their servers to prevent it from happening.

Not at all. I’m a server administrator. I can’t be able (or can’t afford) for 1
different certificat for each of my 50 sub-domains…
Do you consider only big company with many money and professional admin sys
exist on the Internet ? Or worst, only them can have security or choose the
TLS behaviour they want with HTTP/2 ?

> ​If you can exploit Chrome's connection reuse behavior to lead to a MITM
> attack, that would be a critical security bug which we would jump on
> immediately. Please let me know if you are able to do so.

I don’t say this. I only say HTTP/2 behaviour *can’t be distinguished* from
real MITM or downgrade attack.
From an IDS point of view for example, you fetch a content with a certificat or
cipher different of what is expected, exactly the same way current real HTTP/1
attacks do.

But on our way, I sense connection reuse can ease MITM or downgrade attack.
You « just » have to poison the DNS to match the target IP and send a A
content with weak TLS parameters and request targeted content B from A to
force TLS parameters to what you want for the B content fetching.

> ​In Chrome, we prevent connection reuse to hosts which request client
> certificates. HTTP/2 prohibits TLS renegotiation in section 9.2.1.

When I say « renegociation », I mean no channel reusage.
If A domain doesn’t require TLS auth but B domain yes, how will you detect the
need of auth with channel reuse ? Because when the channel will be reused to
fetch B content, no TLS negociation will be done and so not able to see the
auth request, am I wrong ? From B to A, there is no problem, but from A to B,
there is.

Regards,
--
Aeris

Protégez votre vie privée, chiffrez vos communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

Martin Thomson-3
In reply to this post by Ryan Hamilton
On 4 January 2015 at 10:59, Ryan Hamilton <[hidden email]> wrote:
> 1) Changing the hostname -> IP mapping so that hosts which should not share
> connections are on different address
> 2) Serving certificates which are not valid for hosts which should not reuse
> connections to the current host

Or use the new 421 status code.

Reply | Threaded
Open this post in threaded view
|

Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

Ryan Hamilton
In reply to this post by Aeris
On Sun, Jan 4, 2015 at 11:29 AM, Aeris <[hidden email]> wrote:
But on our way, I sense connection reuse can ease MITM or downgrade attack.
You « just » have to poison the DNS to match the target IP and send a A
content with weak TLS parameters and request targeted content B from A to
force TLS parameters to what you want for the B content fetching.

In your example, host A has a valid certificate for host B, but is configured to have weaker security configuration than host B. Is that right? If so, then your DNS poisoning attack works just fine with HTTP/1.1, so HTTP/2 does not make it worse. 

Reply | Threaded
Open this post in threaded view
|

Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

Stefan Eissing
In reply to this post by The IESG
Comments/Questions on
http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2
"Hypertext Transfer Protocol version 2 draft-ietf-httpbis-http2-16"

Overall, for someone with good understanding of HTTP/1.x, this specification is good to read and well structured. The stream states ascii art is informative, though it on first glance implies PP to be on the wrong stream id. Maybe the legend could give a hint that PP works different from all other frames.

I have no comments regarding the language (not a native speaker), not did I check the dots and crosses. I tried to read it with my background in implementing HTTP as someone wanting to code it. Therefore most questions/issues below are concerned with things where the spec could be a bit more specific. According to my taste, that is. Things can be overspecified as well...

With that said, and with respect to all the work done, my comments/questions:

1. "hop-by-hop" vs. "end-to-end" references
At two locations in the spec (5.2.1 Flow Control, 6.9 WINDOW_UPDATE) the distinction between "end-to-end" vs. "hop-by-hop" is being made without explaining how h2/h2c would work with an intermediate. Maybe that is left undefined intentionally. But if a HTTP2 intermediate is a forward or reverse (CDN) proxy, I think it must always
- renumber stream identifiers
- uncompress HEADERs from the upstream and recompress for downstream
- consider carefully the mapping of stream and connection errors
So in what way is it meaningful to see HTTP2, the thing carrying HTTP requests/responses, as more than hop-by-hop?

2. PUSH_PROMISE and header completeness
How are cache sensitive headers like "Authorization" handled in PUSH_PROMISE request headers? If simply left out, the client could store pushed resources in a cache where they do not belong. Should servers use extra Cache-Control directives in such pushed responses?

Related: how is the role of the ACCEPT-* request headers? Should a client reject PUSH_PROMISE with request headers that does not match its own ACCEPT-* preferences? What if it uses ACCEPT-* and the PUSH_PROMISE is lacking those? Or the other way around?

3. Clarification on server-initiated push?
In discussions with colleagues some had the notion that HTTP2 would allow server initiated "requests". My reading of the draft is that this is not really the case. Server pushes are only defined for streams opened by the client.
- Is this the correct reading of the spec?
- If yes, has HTTP2 any advise how to best do long polling or what is the recommended alternative?

4. SETTINGS_MAX_HEADER_LIST_SIZE as advisory
It seems undefined what a client (library) should do with it. Will this not give rise to interop problems if one client respects it and fails requests immediately while another does no checks and sends them anyway? MUST a peer that announces a limit always reply with 431 to requests that exceed it?

5. Graceful connection shutdown
GOAWAY seems to serve two purposes:
- inform peer of highest process stream before closing, so that retries can be done safely
- initiate a graceful connection shutdown
What is expected of a client upon receiving a GOAWAY with Last-Stream-Id 2^31-1, e.g. graceful shutdown?
- it must no longer create new streams
- it should expect a future GOAWAY with a lower stream id
- it can expect responses on half-closed streams?
- it should RST all incoming PUSH_PROMISEs?
(And of course, a connection can always simply break at any time...)

6. Optimisation: Default SETTINGS values same for clients and servers?
I would think that clients have different preferences for defaults than servers. Especially for INITIAL_WINDOW_SIZE. Since differences to defaults need to be send for every HTTP2 connections, are the current values good?
Related: if a peer sends/receives an empty SETTINGS at connection start, do acknowledgements serve any purpose?

7. Opinion: Chapter 9.1 Limitation to single connection
Have we not been here before? In the past, such SHOULD NOTs have not been very helpful. (Most likely already discussed heavily on the list...no strong feelings about this. It will be ignored anyway if not proving useful.)

Best Regards,

 Stefan

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782




123