From mellon@fugue.com Fri Mar 29 15:10:14 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 C364CC14F6A1 for ; Fri, 29 Mar 2024 15:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.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_DNSWL_HI=-5, 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 BkBJPiQOmk47 for ; Fri, 29 Mar 2024 15:10:13 -0700 (PDT) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (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 C364FC14F680 for ; Fri, 29 Mar 2024 15:10:13 -0700 (PDT) Received: by mail-vk1-xa2b.google.com with SMTP id 71dfb90a1353d-4d453ae6af5so925674e0c.2 for ; Fri, 29 Mar 2024 15:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1711750212; x=1712355012; 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=WNhlZB6l+Cx3qgIH1bqyfY0pS05UcJgO0hwIFgZ5n5M=; b=apFEEjWHBGG1GH8+UtaqxE3/3Ne5+HY69UNKxBIH9fypXG9hlujbU1HOuIR3j62UTo CfvotYd9+VlTcVYBnK4hbdjmZjyMe4ocrP0Bo5Ab3tW8DCSRb4caxD+K1dUv6XNIY+li +IUcj6FQ7xrFqhpZ6SZMfvVH8BBF4UFOa12Gs0FlnpTC3nLEEoEbtYFISQ9cW3WVUb2w cedZleXP2BWujQH1IcocVqdWGqEJQ2yx/Zu81UudyiOmG9gI3M428hsmouZPyknYBQOw ovPQKNMgt/PVIbaeepjMP1avdOKc3bUgCtKlmgQqQ/aHJlzds48QwYtg82I0PXTaaOtt okUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711750212; x=1712355012; 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=WNhlZB6l+Cx3qgIH1bqyfY0pS05UcJgO0hwIFgZ5n5M=; b=jUGL9XD+PgIKf2rOSQQfAV0lXosWc0UVru6KD0FFFlBo3tmUoHOHItkMRV95HaYwAU bft4w1NBH1xLBfeAjZ8XDZUZ2FGazQQxvZXr2hCpHseMWJZtMlPLTJl6HKXFwSAmpSaU vzIIdejfiPP8E/dQVs8hPWTSRqHlE9jGo746VXNh7pg9Zxemeu+Q7I6kgcaOOTrsknF5 KdTHNnFlbc3KwZUCZcUDX9vSEsLw20ULWt9Lusq8o99qyvAsExDrKTa5P80FmCA7BwSW O8WttqbMnaSndJGnuuwM8LDxyIgK+0ED2aYYgARVJyFIQlLdcstP+/hv8lC1StljrcGg wQVg== X-Forwarded-Encrypted: i=1; AJvYcCXLOmtd18rZE8D4tQ+3T1lJ2rlP0hyBxbIfNld2YLMXtmVnWsGsRIcA3pz3c7T/PGUGlpTabC/gYztRI1w= X-Gm-Message-State: AOJu0Yzrj7QOstI9T2DMdOSQqeOdGeOjMHBT9dHGOjViCJWpMTVBx9On FymLg8+7jiNeTV1deoKkQ0tnlxGM/7EbitvAHPtb8yXHJEOpXMMBQzSEVvBaStMBmpLbfoEjX6S os7jlkilcB0/+YPUrFLuBjyQlv8m09N0HU1wcAA== X-Google-Smtp-Source: AGHT+IG+5PniQzQnmxFEx6Wbdu2eDMvNhEWeGeqmEnX1GdnrO+Bn+9hC3RROr7xtJVYQ+TAlB8RIPPrNvaGqUk1/F6Y= X-Received: by 2002:a05:6122:2225:b0:4d8:4a7f:c166 with SMTP id bb37-20020a056122222500b004d84a7fc166mr3448025vkb.12.1711750210393; Fri, 29 Mar 2024 15:10:10 -0700 (PDT) MIME-Version: 1.0 References: <171174253501.29384.9373864670898234756@ietfa.amsl.com> In-Reply-To: From: Ted Lemon Date: Fri, 29 Mar 2024 18:09:34 -0400 Message-ID: To: Eric Rescorla Cc: dnsdir@ietf.org, draft-ietf-tls-svcb-ech.all@ietf.org, tls@ietf.org Content-Type: multipart/alternative; boundary="0000000000003c3e4a0614d3e78b" 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: Fri, 29 Mar 2024 22:10:14 -0000 --0000000000003c3e4a0614d3e78b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That seems okay. Would be good to document in the security considerations. On Fri, Mar 29, 2024 at 4:41=E2=80=AFPM Eric Rescorla wrote: > > > On Fri, Mar 29, 2024 at 1:02=E2=80=AFPM Ted Lemon via Datatracker < > noreply@ietf.org> wrote: > >> Reviewer: Ted Lemon >> Review result: Almost Ready >> >> This is a DNS Directorate review for draft-ietf-tls-svcb-ech-01. >> >> Section 4.1 advises disabling fallback, but does not talk about DNSSEC, >> which >> is surprising given that the draft proposes privacy properties for SVCB >> responses containing ECH data. I would think that it would make sense to >> say >> that the SVCB querier should attempt to validate the response, and then >> talk >> about what to do for bogus, insecure and valid positive and negative >> responses. >> >> For example, I would think that a /bogus/ response should be taken to >> mean that >> the SVCB record must be assumed to exist and should be treated the same >> as if >> the list of destinations were not reachable. An /insecure/ NXDOMAIN or >> NODATA >> response would not provide this assurance, and so what is currently >> described >> in the document makes sense for this case. A /valid/ NXDOMAIN would >> assure that >> no SVCB record existed, and hence ECH is not available. >> >> I don't think it's reasonable to specify the privacy properties of SVCB >> and >> /not/ talk about DNSSEC validation. >> > > I could see that there might be an objection that if DNSSEC isn't working >> at a >> particular site because of a broken DNS resolver, this would prevent >> connecting >> to perfectly acceptable destinations simply because of general DNSSEC >> breakage, >> not a specific attack on this specific domain. The problem is that >> there's no >> way to distinguish this from an attack. So if this exception is allowed, >> the >> security considerations section should talk about what the risks are of >> allowing it. E.g. if we succeed in validing the root and com, but can't >> validate the zone containing the SVCB (or determine that it's not >> signed), that >> would be a clear indication of an attack, but if we can't validate the >> root, it >> could just be brokenness, and an attacker would do well to just prevent >> all >> validation so that we can't distinguish. > > > Thanks for your comments. > > While I agree that SVCB being bogus deserves some consideration. I don't > think this > resolutions is *quite* correct. In general, TLS and HTTP don't take a > position > on what if any DNSSEC validation is to be done or what to do in response = to > failures. > > The new angle here is that there are two queries, and so it is possible > for the > A/AAAA queries to produce a valid response but the SVCB to produce a bogu= s > one, which might be used by an attacker to disable ECH. What I would say > here > is that a bogus SVCB should be handled in the same way as if A/AAAA were > bogus. > So if you would normally fail the resolution, you should do that, but if > you would > normally log and move on, then you should do that. > > -Ekr > > --0000000000003c3e4a0614d3e78b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That seems okay. Would be good to document in the security= considerations.

