[DNSOP] Re: [TLS] Re: Re: Re: AD review draft-ietf-tls-svcb-ech

Paul Wouters <paul.wouters@aiven.io> Fri, 04 October 2024 18:30 UTC

Return-Path: <paul.wouters@aiven.io>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B4BC14F605 for <dnsop@ietfa.amsl.com>; Fri, 4 Oct 2024 11:30:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=aiven.io
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 xPKTsIZUaJZn for <dnsop@ietfa.amsl.com>; Fri, 4 Oct 2024 11:30:28 -0700 (PDT)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82E0FC14F680 for <dnsop@ietf.org>; Fri, 4 Oct 2024 11:30:28 -0700 (PDT)
Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a8a6d1766a7so365633866b.3 for <dnsop@ietf.org>; Fri, 04 Oct 2024 11:30:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; t=1728066627; x=1728671427; 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=Sd8hb0G4TVnwOVkuwEdFyceFkeYfnU+KGnAJK2nkmVk=; b=gI1YkwGVXygO6Bv8aNzxUITrt61drzF7KJoEaQu+JVr3YHN0vot/ZOvM7flBeKjJIY FKeJJZYBvCOqMPVlAanzvLmJJB3wwYVUt/crvLy+BdCB9TbjBCKpBPpwLwU8tHYj+oSA xogVGZ7QvxYNRhYKdV29A+nM5ClJtryYQsA2I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728066627; x=1728671427; 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=Sd8hb0G4TVnwOVkuwEdFyceFkeYfnU+KGnAJK2nkmVk=; b=PMBBaJlVFWzF4Wo57sNaehrdhNCI25sd4igB6v3kC7FmP6271NzvBHg9aLaL4Fxlc4 nGuMLAMmsZjmKWZ00E2qXcYc70jtdBXJBTzgUDHzP7A6Y5OJHMT2F/N4dnqVLrtFU1N4 ZPjzesDmvVD3m5zhmTK0Q6A6vv9idAY/fmDlxjNLtDqVI8SCkwNx89IfYSmcg6NJt52n Yth3bkmtAiRlIZcH9oNh16ktI08ujA5q5mU5yhkpxB9X5YldneHaHQ7WWtdgeY+P9ZO+ 7Zmk1m0N1XktD5OTKf7STIato95uGaUNV2U9UYxa87+RAAHRbP+jM61jpyI978d85DNG Ii1Q==
X-Forwarded-Encrypted: i=1; AJvYcCVP3fsUmEg9JPpsTnnEoT5EFOQi1qI7EbVuti4HICWBmsWy3ZkOduy8kTMf8bAndGIDlq1tiw==@ietf.org
X-Gm-Message-State: AOJu0YwFZRCFQrDXWIcp/zEebQlZGS3w4FB/FBn3LoE/+EjfHL98F5OV aASJJN7lpuyNySlLcDKyBNGxRuRe7EGQY/jI1iagKas2210S2n48oyZZf+LOH8TPMoER8XZS80o i0RkZCBTyA3tRxePqG+Ho53a4F6XmqELpL5NWxg==
X-Google-Smtp-Source: AGHT+IHPbyEM8F1b1R3yetHBBEXTKlUpHTBrcEFAZ+O05IvKOqrFKduCr5BPuEelI51rSOLi4AIc+1LrUTlv7jjWews=
X-Received: by 2002:a17:907:3eaa:b0:a98:f475:f9f3 with SMTP id a640c23a62f3a-a991c0234f1mr379084866b.65.1728066626890; Fri, 04 Oct 2024 11:30:26 -0700 (PDT)
MIME-Version: 1.0
References: <CAGL5yWbDFjqxX9JhD6jL=iktamprOWSWjjzGVO1iMTYuADCe0A@mail.gmail.com> <CABcZeBO-d1JdBBoChomponbkqAA=x1YQyMLxmpAZnXmX___MqA@mail.gmail.com> <PH0PR15MB4381A7D9689244A565489331B3762@PH0PR15MB4381.namprd15.prod.outlook.com> <CAFR824y6G6mfWQ4iKMwJoZV7X7oE_xjw-KaLAp4bVaPfi38fBw@mail.gmail.com> <11c797bf-993e-037f-7b9f-6a64947aed75@redbarn.org> <BADE6224-0B10-426F-A381-28D2ED1014FE@broadcom.com> <MW4PR15MB4379D7A2BCD8DDA2D024107BB3702@MW4PR15MB4379.namprd15.prod.outlook.com> <2F26A523-D6D8-44E9-B54D-9C9C7CDD6722@broadcom.com> <65C0B64D-052F-4E58-B462-7C0C4D56DCFF@akamai.com> <CABcZeBPL6FGgRPYg1O_ca_QZ0_obEVRhFZOC-zJy2_4wz6cWeQ@mail.gmail.com> <PH0PR15MB438160E625A016AD9AB898A4B3722@PH0PR15MB4381.namprd15.prod.outlook.com>
In-Reply-To: <PH0PR15MB438160E625A016AD9AB898A4B3722@PH0PR15MB4381.namprd15.prod.outlook.com>
From: Paul Wouters <paul.wouters@aiven.io>
Date: Fri, 04 Oct 2024 14:30:15 -0400
Message-ID: <CAGL5yWbaW8CaDwpCDNTGdum=zHpZn=MPfygHUWKC0vwqDdxoLA@mail.gmail.com>
To: Ben Schwartz <bemasc@meta.com>
Content-Type: multipart/alternative; boundary="00000000000072138b0623aadd0e"
Message-ID-Hash: PLO5KNDVBBCBQYJ7M64TU3FTB2YTJH3N
X-Message-ID-Hash: PLO5KNDVBBCBQYJ7M64TU3FTB2YTJH3N
X-MailFrom: paul.wouters@aiven.io
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Eric Rescorla <ekr@rtfm.com>, "Salz, Rich" <rsalz@akamai.com>, Arnaud Taddei <arnaud.taddei@broadcom.com>, Paul Vixie <paul@redbarn.org>, "draft-ietf-tls-svcb-ech.authors@ietf.org" <draft-ietf-tls-svcb-ech.authors@ietf.org>, "TLS@ietf.org" <tls@ietf.org>, "dnsop@ietf.org WG" <dnsop@ietf.org>
X-Mailman-Version: 3.3.9rc5
Precedence: list
Subject: [DNSOP] Re: [TLS] Re: Re: Re: AD review draft-ietf-tls-svcb-ech
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xKnr-vW8ytrklOO0dJ7dcRSC2DI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

