From mellon@fugue.com Fri Mar 29 18:49:13 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 79485C14F6FF for ; Fri, 29 Mar 2024 18:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.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_NONE=-0.0001, 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 wNEsPN9qpPFy for ; Fri, 29 Mar 2024 18:49:11 -0700 (PDT) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 9FA9DC14F6FB for ; Fri, 29 Mar 2024 18:49:11 -0700 (PDT) Received: by mail-qv1-xf33.google.com with SMTP id 6a1803df08f44-695df25699fso19218266d6.2 for ; Fri, 29 Mar 2024 18:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1711763350; x=1712368150; 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=TXanyK5eQfVG3/LSzbLh6GuEP+oy4XifitW9rDPagv8=; b=neRfrZLL726XtL7MrryTspv1GAH8TK/S9KfnWVCgRIDzNut73/byVEx/9c7OsrJdtv KpPyyuPXmRoiZOuSN/GOamV0a56drYHBh88TQClbUae0Er0JbmKv1jwIobVe6dDAVVLv +W9lKhyo80NzwKh8SvNfr2NlimNKLVovnaZ7qLznVQswF0wLuzmMjTkxdposHqsMkcQS Fwmz1fI09rnFG68nqUpm0EP++v6kNrXHeKbgVRZHd9WiJZhoJFf7gVHToIVWjWdkCD64 AaGs7BvZstx5tavVnqpYsBv4MQF+UHh3XqC2Dmp1kNZJqKJdHPzJTM7oMnieHzyYFAb3 qIUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711763350; x=1712368150; 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=TXanyK5eQfVG3/LSzbLh6GuEP+oy4XifitW9rDPagv8=; b=kcsu21s3SGGcXU35CiWZKtBRJtHY1c1IHqD7rYsX02Y9HO2yHOzJvP0Oc3jaTdLLu7 7iFv3uTDOnED0fDFVCiImr0hP0dSBYx3A354R7qAoIjPyhodOrDJZfbWuICbppWrYlyP 58M1K8dUocIePXw1avcPv4rt2hAq9sdTK83fNb7lS2FmZGXmEmkkpEk/YR9ZffoZ4lCZ ZvYlxf9lKPOk6m1bzklXdLGrEh68diF0BSoVrcH/cW3wNLoHpKBAEiIdYm2laWBJ08G2 luERds8qeA4pySZXTQfVpsvlbxgTi5f70CEqmvPFjQnhoshWZhRAUWJQL2xEYQ++ezDV JhZA== X-Forwarded-Encrypted: i=1; AJvYcCUyL63+bFYX+5SmduxkaN80srptmXUUaksHYST3SQ0msPilvlGe72OxwV6gShMgTjVOzC113UIrbcL9Wvg= X-Gm-Message-State: AOJu0YyMkVoiYV3gFACYzLrqU/DR/822sP+FfoY/KZ/Vcbzrmy8La5eU jraON9QQKUPo1Sj6KdAxEW7nt285As9RkNQuZaJ80NkblIbSoRmoMhzvm5b4i98fk4Fc4whCL1A YOPOGAhI7eShYeZs239+32xUc7KrhKzxzyD1ZYw== X-Google-Smtp-Source: AGHT+IFXiBOciF4JyKy/V4g0k5Pr1dY0K5YyspgdgGJSiyxCNycuhkHJuIazr5QQElRd9bWyne9+FoL4twjCHLVl1PA= X-Received: by 2002:ad4:55e9:0:b0:698:ec76:261 with SMTP id bu9-20020ad455e9000000b00698ec760261mr3473176qvb.35.1711763349811; Fri, 29 Mar 2024 18:49:09 -0700 (PDT) MIME-Version: 1.0 References: <171174253501.29384.9373864670898234756@ietfa.amsl.com> In-Reply-To: From: Ted Lemon Date: Fri, 29 Mar 2024 21:48:33 -0400 Message-ID: To: Rob Sayre Cc: dnsdir@ietf.org, draft-ietf-tls-svcb-ech.all@ietf.org, tls@ietf.org Content-Type: multipart/alternative; boundary="00000000000067d2330614d6f6b7" 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 01:49:13 -0000 --00000000000067d2330614d6f6b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Okay, I think I see the disconnect, maybe. The issue I'm pointing to is that you may or may not be doing DNSSEC validation. And you may or may not be /able/ to do DNSSEC validation if the infrastructure breaks it accidentally or deliberately. The document says: "The SVCB-optional client behavior specified in (Section 3 of [SVCB]) permits clients to fall back to a direct connection if all SVCB options fail. This behavior is not suitable for ECH, because fallback would negate the privacy benefits of ECH." So it's saying that the default handling of SVCB is incorrect and would fail open, and overriding that behavior. Given that this is the case, that implies that it matters whether the data has been validated, but nowhere in the document, certainly not in Security Considerations, is any mention made of this issue. So that's what I'm pointing out. It is absolutely not the case in practice that all stub resolvers do validation. You are making a security decision about trust based on data the trustworthiness of which you've not discussed, in a situation where the implementor has meaningful choices to make with respect to validating that trustworthiness. So it's worth mentioning that if the policy is not to validate, this vulnerability exists. I'm a DNS guy, not a TLS guy, so I don't know the history of this work=E2= =80=94I'm just making this observation about the document I was asked to review. The fact that (apparently) no DNSDIR review ever raised this issue about the other documents you mentioned is of no interest to me=E2=80=94I'm not revie= wing those documents.Whether you take this advice is between you and the IESG. I'm not even claiming to be right=E2=80=94just pointing out the issue I see= . On Fri, Mar 29, 2024 at 7:21=E2=80=AFPM Rob Sayre wrote: > I don't think it relates to DNSSEC. You can fail at DNS (DNSSEC failure) > or you can fail during ECH (unless you want to use non-ECH, which is not > ECH, and not part of this draft). > > It makes sense to me: one can reject a request unless the requirements > embedded in the SVCB are met (the server chooses those, which can include > many aspects of the request). I don't understand why one would insert > DNSSEC here. That seems to be the whole point--it works without it. > > thanks, > Rob > > > On Fri, Mar 29, 2024 at 3:57=E2=80=AFPM Ted Lemon wrot= e: > >> I'm not telling you that you have to require DNSSEC. I'm saying the >> document is incomplete if you don't talk about how it relates to DNSSEC.= I >> think EKR got the point, so maybe go with his approach? >> >> On Fri, Mar 29, 2024 at 6:27=E2=80=AFPM Rob Sayre wro= te: >> >>> It's a policy choice, though, right? I think ekr hinted at this issue a= s >>> 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 th= ink >>> these are separate problems, though. >>> >>> thanks, >>> Rob >>> >>> >>> On Fri, Mar 29, 2024 at 3:10=E2=80=AFPM Ted Lemon wr= ote: >>> >>>> 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=E2=80=AFPM Rob Sayre w= rote: >>>> >>>>> On Fri, Mar 29, 2024 at 1:02=E2=80=AFPM 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, ma= ny 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 >>>>> >>>>> --00000000000067d2330614d6f6b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Okay, I think I see the disconnect, maybe. The issue I'= ;m pointing to is that you may or may not be doing DNSSEC validation. And y= ou may or may not be /able/ to do DNSSEC validation if the infrastructure b= reaks it accidentally or deliberately.

