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

Warren Kumari <warren@kumari.net> Sun, 03 November 2019 01:02 UTC

Return-Path: <warren@kumari.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 45B02120071 for <dns-privacy@ietfa.amsl.com>; Sat, 2 Nov 2019 18:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-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 MR6dAdtkPWpZ for <dns-privacy@ietfa.amsl.com>; Sat, 2 Nov 2019 18:02:05 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 9CD02120020 for <dns-privacy@ietf.org>; Sat, 2 Nov 2019 18:02:05 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id t20so2746407qtn.9 for <dns-privacy@ietf.org>; Sat, 02 Nov 2019 18:02:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zUVDv8rQ0NieNKZ0neaoUwxv7MCupJqwaxU8S9Bh/nk=; b=rrDmh4IQyavhueA2UU4tF/3y4Wt1bADzqnwLXgoYFpzJT1pVJkw/IPXRmWBONiSunZ BwAmUG23jIi+l8XQZ8Ct1cMhARd1ZMiHVVwPY5OVsnaStf6SSVdpiglF1rkk+EdKa2Bw JVYDqnAJZeiEQuAxfqtWGWjFbBntzTBWin6ECjiwb1I+mu0qJ7gPyipdBbIWputDMB3e LQjTW2awAqhLisosgXP8iSiLBhOoFkuJuv8tyz9T1AMNW4VoSjbxmeIqgzRFYve1zefk ZEKr3QTqkxv6oAD5Uqi9Jc7FQY14yaU92S4phh8myIWt4X34VPuVdpZXtlOgtgUVLC1j fpLQ==
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=zUVDv8rQ0NieNKZ0neaoUwxv7MCupJqwaxU8S9Bh/nk=; b=T4ZbeKTZ8Zn9Smp8SDnzYWLX788Kj6bNLvNTji1gE7Sp9RVM43pckkevhCJzfiAJYU C/a+z1MCkXhPgD3VNeS7PDkq3YcywhQfCcnCZGb6C9lN2csRuPOAM7luZuaU6RcZOxEa u0EayxsQMG6lCH+GhqgCi9Nt8eeH3jGjygZF9gY6kQtCnvSLOpNWzgKucawx8cfK0ImK tQp7zMkae3ObWWq24I+/sw7hKrZ187HHowER9HDsE093pnhl+ka37ssJwxU1cKQj/UzZ pmmZ0YJzRR5XEz4eJG6zRL69Z8DKCDcRSMT8w4qy3ikpBm/eId0hOmp0Tc+xGAIfSEnI iljg==
X-Gm-Message-State: APjAAAUU1b0jKt9uNGbSISA48iAFUxcxQJLr8Ai3RIdEwa7c7bPQ3TNU jaIL7Qfcz4V907WkG/9aXLkDah34Ab5Q7qcLh4/I5A==
X-Google-Smtp-Source: APXvYqx0WIFM/HLokd7R0lpinflyTIPho3tINsWlxxnoVO3sXVtUeBQHmgPAN2QDxpd/YaIFU1Y0MA+54cizhszM5tI=
X-Received: by 2002:ac8:4606:: with SMTP id p6mr7066704qtn.364.1572742924188; Sat, 02 Nov 2019 18:02:04 -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> <CABcZeBOBFFi=dA_XEzhkYvRU6kzvND5CMQcMoyriYusDH0RbKQ@mail.gmail.com>
In-Reply-To: <CABcZeBOBFFi=dA_XEzhkYvRU6kzvND5CMQcMoyriYusDH0RbKQ@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Sat, 02 Nov 2019 21:01:27 -0400
Message-ID: <CAHw9_iLz5No-SKa74To03ida3DHfeKY58CrJFJpLph8FsvzNQQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Paul Hoffman <paul.hoffman@icann.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/RbaImWVdtEZN_VqWBYGqVWP3eqk>
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: Sun, 03 Nov 2019 01:02:08 -0000

On Sat, Nov 2, 2019 at 3:59 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> 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

I've suggested a number of times, but haven't actually written up,
that you could encode this in the nameserver name - this is somewhat
similar to the dnscrypt idea...

E.g - no DoX expected:
$ dig ns example.com
;; ANSWER SECTION:
example.com. 42923 IN NS b.iana-servers.net.
example.com. 42923 IN NS a.iana-servers.net.

Recursive resolvers should expect DoT:
$ dig ns example.com
;; ANSWER SECTION:
example.com. 42923 IN NS b-dot.iana-servers.net.
example.com. 42923 IN NS a-dot.iana-servers.net.


Yes, I'll be the first to admit that it is hacky, and not it's not
completely foolproof, but it requires an attacker to do more than just
block port 853 to force a downgrade, and also means that resolvers
don't have to probe 853, wait for a timeout and then try 53
instead....

W



>
>
>>
>> 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
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf