Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-httpssvc-02

[Ben Schwartz <[e-mail]>]

On Fri, Apr 17, 2020 at 6:20 AM Alessandro Ghedini <[e-mail]>
wrote:

> Hello,
>
> First off, I have started implementing support for SVCB and HTTPSSVC as
> part of
> the dnspython library [0] and I'd be interested in doing some interop
> testing
> with other people's implementations.
>
> I also have a few comments/questions about the draft, apologies if they
> have
> already been discussed in the past (haven't been following the draft from
> the
> start).
>
> 1. For interop testing purposes it would be very helpful if the draft
> listed
> commonly agreed upon code-points for the new RR types. Ideally in the form
> of an
> official early assignment from IANA, but if that's not possible picking a
> couple
> of codepoints at random from the "private use" range would also be
> helpful. In
> my implementation I'm currently using "65481" for SVCB and "65482" for
> HTTPSSVC.
>
> 2. The structure of the draft is a bit odd, as it lists a bunch of examples
> before introducing any of the records. This was a bit confusing to me, so
> I'd
> suggest moving sections 1.5 and 1.6 _before_ the examples (that is,
> immediately
> after the introduction). It might also be a good idea to just move the
> examples
> to an Appendix instead.
>

Noted as https://github.com/MikeBishop/dns-alt-svc/issues/135

3. Would it make sense to move the ESNI/ECHO config paramenter to the
> ESNI/ECHO
> draft instead? This way the DNS draft wouldn't need to depend on the ESNI
> draft
> (so e.g. if ESNI ends up taking longer, this draft could be published
> without
> having to wait for it).
>

That's an interesting question.  My main concern with separating it is that
ECHO is the only reason we need to disable fallback, and the need to
support clients that can't use fallback is a major factor in the design.


> 4. What is the point of differentiating between AliasForm and ServiceForm?
> Like,
> couldn't the draft just say that the SvcFieldValue is an optional field
> and be
> done with that? It seems like not having to explicitly differentiate the
> two
> cases would simplify the draft a bit without sacrificing much, though I
> might
> be missing something.
>

It's true that there is no great distinction to an authoritative server.
However, the resolution procedure is quite different.  If there is an
AliasForm, the resolver should follow only one RR (ignoring all the
others), and should re-query SVCB.  Otherwise, it should follow all the
RRs, but only querying A and AAAA.

(To an authoritative, the only distinction I can think of is that "." is
not allowed for AliasForm, because it represents a reference cycle.)


> 5. Section 2.1.1 says
>
>    The presentation format for SvcFieldValue is a whitespace-separated
>    list of elements representing a key-value pair, with an absent value
>    or "=" indicating an empty value.
>
> It took me longer than I'd like to admit to understand the "with an absent
> value
> or "=" indicating an empty value" part. I'd suggest rewording that
> paragraph to
> something like:
>
>    The presentation format for SvcFieldValue is a whitespace-separated
> list of
>    key=value pairs (e.g. "key123=value1 keys456=value2"). When the value,
> or
>    both the value and the "=" are omitted, the value should be interpreted
> as
>    being empty.
>
> Or something better :)
>

Noted as https://github.com/MikeBishop/dns-alt-svc/issues/136


> 6. In Section 2.2 it says (in reference to param field values):
>
>    o  an octet string of the length defined by the previous field.
>
> It might be good to say here that the format of this octet string is
> defined
> according to the corresponding SvcParamKey, and then reference section 6
> for
> ths currently defined keys. The same applies for section 2.1.1 for the
> presentation format.
>
> 7. Section 4.3 says:
>
>    All DNS servers SHOULD treat the SvcParam portion of the SVCB RR...
>
> Should it be SvcFieldValue instead of SvcParam? "SvcParam" is not mentioned
> anywhere else.
>

You're right.  https://github.com/MikeBishop/dns-alt-svc/pull/137

8. Maybe I'm missing something, but the following sentence in Section 6.4
> seems
> wrong:
>
>    When SvcDomainName is ".", server operators SHOULD NOT include these
> hints,
>    because they are unlikely to convey any performance benefit.
>
> My understanding is that ipv4hint and ipv6hint are the way to solve the
> ESNI
> multi-CDN problem


Not exactly.  Hints are not required for that.  Instead, the requirement is
that each RR contains a matched SvcFieldValue and SvcDomainName, from the
same CDN.  The A/AAAA lookup for the SvcDomainName then provides the IPs.

The purpose of IP hints is to reduce resolution latency in that scenario,
only in the case where the recursive resolver is not SVCB-aware, by
avoiding the need to wait for the A/AAAA lookup.

, so let's say I have "www.example.net" that CNAMEs to both
> "cname.cdn-a.example" and "cname.cdn-b.example". A client queries both A
> and
> HTTPSVC concurrently for "www.example.net", and receives two answers (the
> answer
> to the A query points to CDN A, while the answer to HTTPSSVC points to CDN
> B):
>
>     www.xample.net      3600 IN CNAME cname.cdn-a.example
>     cname.cdn-a.example 3600 IN A 192.0.2.1
>
> and
>
>     www.xample.net      3600 IN CNAME cname.cdn-b.example
>     cname.cdn-b.example 3600 IN HTTPSSVC 1 . alpn=h3 esniconfig="..."
>
>
(You have two distinct CNAMEs for "www.xample.net" listed there.
Technically this is not allowed by the CNAME specification.  However, we
can ignore that issue.)


> My understanding is that in this case the client could end up connecting to
> 192.0.2.1 (CDN A) with CDN B's ESNI config (or e.g. with the wrong ALPN).


No, this is not possible.  When using B's ESNI config, the only allowed IP
addresses are those for cname.cdn-b.example.

In this case (as with any case where SvcDomainName=".", IP hints would not
provide a performance advantage, because HTTPSSVC is always queried in
parallel with A/AAAA, so the record for cname.cdn-b.example will come back
along with the corresponding IPs anyway.

...

> 9. Speaking of multi-CDN, AFAICT the problem is mentioned only once in the
> whole
> draft and only in relation to ESNI. However this is not ESNI-specific and
> also
> affects e.g. HTTP/3 as per the example above. So I think it would be
> useful to
> go into a little more detail on this.
>

OK, please suggest text.


> 10. Section B.2: s/pther/other/
>

Will fix.


>
> Cheers
>
> [0] https://github.com/rthalley/dnspython/pull/452
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>