Make a clean break with the past #256
Comments
|
What's the concern here? The current design allows fallback when it is safe, but this is independent of the HTTPS upgrade, which applies regardless of connection fallback. |
|
My concern is with §3 step 6. Realistically, there will always be legacy authority endpoints to handle the long tail of clients that don't support SVCB. But, this authority endpoint will expect less and less load over time, and at some point may fail to be adequately load balanced. If a problem appears with the SVCB chain that causes all clients to fall back to the authority record, you could get a stampeding herd all directed at the target of that record, effectively creating a DDoS. The justification might be the need to support the type of spec change being discussed in #252. I'm not sure that eliminating fallback is doable, even if it might be a good idea in theory. But it seems like the reasoning should be spelled out somewhere. |
OK, but the alternative would be that those users would have already failed to connect. Why is that better? I think the main motivation for the current fallback logic is that more fallback means more resilience. Ultimately, I think fallback behaviors are going to vary between clients: different clients have different design considerations, and the standard can't justify strict requirements on this topic. If we did eliminate fallback in the way you describe, we would still probably have to allow it in cases where there are ServiceMode records but none are compatible with the client. In other words, eliminating fallback would not reduce client complexity. |
|
I think I'm not going to be the only one with these questions, which suggests it might be worthwhile to explain the design choice in an appendix. I agree it doesn't belong in the main text along with normative protocol design. |
|
I don't think this is really a design choice. It's a "MAY", documenting that there's no reason to forbid this behavior. Forbidding the fallback would certainly require a justification (as in Section 8.1). |
|
Conclusion: Remove the item number on this requirement. |
Apart from editorial changes, this reduces the strength of the "alias target fallback" recommendation from SHOULD to MAY. (This is the case where an AliasMode record points to a ServiceMode RRSet but all connection attempts have failed, and the client still wants to follow the alias.) Fixes #256
Apart from editorial changes, this reduces the strength of the "alias target fallback" recommendation from SHOULD to MAY. (This is the case where an AliasMode record points to a ServiceMode RRSet but all connection attempts have failed, and the client still wants to follow the alias.) Fixes #256
|
Update: Step 5 should be updated so its purpose is clearer and it has normative strength. Leaving the 4->5 fallback as SHOULD. |
Fixes #256 * Adjust fallback behavior. Clarify steps 4/5 (primarily editorial) and be explicit about how this works (eg, use to A/AAAA records when no SVCB record or no compatable SVCB record). * Reduces the strength of the "alias target fallback" recommendation (previously step 6) from SHOULD to MAY. (This is the case where an AliasMode record points to a ServiceMode RRSet containing compatable SVCB records but all connection attempts have failed, and the client still wants to follow the alias.) * Rename mandatory section and reword DNSSEC rule
To avoid the problem SSL/TLS had for years with ambiguity re: the CN in the presence of the SAN extension, you should clearly state somewhere that when SVCB is available for an authority endpoint, the legacy defaults (hostname on port 80/443) must never be used as a fallback or as part of a pool of options for the client. That, or explain clearly the justification for the current design choice.
The text was updated successfully, but these errors were encountered: