Re: [OPSAWG] [Add] 🔔 WG LC: RADIUS Extensions for Encrypted DNS

[Ben Schwartz <[e-mail]>]

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 <[e-mail]> 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, [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>