[DNSOP] draft-ietf-dnsop-svcb-httpssvc-01 feedback

[Eric Orth <[e-mail]>]

Been reviewing the latest draft with a bunch of relevant experts within the
Chrome team.  As has been stated in previous emails and in WG sessions, we
generally like the HTTPSSVC approach and are very interested in trying out
an implementation.

Some specific feedback:

   - The name: I still hate the name “HTTPSSVC” because I have trouble
   saying it.  Please paint the bikeshed a different color.
   - Section 1.3: Compared to previous drafts, not much value anymore in
   SvcFieldPriority being a first-class field outside SvcFieldValue.  Client
   will need to fully parse SvcFieldValue to decide the real priority (to
   prefer ESNI and discount unsupported protocols, etc).  Although I will
   admit that it is elegant that multiple aliases get treated as multiple
   0-priority records in that one is randomly picked and non aliases get
   ignored.
   - Section 2.5: We see no valid reason to support an alias chain 8 nodes
   long.  Such a case is likely only configuration error, and following the
   full chain would subject our users to bad performance that the configurer
   is not likely to notice and fix.  Therefore, unless somebody comes up with
   a good reason that longer chains need to be supported, we intend to only
   follow 1 or 2 links before giving up on following the chain further, and
   the spec should be updated to say that such chains should be limited as
   such.  I hear not everybody in the stack can reasonably enforce this limit,
   so maybe state that longer chains are not valid, should not be created, and
   clients/resolvers that can enforce limits should use the value specced here
   for that enforcement.

   I think it would also be helpful for this section to clarify the
   expected behavior on detection of a loop or too-long chain: Fail entirely,
   use the non-SVCB fallback addresses, or use the furthest-down-the-chain
   service records found if such records are mixed with alias records?
   - Section 4: Very much “yes, please” on including the recursive results
   in Additional to prevent additional queries.  We are very sensitive to
   unnecessary latency in DNS.
   - Section 6.1: We have some concerns with the use of ALPN values to
   specify this.  This is complicated enough that we will start a separate
   email thread soon to discuss this point.
   - Section 7: States that HTTPSSVC is only used for http and https
   schemes.  But Chrome also deals with other schemes with implied http URLs,
   like websockets.  There should be clarification text that HTTPSSVC is also
   used for these schemes, with wss:// queried as if it were https:// and
   ws:// queried as if it were http://.  We consider it important for HSTS
   and HSTS-like behavior such as HTTPSSVC existence to also apply to the
   related ws:// URL.
   - Section 7.4: I believe this is saying the correct thing with a strict
   reading (that http://example.com:80 becomes HTTPSSVC(example.com)), but
   I think some more clarity would be helpful.  The text of “specify port 443”
   and such may make it sound like you’re constructing the HTTPSSVC query URL
   including specifying 443 (HTTPSSVC(_443._https.example.com)), but from
   section 7.1, the port is obviously not supposed to be specified.  Maybe
   some extra clarity that these rules are for constructing the actual
   redirect URL (not the query URL) and that that URL then gets encoded into
   an HTTPSSVC query via the rules of section 7.1.

   Also, this section seems slightly inconsistent with section 7.1 in that
   7.1 states HTTPSSVC is used for http and https, but in actuality, HTTPSSVC
   is only used for querying https and section 7.4 shows how to create an
   appropriate https URL to query when you’re starting from an http URL.

   Also, I think this section should clarify that any HTTPSSVC result,
   including alias form, is sufficient for the client to read it as a signal
   to upgrade to HTTPS. Otherwise there may be some confusion over whether or
   not only service form records are sufficient.

   Also, this section states that connection should be abandoned on
   SERVFAIL because it might be a DNSSEC error.  But I think the spec should
   clarify that the client may continue if it has reason to believe the error
   was not caused by DNSSEC validation (e.g. because of an EDE specifying that
   the error was something else).
   - Section 8.1: We’re very sensitive to any situation where it’s too easy
   to accidentally configure DNS to disable QUIC -> TCP fallback. Some of our
   users are behind networks where QUIC cannot get through. If the HTTPSSVC
   records with esiconfig are h3, section 8.1 imples we cannot try TCP because
   that would lose ESNI. Ideally this would be treated as a misconfiguration
   somehow. Failing that, perhaps the ESNI fallback rules should be left open
   to client policy.