From ekr@rtfm.com Fri Mar 29 13:41:19 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 D697EC14F69B for ; Fri, 29 Mar 2024 13:41:19 -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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham 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 hWvfyhIXZ0qe for ; Fri, 29 Mar 2024 13:41:19 -0700 (PDT) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 2AFE7C14F615 for ; Fri, 29 Mar 2024 13:41:19 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id 3f1490d57ef6-dd10ebcd702so2303943276.2 for ; Fri, 29 Mar 2024 13:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1711744878; x=1712349678; 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=nnUTbu5NZbV4xDDaLKqu5ZsfK50cj5HRn7hkqdnifvg=; b=Ki3jobwMuC356ZSa70PBAtR0WYP2LDr5HMgOMQFXm403hSZFaldp4fJwZ6wNV6ghO5 wzDSGYcGOT7iGufTXwetyhsMcIbJ+h9XNgPCc6oHlan+5ghJutcBEFUkQhtWcwaYPc+O yiTwVBqnb3Xqq7w4wSA8G/THrV+GtZ9eD8BX0UiwxUV8gRRNn9WM4Vw7ko2JmrWUETRZ BEXYyztOEBZ7LbuNZQSm50eUa0z3iarRYuZjd67c0vGmwI9xQvJgdlCmhr8Tj1EaU5wP cxv5lNchqzz/0lDBIOgUkM4aLlNi768qnKf+Yu9Zii3tBOtxAesOL5PHCSDfQJyVm8eb tUDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711744878; x=1712349678; 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=nnUTbu5NZbV4xDDaLKqu5ZsfK50cj5HRn7hkqdnifvg=; b=ag437hAZJirPneDpCtPP3MkaGu8SQlLJKQsS/bn2yqcKr90epswC/x/q/V325WeH2Y X+4E0lkFai0UR+lgxe2V8S3C/QsPLNZIHLIFMXlcLcAq9SoHJeeM41MGyG0w1JwEMoAP P1jcHAoudmp9C5g6ZWpmgeqD/9O/ahPFw8+uEGtqJy22gKch7KA0OzbBEsWIS7u24Sow UJWFXzIxrAjcD9y+6gcqd+97aG1wAMHpTDgCVihgpGKMtgIx8TWBqRhzrMoThw7RiUwE IH+nYC8373g3pqFj9jobMWddqNxio82b5GdKwjB+U7qaqNOHKbyMBLJ/shY+d4P109M/ +9IA== X-Forwarded-Encrypted: i=1; AJvYcCUHqEH/zEsnHdd7ZWuChtyZlgXLb6uhICNGeSlNXBRVoAjoUtdMkqueHEk7Ki78GqBL8wnWgojVBKIfOdc= X-Gm-Message-State: AOJu0YyXsQwecM7StLIdhGeDyLoA1hPhKtMEXF/1N4hdWBHflf50HSeW 8o94bqMhzya2jmVlbDEvycC6zlfKD2gjEoUIW1+SZSCuzhQcOe0EwWSU5uvfH62lV/ASZRYIJCa 6YFtpvnrL8mwVnEOl25XgcyxMYj36eiwCotmFAg== X-Google-Smtp-Source: AGHT+IHn03FNTmIeSJoGkBoLMaCKYyXhwyKXQqS/F2dzVt989xVWVclRO6r2R2QCXytN/d7giswHcaHHOymMuoYTBDo= X-Received: by 2002:a25:3546:0:b0:dcd:5635:5c11 with SMTP id c67-20020a253546000000b00dcd56355c11mr3232548yba.45.1711744878100; Fri, 29 Mar 2024 13:41:18 -0700 (PDT) MIME-Version: 1.0 References: <171174253501.29384.9373864670898234756@ietfa.amsl.com> In-Reply-To: <171174253501.29384.9373864670898234756@ietfa.amsl.com> From: Eric Rescorla Date: Fri, 29 Mar 2024 13:40:41 -0700 Message-ID: To: Ted Lemon Cc: dnsdir@ietf.org, draft-ietf-tls-svcb-ech.all@ietf.org, tls@ietf.org Content-Type: multipart/alternative; boundary="00000000000067e3dd0614d2a925" 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 20:41:19 -0000 --00000000000067e3dd0614d2a925 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 29, 2024 at 1:02=E2=80=AFPM Ted Lemon via Datatracker 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 mea= n > that > the SVCB record must be assumed to exist and should be treated the same a= s > 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 assur= e > 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 a= nd > /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 a= ll > 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 bogus 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 --00000000000067e3dd0614d2a925 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 29, 2024 at 1:02=E2=80=AF= PM Ted Lemon via Datatracker <norepl= y@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

--00000000000067e3dd0614d2a925--