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

> 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/