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. 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]
