I chatted with Viktor Dukhovni late last week, and he promised us a sentence to solve all that ails us… or, at least, a simple, clear, concise sentence which only clarifies what appears to have been intended.
I suspect that US Labor day vacation got in the way, but I hope to have it soon. If not, I think we just stick with the original - 'tis not perfect, but all can be fixed in a -bis[0]. W [0]: Quick, someone put that on a t-shirt… On Wed, Sep 07, 2022 at 5:20 PM, Ben Schwartz <bem...@google.com> wrote: > As I noted earlier, changing the non-SVCB fallback recommendation to "MAY" > would nominally make HTTPS-record deployment riskier. I'm inclined to take > the current approach (encouraging fallback when it is safe) for now, and > perhaps revisit this question in a few years if operational experience > shows it to be unnecessary. > > On Wed, Aug 31, 2022 at 11:00 PM Tommy Pauly <tpa...@apple.com> wrote: > > I don’t personally find this proposal to be an improvement for clarity. > > The fact that a client is SVCB-optional means, somewhat by definition, > that they allow not using the SVCB results. Saying that the client “MAY” > doesn’t really help; it’s the very definition of what SVCB-optional is. If > the client doesn’t use non-SVCB connection modes at that point, then it is > SVCB-reliant. > > Listing out the details of what a non-SVCB connection does (not using the > information from the SVCB record) also seems redundant. It is more accurate > to just say “don’t use anything from SVCB if SVCB didn’t work” rather than > trying to list out what all of those details might be. > > Tommy > > On Aug 31, 2022, at 4:13 PM, Brian Dickson <brian.peter.dick...@gmail.com> > wrote: > > So, here is my suggestion, for "a sentence (or possibly two) which only > clarify what is already written?": > > In section 3: > > If the client is SVCB-optional, and connecting using this list of > endpoints has failed, the client now attempts to use non-SVCB > connection modes. > > becomes: > > If the client is SVCB-optional, and connecting using this list of > endpoints has failed, the client MAY attempt to use non-SVCB > connection modes, using the origin name (without prefixes), > > the authority endpoint's port number, and no SvcParams. > > (The original didn't use RFC 2119 language, but the list of failure modes > in 3.1 leads to "MAY" being the most appropriate choice.) > > Let me know if that is good enough. > (The rest can go into a -bis... how soon are we allowed to start a -bis > document? The day of RFC publication? I'd like to start that as soon as > possible, while everything is still fresh.) > > Brian > > On Wed, Aug 31, 2022 at 6:25 AM Warren Kumari <war...@kumari.net> wrote: > > > > > > On Wed, Aug 31, 2022 at 4:39 AM, Brian Dickson <brian.peter.dickson@gmail. > com> wrote: > > Here are some proposed text changes, per Warren's invitation to send text: > > > > Um, no. Warren said: "can we craft a sentence (or possibly two) which > only clarify what is already written?". This is a significantly larger set > of changes than that. The Section 3 changes in particular are (IMO) much > more than a clarification. > > These may or may not be good changes, but anything approaching that level > of change would have to be in a -bis document… > > W > > > > In section 1.2, change: > > 2. TargetName: The domain name of either the alias target (for > AliasMode) or the alternative endpoint (for ServiceMode). > > to: > > 2. TargetName: Either the domain name of the alias target (for > AliasMode) or the host name of the alternative endpoint (for > ServiceMode). > > In section 2.4.2, change: > > As legacy clients will not know to use this record, service operators > will likely need to retain fallback AAAA and A records alongside this > SVCB record, although in a common case the target of the SVCB record > might offer better performance, and therefore would be preferable for > clients implementing this specification to use. > > to: > > As legacy clients will not know to use this record, service operators > will likely need to retain fallback AAAA and A records at the service > name, > although in a common case the target of the SVCB record > might offer better performance, and therefore would be preferable for > clients implementing this specification to use. > > > In section 2.4.3, change: > > In ServiceMode, the TargetName and SvcParams within each resource > record associate an alternative endpoint for the service with its > connection parameters. > > to: > > In ServiceMode, the TargetName and SvcParams within each resource > record associate an alternative endpoint for the service with its > connection parameters. The TargetName MUST be a host name > (as defined in [DNSTerm].) > > In section 3, the following changes are proposed; they introduce a new > term LASTNAME to be used to disambiguate the $QNAME reference so as to > remove ATTRLEAF prefixes from the appended target: > > > 1. Let $QNAME be the service name plus appropriate prefixes for the > scheme (see Section 2.3). > > becomes: > > 1. Let $QNAME be the service name plus appropriate prefixes for the > scheme (see Section 2.3). Let $LASTNAME be the service name without > any prefixes. > > > > 3. If an AliasMode SVCB record is returned for $QNAME (after > following CNAMEs as normal), set $QNAME to its TargetName > (without additional prefixes) and loop back to step 2, subject to > chain length limits and loop detection heuristics (see > Section 3.1). > > becomes: > > 3. If an AliasMode SVCB record is returned for $QNAME (after > following CNAMEs as normal), set $QNAME to its TargetName > (without additional prefixes), set $LASTNAME to this new $QNAME and > loop back to step 2, subject to > chain length limits and loop detection heuristics (see > Section 3.1). > > > Once SVCB resolution has concluded, whether successful or not, SVCB- > optional clients SHALL append to the priority list an endpoint > consisting of the final value of $QNAME, the authority endpoint's > port number, and no SvcParams. (This endpoint will be attempted > before falling back to non-SVCB connection modes. This ensures that > SVCB-optional clients will make use of an AliasMode record whose > TargetName has A and/or AAAA records but no SVCB records.) > > becomes: > > Once SVCB resolution has concluded, whether successful or not, SVCB- > optional clients SHALL append to the priority list an endpoint > consisting of the final value of $LASTNAME, the authority endpoint's > port number, and no SvcParams. (This endpoint will be attempted > before falling back to non-SVCB connection modes. This ensures that > SVCB-optional clients will make use of an AliasMode record whose > TargetName has A and/or AAAA records but no SVCB records.) > > If the client is SVCB-optional, and connecting using this list of > endpoints has failed, the client now attempts to use non-SVCB > connection modes. > > becomes: > > If the client is SVCB-optional, and connecting using this list of > endpoints has failed, the client MAY attempt to use non-SVCB > connection modes, using the origin name (without prefixes), > > the authority endpoint's port number, and no SvcParams. > > > One additional suggested addition to the end of section 3.1 is: > > If DNS responses are cryptographically protected, and at least > one HTTPS AliasMode record has been received successfully, > clients MAY apply Section 9.5 (HSTS equivalent) restrictions > even when reverting to non-SVCB connection modes. Clients > > also MAY treat resolution or connection failures subsequent > > to the initial cryptographically protected AliasMode record > > as fatal. > > [Brian's note: this last would provide some guidance to implementers of > clients: a signed HTTPS AliasMode record is a strong signal that the DNS > operator is discouraging fallback, albeit at a "MAY" level.] > > NB: The 2.4.3 change could be removed as it is mostly independent, as > could the last addition to 3.1. > The 1.2 change is very minor, is not too important but presents a succinct > clarification on the hostname vs domain name thing. > The 2.4.2 change and section 3 changes together are fixes for the > prefix/no-prefix issue (which was basically a scrivener's error, and does > not change the semantics at all.) They should stay or go as one unit. > > Brian > > On Tue, Aug 30, 2022 at 12:08 AM Brian Dickson <brian.peter.dickson@gmail. > com> wrote: > > > > On Sat, Aug 27, 2022 at 3:00 PM Ben Schwartz <bem...@google.com> wrote: > > > > On Fri, Aug 26, 2022 at 10:49 PM Brian Dickson <brian.peter.dickson@gmail. > com> wrote: > > > Fail fast may not be appealing, but in some (probably the majority of) > cases, it may be the most correct option. > > It may also be the case that the zone owner knows whether this is the case. > I think it is much more likely that explicitly declaring the situation (if > known) is more useful than having several billion clients independently > attempting to infer whether the first option will even work, let alone > provide a useful alternative to the second or third. > > > In fact, there is one way for the zone owner to disable fallback: enable > ECH. Fallback is not compatible with ECH, so ECH-aware clients will > disable fallback when the ServiceMode records contain ECH. > > > Wait, what? > > This whole discussion was raised from the perspective of zone owners > publishing AliasMode apex records. > Those owners would not be operating the CDN, which is the whole point of > using a CNAME or AliasMode. > I.e., the zone owner would be the one wanting to disable fallback, but > would not be in a position to do what you suggest. > > The domain's contents are served via a CDN, where the CDN requires > delegation of control, most often with CNAME (or AliasMode at the apex). > The ServiceMode records are placed on the CDN operated zone (in order to > avoid the first connection to establish the AltSvc stuff). > > The AliasMode record cannot be combined with ECH, since no SvcParams are > allowed. The zone owner is not using ServiceMode, that is the declared > assumption. > > If that (ECH) is the only way to disable fallback, that's what the focused > discussion needed to elicit, and I think some slight adjustments are needed > to at least facilitate zone owners preventing fallback. The mechanism > doesn't need to be added to the draft, but likely would get put into a > separate draft or a -bis document. However, there needs to be some daylight > between the fallback method and the mandatory SVCB/HTTPS components, in > order to allow for that development. > > BTW, the concern is less about singleton zone owners than it is about > large scale integrated DNS management of zones in order to accommodate CDN > usage. > > Note also, this issue is not strictly limited to vertical integration > among products/services of the DNS operator; there are large scale > inter-provider (DNS and other services) open partnerships (controlled by > their mutual customers) that have need for the programmatic ability to > assign CDNs and enable/disable fallback (if fallback is part of the > specification). > (For those interested, the not-yet-an-IETF standard for interoperability > between DNS and service providers is Domain Connect. The intent is to > revive the draft for that, which previously lived in the REGEXT WG.) > > I think converting the fallback in the draft into MAY, and having active > discussions, dev, test, and deployment on a voluntary basis outside of the > scope of the current draft, is the fastest path to solving the "no > fallback" signaling issue, and to getting the draft published (with a few > minor tweaks). > > I'll review the other comments, as well as Warren and Viktor's recent > messages, and see if I can come up with some proposed text to make very > limited changes to the draft. > > Brian > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
