From sean@sn3rd.com Wed Apr 10 06:14:30 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 D0D43C14F684 for ; Wed, 10 Apr 2024 06:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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=sn3rd.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 KhpUlUEYyrUF for ; Wed, 10 Apr 2024 06:14:26 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 AE0EEC14F5FA for ; Wed, 10 Apr 2024 06:14:21 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id af79cd13be357-78d6e7343d0so119606685a.0 for ; Wed, 10 Apr 2024 06:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; t=1712754860; x=1713359660; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=cdrDVgacacdeVKAZ9Ei3G5xt22igEMatr2OZeN+aeuY=; b=Qxfujl2hDGhKraFSkRZFQRo3mAtf0VKuDtehhOdpcKbOEUJqXXf2hcHWfKH7xLbN6L jI/u6EPBiCmLnpDZAzfhy12NnSdosQprjKDL3dzsfagDbd5LPkXg8NcC5vcVVw3ODsFX uJ1h9vgw3sohw0l4kLiFl4s5LO9b7faQCiKMY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712754860; x=1713359660; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cdrDVgacacdeVKAZ9Ei3G5xt22igEMatr2OZeN+aeuY=; b=mBVAWcZHe4YCWKNDWk7onGPW6copyF5seft8dMrG6bFqerF9QOrKCcF+oQe5u+nPpD XaP+vcSHMLxzcEObnEnM920mONbOqBiD+rClFpn1e1yqxISbuyTWXm+FZPruMKcMmPYf JtZCtf30XEZeb18oqABaDFWWzzKjhu2cO1gAR3aUzYiVezexV5yXgdKUNOjJouTEs4sZ 14CB2p5e/Chystj+6tVgMotIzV5cF4YBQN0g2I0rRxqE4gyAqma2PLkHcsubmJrHH3ma xrvdJ2O9E1eCvmptZXV1l3bDDxJGzjiJ0cglz+IsWpOqb+v4bfLAVTpWVMPVHMX0muWP OeIw== X-Forwarded-Encrypted: i=1; AJvYcCVQ97UDNmlqd37U3AXU9Ins3ZJR02MvIuOL/uc0SbBzs1y4oFfeKCKFv/y4jCmuyMC9PaK9AHs0YO5c6OU= X-Gm-Message-State: AOJu0YzJRQLvDnNDdWHtXdd6NTo0DwcBAhVR5A6y60CckSkkYNTSn5Ku OcvL5jT/l5t4eqp134N3BIyU3OJ9yc3dYqKduBXNDyMfNYannvBVsgo1KD5Bk7k= X-Google-Smtp-Source: AGHT+IGi/p4RdDRIjEIEHIdd49LPcol/pXmH72AuptLbvsf5vsUx7ekBOe/8sFcvg6D203J09oj/Yg== X-Received: by 2002:a05:620a:4009:b0:78d:65a3:173b with SMTP id h9-20020a05620a400900b0078d65a3173bmr9019569qko.1.1712754859965; Wed, 10 Apr 2024 06:14:19 -0700 (PDT) Received: from smtpclient.apple ([2a00:79e1:abd:dd02:683a:cbcc:9569:59f9]) by smtp.gmail.com with ESMTPSA id o1-20020a05620a228100b0078d55f97601sm4173740qkh.65.2024.04.10.06.14.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Apr 2024 06:14:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) From: Sean Turner In-Reply-To: Date: Wed, 10 Apr 2024 09:14:16 -0400 Cc: dnsdir@ietf.org, draft-ietf-tls-svcb-ech.all@ietf.org, TLS List Content-Transfer-Encoding: quoted-printable Message-Id: <4081DA2B-3A62-48F4-9B27-4036B14F4796@sn3rd.com> References: <171174253501.29384.9373864670898234756@ietfa.amsl.com> To: Ted Lemon X-Mailer: Apple Mail (2.3654.120.0.1.15) 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: Wed, 10 Apr 2024 13:14:30 -0000 Ted & ErikN, So it looks like ErikN submitted the following PR and ekr approved: https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/1 If we have resolved your comments, can I ask on of the authors to spin a = new version and we can look to move this I-D. Also, could I kindly ask you to revise your review to change to = =E2=80=9Cready=E2=80=9D and maybe refer to thread: https://mailarchive.ietf.org/arch/msg/tls/VQcqUuOXSE8sgcp4_CHa6Jlc394/ spt > On Mar 30, 2024, at 19:17, Eric Rescorla wrote: >=20 >=20 >=20 > 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.=20 >=20 > I don't object to people doing DNSSEC validation of ECH records = (though AFAIK no major browser does so), but... >=20 > 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. >=20 > -Ekr >=20 >=20 > 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: >=20 > An attacker who can prevent SVCB resolution can deny clients any = associated security benefits. >=20 > Yes. > =20 > 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. >=20 > I think s/would/could/ here. >=20 > 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. >=20 > thanks, > Rob >=20