> From: Aeris <aeris@xxxxxxxxxx> > To: ietf-http-wg@xxxxxx > Date: Thu, 01 Jan 2015 01:04 +0100 > > 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. [ 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 > components. A connection can be reused as long as the origin server > is authoritative (Section 10.1). For "http" resources, this depends > on the host having resolved to the same IP address. > > For "https" resources, connection reuse additionally depends on > 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. > > 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. 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.