Subject: [httpwg/http-extensions] Consulting the DNS on expanding ORIGIN set? [origin-frame] (#330)

From: HTTP issue updates <[email-masked]>
Date: Fri, 21 Apr 2017 14:21:14 -0700

The current ORIGIN frame draft (as of the changes introduced from #212) now prohibits consulting DNS when establishing a connection's authority, as long as the TLS certificate is consulted:

> Clients MUST NOT consult DNS to establish the connection's authority for new requests.  The TLS certificate MUST stil be used to do so, as described in [RFC7540] Section 9.1.1.

As @MikeBishop pointed out during discussion in Chicago, this is the first draft that explicitly removes DNS from the loop as a factor, rather than just delegating DNS.  I did not get the sense that strong consensus exists yet for removing DNS as a factor without an additional authenticator.

Particular concerns (some of which are highlighted in the Security Considerations) include:

* When a cert (or validation behavior) is compromised, currently active MitM or DNS poisoning is required to exploit.  This new behavior enables vulnerabilities here to be exploited by simply getting a client to follow a link to a malicious server that can expand the ORIGIN set to cover the origins it wants to hijack (and which are covered by the compromised cert or compromised validation behavior).
* This has the change has potential to significantly change the operational behavior of clients.  Rather than clients always following DNS, clients may now aggregate origins onto a connection to a server that was never handed out in the DNS for that name.  This may have unintended consequences, such as allowing a non-production server sharing a cert with a production name to accidentally hijack production traffic; or otherwise giving a server operator with a cert covering a name the power to pull in client traffic for that name without this being explicitly configured through the DNS.

This change (to not follow the DNS) also becomes much more powerful (and more useful and more potentially perilous) when combined with any future pushed certificate functionality.

Some options appear to be:

1) Remove this "Clients MUST NOT consult DNS" clause.  This doesn't prohibit the expansion of ORIGIN sets, but does mean that existing DNS service discovery and DNS following behavior must still be followed.  This change could be introduced in a subsequent draft that much more explicitly worked through the security considerations and mitigations.
2) Leave the language as-is, possibly expand on security considerations, and do a more detailed security analysis (especially for how this might interact with future pushed server certs).
3) Specify additional mitigations that should replace consulting DNS, such as a pushed DNSSEC record chain terminating in the server IP, signed Alt-Service records, or similar.  Most of these would require subsequent drafts to define in-detail, along with a corresponding security analysis.

(Regardless, we may wish to clarify the subsequent bullet to make it clear that clients MAY consult the DNS to determine whether an existing connection can be reused or whether a new connection should be established.  While the existing "MUST NOT consult DNS" phrasing does not prohibit this, it is misleading on a first reading.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/330

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 25 Apr 2017 22:28:08 -0700

Erik -

I'm trying to understand your second concern WRT operational behavior of clients. The origins being added are explicitly nominated by the server; presence in the certificate is not enough to cause the connection to be used (indeed, that concern was a large part of the motivation of this draft).

Regarding the first concern -- to me, the convincing argument was that the assurances added by using DNS are incredibly weak, to the point of being of no value, especially as more people use DNS services (Open DNS, Google Public DNS, etc.), and as networks mess with them (see <https://recdnsfp.github.io> for one example).

It might make sense to add more text to Security Considerations, e.g., encouraging (or requiring) use of a higher level of assurance (CT, pinning, etc.) as an effective second factor. Would that help?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/330#issuecomment-297241822