Hi Watson, A clarifying question in-line.
On Thu, Sep 4, 2025 at 2:38 PM Watson Ladd <watsonbl...@gmail.com> wrote: > On Thu, Sep 4, 2025 at 5:24 AM Stephen Farrell > <stephen.farr...@cs.tcd.ie> wrote: > > > > > > Hi Watson, > > > > On 04/09/2025 00:58, Watson Ladd wrote: > > > Dear TLS WG, > > > > > > I've read the draft carefully, and I am afraid that I have a few > > > comments. These might be completely uninformed, but I hope they at > > > least point out places other people might have confusion, > > > > Comments are welcome, esp. good ones like these! > > > > I'll make issues/PRs once you've had a chance to respond. > > > The first comment is that while the draft talks a lot about HTTPS > > > records, it could also work for non-HTTP protocols via SVCB. The text > > > isn't entirely clear on this point one way or the other. > > True. I guess there're a couple of ways one could go with that: > > > > - just add some text saying the ZF needs to know whether an HTTPS > > or SVCB RR is to be published (which has been my assumption) > > - add a field/flag to the JSON saying which is desired > > > > I guess there's also the issue of the ZF verifying that the content > > in the JSON works - we probably need a sentence saying that if the > > protocol isn't HTTP then the ZF should do something else appropriate. > > Ben Schwartz pointed out privately that we might need something a bit > more complex here. Maybe start with HTTPS only for now in the text and > if there's demand, can always write something short to say how to > extend. > Is it your thinking that the draft ought to drop support for SVCB records? Speaking personally, I think it is worth keeping support for SVCB in the draft, given that it is going for experimental status. The experiments to deal with it would be a pretty valuable output, at least in my opinion. As it stands, what interests me most about the draft is that the mechanism would actually be pretty general purpose, and there are enough other uses of SVCB out there (https://www.iana.org/assignments/dns-svcb/dns-svcb.xhtml) that I think it is worth the effort. Just my two cents, Ted > > > > > Secondly I'm not sure I understand the split mode example in the > > > draft. > > > > It is a bit sketchy indeed. (And perhaps why this ought to > > be experimental - I don't know of anyone else who's deployed > > split-mode.) > > > > > The zone being made is the backend.example.com zone, but the > > > data for that zone seems to come from the load balancer machine. > > > > At least the 'ech=' will, yes. Not sure about other values, but > > as that set can be extended there could be more that need to come > > from the cfs. > > > > > However, the load balancer machine has to know its own ECHConfig value > > > (after all the REAL backend took that data from there) plus all the > > > other relevant bits of the HTTPS record. Why does the REAL > > > backend.example.com need to compute any part of the HTTPS record? > > > > Things like TLS groups would come from the backend so the backend > > needs to be the one to construct the JSON. > > > > > Once > > > that's computed, the zone builder talks to the client facing server to > > > put the DNS data on example.com. However it's talking to cf.lb.example > > > to get that DNS data. > > > > Yep. The ZF doesn't necessarily know that split mode is in use. > > > > > I think it would make slightly more sense for the zone factory to talk > > > to the REAL backend and put that data in for example.com. This way > > > it's clear how the administrative ownership and flow of data are > > > aligned. > > > > But the A/AAAA for backend points at the cfs, so the ZF would > > need to know more. I constantly confuse myself about this, esp > > when I think about possible multi-CDN setups. > > It's also the case that the REAL backend might not be available to the > ZF because of the setup. > > I think actually we're ok: the ZF can just resolve the name that we're > trying to set up even the first time without knowing the HTTPS record, > find the data, check it, and make the record. It has to work somehow! > As for A/AAAA aligning with HTTPS, > > > > > In Security Considerations I see "Similarly, a ZF that also has write > > > access to A/AAAA RRs for a backend, SHOULD NOT publish HTTPS RRs that > > > contain ipv4hints or ipv6hints that are in conflict with the correct > > > A/AAAA values unless those have been verified (via webPKI) as > > > belonging to the same backend". To my mind this is written > > > incorrectly: its not the backend that has the IP, but the hostname > > > we'd like to resolve consistently. > > > > Sorry, not getting the point. Can you say what you'd like it > > to say, or explain more? > > I think what confused me is IP address of a server, vs. the IP > addresses a name resolves to on the public Internet. When both are > called backend I'm confused. In some sense "backend" is largely > irrelevant. It's just somename.example that wants to use ECH on > lb.example.net, and the box hosting somename.example can have whatever > IP and other names it wants. More textual/editorial than anything else > I think. > > > > > > And that brings me to another point: the processing done by the > > > backend in creating this file in split mode is rather underspecified. > > > It should just be copying the correct configuration from > > > cf.lb.example. The CDN/load balancer/etc knows how to set up DNS for > > > it to work right, the only thing backend.example.com can do is mess it > > > up. > > > > Not sure I agree there, though we probably have to speculate > > a bit about split-mode, so hard to be sure. For a split-mode > > backend to make real sense, there'd likely need to be a VPN > > or something between the cfs and backend, so I'd hope that > > messing this up was less likely on the basis that it'd be a > > "sophisticated" CDN customer. Also its only the backend that > > knows all the TLS settings in split-mode, so the cfs can't > > know those for all of a set of split-mode backends. > > > > > Lastly, and I'm not a DNS person by any means, I seem to remember that > > > CNAME is the only record allowed on a zone, and CNAME would resolve > > > the HTTPS record. So what exactly is the setup here that gets the > > > right A and AAAA records for the backend.example.com and uses the CDN? > > > If this only applies to cases where IPs are specified by customers, it > > > will be a very narrow situation. Or are we anticipating HTTPS only > > > CDNS (will never happen for install base/compatibility reasons)? I > > > know this got discussed in the adoption call but sadly my archive > > > searching skills are not finding the relevant emails. > > > > Sorry, I'm not sure what you mean again. Maybe an example may > > clarify? > > Ben puts forward a few usecases that make sense: > 1 Mixing HTTPS records for MultiCDN > 2: AliasMode not supported > 3: Additional SvcParams that the CDN doesn't know in split mode > > Might be worth adding them somewhere as additional motivation. I might > go open a PR today/tomorrow with some suggestions, but this is > dependent on tuit supplies. > > > > > Thanks again, > > S. > > > > > > > > > > Sincerely, > > > Watson > > > > > -- > Astra mortemque praestare gradatim > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
