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

Colm MacCárthaigh <> Sat, 09 April 2016 21:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1BA8D12D0D9 for <>; Sat, 9 Apr 2016 14:58:46 -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 p5uDDLabxh2b for <>; Sat, 9 Apr 2016 14:58:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4AA4712B007 for <>; Sat, 9 Apr 2016 14:58:44 -0700 (PDT)
Received: by with SMTP id t10so171073879ywa.0 for <>; Sat, 09 Apr 2016 14:58:44 -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=7M6EgIopHTNt0w8OHP1jHaoA5mE2aOTPGSGkX9x0wjw=; b=qH0CD0xMnkXTJ8nr+omn/781YHrsgNLKqg+rc91HPXKP14/GNeIxqxu4Y4PElPfSGk 6a2RLk1jH5VTVPOeYmCgsgtfEEOz6i9rwZ3Res9ZONaEXahhAoHShPYHFTf1GDuPzD68 vXQCwzLqCq016F93psIbj9TLjUAZq/g2yr38r6frsv9emMywR9WjJrON1g+QO+tioto3 EWDN18UGodYri8lGn04VBRBEINFfM/OulA7QtzQLbuPjB570uhfIwjlKGSrRirNexwwX hCiiYrd825kOOizBoedUsJLmaMPx+p3qtUIT0M/I6fXmqjFM6cILQgCKOvySH1Cnu8Lq keuQ==
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=7M6EgIopHTNt0w8OHP1jHaoA5mE2aOTPGSGkX9x0wjw=; b=N45NPkA1/YWjHk79uqbnR1PHuQ07rJUv+7OHjXn37k/YRjcHmmgTPUr0ERkUGmd/HW QYBHlCwIHbM83DTG3p2QV0fnfLH7J3A3GSr7zh+IqCP3E5IWmjDAx94iAyx+MKFUTyJ9 ZxP/oocDFhEUtKiS3255S/gMO2ZvojSe75CCRRyYjvtspG80/Rnzq+LIWWqoLuW3r0Hw KDtre5QIn0z4fIc9WNyfEEvtGUaMzb0opOnJsu28SOTi7sX1PwPXRf5c5zhubUuc8/DJ wBgqKB9Jns84qYY55ls5iJa4OfWcO+iKXtW6sYFhhde2nMjXAudT9IPzYbE7iQwhFadr 636A==
X-Gm-Message-State: AD7BkJKCpj/879r5RIxnVGM3FxGHXRLu/GsyapLht9zyUT47pd58VgvY1UH0nVctawUCn9cHJWM+dQAlFpVwag==
MIME-Version: 1.0
X-Received: by with SMTP id b13mr8168365yba.159.1460239123409; Sat, 09 Apr 2016 14:58:43 -0700 (PDT)
Received: by with HTTP; Sat, 9 Apr 2016 14:58:43 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Sat, 09 Apr 2016 14:58:43 -0700
Message-ID: <>
From: Colm MacCárthaigh <>
To: Daniel Kahn Gillmor <>
Content-Type: multipart/alternative; boundary="001a1147cc743d3c530530146aad"
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: Sat, 09 Apr 2016 21:58:46 -0000

On Sat, Apr 9, 2016 at 2:58 AM, Daniel Kahn Gillmor <>
> >  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.
> This would be a good argument against doing any sort of session
> resumption, i think, not just 0-RTT.

I intend more as an argument against the kind of session resumption that is
in TLS. Elsewhere the protocol has all sorts of reasonable limits on key
re-use, and they're enforced with decent mechanisms. But there's a gigantic
out in that ticket encryption keys are "outside" of  the protocols own
scope and so frequently they end up being a very weak point in the chain.
We should do something about that. I don't mean that session resumption as
a concept is a bad one.  I do mean that folks will hard-code those keys,
not rotate them nearly frequently enough, and that since DNS queries fit in
the 0RTT data the reality will be that a single key compromise could
uncover years of queries. Seems like a pretty big deal.

>  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.
> Just to make sure i understand this attack: suppose the rotation of two
> RRs returned for a given response goes:
>   A,B
>   B,A
>   A,B
>   ...
> Then the attacker would query, note the order, replay, then query again.
> if the order received each time was the same, it's strongly suggestive
> that it was the correct guess.  Is that the proposed attack?

Yep - you have it. It's easier too when there are more RRs, since the
signal is stronger, but an attacker can repeat the attack as many times as
necessary to gain confidence that they've identified the query.

> >  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.
> It strikes me that we should discourage privacy-sensitive resolvers from
> employing this pattern. though i'm not sure where that documentation
> would go or how to write it.  Is there a term for this kind of stateful
> response history leakage?

Bind9 calls it "cyclic" rrset-order:

but I'm not sure if it comes from a recommendation in any RFC - I couldn't
find one from a quick search.