On Thu, Oct 13, 2022 at 7:51 AM Ben Schwartz <bemasc= [email protected]> wrote:
> 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. > +1 --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 >> > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