The document says= : "The SVCB-optional client behavior specified in (Section 3 of [SVCB]= ) permits clients to fall back to a direct connection if all SVCB options f= ail. This behavior is not suitable for ECH, because fallback would negate t= he privacy benefits of ECH."

So it's sayi= ng that the default handling of SVCB is incorrect and would fail open, and = overriding that behavior. Given that this is the case, that implies that it= matters whether the data has been validated, but nowhere in the document, = certainly not in Security Considerations, is any mention made of this issue= . So that's what I'm pointing out.

It is a= bsolutely not the case in practice that all stub resolvers do validation. Y= ou are making a security decision about trust based on data the trustworthi= ness of which you've not discussed, in a situation where the implemento= r has meaningful choices to make with respect to validating that trustworth= iness. So it's worth mentioning that if the policy is not to validate, = this vulnerability exists.=C2=A0

I'm a DNS guy= , not a TLS guy, so I don't know the history of this work=E2=80=94I'= ;m just making this observation about the document I was asked to review. T= he fact that (apparently) no DNSDIR review ever raised this issue about the= other documents you mentioned is of no interest to me=E2=80=94I'm not = reviewing those documents.Whether you take this advice is between you and t= he IESG. I'm not even claiming to be right=E2=80=94just pointing out th= e issue I see.=C2=A0

On Fri, Mar 29, 2024 at 7:21=E2=80=AFPM Rob Sayre= <sayrer@gmail.com> wrote:
I don't think= it relates to DNSSEC. You can fail at DNS (DNSSEC failure) or you can fail= during ECH (unless you want to use non-ECH, which is not ECH, and not part= of this draft).

It makes = sense to me: one can reject a request unless the requirements embedded in t= he SVCB are met (the server chooses those, which can include many aspects o= f the request). I don't understand why one would insert DNSSEC here. Th= at seems to be the whole point--it works without it.
=
thanks,
Rob


On Fri, Mar = 29, 2024 at 3:57=E2=80=AFPM Ted Lemon <mellon@fugue.com> wrote:
I'm not telling you that you have to require DNSSE= C. I'm saying the document is incomplete if you don't talk about ho= w it relates to DNSSEC. I think EKR got the point, so maybe go with his app= roach?

On Fri, Mar 29, 2024 at 6:27=E2=80=AFPM Rob Sayre <sayrer@gmail.com> wrote:
<= /div>
It's a policy choice, though, ri= ght? 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&= #39;s the case, DNSSEC doesn't help. There will certainly be a transiti= on period where that will be impractical for many servers. I think these ar= e separate problems, though.

thanks,
Rob=


On Fri, Mar 29, 2024 at 3:10=E2=80=AFPM Ted Lemon <= mellon@fugue.com&= gt; 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=E2=80=AFPM Rob Sayre <sayrer@gmail.com> wrote:
On Fri, Mar 29, 2024 at 1:02=E2=80=AF= 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.

Cou= ld you explain more about this part? I think DNSSEC doesn't add much he= re, unless you want to accept non-ECH traffic. For example, many of the tes= t servers will bounce you to some other site if you don't send ECH or s= crew it up in some way (speaking as someone who has screwed it up many time= s...).

I think there might be a DoS attack here, w= here someone messes with the response, but they can also turn off the DNSSE= C bit unless it's DoT/DoH/DoQ etc. So, if using those, it's just th= e trustworthiness of the DNS server itself, right? Sorry if I'm missing= =C2=A0something.

thanks,
Rob
<= br>
--00000000000067d2330614d6f6b7--