[TLS] Re: Comments on draft-ietf-tls-wkech-09

[Stephen Farrell]

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.

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.

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?

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?

Thanks again,
S.

Sincerely,
Watson

OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org