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

[Viktor Dukhovni <[e-mail]>]

On Wed, Aug 31, 2022 at 01:39:32AM -0700, Brian Dickson wrote:

> Here are some proposed text changes, per Warren's invitation to send text:
> 
> 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).

This looks correct.  The alternative target name needs to be a valid
hostname.

> 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, [... unchanged ...]
> 
> 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,
>    [... unchanged ...]

This is correct, because in the presence of one or more AliasMode
records the ServiceMode record is no longer "alongside" the A/AAAA
records.

> 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].)

This is basic conformance with RFC 1123 section 2, avoids
interoperability issues with proxies, and various software that
validates hostnames in applications and DNS resolvers.  Otherwise, this
document may need to update RFC 1123, relaxing the syntax rules for
hostnames.

> 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.)
> 

This scary-looking long edit is an attempted bug correction.  But Ben
tells me that the actual intent is to only add $QNAME to the search list
if there's a non-zero number of AliasMode records encountered.
Otherwise, there is no need to append any $QNAME to the list, since it
is the same as the legacy fallback (non-SVCB connection modes below).

A simpler fix should be possible.

>    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.

And then this change likely becomes redundant.

> 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.]

This likely indeed falls into the territory of new work.


On Wed, Aug 31, 2022 at 06:25:26AM -0700, Warren Kumari wrote:

> On Wed, Aug 31, 2022 at 4:39 AM, Brian Dickson <[e-mail]> 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…

Can we "rescue" just the clarifications/corrections?

    * Fix the $QNAME issue
    * Clarify that ServiceMode targets MUST be valid hostnames

[ It may be worth noting that also AliasMode targets that are not valid
  hostnames may not be suitable fallback values to append to the candidate
  target list, though if one is sure that these will then resolve to a
  usable ServiceMode record, then the intermediate non-hostname falls
  out of the picture.   In a "-bis" document I'd be inclined to say
  that the targets of all SVCB/HTTPS records "SHOULD" be hostnames. ]

-- 
    Viktor.