Re: [dns-privacy] Fwd: New draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features

Eric Rescorla <ekr@rtfm.com> Wed, 26 May 2021 19:50 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6593A0E2A for <dns-privacy@ietfa.amsl.com>; Wed, 26 May 2021 12:50:42 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Nzy_CaU9B8k for <dns-privacy@ietfa.amsl.com>; Wed, 26 May 2021 12:50:37 -0700 (PDT)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737213A0E27 for <dns-privacy@ietf.org>; Wed, 26 May 2021 12:50:37 -0700 (PDT)
Received: by mail-il1-x130.google.com with SMTP id z1so2036638ils.0 for <dns-privacy@ietf.org>; Wed, 26 May 2021 12:50:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O66XNpllcpA4Gk1fErVIx0UrGnwG7VWfjK65O0j5XIE=; b=DmgtW0pBw5l1y0CPhRCPNpuRXqsfEZDOdYsCEPN919AK8PC6aXO+nMBCuV/wjd+5GG oI9xrAgaCuDYvQdk6mIa6yrg7QNgilKoV2Y19mVrxFmvvURtuMMkyg9hJNMFBOJvhgyi ZW9Vrh5lvmvLnsml3aNc/Xkv4A1m69m3qrUfB6kaXHDS/IPX2zoGZ9+oQFpHRdGpk07b 4V5Md1UhP/tzjKJATY/zg+aURuNtPuP9vVDn5s7bbou+FWfcuKg9JlpuW2Y6CfhNLKjG GB078SsvlRf2aiJX78uwuk+Xu7/qryK8THLNOjShcmQ3ylWoz6jiaNXLm4RtItPs3w+Z p7Gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O66XNpllcpA4Gk1fErVIx0UrGnwG7VWfjK65O0j5XIE=; b=ReIXE3I/nDeQBsBH0IuMkeHGITSgNOcxmIz9zBmHTO3/zntMlUdppiqx86KtBamKrS qtBVMaS48KS0cOoo1ZDncq8kSthyGHLBNRnR54wiJt5lXXeA4cOc+y1evpWM3SqxrfZ2 iQI37BxDqjzqeWx6yw8OpBce5xQRYX5gzn0X4BcsiSirtMVPxa3GOyx+UUjk2Gb7UE6j NYq9qbTij43R/P5ilQ0Vhouw4DBBoEBmuiU70efSwrEDgMm52PtcvYTBDcTG6ilS3ynk 8GMeit0n0NKpvesguX2Z0NQXXTRz68oPf588T0/Y9ByHSLop3HcwWCMjaQ5JrFVmg04b OhvQ==
X-Gm-Message-State: AOAM532aXDQhzhODLXLqLtnxVVhtVZ/df18zH+aoo33vZmhjNar3NhKX PdQ8qMs8nNjfYez119ZgYrv6J5A/q+z813g+cKDQcA==
X-Google-Smtp-Source: ABdhPJykRQW3tl42Idrgk8OUEDbI32OEsXyV/f8VIINWDLw80OW5cM0oVooQEJZF3VQPRi9R0Jtinryq84zvLMlih+g=
X-Received: by 2002:a05:6e02:e10:: with SMTP id a16mr27212ilk.56.1622058636246; Wed, 26 May 2021 12:50:36 -0700 (PDT)
MIME-Version: 1.0
References: <B27C4F2E-D5AF-428B-BBD1-A57E7D676BD5@icann.org> <CADyWQ+E9jpV0BwMsaS8=vNbs7x87d4qqGbKQevj8MVGCLGyv5w@mail.gmail.com> <5714de37-baae-9f72-3f02-e2765a6d4e2c@nic.cz>
In-Reply-To: <5714de37-baae-9f72-3f02-e2765a6d4e2c@nic.cz>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 26 May 2021 12:49:59 -0700
Message-ID: <CABcZeBP5vCNJ3cPrwmAxo_YMkHMAQkw6RtN4Pt+ueo5wCXTyGA@mail.gmail.com>
To: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat+ietf@nic.cz>
Cc: DNS Privacy Working Group <dns-privacy@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d195a205c340f4c9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/MFZAAE1ekAP_iwNWz6bxCTDGS4Q>
Subject: Re: [dns-privacy] Fwd: New draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2021 19:50:42 -0000

On Wed, May 26, 2021 at 11:21 AM Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
wrote:

> I like it in principle, so I say adopt.
>
> I already see a significant problem, though I expect we can fix it somehow
> after adoption:
>
> After sending out all requests for SVCB records [...]
>
> My understanding of section 3 implies that an implementing resolver MUST
> NOT ask any of the nameservers until *all* their SVCBs have been attempted,
> in the most common case where no encryption is supported by the
> nameserver-set.  That would *not* scale at all.  Even with 13 NSs it's a
> rather bad amplification factor, and it reminds me of the recent NXNS
> attack.
>
> On the whole, if a NS set has (many?) names without encryption support,
> I'm afraid the corresponding zones may have to do without a guarantee of
> getting encryption, though glue might help.
>
>
> On 26/05/2021 15.21, Stephen Farrell wrote:
>
> SVCB in the parent zone will take years to happen
>
> The SVCB glue is just a slight optimization.  I don't think it can even
> save latency, just a packet per NS (and only in cases where the SVCB
> exists).
>
As noted in my presentation, it's more than an optimization. It's an
important security function in cases where the sensitive domain name is the
apex.

-Ekr


> --Vladimir
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>