I am supportive of this effort, but I am not convinced that the proposed mechanism is right.
In ECH, there are two essential deployment topologies: "shared" and "split". In "shared" mode there is operationally only one TLS server (processing inner and outer ClientHellos); in "split" mode there are two. Note that CDNs are an instance of "shared" mode, whereas "split" mode is a novel architecture that somewhat resembles a L3 load balancer. For coordination of ECHConfigs between CDNs and their customers, the SVCB draft defines a clear and simple mechanism: use CNAME and/or SVCB AliasMode to point at the CDN's record. This avoids the need to copy any information from the CDN zone into the customer zone, which adds complexity and creates a risk of desynchronization. I don't think this draft should try to address that use case. For coordination between a "shared mode" HTTP server and its own DNS zone, this draft could apply (although perhaps not with the current draft's path structure). However, it strikes me as incomplete, as it does not convey all the other information that an HTTP server would likely want to use to populate its DNS zone, such as ALPN and perhaps even IP addresses. For this application, I would prefer a version that is extensible to future SvcParamKeys as well (e.g. dohpath [1], oblivious [2]). For coordination between a "split mode" server and the "backend" origin zone, this draft seems to provide the right functionality, but its use of HTTP seems odd, as neither party is otherwise obligated to use HTTP at all. It might be preferable to tell the split mode server to publish its ECHConfigs in a SVCB record, and instruct backends to copy it into their HTTPS record. This would avoid asking DNS servers to become HTTP clients. While DNS is not necessarily secured, ECH excludes DNS-modifying adversaries from its threat model, so this might be acceptable (although the location of the attack is different in this case). Alternatively, this coordination could be achieved by a simple TTL extension to the ECHConfig structure. Zone Factories could retrieve an up-to-date ECHConfigList by sending an empty inner_client_hello extension, triggering the fallback mechanism to learn the ECHConfigList and its TTL. So in summary, I am willing to review this draft, but I would prefer to have more discussion from first principles about the use case and mechanism before we pick a direction. [1] https://datatracker.ietf.org/doc/html/draft-ietf-add-svcb-dns#section-5.1 [2] https://www.ietf.org/archive/id/draft-pauly-ohai-svcb-config-01.html#section-3.1 On Wed, Jun 8, 2022 at 2:17 PM Sean Turner <s...@sn3rd.com> wrote: > Hi! > > The author of "A well-known URI for publishing ECHConfigList values" [0] > presented at IETF 113 in dispatch [1]. He was directed to dnsop, but dnsop > passed on adopting the I-D. To explore the 2nd option suggested by > dispatch, please send a message to the TLS list by 2359 UTC 23 June 2022 > that indicates: > > 1) Whether you are willing to review and contribute to this I-D, and > 2) Whether you support adopting this I-D as a WG item. > > Please include any additional information that is helpful in understanding > your position. > > Thanks, > Joe and Sean > > [0] https://datatracker.ietf.org/doc/draft-farrell-tls-wkesni/ > [1] > https://datatracker.ietf.org/meeting/113/materials/slides-113-dispatch-a-well-known-url-for-publishing-echconfiglists-00 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
