On Wed, May 8, 2024 at 3:50 PM Watson Ladd <watsonbl...@gmail.com> wrote:
> 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. > I think there's a generic form for the presentation format (which is basically the wire format but with more ASCII), but yeah the person assembling the .well-known file has no good way to tell when something was dropped. I think that concern applies to every option short of using the wire format though. Even using string names for the keys must account for the DNS frontend being unaware of the key. David
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
