I don't think we need to determine whether ECH is relevant for the DNR use case. Indeed, ECH as presently specified will generally fit inside the 250-octet limit. My point is that we are setting ourselves up for a very painful compatibility challenge if longer SvcParams come into use in the future. I can certainly imagine longer parameters (e.g. signed objects with certificate chains) that might be useful in DNR.
Even if longer SvcParams aren't useful in DNR, creating an encoding that can't carry them introduces a serious compatibility problem for systems that copy between SVCB, DNR, and RADIUS. What is such a tool supposed to do when a valid SVCB record or DNR option is unrepresentable in RADIUS? What is a naive operator to do, faced with this error message? I understand that we can't eliminate this problem, due to the 4K limit, but I think it's worth avoiding it as much as we can, even if it costs us a page or two of standards text. --Ben On Thu, Oct 13, 2022 at 9:03 AM Joe Abley <[email protected]> wrote: > Hi Mohamed, > > I may well have missed some nuance in the discussion that came before, but > I found this comment interesting: > > On Oct 13, 2022, at 03:41, [email protected] wrote: > > This specification targets typical broadband services in which the use of > ECH is not relevant. It does not make sense for ISPs to be hosting multiple > domains on the same IP address as the encrypted DNS resolver. > > > Can you say why? > > If an operator has invested in infrasructure designed to be able to handle > TLS and HTTP at high volumes with high availability, does it not seem > possible that they would seek to reuse that general TLS/HTTP infrastructure > for multiple purposes? If ECH is relevant in other services carried over > HTTPS, why is it definitively not relevant for this one? > > > Joe > -- > Add mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/add >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
