Hi,
I've created an issue for this in the repo. [1] I agree that we probably need some change to the JSON similar to that proposed below. (I'd not pick 'scheme' as the field name though:-) I'll go look see how SVCB is being used or proposed elsewhere and propose something. Cheers, S. PS: @Watson - ping if you think other issues ought be raised on the repo - I think, but am not fully sure, that the other points you raised were addressed in the list discussion or off list. [1] https://github.com/sftcd/wkesni/issues/59 On 11/09/2025 08:35, Ted Hardie wrote:
Hi Watson, Sorry for the delayed reply; I was travelling and in meetings that past few days. The label is derived from the relevant URI scheme. I'm guessing you are concerned that that the JSON at the .well-known URI needs to have a way of disambiguating which protocol is at issue for the parameters given, in the case that a single .well-known URI wants to have data about more than one scheme (say, ftp and rsync at file-access.example.com). I've had a quick off-list exchange with Stephen, and it looks like something like this might work to eliminate ambiguity in that case: { "regeninterval": 3600, "scheme": "xmpp" "endpoints": [ { "priority": 1, "params": { "ipv4hint": [ "192.0.2.1", "192.0.2.254" ], "ipv6hint": [ "2001:DB::ec4" ], "alpn": [ "xmpp-client"] } } ] } By adding an explicit reference to the URI scheme, you eliminate any ambiguity. Does that resolve the issue you were concerned about? regards, Ted Hardie On Sat, Sep 6, 2025 at 3:44 PM Watson Ladd <[email protected]> wrote:On Sat, Sep 6, 2025, 7:06 AM Ted Hardie <[email protected]> wrote:Hi Watson, Quoting and replying: "I don't believe the draft supports it now and it would take changes to add in SVCB support that I don't think have been contemplated yet. One issue in particular is that SVCB records don't live at the name associated to the origin, but rather at a special label prefix. That prefix differs by service, so at minimum would have to be added into the JSON to show what service is being talked about. I'm sure there are others." The draft defines the well-known URI based on SVCB, so I'm a little surprised to see "not contemplated yet" as a description of the state of play. The JSON in section 5 also shows in the params section the set of SVCB entries its providing data on: { "regeninterval": 3600, "endpoints": [ { "priority": 1, "params": { "ipv4hint": [ "192.0.2.1", "192.0.2.254" ], "ech": "AD7+DQA6NAAgACCn3zNTeX/WOD...AAA==", "ipv6hint": [ "2001:DB::ec4" ], "alpn": [ "h2", "http/1.1" ] } } ] } The draft doesn't mention directly that a different label prefix would be used for each of the different entries, and I agree that it would be useful to mention that, along with a reference to RFC 9460's section 2.3 (and maybe 7 for one of the original examples). If you think the draft needs additional clarity on how SVCB works, that might make sense, but I think we should be careful to rely on the original descriptions as much as possible, whether in RFC 9460 or the later protocol mapping documents.What prefixes would be associated with the above? And would it make an HTTPS record?regards, Ted Hardie On Fri, Sep 5, 2025 at 6:00 PM Watson Ladd <[email protected]> wrote:On Fri, Sep 5, 2025 at 3:07 PM Ted Hardie <[email protected]> wrote:Hi Watson, A clarifying question in-line. On Thu, Sep 4, 2025 at 2:38 PM Watson Ladd <[email protected]>wrote:On Thu, Sep 4, 2025 at 5:24 AM Stephen Farrell <[email protected]> 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. Thetextisn'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 elseappropriate.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 SVCBrecords? I don't believe the draft supports it now and it would take changes to add in SVCB support that I don't think have been contemplated yet. One issue in particular is that SVCB records don't live at the name associated to the origin, but rather at a special label prefix. That prefix differs by service, so at minimum would have to be added into the JSON to show what service is being talked about. I'm sure there are others.Speaking personally, I think it is worth keeping support for SVCB inthe 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, TedSecondly 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 ECHConfigvalue(after all the REAL backend took that data from there) plus alltheother 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 facingserver toput the DNS data on example.com. However it's talking tocf.lb.exampleto 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 totalkto the REAL backend and put that data in for example.com. Thiswayit'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 haswriteaccess to A/AAAA RRs for a backend, SHOULD NOT publish HTTPS RRsthatcontain ipv4hints or ipv6hints that are in conflict with thecorrectA/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 havewhateverIP 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 ratherunderspecified.It should just be copying the correct configuration from cf.lb.example. The CDN/load balancer/etc knows how to set up DNSforit to work right, the only thing backend.example.com can do ismess itup.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 rememberthatCNAME is the only record allowed on a zone, and CNAME wouldresolvethe HTTPS record. So what exactly is the setup here that gets the right A and AAAA records for the backend.example.com and usesthe CDN?If this only applies to cases where IPs are specified bycustomers, itwill 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 -- [email protected] To unsubscribe send an email to [email protected]-- Astra mortemque praestare gradatim
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
