Re: [Privacy-pass] Draft on key consistency and discovery

Ben Schwartz <bemasc@google.com> Fri, 26 February 2021 21:46 UTC

Return-Path: <bemasc@google.com>
X-Original-To: privacy-pass@ietfa.amsl.com
Delivered-To: privacy-pass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1483A0C94 for <privacy-pass@ietfa.amsl.com>; Fri, 26 Feb 2021 13:46:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 KF-nwzV_GsF8 for <privacy-pass@ietfa.amsl.com>; Fri, 26 Feb 2021 13:46:56 -0800 (PST)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 133B53A0C8F for <privacy-pass@ietf.org>; Fri, 26 Feb 2021 13:46:56 -0800 (PST)
Received: by mail-wr1-x42b.google.com with SMTP id n4so9964219wrx.1 for <privacy-pass@ietf.org>; Fri, 26 Feb 2021 13:46:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/+zuh2BDRzDZ3iXyD4lfXF/5W5I5OeSpLH5NxbBElRI=; b=sTzH95RcgVSlMCg5oyaax+scpeH0W2WBhbRRdvZtZ3WkvCtALzYZiT1sFlaDb5kkBK eyfAR5eDBgjjaUe3rdnJVafXzY2LCHERyYPC7vYB8uswm6qHprJ7jms5zqXfYHg0MpWy EygkkIIG7dwesKbmXWpfv0qnUeCgi3hIIxI3yrGTaCj4tzACRgXWHPqKHzP1PEHg50De ZEAtdHXjZirM8v4M/5c/a9jdpDvY+buDkfMGmA+mlAeJ8IR0elyuFDdsDo53ECL2EYKm 05RFr8ncc9QkbOs53Ua5Z7v7HchqkSvNjJZ30Tfk/RBAZWgpXsULp92I48M+9UX4wMXL 95mQ==
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=/+zuh2BDRzDZ3iXyD4lfXF/5W5I5OeSpLH5NxbBElRI=; b=LLfZeG4iQS5HmpmaeG2woCKz2II+TZyvAijMmMG1fbisc8q7cM+LjNo94NnARNydRU PfWWkGiyg9bRe3MVVKadV6lnBrCTFXtgpXkR2MkDHzmtCXJ6cbfNIghzlDYy3nY08gOi zBIeyoFqs4F804xkBvtL4RIDKz+H+1s/8vfaZFgZ5ffgasioNwEAVpbB6hyu1DhHfopz W0drVOTxh9FY3g3EcFh2H5nlJSVxarn0l7xAFkiC8h1jgxr8fKW9eC1gN8mSOB/lowXq AOBuQouRyOZhBEzJUnyzfXaa2d7cUuiDFKC2KwyHa2Z4CuLhgIZD8UIIt3mm7PBR031m a4wQ==
X-Gm-Message-State: AOAM531qZ93czx1SXPjUP9fmFFXSJQOGMipo5d0V2DL32gFRfWZBH753 BRKeE+LtDK8pXDpbEOXBB/e/hwqjbOkz+PCUJ8TtlQ==
X-Google-Smtp-Source: ABdhPJwiC8MjqZFKu82BwS8tRIntuoEM++R0IKHd684c1zwSBQAwJOtjeGCuttmzrPz+1AOa8s0Czq1CaamVQI7fDfQ=
X-Received: by 2002:a05:6000:1081:: with SMTP id y1mr5067566wrw.177.1614376014311; Fri, 26 Feb 2021 13:46:54 -0800 (PST)
MIME-Version: 1.0
References: <92ed42af-2b1b-4974-9be4-4f73a9e0290c@www.fastmail.com> <CAHbrMsBhKKa6vZpXoqMJgQWv07CC57oV2=zt0om_N57mgr8EVw@mail.gmail.com> <20210225233942.stwecrzm6uiqdha3@localhost> <CAHbrMsDCXsgdi=Z0R-tszFZaM7fGFTNmumRVzD0MkuswrBG+hQ@mail.gmail.com> <CA+AE54ch3AvS=h71RemZXQcdd4xU2BFJn1z4SCbZkqEpS9skAw@mail.gmail.com>
In-Reply-To: <CA+AE54ch3AvS=h71RemZXQcdd4xU2BFJn1z4SCbZkqEpS9skAw@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Fri, 26 Feb 2021 16:46:41 -0500
Message-ID: <CAHbrMsD7_VLeMgRu1ntDZKbiDhC=Sy=yGzL9RKde7eER0kSiow@mail.gmail.com>
To: Eli-Shaoul Khedouri <eli=40intuitionmachines.com@dmarc.ietf.org>
Cc: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, Matthew Finkel <sysrqb@torproject.org>, Christopher Wood <caw@heapingbits.net>, privacy-pass@ietf.org
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000e2c3dd05bc4434a0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/privacy-pass/LjGFd-1XiYE7UNMRld5rLJYtXxY>
Subject: Re: [Privacy-pass] Draft on key consistency and discovery
X-BeenThere: privacy-pass@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <privacy-pass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/privacy-pass>, <mailto:privacy-pass-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/privacy-pass/>
List-Post: <mailto:privacy-pass@ietf.org>
List-Help: <mailto:privacy-pass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/privacy-pass>, <mailto:privacy-pass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Feb 2021 21:46:58 -0000

On Fri, Feb 26, 2021 at 4:19 PM Eli-Shaoul Khedouri <eli=
40intuitionmachines.com@dmarc.ietf.org> wrote:

>
>
> On Fri, Feb 26, 2021 at 12:28 PM Ben Schwartz <bemasc=
> 40google.com@dmarc.ietf.org> wrote:
>
>>
>>
>> On Thu, Feb 25, 2021 at 6:40 PM Matthew Finkel <sysrqb@torproject.org>
>> wrote:
>>
>>> > For Privacy Pass, at least, there is potentially a presumption that the
>>> > user has access to the network in a way that hides their identity and
>>> does
>>> > not collude with the target.  This might mean that the user's DNS
>>> resolver
>>> > is presumed to be trusted.  In that model, the resolver could act like
>>> a
>>> > trusted proxy (Section 4.2).
>>>
>>> Yes, but that could be misleading. "One DNS resolver" does not
>>> necessarily translate into one DNS cache, especially not a global DNS
>>> cache, so the global consistency properties of DNS are a bit fuzzy.
>>>
>>
>> Yes.  On the other hand, an adversary can probably identify which
>> resolver cache instance you're hitting by putting a different IP in each
>> one, so privacy beyond that level may be an illusion.
>>
>
> This can be detected and mitigated by the client with TACK
> <http://tack.io/draft.html>-style pinning pools, but seems a bit out of
> scope for the core protocol.
>

I'm not familiar with TACK.  Are you suggesting that the domain would
commit to the universality of its IP addresses and other DNS records?
That's an interesting idea, though it might not be compatible with using
classic DNS for connection setup.