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

On Thu, Oct 13, 2022 at 7:51 AM Ben Schwartz <bemasc=
40google.com@dmarc.ietf.org> 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 <jabley@hopcount.ca> 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, mohamed.boucadair@orange.com 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
>> Add@ietf.org
>> https://www.ietf.org/mailman/listinfo/add
>>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>