IETF Logo Mail Archive

Re: [dns-privacy] DNS + 0-RTT

Colm MacCárthaigh <colm@allcosts.net> Wed, 06 April 2016 14:09 UTC

Return-Path: <colm@allcosts.net>
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 1A62E12D663 for <dns-privacy@ietfa.amsl.com>; Wed, 6 Apr 2016 07:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.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 EmH7KCYM1o9v for <dns-privacy@ietfa.amsl.com>; Wed, 6 Apr 2016 07:09:06 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 1A52F12D61B for <dns-privacy@ietf.org>; Wed, 6 Apr 2016 07:08:56 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id d68so57641676ywe.1 for <dns-privacy@ietf.org>; Wed, 06 Apr 2016 07:08:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=YFArLQp/ydfD6hVWV5dUxUiZcoGfOcgNCvVWGPt3vK8=; b=GkSULw1aQK+2fd+DQX/DnV4BUewmknVH7jH0cYC74EfC7odTkaa5inbZ1egHKJcURF tQlNfw2f1Q2Cd8Ms8fO3puA9lD66l2tHCETJlaZ/8xdITMhK/5eKE7jRh+2xrwJfP5vp q5gTCa7+hJBJZA5rEntELlh31GuvP0Nls/RGwzl20BwdEmirtTZ009xp5qGx4dz9537t IBG6XlJcwuU4SfkWX6Mf/w1iLj4KsN6AK/hvvoaOBQ7QXmsfQarmk7401dRMXz6ZR3yp FC/gVSh41fsYyUiNiRTK7wYatAkQQtqQth7sjTz2DBANTf07lFO4aZcbfXyEgq8zTaVB 9/lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=YFArLQp/ydfD6hVWV5dUxUiZcoGfOcgNCvVWGPt3vK8=; b=gISJumHkvuUB1EAJGhyG4NrKrAeFruy/BgYhyKz96xiYpFyIOiLYbNMgeT59s6+d+4 HyB2AnaUOo3bNkgJZ3hv8rYJSH7D/ASE8413i3UC2PIF442S5u/OIOHZlQ9TsB+pw33m p5bNOqlT+w1KNp0D1lUQeqjx7aypbg9L/kTeWJabbAMKKFAqUOg2cewbMpUaGQf1Neej b520yTw4vneTZOou3cAsAXsjS75cTmn9MrOqHbinIOGfYZV6dd9i2P/4s7Bwoh8ZoUri sfqf+7HEzG7C8ZYa9eQ8pjuriFWw137O6xY6WNfaUQ92TQ7XfVzBx9g4Vn/Z5VcSn5u3 Ml0A==
X-Gm-Message-State: AD7BkJL0miS5HVy9q7e6+s/aab36T8Y82vcDcbk0WeI42SiFA+8BWtNWFDwHzJEhChMOLCAUxkpD2En1O8r3fQ==
MIME-Version: 1.0
X-Received: by 10.37.52.13 with SMTP id b13mr1010230yba.159.1459951736040; Wed, 06 Apr 2016 07:08:56 -0700 (PDT)
Received: by 10.129.88.86 with HTTP; Wed, 6 Apr 2016 07:08:55 -0700 (PDT)
In-Reply-To: <87egaidh3y.fsf@alice.fifthhorseman.net>
References: <5703F0CF.3050306@gmail.com> <87egaidh3y.fsf@alice.fifthhorseman.net>
Date: Wed, 06 Apr 2016 07:08:55 -0700
Message-ID: <CAAF6GDcwGJmrPcFj_o+tCe7PTL5jFj=YZ+2LCgCTVZ=64CpOdA@mail.gmail.com>
From: Colm MacCárthaigh <colm@allcosts.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Content-Type: multipart/alternative; boundary="001a1147cc749de5e8052fd18055"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dns-privacy/HUzwIShRVwoBMghRnbfqNO_iOpA>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Subject: Re: [dns-privacy] DNS + 0-RTT
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.17
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, 06 Apr 2016 14:09:09 -0000

On Wed, Apr 6, 2016 at 6:03 AM, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:
>
> forward secrecy
> ---------------
>
> IIUC for (b), the failing forward secrecy window is constrained by the
> duration of the PSK/session resumption ticket.  That's doesn't seem
> particularly worrisome to me for DNS.
>

I'd expect many operators to re-use ticket encryption keys for far too
long, as we see with HTTPS today, so the effect is that a dns server bug
may unlock years of 0RTT data. For DNS, the query is always likely to fit
in there.


> replay protection
> -----------------
>
> For DNS we don't particularly care about replay attacks initially, but
> replayable traffic might have some privacy implications.
>
> For example, if Mallory can monitor the traffic to and from the DNS
> resolver, and a TLS-wrapped DNS request is made that is answered from
> the cache, then the attacker has no additional information about what
> the answer is.
>
> But if the request is replayable, Mallory can capture it, and replay it
> at different intervals (when parts of the cache might be expired) to try
> to coax the recursor to call out to the authoritative resolvers, which
> might provide more information about the original query.
>

There's a simpler attack too; if the RRSet contains multiple RRs, it's
common for resolvers to rotate the order of the RRs in a fixed and
predictable order. So you can query a name you suspect was queried, then
replay the target query, then query the name again, and confirm your
suspicion. This requires only a copy of the target 0RTT section, and access
to query the resolver, so a typical wifi scenario would do. Multi-RR
responses are very common these days too.

-- 
Colm

v2.23.0 | Report a Bug | By Email