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

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