IETF Logo Mail Archive

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

Joe Abley <jabley@hopcount.ca> Thu, 13 October 2022 13:03 UTC

Return-Path: <jabley@hopcount.ca>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A77C14F726 for <opsawg@ietfa.amsl.com>; Thu, 13 Oct 2022 06:03:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97OE7np-20qM for <opsawg@ietfa.amsl.com>; Thu, 13 Oct 2022 06:03:03 -0700 (PDT)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4933BC15256F for <opsawg@ietf.org>; Thu, 13 Oct 2022 06:03:03 -0700 (PDT)
Received: by mail-il1-x12d.google.com with SMTP id h18so909142ilh.3 for <opsawg@ietf.org>; Thu, 13 Oct 2022 06:03:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=PSNZNCF/7pnKE15/hOFlJklqEJTLV0d86bji1EFR6ww=; b=nE3nzH77r9xgt3ICVD7tuMO3LCP0jJ+s08LM8OBK93IaAQtzyLb5IPtQU2tBLmG+K7 ZNU3K7uELJc1sgQ0I8/ZQiXROA+eBv8bVIozXWXeJAR8I7Yyjdq8jBRnCckAEEnzFFc1 ua3lMO09mmQaCK/R+Ubw8b+D8GgZAj9L065gA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PSNZNCF/7pnKE15/hOFlJklqEJTLV0d86bji1EFR6ww=; b=pog6PSgoDOlObNTHacbJKx49GBkqU/DBWY0rRFHLnOZ+G49fLmUC4fb3zbxeEp92Rq GWp0Ffu4dsqrAXrx4p3Zy3pZIbueRvnF91nhUt/DqcesJ/nKI7LNGbF/NsVvIstlbpUc vB9aQcuPMHjESbPVjcah76y/ykCN4wvQfF1rRKh1wkj/SMulo1V2TEW3XIz34Z1QodKP M44LxNYCNEVEh+AjebESGOMnXCvgrsg7k00U5cLFgme6xYF/on93dyNhnn9e7YvQ9cce qUjOUCUvsKL4emHG1uvvCCSAhcFO7BMfnNhV9omlHeCmGqVTel001bi3RQaMezsdmv0k DKdw==
X-Gm-Message-State: ACrzQf2aIMDUnhxwaA5YygEmvNaLi/hZDN/9s4enrIZN38K8DYv78kmO bqWm8sED9QaD8+bkluwlwK343A==
X-Google-Smtp-Source: AMsMyM7O+5z7ueAF6LDhAbOv2BBI5bOnIWnchFr2pUrXWONRC3nvyPR369ZeRG5pxxlpihB/E5b0Eg==
X-Received: by 2002:a05:6e02:b49:b0:2fc:86c3:a9e9 with SMTP id f9-20020a056e020b4900b002fc86c3a9e9mr6807288ilu.200.1665666169603; Thu, 13 Oct 2022 06:02:49 -0700 (PDT)
Received: from smtpclient.apple ([2a09:bac0:29::82c:3f09]) by smtp.gmail.com with ESMTPSA id o14-20020a92c04e000000b002fc165318basm4743084ilf.30.2022.10.13.06.02.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Oct 2022 06:02:48 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-AE2731B2-158E-4E20-BBD0-2EF70B24951B"
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@hopcount.ca>
Mime-Version: 1.0 (1.0)
Date: Thu, 13 Oct 2022 09:02:46 -0400
Message-Id: <B6BBABE1-9194-4190-A84A-BA64889FC6E6@hopcount.ca>
References: <28766_1665646855_6347C107_28766_2_1_c61b294eae1742b4bfbf125d0fd0e92f@orange.com>
Cc: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, Alan DeKok <aland@deployingradius.com>, "Joe Clarke (jclarke)" <jclarke@cisco.com>, opsawg@ietf.org, radext@ietf.org, add@ietf.org
In-Reply-To: <28766_1665646855_6347C107_28766_2_1_c61b294eae1742b4bfbf125d0fd0e92f@orange.com>
To: mohamed.boucadair@orange.com
X-Mailer: iPad Mail (19H12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/oiEpZQxW9z_Ozq4F54kuoWL2R_Q>
Subject: Re: [OPSAWG] [Add] 🔔 WG LC: RADIUS Extensions for Encrypted DNS
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Oct 2022 13:03:07 -0000

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

v2.28.0 | Report a Bug | By Email | System Status