Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

Ted Lemon <mellon@fugue.com> Sat, 30 March 2024 18:09 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595E9C14F61F for <tls@ietfa.amsl.com>; Sat, 30 Mar 2024 11:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20230601.gappssmtp.com
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 mnhagVKX7ymp for <tls@ietfa.amsl.com>; Sat, 30 Mar 2024 11:09:57 -0700 (PDT)
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 BB782C14F61E for <tls@ietf.org>; Sat, 30 Mar 2024 11:09:57 -0700 (PDT)
Received: by mail-oi1-x229.google.com with SMTP id 5614622812f47-3c4de6ea593so408788b6e.1 for <tls@ietf.org>; Sat, 30 Mar 2024 11:09:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1711822196; x=1712426996; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nK8nAjLqJO/oRigUaRSeoU/xcMTUU2M+Zo/exBkte+s=; b=2B6wuYvs3F/vXsD6BFydo8RBxbPYUiTqJgThoAdK4D085tqGMJjgD45gNv+wTkr8Mp 1J8HBfmXL9973dh9mhZXZUU8cZD0NaFO9XZn3/laItqocI+liz4fM3MbrrLpwjfHA0bs Y0dXcytjQdkUf5sAqs+Y+NQq844D2J20DQzjzBFD3c0hzs9eL/n5WQnXj3SeY8zIoCq9 u6bMmN8hEUrsknKrX2SCkW4inRc4gKj3aaWi21TElLlMW62ip0UvsymtH7QttVkmlpzm f44FFFe/1mhpm9f+lsrq6pUu/bycYu/XF1eB8keUXE+0SDti2Ey1d2nJ9CuuoMYaGoZ2 PZEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711822196; x=1712426996; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nK8nAjLqJO/oRigUaRSeoU/xcMTUU2M+Zo/exBkte+s=; b=eCg9A6Ms6tk3n+Pe0Q1BHuCMuPe6c5r88Ne1du8BbIFQtawox9ns955vasOZlpqDAS Y9iwzFirTx7vnMwmcl38SKEwHxWghkKLM+/lnHSW2p029FIdpUjL4KjIJpCu6cmFBQrc NBsHXUNCkRcOBIotUO2jdOvXBWreFk/2IiQWgJ7+qjWPpeQM57UThSv49WAtJeuNiv0L LZ2TgQ1HOoIWyTHCfHFFXJaBjzce55KvxfVda0AQ7fdpm+C6+BRRMq8UWDfSgRBemjza dj4PZDJHlmuZ+pg1lePXIdaRW4UOKgn24bfELo5h4TLnVwFPfyEI4N/lx6syrIq7hcal ZMFA==
X-Forwarded-Encrypted: i=1; AJvYcCXF0iQLu+4kZwq4gzKsE9yod5Sc3EX9K9H7yJPBDXvNLJPNkJEe7NJnP6bjYcUT1N74kgv/qbesAQEPE0w=
X-Gm-Message-State: AOJu0YzHYbMYhmafITZNwmpHpFba0h7jl0XdkEOFtEFqIoIWWHjbS7Q4 aK2iPfbwXrvfgXaKudSiAjwWiteTD92JFjQHiUUnPHswUEXsxVtnjIkXSBExwwD5mxEzq0RNQ11 CPERGEIy1PNC4tBhdQp+uLLlwGBXYDas7KiKILw==
X-Google-Smtp-Source: AGHT+IHgfsRpUoCK4VKj+5DFbAcfWoFfeV7U8gdKqHY8QxrtJJ/0GvD4akysf8qiQnG7Xe5NWFzMsBEi+sKSuIlM4to=
X-Received: by 2002:a05:6808:3c86:b0:3c3:d587:4ac with SMTP id gs6-20020a0568083c8600b003c3d58704acmr6789924oib.25.1711822196530; Sat, 30 Mar 2024 11:09:56 -0700 (PDT)
MIME-Version: 1.0
References: <171174253501.29384.9373864670898234756@ietfa.amsl.com> <CAChr6SwCKV4P_xab_3dKSwKDfPdxjz3WinQaWebMcXh8-_xy0g@mail.gmail.com> <CAPt1N1knx=+K627L6rsf4nGuiwpSXjWoMB4QcMfwhJdaGKypUw@mail.gmail.com> <CAChr6SxKA7YidnYWW=6DOWeQo+_CKNaWNOQL9JQnJUB3thgBhw@mail.gmail.com> <CAPt1N1=snvSeQ74xs=HNVyszxjTD1SPMxw3+BVh-5-HBnOcZag@mail.gmail.com> <CAChr6Sx0WX-X3dWjkwMJAa4Rz3BhnUdYMFwWgLkorm6d-16g1w@mail.gmail.com> <CAPt1N1=LzjPMfADvdTdt_kCZ3XTznKs4p4_FYAH_RDb6WVcv7w@mail.gmail.com> <CABcZeBMVbi2_0yaTTe+-U2cBWqscXAdhcrwPufKNg0a-8U292A@mail.gmail.com> <CAPt1N1kEVk6MEHqnXAPenRp057eTDhptxsstcxyEkXqWBdyHQA@mail.gmail.com> <CAKC-DJiEWYDmz3EdPq2hjpR6kGPAnRPTA9H1HAwo4BR-1XG=mQ@mail.gmail.com> <CAPt1N1kNCr+khExy8ajksPakgsQtnPWC4ckmwB9kZDhQk4Cywg@mail.gmail.com> <CAChr6SwMVuCT7trjZVdG-zhGX21vMK9iu_th+Pc7_94s9hZ8bg@mail.gmail.com> <CAKC-DJi2NqpRfxb3cHbvdK+cSLBkSP7XkH4oqEQ3CxkSvRq8Kg@mail.gmail.com> <CAChr6SwoKqvrsKbm-K3vK793sn0p1WR2wky8cJSR-JbHytEBiA@mail.gmail.com>
In-Reply-To: <CAChr6SwoKqvrsKbm-K3vK793sn0p1WR2wky8cJSR-JbHytEBiA@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Sat, 30 Mar 2024 14:09:45 -0400
Message-ID: <CAPt1N1mZNXN+cEjgmOULMcWOi-pb7cuzD-rw10mgXQSqFH9rWA@mail.gmail.com>
To: Rob Sayre <sayrer@gmail.com>
Cc: Eric Rescorla <ekr@rtfm.com>, Erik Nygren <erik+ietf@nygren.org>, dnsdir@ietf.org, draft-ietf-tls-svcb-ech.all@ietf.org, tls@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f17d660614e4a954"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/yFPTqqfQw-l6qnhUlM_WR_iVTLM>
Subject: Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Mar 2024 18:09:59 -0000

