Re: [dns-privacy] ADoT requirements for authentication?

Ted Hardie <ted.ietf@gmail.com> Tue, 29 October 2019 15:02 UTC

Return-Path: <ted.ietf@gmail.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 C06EA120883 for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 08:02:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 CIFUcDJTxiC2 for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 08:02:56 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 8D9661208D5 for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 08:02:56 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id c6so15077346ioo.13 for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 08:02:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dhvg8Z+HO587P1OP87R/8hOcz2vu2QDetUCg746DFDI=; b=k6xBAuVbP12ceJo7NKQbU+zrPaR2S2c34lvNF39kGcvdrLNX81iaVECGrRGWuC5Y+l tEt5TDZFZoekFkqHfQ5KPO69RLwIzloSV9gxbnWM9IrkG+IalxvhFXT+ZyviZ0LXfRKZ ePsOqkeHpHLL5aOZ31HbxcYVQjBmhiSWkiwW/5Y1U8L+Lu+Z1ScIni58j7H32ECwYTFO N868fZtvu9KLRxROgZ+knsBv8ba5kKklWr3DRozdr6N4A8cLOtbcklulefVXQRIKS95X Jnkyhisv7MkV1ACqxf/vOKfVprISCip27+TM46Lf4FdBaAurwL/Kapj3lJ6339DcOEp3 ZmUQ==
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=dhvg8Z+HO587P1OP87R/8hOcz2vu2QDetUCg746DFDI=; b=NJVETHVMBeBMb3eYrMDEE+/21G8vM52BEifZ9GdybwPxyegyZirhOOGqBv6emPpTmV fG259NV0wo818nOUnhw+nZluCPpKoQ+BqAv90xFlHo+GXufNvDEi3I3obVXDjGKtcs+p 8mtIt4r18r9zRCsGRueXFtKD0anUEgOrRJoHKjluBdFCy7oBsJiA9V09D36AUwdC6ccF OCyd5Idct+l3gSFMtW3yNCxBUEfANqwyQflVIN/nN3lK2H/+LRx46Hs+u6pTKlt6t09f LM/XAyQH4+qSpSrBQEyZP3UH6UadJVOHWJYt3m3dCLRLif2iUdOsKkdxqUa0EtULiBaz 6PQg==
X-Gm-Message-State: APjAAAWUb2oIUhj1Ur68g/CO6sC5a2YHkxGJUxADB0edF+3r3e51UadM 8WEOw3TbarThQBCso1zi5ibI2Uaaww8Tta8q6r8=
X-Google-Smtp-Source: APXvYqwO89GMaAnUxI+q937/DOYh8O7mFa/mNFhpu12seXCUJuYo6AQHb6+mfoILb3n3vgDQFkS7rQ9gxtGW//MrvB4=
X-Received: by 2002:a5d:9a10:: with SMTP id s16mr4149955iol.121.1572361375559; Tue, 29 Oct 2019 08:02:55 -0700 (PDT)
MIME-Version: 1.0
References: <943e3973-f6a7-9f6e-a66a-33aff835bd5e@innovationslab.net> <503df6fb-b653-476f-055f-15c1a668ba36@innovationslab.net> <5fe86408-35a8-16ea-d22a-9c6c4a681057@icann.org>
In-Reply-To: <5fe86408-35a8-16ea-d22a-9c6c4a681057@icann.org>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Tue, 29 Oct 2019 08:02:42 -0700
Message-ID: <CA+9kkMBZUPfWov6B+pgLYuFmZh10dTzwF2PdKs5Vozzssqvzjw@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003fb3cd05960de971"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/QE-FpyAt5nqBnOh7x4ldw1E11vY>
Subject: Re: [dns-privacy] ADoT requirements for authentication?
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: Tue, 29 Oct 2019 15:02:59 -0000

Hi Paul,

On Tue, Oct 29, 2019 at 7:50 AM Paul Hoffman <paul.hoffman@icann.org> wrote:

> Greetings again. I was surprised, but happy, to not see a requirement in
> the list for authentication of servers in the list. However, I suspect that
> this might have been an oversight, and the endless debate on authentication
> requirements will start as soon as there is a proposed protocol document.
>
> My preference would be that the core requirement is that ADoT servers use
> either IP address or DNS name authentication in their certificates, but
> that the certificates can be issued by any CA, including being self-issued.
> The core requirement could also go on to say that resolvers be able to
> authenticate servers for logging purposes, but not be required to break TLS
> connections if the server's identity cannot be authenticated against the
> resolver's set of trust anchors.
>
>
To be sure I understand you correctly, in the second case, the connection
would be made to some IP address (e.g. NASA's 198.116.4.181).  The
recursive resolver logs the details of the certificate, but it continues
with the connection even if the CA NASA uses for the certificate is not
known to the resolver?  What does it do in the face of other certificate
errors like expired certificates or certificates presenting a different
name?

I have to say that I'm pretty surprised by the idea that TLS in this
context should behave any differently than TLS in application layer
contexts, and I'm a little concerned about having configuration options for
this that amount to "ignore errors of types $FOO".  Accepting self-signed
certificates is a known configuration, so I get that, but if someone has
configured roots of trust, accepting other certificates outside the roots
of trust in the configuration is pretty odd practice.

Just my two cents,

Ted





> --Paul Hoffman
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>