[changing the subject since I expect this to mostly be a tangential
discussion]
On Sat, May 4, 2024, 09:12 Stephen Farrell
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