Encrypted dns transport works if you can trust the provider you are talking
to. DNSSEC works even if you can’t. And if your provider is trustworthy,
DNSSEC validation of results acquired through this tunnel should work. So
it’s silly in this case to trust the tunnel—there’s no upside to doing so
other than avoiding a few signature verifications.

Op za 30 mrt 2024 om 14:02 schreef Rob Sayre <sayrer@gmail.com>

> On Sat, Mar 30, 2024 at 10:47 AM Erik Nygren <erik+ietf@nygren.org> wrote:
>
>>
>> An attacker who can prevent SVCB resolution can deny clients any
>> associated security benefits.
>>
>>
> Yes.
>
>
>> A hostile recursive resolver can always deny service to SVCB queries, but
>> network intermediaries can often prevent resolution as well, even when the
>> client and recursive resolver validate DNSSEC and use a secure transport.
>> These downgrade attacks can prevent a client from being aware that "ech" is
>> configured which would result in the client sending the ClientHello in
>> cleartext.
>>
>>
> I think s/would/could/ here.
>
> I don't know if we want to write it, but doesn't using encrypted transport
> DNS to an IP address avoid this problem? Like using 1.1.1.1 or 8.8.8.8 etc.
> I know that raises centralization issues, but it does help with this issue.
>
> thanks,
> Rob
>
>