Hiya,
On 09/05/2024 00:01, David Benjamin wrote:
Actually, I think one thing that could help is one of your drafts! Onebarrier 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 iscurrently 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.
OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
