Consulting the DNS on expanding ORIGIN set?

[enygren]

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. I'm not convinced that the having to follow the DNS name is "onerous" enough to justify the security impact.

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.)

[mnot]

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?

[PiotrSikora]

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).

I believe that limiting origin-set and connection reuse was the original motivation for this draft, however, it seems that possible use cases changed a bit because of draft-bishop-httpbis-http2-additional-certs, which together with this draft, makes it possible to expand the origin-set and effectively hijack traffic for all domains that server has valid SSL certificates for.

Even ignoring the compromised server scenario, there are at least a few operational issues with bypassing DNS:

1. Many medium to large companies use multiple CDN providers and steer traffic using DNS. They use either custom GeoDNS solutions or services like Cedexis to load balance traffic across multiple CDNs, or simply use one of the CDNs as the primary and rest as active backups. All those CDNs have valid SSL certificates, so neither CT nor certificate pinning would help. Similarly, some websites migrate traffic to DDoS protection services only during attacks, but those services are configured and have valid SSL certificates at all times. Basically, configured != active.

2. Servers with wildcard certificates can takeover all traffic for the domain, even if some subdomains would never be routed to a particular server. To give an extreme example, let's say that www.bank.com, promotions.bank.com, etc. are served by the CDN, but secure.bank.com is handled by the bank's own infrastructure. There is nothing stopping the CDN with valid certificate for *.bank.com from hijacking the traffic for secure.bank.com, and while certificate pinning would prevent traffic for secure.bank.com from reaching the CDN, it would effectively result in DoS and pretty bad end-user experience.

One solution that came up in discussions with @grittygrease and @enygren, was to include signed DNSSEC response in the ORIGIN frame, to prove that the traffic should be routed to this particular server. This obviously solves only part of the problem, since it doesn't mean that traffic from this particular client would be routed to that server, but it's much better than servers going completely wild.

[mnot]

@PiotrSikora - thanks for the input.

WRT global load balancing / CDN balancing -- one of the things that has been discussed is a bit to tell the client whether or not to check DNS; that would allow them to use this, I think.

WRT wildcards -- ORIGIN doesn't currently support wildcarding.

[enygren]

Even without supporting wildcard ORIGINs, @PiotrSikora has a valid point that if a server has a wildcard cert it can pull in any hostnames that it wants to.

Telling a client whether or not to check DNS certainly helps for some of these cases (ie, it helps avoid a few operational snafus) but doesn't help against malicious use-cases.

My inclination is still to pull this draft back to the original "limiting origin set and connection reuse" scenario but while leaving placeholders for a subsequent draft that would cover expanding the origin set (ie, with using additional-certs and whatever other mitigators are deemed appropriate). Otherwise this draft changes the operational model of the web much more substantially than people may realize at first glance. Any operational shift this significant likely wants to be a first-class discussion rather than being a side-effect of a draft that initially had a much more constrained scope.

[PiotrSikora]

wrt "check DNS" flag - it's still the server (i.e. CDN) that's making this recommendation to the client, right? If so, then I don't think it fixes anything, since CDNs can omit this flag and prevent clients from consulting DNS, justifying this with "we're improving the performance" excuse.

[martinthomson]

Let me try to summarize the concern in a different way: having a certificate for a name is not always sufficient basis for that server to be chosen and used.

