Subject: [dane] Fwd: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

From: Stephen Farrell <[email-masked]>
Date: Thu, 01 Jan 2015 12:08:39 +0000

FYI. If you're interested in this, the discussion needs to be
on the httpbis WG list and/or on [email-masked] as HTTP/2.0 is
in IETF LC now, until Jan 14th.

Cheers,
S.

- -------- Forwarded Message --------
Subject: Comments about draft-ietf-httpbis-http2-16 : Connection reuse
Resent-Date: Thu, 01 Jan 2015 00:04:36 +0000
Resent-From: [email-masked]
Date: Thu, 01 Jan 2015 01:04 +0100
From: Aeris <[email-masked]>
To: [email-masked]

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/

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 2 Jan 2015 18:26:47 +0000

> only few days ago when I activate SPDY on a TLSA protected domain.

[ Inserting verbatim text from draft ]

>   9.1.1. Connection Reuse
>
>        Connections that are made to an origin servers, either directly or
>        through a tunnel created using the CONNECT method (Section 8.3)
>        MAY be reused for requests with multiple different URI authority
>        is authoritative (Section 10.1).  For "http" resources, this depends
>        on the host having resolved to the same IP address.
> 
>        having a certificate that is valid for the host in the URI.  An
>        origin server might offer a certificate with multiple
>        "subjectAltName" attributes, or names with wildcards, one of which
>        is valid for the authority in the URI.  For example, a certificate
>        with a "subjectAltName" of "*.example.com" might permit the use of
>        the same connection for requests to URIs starting with
>        "https://a.example.com/" and "https://b.example.com/".

The key words to consider are:

     ... a certificate that is valid for the host in the URI. ...

Were browsers to actually implement DANE TLSA as a built-in
alternative to the Web PKI, then the words above would need to be
understood in the context of DANE TLSA.

With the Web PKI, verification of server identity is split into
two parts:

    * Verify the certificate trust chain: is the content of the
      certificate trustworthy?

    * Verify the server identity: does the certificate bind the
      subject public key to the desired subject (alternative) name?

Notably, the first part is independent of the second, and once the
certificate is deemed trusted, it can be "queried" multiple times
to determine whether any of a plurality of names are associated
with the same subject public key.

With DANE TLSA, the validity of a certificate chain is not independent
of the desired subject name (essentially a transport endpoint:
port, protocol, hostname).  This is because the chain's X.509 trust
anchors are not absolute, they are potentially different for each
"authority".

Therefore, a correct implementation of connection reuse per 9.1.1
in the context of DANE would involve the client obtaining the TLSA
records for the desired (new) authority, and determining whether
the existing connection's certificate chain is valid with respect
to the TLSA records for the new authority.

So in my view 9.1.1 is fine, provided one understands the term
"valid" in the appropriate context.

For a non-HTTP example, in the Postfix MTA, the lookup key for TLS
session resumption includes a digest of the peer's (sorted) TLSA
records.  When a peer's TLSA records change, sessions validated
via the previous TLSA records are not resumed because they may no
longer be valid.

> In my opinion, this behaviour leads to 2 huge problems in term of security
> and 1 in term of usability/maintenability of HTTP/2.
> 
> 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
> 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.

The real problem here is the fact that TLSA support is an add-on
feature in browsers, that piggy-backs on the browser's connection
management, rather than an integral feature than is taken into
account as part of connection management.

So I think that the problem is less with the text of 9.1.1 and more
with the approach of doing DANE via plugins.

If DANE is to be used with browsers, it needs to be an integral
part of the implementation, not an afterthought.

-- 
	Viktor.