@bemasc says

On further consideration, I think a SVCB scope may be unworkable. Consider a CDN customer who copies the CDN's ServiceForm RRSet into their own domain, and (alas) fails to keep it up to date. If the CDN adds a new incompatible protocol, everything will work fine, but SNIP will flag this as an attack, possibly making the customer's site unreachable.

The problem is that the SVCB scope doesn't identify which SVCB RRSet it's referring to, and it's not always easy to enumerate all the SVCB RRSets that include a particular endpoint.

I think that the first is just an operational issue (a worthwhile one to note). I don't think that identifying the set is likely to be useful as a response to this though. Ensuring that the CDN does not enable protocols without ensuring the consistency with DNS configuration (or other discovery configuration) is what I would prefer.

There can be some protocols that are defined as incompatible, which are subsequently (through revisions or extensions) made compatible. A server won't know if a client is aware of this and so it has to advertise these protocols as though they were incompatible. It can only omit them if the client lists them in ALPN, which indicates that the client both knows about the protocol and believes it to be compatible.

The draft should include something to the effect of the above. QUIC version negotiation has to deal with a similar problem.

@bemasc

BTW, Section 6.2 seems to assume that all ServiceMode (formerly "ServiceForm") SVCB records in an RRSet have the same TargetName (formerly "SvcDomainName"), but that is not required. The scope as currently defined is effectively "same IP", which is narrower.

This was never the intent, my understanding was that the IP might be different. Check and maybe clarify.

Say a client discovers an HTTP server using an A record and so connects over HTTP/1.1 or HTTP/2, even if it supports HTTP/3 (leaving optimistic attempts to use HTTP/3 aside for this example).

If that server advertises availability of HTTP/3, can the client act on this information?

According to the draft as written, the client cannot. However, if the client supports SVCB (technically, the HTTPS record), it might reasonably assume that the server would not advertise HTTP/3 without also having provided some means of discovering it. As framed, the server might have offered some other way of discovering this incompatible protocol, so the client cannot assume that the option to use HTTP/3 was the result of an attack that suppressed the SVCB record. The client therefore cannot treat this as a potential attack. That's not great. It would be good if they could at least act.

@bemasc suggests:

I think this draft should probably either name the scope or be specific to SVCB, to avoid cases where the scope is ambiguous. Naming the scope, and providing a scope identifier meaning "IP and port number", would often be sufficient for secure QUIC upgrade without SVCB, at the cost of some conceptual complexity.

I think that this reasonable. There are a few options:

1. Limit this to just SVCB. That's simple and understandable, but it means that we can't use the mechanism for new things. QUIC version negotiation has already been identified as something that might benefit from this. And having to define a new mechanism for authentication of a new scheme is suboptimal.

2. Have the client advertise what it believes the scope to be. I included this for completeness, but I think that this doesn't help at all. This requires that the server act, and the model here depends on client action.

3. Have the server advertise a single scope of applicability. The problem with this is that it makes it hard to know what the right scope is. The server has to choose. You could base this on information that the client provides, but I think that biases the outcome in ways that might be exploited by attacks. I don't think that this is viable either.

4. Have the server advertise multiple scopes of applicability. There is two ways to spell this: as a set of scopes (IP+port, SVCB, QUIC-VN) or by recognizing that the goal is to define the union of sets and that most of the sets are subsets of others.

So I think that I agree with Ben here. It sounds like a single identifier would be good. We could define just two values for the moment: IP+port and SVCB. In this case, the first is understood to be a subset of the other so we don't need to define IP+port||SVCB as a separate codepoint. We could recommend that every new scope defined include identifiers for all possible sets, either by being a superset or subset of other scopes or defining identifiers that combine the new scope with every other identifier.

The problem with that approach is that introducing a new scope at the server causes old clients to lose protection, because they don't understand the old scopes. So we need to go back to a set (or list).

I tend to think that the number of scopes will be low, so I'm inclined to use a bitfield for this (16 bits seems like it is enough) so that we don't have to grapple with the complications that come with list parsing. The minimum size is the same as opaque<1..255>, but it doesn't increase in size, so it is easier to process.

@bemasc says:

Overall, I still think SNIP would be more useful if it focused on the scope of "same IP and port number", which would minimize coordination problems and increase utility in most use cases. That happens to be the effect of the "QUIC" scope anyway. I would call this the "default" scope.

Currently, if multiple hosts share an IP, the draft essentially says that the server is expected to offer the same set of protocols to clients that request any protocol. That really needs to be explicitly stated or there will be questions. I believe that this is the right answer, but it does have operational consequences and so it needs to be clear.

The alternative is to further narrow the scope to explicitly include hostname. That's more or less what the draft means in practice, as there is no caching of the state. The state is implicitly constrained to a single connection attempt, so an attempt to connect to a different hostname would result in a different set of queries. Again, being clear that this is the case would help a great deal.

@bemasc says

I'm having trouble understanding the "default authentication scope". How can this be a useful construct, if clients and servers are both forbidden from using it?

Section 7 says that ordinary connection to a service by its AAAA record and a well-known port "does not provide enough information to locate other incompatible protocols". That seems like a convention, rather than a matter of fact.

This might just go. That is, it can be as simple as: If your discovery mechanism isn't listed, then anything you might discover using that method can't be authenticated.