Client handling of null AliasMode records

[Saklad5]

dns-alt-svc/draft-ietf-dnsop-svcb-https.md

Lines 480 to 483 in 1dac790

	For AliasMode SVCB RRs, a TargetName of "." indicates that the service
	is not available or does not exist. This indication is advisory:
	clients encountering this indication MAY ignore it and attempt to connect
	without the use of SVCB.

I don't see why this is a MAY: such a record constitutes an explicit denial of any support for the relevant protocol, and I feel a client should only ignore that if it has a specific reason to.

Changing this to say that clients SHOULD NOT (or even MUST NOT) attempt to connect without SVCB could be helpful for preventing downgrade attacks: as written, for instance, web browsers would respond to an HTTPS null record by making an HTTP request that could be exploited by an attacker. At the same time, changing this wouldn't make it easier for a spoofed DNS record to prevent access: attackers could already do that consistently by spoofing A/AAAA records or ECH endpoints.

[Saklad5]

By the way, the Client behavior and DNS Server Behavior sections should at least acknowledge the special handling of AliasMode "." records. As written, they technically say that you should query the DNS root.

[davidben]

Do we actually need "." to be treated special? Seems one could just as easily indicate service not existing by not providing any records. If we just say "." is always expanded to the owner name, then it could just fall through to this logic (or general loop prevention), which clients need to handle anyway because you can always write out the owner name explicitly.

dns-alt-svc/draft-ietf-dnsop-svcb-https.md

Lines 403 to 408 in 1dac790

	The AliasMode TargetName SHOULD NOT be equal
	to the owner name, as this would result in a loop.
	In AliasMode, recipients MUST ignore any SvcParams that are present.
	Zone-file parsers MAY emit a warning if an AliasMode record has SvcParams.
	The use of SvcParams in AliasMode records is currently not defined, but a
	future specification could extend AliasMode records to include SvcParams.

[enygren]

This draft is already past IESG and in the RFC editors queue. Any changes at this point (especially
any with technical/normative impact) would need to be in subsequent drafts (or errata if bugs).
As such, it seems too late for this discussion.

[Saklad5]

This draft is already past IESG and in the RFC editors queue. Any changes at this point (especially
any with technical/normative impact) would need to be in subsequent drafts (or errata if bugs).
As such, it seems too late for this discussion.

There's plenty of issues labeled as "future draft", and I'm hardly proposing a breaking change here. I see no reason to wait to discuss this.

[enygren]

