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. 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?
>>
>> 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 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 -- [email protected]
>> >> To unsubscribe send an email to [email protected]
>>
>>
>>
>> --
>> Astra mortemque praestare gradatim
>>
>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
