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

Rob Sayre <sayrer@gmail.com> Fri, 29 March 2024 22:27 UTC

Return-Path: <sayrer@gmail.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 0D90BC14F68B; Fri, 29 Mar 2024 15:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 NgrvdeCY1zfB; Fri, 29 Mar 2024 15:27:20 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 7DFAFC14F5E9; Fri, 29 Mar 2024 15:27:15 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2d700beb60bso45761151fa.1; Fri, 29 Mar 2024 15:27:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711751233; x=1712356033; 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=qcWz4UepEoD8BeOpYCRjz4EpiSTopDVUN5fbxNiFPFM=; b=QhNs9E1dB0UwlHdgPmEzfoKsJKVtDQWosOtNJKLwPWL3F9VCqCPwCRDuAJAoDgr0cZ kM3ju0+qN69MsYmYe0tMGw0yHHGly/Dv26nwB5fXumfCY3mWySRqCNenM1aBU9yoaWM6 BcrR2C4m2BPQeHZ1mtSV4yRjvJBCjtlZqg43fKwasZVWzpz5UKPE8zrBY8FHCuWmx72p hDFaSzDctOuMm+Qixrt7dZ9lIRPNK4jb+5PzMkjfUTRSA8B4RZswfhfvY4MZZzt+hRt7 +1ZbScvGBGcxyCM3ksIBH4gAARJC9Qye+jeBaj3fttu/9GIrJd/tSG2lhp7dMBtiuqkh 5VwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711751233; x=1712356033; 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=qcWz4UepEoD8BeOpYCRjz4EpiSTopDVUN5fbxNiFPFM=; b=ptc6cLv+ZU6ydxSCJqqGO9Da34HcGsaJFYXmkrMje8z67ujT1WRqe9rM0tZEro5ptb 4V+tnvWkXE9wi5cuh3ejaG7VW43xrKP/g7d/oUllu0+tivgOshdjtGwiL76Hga2BQx+S jwUENrfY+wOUHES9qUSRXzADhTRHljtXETTGwylFDpKoxNgy5tJx0oOW7S9QkS4iZfQN IlsrEepNV23aN+4yweum8qR595krhYZGHvCl3FjW9CNQdv5fuiWddptQ7mlqRgOuWT0p ZeT8bdKGUPd+xxd4PnQhKJw4B9u2iORn019zAc2wQGJsv9L+Ic7b9vCUH5tFNWXsiJMu 1puw==
X-Forwarded-Encrypted: i=1; AJvYcCXTRhACa9f/Aqc4rA8WE52Q3cwiwun/ndguXuaW297MlQG6MoRJRpQUBCu+djcmxQPuuhivVZ1Jzy3DB51/pwlHc/YIyoIOrvJdQsETnOOdbYFmrYWaA/lPRv7pNgVOn7a3Hw==
X-Gm-Message-State: AOJu0YwX1+yHamf6hYu5z5i+tmddUALr2LYCQehE8TdpPW6RjdFRORbB GSKaQh4GqZxvZBW4Xu9bTb5fPekKdJVWnwAcl4pTsxJYmo07irI92JEniemFkFpp+ka4Ysife8r i/w8edsrk0qYAhJ6FgiPaPFheTdUgz6nEMXdL3A==
X-Google-Smtp-Source: AGHT+IHZEaitepqphUYxmeOeCPpd9Vdq37GctCNddN3efP/MvV/K5fM/0MtpmdlDjCZaKM5QRHZtXpKjEnhCsfmOcyY=
X-Received: by 2002:a2e:b16a:0:b0:2d6:fa7a:a670 with SMTP id a10-20020a2eb16a000000b002d6fa7aa670mr2550543ljm.33.1711751232764; Fri, 29 Mar 2024 15:27:12 -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>
In-Reply-To: <CAPt1N1knx=+K627L6rsf4nGuiwpSXjWoMB4QcMfwhJdaGKypUw@mail.gmail.com>
From: Rob Sayre <sayrer@gmail.com>
Date: Fri, 29 Mar 2024 15:27:01 -0700
Message-ID: <CAChr6SxKA7YidnYWW=6DOWeQo+_CKNaWNOQL9JQnJUB3thgBhw@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: dnsdir@ietf.org, draft-ietf-tls-svcb-ech.all@ietf.org, tls@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002c4a520614d42482"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/54V_3d2xq6MGY8e7BOFrIWJ8xjM>
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: Fri, 29 Mar 2024 22:27:22 -0000

It's a policy choice, though, right? I think ekr hinted at this issue as
well.

It's that one might also view requests that reveal the SNI as insecure. If
that's the case, DNSSEC doesn't help. There will certainly be a transition
period where that will be impractical for many servers. I think these are
separate problems, though.

thanks,
Rob


On Fri, Mar 29, 2024 at 3:10 PM Ted Lemon <mellon@fugue.com> wrote:

> It looks like if you can't get the SCVB you're going to fail insecure, so
> being able to use DNSSEC to prevent that for signed domains seems
> worthwhile.
>
> On Fri, Mar 29, 2024 at 4:41 PM Rob Sayre <sayrer@gmail.com> wrote:
>
>> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
>> noreply@ietf.org> wrote:
>>
>>>
>>> I don't think it's reasonable to specify the privacy properties of SVCB
>>> and
>>> /not/ talk about DNSSEC validation.
>>>
>>
>> Could you explain more about this part? I think DNSSEC doesn't add much
>> here, unless you want to accept non-ECH traffic. For example, many of the
>> test servers will bounce you to some other site if you don't send ECH or
>> screw it up in some way (speaking as someone who has screwed it up many
>> times...).
>>
>> I think there might be a DoS attack here, where someone messes with the
>> response, but they can also turn off the DNSSEC bit unless it's DoT/DoH/DoQ
>> etc. So, if using those, it's just the trustworthiness of the DNS server
>> itself, right? Sorry if I'm missing something.
>>
>> thanks,
>> Rob
>>
>>