Hi Ben,
On 08/06/2022 20:35, Ben Schwartz wrote:
I am supportive of this effort, but I am not convinced that the proposed mechanism is right.
That's fair. FWIW, I do agree the issues you identify below warrant discussion (my preference of course is to do that after WG adoption:-)
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.
Correct. And the draft doesn't try address such deployments where other mechanisms would be better. (I think you made a comment before that some text somewhere that describes a set of ECH or SVCB deployment options could be useful. I agree with you about that - not sure an I-D/RFC would be the best place for it though.)
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 pathstructure).
Actually, I think you'd still need (to be able to) use a scheme like the current draft's to handle VirtualHosts. But I'm not particularly tied to the current path structure either.
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]).
I agree that's a topic to discuss - the current draft only does what I needed and I was only using v. simple HTTPS RRs. My first cut for such things would be to handle 'em by allowing that kind of data to be part of the JSON responses. Be nice if there was some way to characterise what kinds of data make sense there so avoid the potential slipperly slope though. (I do agree about inner alpns though - that definitely makes sense.)
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 atall.
Well, my focus has been on where the ECH front-end (whether shared or not) is a web server on which the ECH key pairs are generated, so using HTTP there seems natural to me.
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 theirHTTPS record.
Could be. My guess is organisationally that'd be harder to arrange, for organisations where different people manage the DNS and web servers.
This would avoid asking DNS servers to become HTTP clients.
I figure the zone factory thing is more likely a hidden primary or similar so I don't think that's tricky, but fair point I guess.
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).
Yeah, another benefit of HTTP is server authentication. An HTTP client in the zone factory also enables validation that the ECH keys provided actually do work, before publishing them in the DNS, which seems desirable to me.
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.
I thought about that (and it's noted in the draft.) The argument against is that the retry-configs (at least as I provide 'em from web servers) only include the most-recent ECH public key whereas the HTTPS/SVCB RRs include that plus the older ones that still work. I would guess what one gets in retry-configs might be too variable to use as the source of data to publish in the DNS. And of course, you'd also miss out on the other data (alpn etc.) you'd like to see in the JSON or wherever.
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.
Again, I'd argue that'd all be better done after WG adoption. Cheers, S.
[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_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
