From ekr@rtfm.com Sat Mar 30 16:18:31 2024 Return-Path: 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 327CDC14F615 for ; Sat, 30 Mar 2024 16:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 kt9F2FwVnsuN for ; Sat, 30 Mar 2024 16:18:26 -0700 (PDT) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 A37FAC14F616 for ; Sat, 30 Mar 2024 16:18:26 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id 5614622812f47-3c38eced701so1728231b6e.1 for ; Sat, 30 Mar 2024 16:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1711840705; x=1712445505; 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=EAz2gF/ppSd+Kd0AlvCXuTKY6n5MvpZxEcTBZjxyEoI=; b=NPJIRGkwBE8D53D6METR1jiqUkrJnuITG9GmKI72lSjom6h6o86NYG+UjDlVvrc4G0 JsZAxG5wasbxucVue+b0McL1hJZg5mpvA9NpSPcn0rTDqiNlXR8s5k4KZdpXSsvYEtoW VeCylp5JdL9n+adC376bigS22kugyQ0NMlCwmFmuWnvFzImefVD+z3rjYv0lQwXjlqwx qRwsDWOnCxUgGlcMK2BMD+zeoWpdcrSezBey2MhZsD6FjYUCvPhKuZK0oJs1szLhg9qL LrtPHk1P0skDN9BgqXkrR0Xwvt3iI5T8KDbtuFB/szkyoaWX0nmAEAi0m10aTDx+c8Mf 3czA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711840705; x=1712445505; 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=EAz2gF/ppSd+Kd0AlvCXuTKY6n5MvpZxEcTBZjxyEoI=; b=UEzFOLEnjEocY/u/4vTHaJ3EULgYoUJByyTsmkwEwC53Y/duE2J+phWQw2a5uXo2WL iBRc9Dk3oToj6TkcSXhWOH6wah2eUNxlSdZkNqK6wcdc8NAEq3vfhca3wkMZ84JvVOBD 6R9xaU/4JcvOaRYjZkFc/FnVHwiMAnIIOXJOofcu/WsOMKpPuwUOuT7mHjJnkJaFNV0v LbYEbOsCepiKWGgL2o17dPczPfv8DPTPLKLPf/5xO3kxDW+Q54WIsb+hf0XhfTkyD4SR FHWSlfbAvfIuerEP6tlnuyrwfiJGDwQluzGUe/+VQbb1DYfZlf8e99d28SQ/tJdRiPjE 6Oog== X-Forwarded-Encrypted: i=1; AJvYcCUu/gF7QlMinVwHv95buXKJoftGqlSTwj8zhmvo4t1xA2tyM9d6q1VhmJl1SP6AG7kC0SA8+q4jXVmi/rU= X-Gm-Message-State: AOJu0YzfZFl08ciHE1gqxJ4qpsmaX/DUpxCWfCug74n+XQzmXOaJizQC a04Oiyr7bMCzM13s6sCoSei4rS5ZCs+Vq/Ptx47MfVnlLJmcmUn2x6YF41pDSVYZr0H6e1TFpwX 1K8vlN/OJ4xchZdKS0620rtCtUD4vSxBptnZKaA== X-Google-Smtp-Source: AGHT+IEuobwvBrA/0axtbwEjfzvRqueQLYYMuSIctJU6Gm/QhKY4FQfcBhFH/kGkyQliQ6ey0sFMuaCghkgKK3LC3uA= X-Received: by 2002:a05:6808:114c:b0:3c3:6500:66f1 with SMTP id u12-20020a056808114c00b003c3650066f1mr7305809oiu.43.1711840705332; Sat, 30 Mar 2024 16:18:25 -0700 (PDT) MIME-Version: 1.0 References: <171174253501.29384.9373864670898234756@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Sat, 30 Mar 2024 16:17:48 -0700 Message-ID: To: Ted Lemon Cc: Rob Sayre , Erik Nygren , dnsdir@ietf.org, draft-ietf-tls-svcb-ech.all@ietf.org, tls@ietf.org Content-Type: multipart/alternative; boundary="0000000000002766a50614e8f9e8" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2024 23:18:31 -0000 --0000000000002766a50614e8f9e8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Mar 30, 2024 at 11:09=E2=80=AFAM Ted Lemon wrote= : > Encrypted dns transport works if you can trust the provider you are > talking to. DNSSEC works even if you can=E2=80=99t. And if your provider = is > trustworthy, DNSSEC validation of results acquired through this tunnel > should work. So it=E2=80=99s silly in this case to trust the tunnel=E2=80= =94there=E2=80=99s no > upside to doing so other than avoiding a few signature verifications. > I don't object to people doing DNSSEC validation of ECH records (though AFAIK no major browser does so), but... 1. The resolver only gains a limited amount by forging the SVCB response because the resolver already knows the domain name you are going to. This does conceal (say) the ALPN, but that's usually less interesting than the SNI. 2. If the authoritative domain is misconfigured, which is not unheard of, then this can create resolution failures (this is true for A/AAAA, of course). Probably not much of an issue for the big public recursives, but can definitely be an issue if you are just talking to some locally-supplied resolver. -Ekr > Op za 30 mrt 2024 om 14:02 schreef Rob Sayre > >> On Sat, Mar 30, 2024 at 10:47=E2=80=AFAM Erik Nygren >> 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 w= hen >>> the client and recursive resolver validate DNSSEC and use a secure >>> transport. These downgrade attacks can prevent a client from being awar= e >>> 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 >> >> --0000000000002766a50614e8f9e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Mar 30, 2024 at 11:09=E2=80= =AFAM Ted Lemon <mellon@fugue.com> wrote:
Encrypted dns transport works if you can trust the provider = you are talking to. DNSSEC works even if you can=E2=80=99t. And if your pro= vider is trustworthy, DNSSEC validation of results acquired through this tu= nnel should work. So it=E2=80=99s silly in this case to trust the tunnel=E2= =80=94there=E2=80=99s no upside to doing so other than avoiding a few signa= ture verifications.=C2=A0





Op za 30 mrt 2024 om 14:02 schreef Rob Sayr= e <sayrer@gmail.co= m>
On Sat, Mar 30, 2024 at 10:47=E2=80=AFAM Erik N= ygren <erik+= ietf@nygren.org> wrote:

An attacker who can prevent SVCB resolution can den= y clients any associated security benefits.
=

Yes.
=C2=A0
A hostile recursive resolver can always deny se= rvice to SVCB queries, but network intermediaries can often prevent resolut= ion as well, even when the client and recursive resolver validate DNSSEC an= d use a secure transport. These downgrade attacks can prevent a client from= being aware that "ech" is configured which would result in the c= lient sending the ClientHello in cleartext.
=

I think s/would/could/ here.

I= don't know if we want to write it, but doesn't=C2=A0using encrypte= d transport DNS to an IP=C2=A0address avoid this problem? Like using 1.1.1.= 1 or 8.8.8.8 etc. I know that raises centralization issues, but it does hel= p with this issue.

thanks,
Rob

--0000000000002766a50614e8f9e8--