Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Warren Kumari <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>