On Fri, Mar 29, 2024 at 4:41=E2=80=AFPM Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com">ekr@rtfm.com> wrote:


On Fri, Mar 29, 2024 at 1:0= 2=E2=80=AFPM Ted Lemon via Datatracker <noreply@ietf.org> wrote:
Reviewer: Ted Lemon
Review result: Almost Ready

This is a DNS Directorate review for draft-ietf-tls-svcb-ech-01.

Section 4.1 advises disabling fallback, but does not talk about DNSSEC, whi= ch
is surprising given that the draft proposes privacy properties for SVCB
responses containing ECH data. I would think that it would make sense to sa= y
that the SVCB querier should attempt to validate the response, and then tal= k
about what to do for bogus, insecure and valid positive and negative respon= ses.

For example, I would think that a /bogus/ response should be taken to mean = that
the SVCB record must be assumed to exist and should be treated the same as = if
the list of destinations were not reachable. An /insecure/ NXDOMAIN or NODA= TA
response would not provide this assurance, and so what is currently describ= ed
in the document makes sense for this case. A /valid/ NXDOMAIN would assure = that
no SVCB record existed, and hence ECH is not available.

I don't think it's reasonable to specify the privacy properties of = SVCB and
/not/ talk about DNSSEC validation.

I could see that there might be an objection that if DNSSEC isn't worki= ng at a
particular site because of a broken DNS resolver, this would prevent connec= ting
to perfectly acceptable destinations simply because of general DNSSEC break= age,
not a specific attack on this specific domain. The problem is that there= 9;s no
way to distinguish this from an attack. So if this exception is allowed, th= e
security considerations section should talk about what the risks are of
allowing it. E.g. if we succeed in validing the root and com, but can't=
validate the zone containing the SVCB (or determine that it's not signe= d), that
would be a clear indication of an attack, but if we can't validate the = root, it
could just be brokenness, and an attacker would do well to just prevent all=
validation so that we can't distinguish.

Thanks for your comments.

While I agree that SVC= B being bogus deserves some consideration. I don't think this=C2=A0
resolutions is *quite* correct. In general, TLS and HTTP don't t= ake a position
on what if any DNSSEC validation is to be done or = what to do in response to
failures.

= The new angle here is that there are two queries, and so it is possible for= the
A/AAAA queries to produce a valid response but the SVCB to p= roduce a bogus
one, which might be used by an attacker to disable= ECH. What I would say here
is that a bogus SVCB should be handle= d in the same way as if A/AAAA were bogus.
So if you would normal= ly fail the resolution, you should do that, but if you would
norm= ally log and move on, then you should do that.

-Ekr

--0000000000003c3e4a0614d3e78b--