On Fri, Oct 4, 2024 at 10:06 AM Ben Schwartz <bemasc@meta.com> wrote:

> I've updated PR#16 to reframe this paragraph as a statement of fact:
> https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16/files
>

Speaking as individual,


>
> It seems strange to me to describe a vulnerability without explaining how
> to mitigate it, but I'm willing to move forward if this is all we have
> consensus for.
>

I also find it a bit odd that we don't warn people the entire purpose of
the draft would be in vain, if one did not use a properly secured DNS
transport to a DNS server with a compatible privacy policy.

Perhaps a short Operational Considerations section could be added
explaining the use of ECH at the Enterprise network and networks deploying
DNS filter security services could be blocked for security reasons at the
cost of privacy loss to the network? And that the enduser might not have a
choice based on the DNS constrains within those networks.

Of course I myself am now thinking I want a DNS module that pulls these DNS
records based on previous queries and stashes these in my own DNS resolver
so that I can move onto these kind of networks and use ECH without
requiring to do further DNS lookups :P

Maybe just an aggressive prefetch of ECH related records :P

Which makes me wonder if it makes sense to advise long TTLs on these
records so that they move along on your phone/laptop even if you enter
these kind of networks.

Paul W


>
> --Ben
> ------------------------------
> *From:* Eric Rescorla <ekr@rtfm.com>
> *Sent:* Friday, October 4, 2024 8:07 AM
> *To:* Salz, Rich <rsalz@akamai.com>
> *Cc:* Arnaud Taddei <arnaud.taddei@broadcom.com>; Ben Schwartz <
> bemasc@meta.com>; Paul Vixie <paul@redbarn.org>; Paul Wouters <
> paul.wouters@aiven.io>; draft-ietf-tls-svcb-ech.authors@ietf.org <
> draft-ietf-tls-svcb-ech.authors@ietf.org>; TLS@ietf.org <tls@ietf.org>;
> dnsop@ietf.org WG <dnsop@ietf.org>
> *Subject:* Re: [DNSOP] Re: [TLS] Re: Re: Re: AD review
> draft-ietf-tls-svcb-ech
>
> I don't really think it's helpful to re-litigate the broader topic of the
> merits of ECH; nothing we say in security considerations will make a
> material difference there. With that said, I don't love the last sentence
> as we know users
> I don't really think it's helpful to re-litigate the broader topic of the
> merits of ECH; nothing we say in security considerations will make a
> material difference there.
>
> With that said, I don't love the last sentence as we know users don't
> really choose their resolvers. How about simply stating the facts:
>
> "This specification does not effectively conceal the target domain name
> from an untrusted resolver."
>
>
> -Ekr
>
>
> On Thu, Oct 3, 2024 at 9:41 AM Salz, Rich <rsalz=
> 40akamai.com@dmarc.ietf.org> wrote:
>
> I do not think this conflict of views can be resolved. The draft is
> intended to show how it ECH should be used to preserve it’s security
> guarantees, and there are groups in the DNS community who say this prevents
> their normal course of operation, and providing the features that they
> provide.  I apologize in advance if anyone finds my wording clumsy or,
> worse, offensive. I was trying to use neutral words throughout.
>
>
>
> I think we just acknowledge that in the security considerations and
> declare the issue closed.
> _______________________________________________
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-leave@ietf.org
>
>