Added future draft label. (Not trying to stop conversation and didn't want to close it out, just wanted to document
for the record that it wouldn't make it into the current draft.)

[bemasc]

@davidben Yes, this is why the special-case for "." makes sense in AliasMode. The goal of this text is to allow clients to say "The requested service does not exist" instead of "A misconfiguration was detected (infinite loop)".

It also nicely matches RFC 7505, "null MX".

[Saklad5]

It also nicely matches RFC 7505, "null MX".

I was specifically thinking of RFC 7505 when I opened this issue, yes. SVCB-optional records have the same fallback to A/AAAA, and they should have the same way of disabling that.

---

I recognize that it is much more important to definitively know whether an SMTP server is down or non-existent, given the retry behavior. That doesn't necessarily apply to HTTPS or DNS connections. However, it is not difficult to imagine that protocols with that concern will become SVCB-optional in the future, and it is also a bit odd that the standard implements a way to do this without actually giving it any weight.

[ericorth]

I don't quite understand the goal here.

Is the suggestion that a "." alias should prevent connection for "http://"-scheme requests? Doesn't it already do that in the current draft? "If an HTTPS RR query for this "https" URL returns any AliasMode HTTPS RRs, or any compatible ServiceMode HTTPS RRs (see Section 8), the client SHOULD behave as if it has received an HTTP 307 (Temporary Redirect) status code with this "https" URL in the "Location" field."

Or is the suggestion that a "." alias should prevent the SVCB-optional behavior of connecting to A/AAAA? What "downgrade attacks" would that prevent? That would just create a situation where non-SVCB-aware clients could successfully connect to A/AAAA normally and SVCB-aware clients would have to give up and give the user an error, despite finding "perfectly good" A/AAAA records.

[Saklad5]

Is the suggestion that a "." alias should prevent connection for "http://"-scheme requests? Doesn't it already do that in the current draft? "If an HTTPS RR query for this "https" URL returns any AliasMode HTTPS RRs, or any compatible ServiceMode HTTPS RRs (see Section 8), the client SHOULD behave as if it has received an HTTP 307 (Temporary Redirect) status code with this "https" URL in the "Location" field."

That would mean acting as if you received a redirect with Location: https://., which is hardly the intent. Or am I mistaken? At any rate, this suggestion isn't specific to HTTPS: I only mention it because that's the only protocol implemented in this standard.

---

Or is the suggestion that a "." alias should prevent the SVCB-optional behavior of connecting to A/AAAA? What "downgrade attacks" would that prevent? That would just create a situation where non-SVCB-aware clients could successfully connect to A/AAAA normally and SVCB-aware clients would have to give up and give the user an error, despite finding "perfectly good" A/AAAA records.

This is less about HTTPS specifically than it is about future SVCB-optional protocols, but there is a downgrade attack this would prevent.

Consider a host noweb.example. This host has A/AAAA records, but does not have an accessible HTTPS server. It presumably offers other services instead.

Imagine an SVCB-aware client was unaware that there is no HTTP server there. It would check for an HTTPS record, and if it didn't find one it would proceed to attempt an HTTP connection.

This HTTP connection could then be observed or hijacked by an attacker on the network. As one of the goals of HTTPS records is to eliminate HTTP-by-default without requiring an impractical preloading list, this is a (minor) problem.

[bemasc]

No, the presence of "any AliasMode HTTPS RRs" is sufficient to trigger the HSTS redirect, even if the RR in question is "null AliasMode".

[ericorth]

That would mean acting as if you received a redirect with Location: https://.

No. 'this "https" URL' obviously refers to the query name, not the alias target, so it would result in a redirect from http://query.name.example to https://query.name.example. Then after the redirect, the client would query HTTPS again (or in practice, just read it from cache), see the "." alias, and choose whether or not to attempt a non-SVCB https:// connection to the A/AAAA results (also probably read from cache).

Consider a host noweb.example. This host has A/AAAA records, but does not have an accessible HTTPS server. It presumably offers other services instead.

Imagine an SVCB-aware client was unaware that there is no HTTP server there. It would check for an HTTPS record, and if it didn't find one it would proceed to attempt an HTTP connection.

This HTTP connection could then be observed or hijacked by an attacker on the network. As one of the goals of HTTPS records is to eliminate HTTP-by-default without requiring an impractical preloading list, this is a (minor) problem.

No, the presence of "any AliasMode HTTPS RRs" is sufficient to trigger the HSTS redirect, even if the RR in question is "null AliasMode".

Right. There's no downgrade attack here with HTTPS records because the HTTPS-record-aware client will then only attempt to connect to A/AAAA via https://, safe from attackers whether or not the server ever responds to those requests. It's left up to the client as a MAY whether the client wants to optimize for the assumption the connection wouldn't work or if it wants to try anyway. I expect most general-purpose clients like browsers would attempt the A/AAAA connections anyway since it's a case where the only alternative is to fail and give the user an error message.

So in the very least for HTTPS, it seems changing the MAY to SHOULD/MUST is unnecessary and potentially detrimental, so it would certainly not be ideal to make that the rule for everything SVCB. But future SVCB-based types certainly should analyze if their particular cases and behaviors do create a downgrade attack and potentially alter the behavior for that type to prevent it. Anything here we should change in a hypothetical bis draft? Or is this all best left to be handled when those hypothetical future SVCB-based types are added?

[Saklad5]

So in the very least for HTTPS, it seems changing the MAY to SHOULD/MUST is unnecessary and potentially detrimental, so it would certainly not be ideal to make that the rule for everything SVCB.

I don't see how it could be detrimental. And I don't see why any SVCB-based type would not want clients to acknowledge null AliasMode records.

Could you provide a hypothetical example of how this could be ill-suited to a future SVCB-based type? All protocols obtain at least some benefit by not having clients waste time and resources on doomed connection attempts.

[ericorth]

All protocols obtain at least some benefit by not having clients waste time and resources on doomed connection attempts.

If the client is the only agent wasting time and resources, then without other motivation like security downgrade attacks, no reason to mandate the client's behavior. If the only alternative for the client is complete failure anyway, many clients would consider the time and resources worth it on the off chance the connection attempt is not in fact doomed. Plus the "waste" can be worth it just for code simplicity if the client always attempts non-SVCB connections and doesn't need special logic to prevent it. Another client may do something different and e.g. have alternate URLs to try rather than going straight to complete failure, and those clients could benefit from shortcutting out of the current URL and moving to the alternate URL immediately on receiving the "." alias. Thus a MAY that lets the client do what's right for the client's circumstances is, in my opinion, the right way to go.

[Saklad5]

Speaking of doomed connection attempts, there is another scenario that calls for null AliasMode records: hosts that act only as a target for other hosts.

example.com.      7200  IN HTTPS 1 cdn.example.net.
cdn.example.net.  7200  IN HTTPS 0 .

While cdn.example.net has an HTTPS server on port tcp/443, it is not meant to be authoritative for cdn.example.net.

This is also a decent way to deal with port forwarding through NAT: individual devices get their own hostnames, but use the network's entry point (i.e. a home router) as a target. Even if that entry point is forwarding the assigned port of a given protocol, it shouldn't be treated as offering services of its own. It's an implementation detail, not a destination.

---

Thus a MAY that lets the client do what's right for the client's circumstances is, in my opinion, the right way to go.

That's what a SHOULD imperative does. The difference is that MAY doesn't recommend behavior at all.

[ericorth]

That's what a SHOULD imperative does. The difference is that MAY doesn't recommend behavior at all.

In principle, I don't completely disagree, but IETF seems to hate writing SHOULD right now when not paired with a paragraph of explanation on all the specific reasoning to go one way or another.

[Saklad5]

What you just wrote seems like a decent start.

I'd also add that RFC 7505 uses SHOULD, and even this standard says the client SHOULD abandon the connection if SVCB resolution fails:

dns-alt-svc/draft-ietf-dnsop-svcb-https.md

Lines 560 to 565 in be0836f

	If DNS responses are cryptographically protected (e.g. using DNSSEC or
	TLS {{!DoT=RFC7858}}{{!DoH=RFC8484}}), and SVCB resolution fails
	due to an authentication error, SERVFAIL response, transport error, or
	timeout, the client SHOULD abandon its attempt to reach the service, even
	if the client is SVCB-optional. Otherwise, an active attacker
	could mount a downgrade attack by denying the user access to the SvcParams.

The standard currently states that the client SHOULD abandon the attempt if it can't resolve a record over encrypted or signed channels, but MAY abandon it if it can and the result explicitly says not to. This seems somewhat absurd.

---

By the way, I feel that all imperatives should have an explanation of specific reasoning. I don't think MAY deserves less scrutiny than SHOULD, given it burdens all implementations with supporting both positive and negative cases. RFC 2119 literally defines it with two MUST imperatives, and it should require more scrutiny than any other imperative as a result.

[ericorth]

The standard currently states that the client SHOULD abandon the attempt if it can't resolve a record over encrypted or signed channels, but MAY abandon it if it can and the result explicitly says not to. This seems somewhat absurd.

One comes with specific potential for downgrade attacks (and probably would have been a MUST if everyone involved was 100% confident that such cases could be abandoned without breaking too many users). The other does not.

[Saklad5]

One comes with specific potential for downgrade attacks

I initially thought so too, but no: that part applies to all kinds of SVCB record, not just those with SvcParams that improve security.

[ericorth]

Good point. If there's ever a bis, maybe it would make sense to make them both "SHOULD abandon" for the general SVCB case, and give HTTPS the more specific guidance for the needs there that one is a security issue and the other is not. (But I would still expect most HTTPS clients to abandon on no response and fallback to A/AAAA on null alias.)

[Saklad5]

This suggestion isn't really about HTTPS records specifically. HTTPS records mandate SNI, so the harm there is relatively limited.

HTTPS also has this section conflating cached Alt-Svc headers authoritative for an origin with the HTTPS records of alternate targets:

dns-alt-svc/draft-ietf-dnsop-svcb-https.md

Lines 1165 to 1172 in be0836f

	## Interaction with Alt-Svc
	Clients that implement support for both Alt-Svc and HTTPS records and
	are making a connection based on a cached Alt-Svc response SHOULD
	retrieve any HTTPS records for the Alt-Svc alt-authority, and ensure that
	their connection attempts are consistent with both the Alt-Svc parameters
	and any received HTTPS SvcParams. If present, the HTTPS record's TargetName
	and port are used for connection establishment (as in {{client-behavior}}).

I dislike this section quite a bit, but it's in the draft, and it seems unlikely to get removed. It only affects servers that use both Alt-Svc headers and HTTPS records, so it hopefully won't be a massive pain. Most of the HTTPS examples I've been giving break if those headers are present.

[bemasc]

@Saklad5 AliasMode records chain to each other, so in your example, you are denying the existence of https://example.com as well as https://cdn.example.net. Null aliases do not allow the "target-only" semantics that you described.

As I mentioned earlier, the "MAY" level recommendation was based on the concern (noted at #203 (comment) and #212 (review)) that null AliasMode records could be injected by an adversary in a way that enables new attacks. The "MAY" leaves room for clients to decide that the repudiation could be an attack and ignore it (for SVCB-optional protocols like HTTP).

[Saklad5]

AliasMode records chain to each other, so in your example, you are denying the existence of https://example.com as well as https://cdn.example.net. Null aliases do not allow the "target-only" semantics that you described.

That was a typo on my part: I meant for the first record in my example to be a ServiceMode record. I've corrected it.

As I mentioned earlier, the "MAY" level recommendation was based on the concern (noted at #203 (comment) and #212 (review)) that null AliasMode records could be injected by an adversary in a way that enables new attacks. The "MAY" leaves room for clients to decide that the repudiation could be an attack and ignore it (for SVCB-optional protocols like HTTP).

SHOULD would also leave room for that. I don't really see much reason to distrust SVCB records more than A/AAAA records, anyway.

[bemasc]

I meant for the first record in my example to be a ServiceMode record.

OK. Note that this is not the typical recommended configuration. CDNs normally should own their ServiceMode records, because these records need to be kept in sync with the CDN's server configuration, and customers should use AliasMode (or CNAME).

SHOULD would also leave room for that.

The MAY/SHOULD distinction is really about defaults for a naive implementor. We judged that it was better for the naive/lazy implementor to lose the repudiation hint (which is only useful for improving error reports) than to risk a possible attack.