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

Colm MacCárthaigh <> Wed, 06 April 2016 14:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A62E12D663 for <>; Wed, 6 Apr 2016 07:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EmH7KCYM1o9v for <>; Wed, 6 Apr 2016 07:09:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A52F12D61B for <>; Wed, 6 Apr 2016 07:08:56 -0700 (PDT)
Received: by with SMTP id d68so57641676ywe.1 for <>; Wed, 06 Apr 2016 07:08:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id b13mr1010230yba.159.1459951736040; Wed, 06 Apr 2016 07:08:56 -0700 (PDT)
Received: by with HTTP; Wed, 6 Apr 2016 07:08:55 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 06 Apr 2016 07:08:55 -0700
Message-ID: <>
From: Colm MacCárthaigh <>
To: Daniel Kahn Gillmor <>
Content-Type: multipart/alternative; boundary="001a1147cc749de5e8052fd18055"
Archived-At: <>
Cc: Tim Wicinski <>, "" <>
Subject: Re: [dns-privacy] DNS + 0-RTT
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <>
> 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.