Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-svcb-https-08: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'd like to have a (hopefully brief!) discussion about our description of the "strict transport security" functionality the HTTPS RRtype provides, with respect to its accuracty/completeness and how explicit vs implicit we should be about the corresponding divergence from "pure" HTTP behavior. It's pretty clear that at a pure HTTP protocol level (which as far as I can tell is the scope of applicability that we claim) that resources accessed with "http" scheme and resources accessed with "https" scheme have no intrinsic relationship -- §4.2.2 of draft-ietf-httpbis-semantics-19 says: Resources made available via the "https" scheme have no shared identity with the "http" scheme. They are distinct origins with separate namespaces. [...] But the procedures in this document (e.g., §9.5, §9) seem pretty clear that, when an HTTPS record is published, accesses for "http" scheme resources should be converted to "https" scheme accesses, with implication that the client should expect to get the same resource back from the modified query compared to the unmodified "http"-scheme one. While there is a caution in §9.5 that: If this redirection would result in a loss of functionality (e.g. important resources that are only available on the "http" origin), the operator MUST NOT publish an HTTPS RR. but in my reading it leaves some important details as only implicit! We need to care not only about resources only available on one vs the other origin, but also about whether the translation would change the semantics of the client's request/response exchange. That is, whether the resources accessible by the different schemes are actually analogous (which, per the above, is not required by HTTP and is subject to the site administrator's control or in some cases other application protocols on top of HTTP used by that origin). This (mostly implicit) requirement is a potential barrier for adoption of the HTTPS RRtype, and while the precondition is very often going to be satisfied, I wanted to get a sense for whether we should make the requirement more explicit, and possibly more prominent in the document (e.g., mention it in the Introduction). I don't know what the right answer is, but it seems important enough to ensure that the topic receives deliberate consideration. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- First off, thanks for this well-written document! It was pretty clear and easy to read despite covering some fairly complex logic. I made a github pull request with some hopefully boring editorial suggestions: https://github.com/MikeBishop/dns-alt-svc/pull/365 I did have a few high-ish-level thoughts that I either wasn't sure where to put in the section-by-section comments or wanted to make a bit more prominent. The first is a bit hard for me to describe, but basically, when we construct a QNAME for an SVCB or HTTPS query, we include information reflecting URI scheme and port, but when we get a TargetName back, that's been flattened to a single name, in some sense "using up more" of the DNS hostname namespace under the control of the alternative endpoint then in the authority's namespace. That is, if I wanted to provide service for both "foo" and "bar" schemes on two ports each, in order to serve all four combinations for a single service name, I would need to allocate four hostnames for alternative endpoints. We do mention this property as it relates to URI schemes, in §11.1 where we say that "zone owners SHOULD choose alias target names that indicate the scheme in use", but I didn't see much discussion of the port-related aspects. I know that the ServiceMode response can include a port to use in the parameters, so it's not really a concern about losing flexibility of what ports to use. It just seems "unbalanced" in some sense that I can't really put my finger on. On the other hand, it's not like hostnames are a particularly limited resource, so I don't really see any practical consequences of this setup; I'm just curious if this is a topic that the WG gave much consideration to. I was also struck by the procedure near the end of §3 where we append to the very end of the priority list an endpoint specified by the final value of $QNAME combined with the port number from the (original) authority endpoint. This seems a strange combination, since the authority port number is chosen by the origin but the final QNAME will potentially be a service operator rather far removed from the origin. Making provision for what essentially requires a tight coupling between these entities (when non-default ports are used, at least) feels somewhat at odds with the stated goal of allowing delegation of operational authority that I take to imply a more "hands-off" or independently operated approach. While I understand the utility in picking a single port to use for this last-ditch entry on the priority list, it doesn't seem like the port from the original authority is the only choice. One might imagine using the default port for the scheme, or the last 'port' SvcParam encountered in alias chasing, or probably other things as well. I suspect there are some subtleties here, but I don't think I can think about it in much depth at the moment, so I hope that the WG has already undertaken such consideration. I found it a bit surprising (though well described and in that sense well justified) that we limit ourselves to using ALPN values for which the ALPN value uniquely identifies the suite of protocols to use, most notably relating to whether TLS or DTLS is used. That is not something I typically associate as being a property that ALPN provides, though as I look through the registry, almost all of the existing entries (that I know much about) do seem to provide that property. Do we know of any ALPN values that are unusable as a result of this restriction? I'm somewhat curious what the TLS DEs would say if faced with registration requests designed to "split" an existing ALPN registration so that it would be usable with SVCB. The registration procedure for the new Service Parameters registry (Section 15.3.1) starts off saying that it's FCFS, but accompanies that with a MUST-level requirement for "MUST specify how to convert the SvcParamValue's presentation format to wire format" (plus some MAYs as well). I'm somewhat surprised that IANA is willing to accept responsibility for assessing whether the "MUST specify..." has been met. Perhaps a policy of Expert Review with directions to the experts that allocations are "shall issue" provided the MUST is satisfied would be more appropriate? Section 1.2 In ServiceMode, the SvcParams of the SVCB RR provide an extensible data model for describing alternative endpoints that are authoritative for the origin, along with parameters associated with each of these alternative endpoints. (editorial) Since the term "origin" has a specific meaning in the HTTP context, and this document covers both the generic SVCB and the HTTP-specific HTTPS records, but this section is supposed to be the "generic" one, I wonder if we can come up with a different term than "origin" to use here. Would "service" or a derived term be consistent with our definitions? Section 2.1 The presentation format of the record is: Name TTL IN SVCB SvcPriority TargetName SvcParams The SVCB record is defined specifically within the Internet ("IN") Class ([RFC1035]). Should we say something about how "Name" and "TTL" have the same meaning as in RFC 1035? alpha-lc = %x61-7A ; a-z SvcParamKey = 1*63(alpha-lc / DIGIT / "-") SvcParam = SvcParamKey ["=" SvcParamValue] SvcParamValue = char-string value = *OCTET I'd suggest putting some comments in the ABNF that <char-string> is defined in Appendix A and that <value> and <char-string> are related as described in the prose. Arbitrary keys can be represented using the unknown-key presentation format "keyNNNNN" where NNNNN is the numeric value of the key type without leading zeros. A SvcParam in this form SHALL be parsed as specified above, and the decoded value SHALL be used as its wire format encoding. Being SEC AD makes me think about edge cases a lot; do we want to say anything about whether a parser is required to be able to handle "keyNNNNN" for key types defined in this document? (Not that parsing DNS presentation format is the best thing to do in the first place, but it surely happens...) Section 2.4.2 The primary purpose of AliasMode is to allow aliasing at the zone apex, where CNAME is not allowed. In AliasMode, the TargetName will be the name of a domain that resolves to SVCB, AAAA, and/or A records. (See Section 6 for aliasing of SVCB-compatible RR types.) The TargetName SHOULD NOT be equal to the owner name, as this would result in a loop. Why is this not a "MUST NOT"? Does it ever make sense to cause such a loop? Using AliasMode maintains a separation of concerns: the owner of foosvc.example.net can add or remove ServiceMode SVCB records without requiring a corresponding change to example.com. Note that if foosvc.example.net promises to always publish a SVCB record, this AliasMode record can be replaced by a CNAME, which would likely improve performance. So this would be "_8080._foo.example.com CNAME foosvc.example.net" rather than "example.com CNAME foosvc.example.net"? I wonder if clarifying that it's not "example.com CNAME foosvc.example.net" is worthwhile. Section 3.1 For a section titled "Handling resolution failures", perhaps we should also give guidance on how resolution failures should be handled when DNS responses are not cryptographically protected? (I assume "proceed to the fallback", but for completeness' sake...) Section 4.3 For complex value types whose interpretation might differ between implementations or have additional future allowed values added (e.g. URIs or "alpn"), resolvers SHOULD limit validation to specified constraints. I'm not entirely sure what "specified constraints" is intended to mean, here. Would it be those constrains specified as always suitable for validation in the document that defines the SvcParam in question, or something else? Section 5.2 As a performance optimization, if some of the SVCB records in the response can be used without requiring additional DNS queries, the client MAY prefer those records, regardless of their priorities. This might be a performance optimization for the initial connection setup while being a performance de-optimization for the actual application traffic that goes over the connection (i.e., the authoritative's priority values might be assumed to provide actual value to the user). Did the WG discuss whether or not to go into such subtleties here? Section 7.1.2 Clients SHOULD NOT attempt connection to a service endpoint whose SVCB ALPN set does not contain any supported protocols. To ensure consistency of behavior, clients MAY reject the entire SVCB RRSet and fall back to basic connection establishment if all of the RRs indicate "no-default-alpn", even if connection could have succeeded using a non-default alpn. (editorial) Just to confirm: these two directives are only related in that they cover client ALPN handling, and there is no expectation that the "MAY reject" is preconditioned on "SVCB ALPN set does not contain any supported protocols"? I might consider splitting into two paragraphs, even though my general preference is to avoid single-sentence paragraphs. Section 7.2 The "port" SvcParamKey defines the TCP or UDP port that should be used to reach this alternative endpoint. [...] Is this intentionally excluding SCTP/DCCP/etc? Section 9.3 Origins that publish an "ech" SvcParam in their HTTPS record SHOULD also publish an "ech" SvcParam for any alt-authorities. [...] Just to confirm I'm understanding this properly: this is saying that if an origin publishes an HTTPS RR with an "ech" SvcParam (any single RR in the RRset suffices to trigger the condition), then the origin should also publish HTTPS records for any alt-authorities that it would send in an Alt-Svc header field, and those other HTTPS records should all include an "ech" SvcParam as well? I'm a little confused at why the RFC 7838 "alt-authorities" keyword is used here without any specific reference to Alt-Svc itself. (There are only three instances of the string "alt-authorit" in this document, two of which are in this paragraph; the third is clearly marked as applying to the Alt-Svc usage.) Section 9.4 Clients MUST NOT use an HTTPS RR response unless the client supports TLS Server Name Indication (SNI) and indicates the origin name when negotiating TLS. This supports the conservation of IP addresses. I could sort-of see a misreading of this that says you have to put the real origin in the SNI extension and not use ECH with a separate fronting origin. Maybe we want to say something about "uses SNI (possibly in conjunction with ECH) to indicate the origin name"? Section 11.2 queries for TargetName in advance (see Section 5). Unless otherwise specified, the convention is to set TargetName to the service name for an initial ServiceMode record, or to "." if it is reached via an alias. For foo://foo.example.com:8080, this might look like: I think it would be helpful to show an example of the "set TargetName to the service name for an initial ServiceMode record" in addition to the alias example that is shown. Section 11.3.3 Suppose that svc.example's default server pool supports HTTP/2, and it has deployed HTTP/3 on a new server pool with a different configuration. This can be expressed in the following form: $ORIGIN svc.example. ; A hosting provider. pool 7200 IN HTTPS 1 h3pool alpn=h2,h3 ech="123..." The prose suggests that perhaps the new pool is h3-only and doesn't support HTTP/2, but the actual example lists both alpn values. I guess it also omits no-default-alpn, so the new pool actually supports all three http versions... Section 11.3.4 * The A, AAAA, and HTTPS resolutions are independent lookups, so clients may observe and follow different CNAMEs to different CDNs. Clients may thus find a TargetName pointing to a name other than the one which returned along with the A and AAAA lookups and will need to do an additional resolution for them. [...] (editorial) I think something went awry near "the one which returned along with", as it's not even clear whether there are separate queries vs additional-section responses in the intended scenario. Section 13 Do we want to mention the discussion in §3.2 about using caution in resolving SVCB when using a proxy? I note that draft-ietf-tls-esni has a note (its §10.2) explaining that DNSSEC or other protection is not really needed for ECH config, since an attacker that controls DNS can already defeat ECH protections. Do we want to include similar discussion or otherwise mention this topic (e.g., by reference)? Section 15.3.2 | 65535 | N/A | Reserved | (This document) | | | | ("Invalid | | | | | key") | | Do we care that 'I' is not a lowercase letter? Section 15.4 I always worry somewhat when we propose a new mechanism with no worked examples for it (in this case, protocols using SVCB per the "MUST have an entry for its scheme" requirement in §12). Perhaps the HTTPS example is close enough that my worries are groundless. Section 17.1 Why is [DNAME] classified as normative? I only see one reference to it, in a list of examples of possible ways that resolvers might follow aliases, which does not seem like a "protocol feature" of this document. I could also perhaps see an argument that references to [HSTS] are just by way of analogy or indicating that we provide equivalent behavior, which would not seem to require the reader to understand [HSTS] in order to implement this specification. RFC 6147 is referenced only as part of a "MUST NOT perform DNS64" construction, which seems to indicate that it is *not* a normative reference. Appendix D.2 [I did not carefully review the examples for internal consistency, trusting that this document has received ample review already.] _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
