Re: [dns-privacy] [Ext] Threat Model

Eric Rescorla <ekr@rtfm.com> Sat, 02 November 2019 19:59 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 A51A012021C for <dns-privacy@ietfa.amsl.com>; Sat, 2 Nov 2019 12:59:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 67lEF2JmnGEz for <dns-privacy@ietfa.amsl.com>; Sat, 2 Nov 2019 12:59:17 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 349FB12002E for <dns-privacy@ietf.org>; Sat, 2 Nov 2019 12:59:17 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id e9so240014ljp.13 for <dns-privacy@ietf.org>; Sat, 02 Nov 2019 12:59:17 -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=8icCHVtDGt66YJZdriaMAsnvDvzQDx/TwBR3l0FD2Q8=; b=BF1hMgjZjM+G9kqUEScxNjJGS3Mrn8WSLSGJ9x4pj5ElNz3XaKD9KEjY6pGqsnq53t wSGBM+mw0nzD8RMvmurwwFCIXpOQbg+UNRwLB+U6SnZUIfGGQwgoH1lUZSaCbWm0GZKi 73ZUwOtrsM3ITzDFaoHkW4nr0b8CCdWPTpL73eOkYa4irVF3+LK48drtXRjiyz6AGrVb PFOCcm/Sd7BN+zpaKYtNVHt69bgArT/VJfvMJncGLwcXFv2B4bKsoFrfmOnArxVzdO3V z59ndWFFAUdPeBL3nJO4Wudj4QKUwIQzjHSo9FOWC8W86kkAXEf2n3kzx3UlLAL5c2S9 r6JQ==
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=8icCHVtDGt66YJZdriaMAsnvDvzQDx/TwBR3l0FD2Q8=; b=sILmkacgWeloxJ8DjtMGkH5u+2dFp52nrs+VHqPlQQlg/Kdum66De29TKfo8qTV8Aa 1Ze8nZRxmZRsPQhdPGOld3NYWz/PgmTdWTfUeZTEglPCaDNoXi2aQQ4jPQ5r2k4e+sxE PayYJXlFxQssnjwGNvvr+/u8Lme5nUbLzEXy/esTUduLufnRYalbZiHBzoKTfOoVDopH HpPtUBxvfvkQTs4/97LKWkL+mOIa4/LMzs+QIWAreTjgSCx94gXHyThf8F/Gl546SxEr onp0JNfn4FH60NjUX/3fXQ19oAwD2LZUwcr3+f/lvdv5DFpuzwCHJYxtLqUrwFilMf0k U6nw==
X-Gm-Message-State: APjAAAW70qQmVC+o7mPgVQr/qbAcNSXMyS1NsTnugzi5f6Wp4UqbuhRi Dm9Et+DxUYE7N0YeXys6lVGhI32OAvSycEP3d6nKFw==
X-Google-Smtp-Source: APXvYqwbF7H6txU1orKeMlvy7Ypu/FPUELVkj5h9RA5EO+ZmCdRLrmWcDvzmmdiwqf9H47i1vNPf4R8qXTDp7eZ3kQc=
X-Received: by 2002:a2e:8947:: with SMTP id b7mr12559939ljk.29.1572724755485; Sat, 02 Nov 2019 12:59:15 -0700 (PDT)
MIME-Version: 1.0
References: <CABcZeBMQEJ=LE8ATQYnJj59srsK47hf4HT3BMMg3X2crVfSUXQ@mail.gmail.com> <1a70035e-edef-a3f4-ea91-52409ba37828@icann.org> <CABcZeBPAtvf3RU2gKWzyTaNwd6NBGsBuxq+n6r0W6-2RCnivSA@mail.gmail.com> <17189d1a-7689-f68d-6fe3-8d704af614a3@icann.org> <CABcZeBOhSYvqPyDcm9zbMYRc03DmPcCKYTYE-uC54=Mm9HMcnQ@mail.gmail.com> <99ee8cd4-9418-2d64-57fd-487b4f2c3a1a@cs.tcd.ie>
In-Reply-To: <99ee8cd4-9418-2d64-57fd-487b4f2c3a1a@cs.tcd.ie>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 02 Nov 2019 12:58:39 -0700
Message-ID: <CABcZeBOBFFi=dA_XEzhkYvRU6kzvND5CMQcMoyriYusDH0RbKQ@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Paul Hoffman <paul.hoffman@icann.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000616b7e0596628499"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/X_oDiPlJv0OXYr8hUURSEJHqqVA>
Subject: Re: [dns-privacy] [Ext] Threat Model
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: Sat, 02 Nov 2019 19:59:20 -0000

On Sat, Nov 2, 2019 at 11:52 AM Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> Hiya,
>
> On 02/11/2019 18:33, Eric Rescorla wrote:
> > On Sat, Nov 2, 2019 at 7:03 AM Paul Hoffman <paul.hoffman@icann.org>
> wrote:
> >
> >> On 11/2/19 9:58 AM, Eric Rescorla wrote:
> >>> Generally, I would expect that a solution which addressed the active
> >> threat model would also address the passive one.
> >>
> >> Of course, but there are many threat models that have different
> solutions.
> >> The passive threat models might be addressable more quickly than the
> active
> >> threat model.
> >>
> >
> > Yes, that's why I asked the question of whether we are trying to solve
> the
> > active attacker case.
>
> Tackling passive and active attacks are not mutually
> exclusive goals.
>

Nor did I say they were.



> Experience from SMTP/TLS (as I interpret it anyway)
> was that defence against active attacks only really
> became tractable a few years after mitigations against
> passive attacks had been deployed and clearly hadn't
> broken anything. Note that that transition did not require any changes
> to SMTP/TLS, though it may have needed
> the mail equivalent of HSTS and reporting to have been
> defined (it's hard to tell what really motivated folks
> to try mitigate active attacks for sure).
>
> Whether or not adot is sufficiently similar is (for me)
> an unknown at this point but I'd hope we don't rule that
> out.
>

I think the primary difference between this case and the TLS case,
where, as I note below, defense against active attacks was required from
the beginning, is the question of whether or not the reference that
the initiator has tells it that it supposed to expect security. In the case
of TLS you have that with the different URI scheme (https) but in
the case of email you do not.

Conversely, what made opportunistic style approaches viable for
SMTP was that there was an existing protocol handshake that
could be conveniently adopted to have upward negotiation (STARTTLS).
This was more of a pain with HTTP, though RFC 2817 does in fact
specify something.

In this case, I think the relevant question is whether there is some
viable mechanism (by which I mean one that people might actually
use) by which recursive resolvers would, in talking to an authoritative
resolver, detect that that resolver supported secure transport and
upgrade. If there is, then it's potentially possible to have some kind
of opportunistic approach. And conversely, whether it's viable
to have the records that point you to the next authoritative convey
that you should expect security. If there is, then it's potentially
possible/better to have a non-opportunistic approach



> ISTM that requiring day-1 defence against active attacks was to an
> extent responsible for the lack of deployment
> of IPsec and DNSSEC,


I don't understand what DNSSEC would do if not defend against active
attack.


so I hope we keep an eye on that
> ball too.
>

OTOH, TLS had day one defense against active attacks.

-Ekr