Re: [DNSOP] DNSSEC as a Best Current Practice

Ted Lemon <mellon@fugue.com> Mon, 21 March 2022 12:55 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A623A19CD for <dnsop@ietfa.amsl.com>; Mon, 21 Mar 2022 05:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.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 sgPGBRkQOro0 for <dnsop@ietfa.amsl.com>; Mon, 21 Mar 2022 05:55:27 -0700 (PDT)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 DABE23A0E5C for <dnsop@ietf.org>; Mon, 21 Mar 2022 05:55:26 -0700 (PDT)
Received: by mail-ot1-x334.google.com with SMTP id a7-20020a9d5c87000000b005ad1467cb59so10428325oti.5 for <dnsop@ietf.org>; Mon, 21 Mar 2022 05:55:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q31/CCa0lE/nMGVqHLMrDRSOj6Ff8goF6Zf4YQKTV90=; b=MtWKMfJA2KIr9lic/20YxHAV8lYD3qwghmhnWH8bu1ElL9BdTKQU6VMexLG1ji1Pyy 8y8NgmHyCfOcZgiWTCk5wd4Dt1+2gb8dyYb+vrgxNXpSug65jH3pxuXR14gnJLOMC6Vt CMP6HsxzbHjmXh3q5msNMv4pteijFz8H/Wzsd2PZjmVGVwk3NrqtTwMeIRd6Ikh/cdgR R1Bb5RoO/cnE0IKWksN68Sg1Rg8vUBJ4tH6mPkPp0u99U3TYAfyjIvYy74rHmoSkCncC h16PBfb3nnQkI1wFOvoO4Lwh8HZ5QyOvWAhmP41V0vIpJd26dGDT3nK63d+Pf8J0Uvvb mh/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q31/CCa0lE/nMGVqHLMrDRSOj6Ff8goF6Zf4YQKTV90=; b=mzBV+JGyeR9We2E0cBgpPxn/T+pMT8fkVlAisZXWEr7/tqT9BI1udJ/eNgHDoDzBJC MjQvJWbPNEZMzG7zw4TCAVfOCu0cV3Is0C+owHJN0JI+MU2+L4qqh823tW1F7aP/ifDu yLn6uc9ZX+q8PhTmSagM16glP8JwVbpci8pHcPWKiEKNp3A6WQ22+FfIOeZ7JIzG8vHi +kca51/XhKVVh/R5upLPFyAoXcCNkcEtDG6XQinmO/mMhMxWr8GRWPcy9cB9R+0j6Yne cw6irFo/DMhtsya54wKvkJiwEhB2u5JQ45VHMbZN0R1z2ibFFeGMSIaULvhjaZpogQYE fqag==
X-Gm-Message-State: AOAM531y0dqPLZBJXpawXInfJZPULrnt+/vIdFKfST3djDZUAuXeayuQ mq51xaRk+5S4S7/AzQ7cisMv+OBNTNebRvYj7wweyqeCMpIB0ZPXwMc=
X-Google-Smtp-Source: ABdhPJwviYu8KjkInFeu/y2gT9ru+Xbz/x1VBOl3p4Bnfd0U5/ASD8GrokHakF+NmRkiYF4suZCSawryBb286+fS1Xc=
X-Received: by 2002:a9d:6292:0:b0:5b2:4693:de5a with SMTP id x18-20020a9d6292000000b005b24693de5amr7796878otk.163.1647867325786; Mon, 21 Mar 2022 05:55:25 -0700 (PDT)
MIME-Version: 1.0
References: <7aaed092-8877-ec15-9b7b-5d488e383d04@necom830.hpcl.titech.ac.jp> <7C43871E-60AF-485D-8AB3-65E72539F831@nohats.ca> <59fdc791-4482-141b-03b4-bc27e8824f31@necom830.hpcl.titech.ac.jp> <CAPt1N1maPf2zrEkyXL1yqkkNbVOR6sUyLXZv2Lc_r4=iVhVO=w@mail.gmail.com> <3035599f-bcb9-b753-54bc-32f61683a0e5@necom830.hpcl.titech.ac.jp>
In-Reply-To: <3035599f-bcb9-b753-54bc-32f61683a0e5@necom830.hpcl.titech.ac.jp>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 21 Mar 2022 13:54:49 +0100
Message-ID: <CAPt1N1nx78t9or38S-zNbV2bSyYnQNmGnwzQ0FZX+fTvu=DpAQ@mail.gmail.com>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Cc: dnsop@ietf.org
Content-Type: multipart/alternative; boundary="00000000000097433105daba02ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tEqtDMsV91Y8-hAq5CDlZb0eLII>
Subject: Re: [DNSOP] DNSSEC as a Best Current Practice
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Mar 2022 12:55:30 -0000

Ohta-san, I think the points you are making in response to what I have said
are that

(1) it's easier for a government to fake a DNS delegation than to MiTM an
IP connection, and
(2) if it's a government that's faking your DNS, they can jail you for
noticing.

I think these are both valid points. However, I don't think they lead to
the conclusion you are drawing. First, if the government really cares about
censorship, it's probably going to do some degree of DPI for connections to
IP addresses it has reason to care about. So you could in principle do a
connection to a device that isn't on the government's radar and bypass
their attack, for sure. But this is actually quite hard for a layperson to
arrange, and impossible to automate, since any automatic mechanism would be
known to the government in question.

To the second question, this is also absolutely true, but at the same time,
as we can see, just because something is illegal doesn't mean that it's not
useful. E.g., the government in Russia has made it illegal to protest the
war in Ukraine, and yet we see people protesting in the streets. Their goal
is pretty clearly to bypass a government restriction on communication.

Having a watchdog in software that notices when a certificate has been
replaced by one that isn't valid isn't that hard, and while it might be
made illegal after the fact, officially making it illegal would be a public
act that would have to be announced by the government in order to be
enforceable—otherwise software vendors would have no reason to know they
were violating the law. By announcing it, the government in question is
disclosing the status of your security, which is the whole point. Absent
such a disclosure, citizens can continue to run such software, and continue
to detect such attacks. In the presence of such a disclosure, citizens know
that their traffic is not secure, which is obviously not great, but still
represents success: the user now knows that the network isn't safe to use.