[changing the subject since I expect this to mostly be a tangential discussion]
On Sat, May 4, 2024, 09:12 Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > I hope, as the WG are processing this > [draft-davidben-tls-key-share-prediction], we consider what, > if anything, else could be usefully added to HTTPS RRs > to make life easier. > 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 We might also think about the extension model for that document. Does each SvcParamKey opt into use with the document, with its own JSON key and text describing how to map it, or should we just use the presentation syntax and import it all en masse? (I'm not sure. The latter would certainly be less work for new SvcParamKeys, but I'm not sure what the implications would be of the DNS frontend picking up SvcParamKeys it doesn't understand. Then again, we seem to have happily imported basically all the existing keys anyway.) David
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