All these cases reduce down to the same complaint: the client might be talking to an instance that has a certificate for N>1 names and the intent is that only a subset of those names is used. This might be due to geographical distribution of nodes, contractual arrangements (the CDN is charging more than their competitor today, so they're on backup duty), or any other operational concern.

The problem with all of these is that there is no way to communicate this intent to the client that doesn't ultimately chain back to the certificate. A certificate that the server instance has. Relying on the DNS is a fig leaf. As @PiotrSikora says, even DNSSEC fails because you can't be sure that this is the RRset that would be sent to this particular client.

It looks like what you are looking for is a better means of control over your server instances. The reliance on DNS is a poor substitute for a genuine signal.

Crazy suggestion, would a certificate extension that enabled this functionality make you happier? As long as the CDN never received a certificate with the extension, it couldn't make these sorts of assertions. I'm not saying that I think that's a good idea, but I want to explore the boundaries of your problem better.

[PiotrSikora]

@martinthomson I originally wanted to dismiss this idea (since CDNs could mis-issue certs with the extension anyway, so it doesn't add 2nd factor). However, we chatted a bit about it with @grittygrease yesterday, and we came to conclusion that opt-in certificate extension, along with CT requirement (so that it would be obvious that CDN requested certificate with such extension, even when domain owner didn't opt-in for it) seems like an acceptable solution.

[mnot]

Please review proposed changes in latest commit.

[MikeBishop]

I see the associated suggestions in the Security Considerations, but I thought the discussion on the list led toward putting a "MAY skip, but SHOULD use something else instead"? Even if the concrete suggestions of what the "something else" could be still live in Security Considerations....

[mnot]

I don't see how I can put "SHOULD use something else" in an RFC with a straight face. If someone can suggest appropriate wording here, I'd be ever so grateful.

[MikeBishop]

On the thread, "Clients opting not to check DNS SHOULD employ some alternative means to increase confidence that the certificate is legitimate, such as Certificate Transparency or revocation checks" got +1s from Ryan and @enygren. Since you have a mention elsewhere, you could adapt that to "such as those discussed in Section 4" reasonably enough.

[mnot]

Hmm. I suspect a requirement that's so vague won't get through IESG, but I guess we can try it.

[mcmanus]

how about a non normative should.. that way you're describing the tradeoffs in a way that sheds some light on the situation (with examples) but not doing a normative "do something unspecific"

On Mon, Jul 31, 2017 at 7:52 PM, Mark Nottingham notifications@github.com wrote:

Hmm. I suspect a requirement that's so vague won't get through IESG, but I guess we can try it.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/httpwg/http-extensions/issues/330#issuecomment-319228529, or mute the thread https://github.com/notifications/unsubscribe-auth/AAP5syDDXgoZVomlOAAPMBOMGirt8jraks5sTmjBgaJpZM4NEzUM .

[MikeBishop]

Seems ripe for an RFC6919 MAY WISH TO or SHOULD CONSIDER.

[mnot]

/me is very tempted to get a 6919 ref in there

[mnot]

I think we're almost there; see latest revision.

[enygren]

On the commits:

• From discussions, I think the CT and OCSP responses should be an "and" not an "or". They both address different threats and both are needed. CT helps reduce some of the risks around mis-issuance while OCSP allows any mis-issuance to be addressed in a reasonable period of time.

• I think for "Additionally, clients MAY avoid consulting DNS to establish the connection's authority for new requests." we may want append "when employing adequate additional mitigations to security and operational risks."

Is there a precedence or convention for having the "adequate additional mitigations" be defined in a future RFC?

My general concern continues to be that we're changing the security profile of a complex system in ways that crosses protocol layers. Even if solving some of those problems requires a much more in-depth risk analysis, people looking to exploit these changes won't be constrained by a "but that violates layering to specify more!".

Note that as discussed above, there is also a class of issues which might require a not-as-yet-defined certificate extension to make some of the people here fully comfortable. (Which would possibly be in-addition to the OCSP and CT requirements.)

[mnot]

From discussions, I think the CT and OCSP responses should be an "and" not an "or". They both address different threats and both are needed. CT helps reduce some of the risks around mis-issuance while OCSP allows any mis-issuance to be addressed in a reasonable period of time.

My sense of the discussion was that we flirted with "and" but settled on "or". Happy to be corrected there; @mcmanus?

I think for "Additionally, clients MAY avoid consulting DNS to establish the connection's authority for new requests." we may want append "when employing adequate additional mitigations to security and operational risks."

Seems reasonable to me.

Is there a precedence or convention for having the "adequate additional mitigations" be defined in a future RFC?

That's possible, but as noted there's been a historical reluctance to define the exact requirements in RFCs. Remember that Web browsing is just one use of HTTP.

[enygren]

I think we also want to change the intro sentence for consistency:

This specification relaxes the requirement to check DNS when the ORIGIN frame is in use. to: This specification relaxes the requirement to check DNS when the ORIGIN frame is in use in-combination with additional security mitigations.

[martinthomson]

The "or" seems appropriate here, given that these are examples only. We might add new higher requirements for this over time. For instance, we might require that these sites include Expect-Staple or Expect-CT policies (to match the checks for OCSP or CT), or we might devise new and better schemes for avoiding key theft and require those as well. That certainly doesn't mean that "and" won't be the actual requirement.

We have to be careful not to overproscribe client policy here. Browsers have a lot of resources to throw at these problems, but we could exclude other types of clients from these features by the sheer weight of the set of requirements that come with them.

[mcmanus]

I think the direction this is going is to say something along "Examples of mechanisms that can give additional confidence in a certificate are [ct] [ocsp]".. both "or" and "and" in the current text seem to convey more policy than is meant.

On Wed, Aug 16, 2017 at 9:23 PM, Martin Thomson notifications@github.com wrote:

The "or" seems appropriate here, given that these are examples only. We might add new higher requirements for this over time. For instance, we might require that these sites include Expect-Staple or Expect-CT policies (to match the checks for OCSP or CT), or we might devise new and better schemes for avoiding key theft and require those as well. That certainly doesn't mean that "and" won't be the actual requirement.

We have to be careful not to overproscribe client policy here. Browsers have a lot of resources to throw at these problems, but we could exclude other types of clients from these features by the sheer weight of the set of requirements that come with them.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/httpwg/http-extensions/issues/330#issuecomment-322942923, or mute the thread https://github.com/notifications/unsubscribe-auth/AAP5s4nA8QgvkAKYllvpWoRRR5QXdM0dks5sY5X3gaJpZM4NEzUM .

[mnot]

@mcmanus seems reasonable. There will need to be an "and" in there because english, but it'll be clear it's not requiring the set (because examples).

[PiotrSikora]

Looks good, thanks!

One missing thing is that there is no way to limit the Origin Set (which was the original motivation behind this draft) without allowing clients to bypass DNS, leading to the aforementioned operational issues with DNS-based load balancing. This could be easily solved with 1-bit flag, but it's such an edge case, that I'm not sure if it's worth accommodating.

[mnot]

I remember some conversations about that (although I don't think it was in a WG session); the conclusion was that it probably wasn't worth the trouble. The biggest use case is sending the empty origin frame (i.e., limiting to SNI), which means that the DNS bypass is a no-op.

[mnot]

Closing, as we seem to have consensus. AIUI we're going to WGLC soon, so please say otherwise if you don't agree.