On Tue, May 7, 2024 at 8:07 AM David Benjamin <david...@chromium.org> wrote: > > [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.)
The one reason I could see this being a problem is that the HTTPS RR RFC specifies per-key wire format encodings. If we use presentation format and import it all en masse we need to deal with what happens when the DNS infrastructure doesn't understand a ScvParamKey. If we encoded wire format somehow in the JSON, people making these would be sad. But I like the idea of extending this mechanism vs. making a new one. Sincerely, Watson > > David > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
