[TLS]Re: HTTPS-RR and TLS

[Stephen Farrell <[e-mail]>]

Hiya,

On 09/05/2024 00:01, David Benjamin wrote:
>>> Actually, I think one thing that could help is one of your drafts! One
>> barrier with trying to use HTTPS RR for TLS problems is keeping the DNS and
>> TLS sides in sync on the server deployment. Prior to ECH, this hasn't been
>> done before, so I wouldn't expect any deployments to have a robust path
>> from their TLS configuration to their DNS records.
>>>
>>> draft-ietf-tls-wkech seems like a good model for this, but it is
>> currently written specifically for ECH. What are your thoughts on
>> generalizing that document to cover other cases as well?
>>> https://github.com/sftcd/wkesni/issues/14

Thanks for making that GH issue. I'm fine with discussing
details there, and have no problem if the draft is more useful
if it's more generic, but have a question for the broader group
that may be better asked here:

What HTTPS RR parameters do we expect will see regular changes,
and controlled by whom?

It seems fairly clear that ECHConfig values will be changed
often, e.g. hourly, which I think motivates the wkech thing,
but I'm unclear how often other bits of HTTPS RRs might
change and who may be in charge of those in real deployments.

My mental picture is something like:

what, changes how often, controlled by whom
ech, maybe hourly, client-facing server admin
alpn, rarely, client-facing server admin
tls-supported-groups, rarely, client-facing server admin
ipXhints, unpredictable, DNS admin?

Does that look kinda right? Are there other things to
consider now?

Ta,
S.