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

Brian Dickson <brian.peter.dickson@gmail.com> Tue, 29 October 2019 17:07 UTC

Return-Path: <brian.peter.dickson@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 2C8D5120848 for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 10:07:44 -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 qsUo5tNYoYBY for <dns-privacy@ietfa.amsl.com>; Tue, 29 Oct 2019 10:07:42 -0700 (PDT)
Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 ECB5C12080D for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 10:07:41 -0700 (PDT)
Received: by mail-vs1-xe2e.google.com with SMTP id k15so9254124vsp.2 for <dns-privacy@ietf.org>; Tue, 29 Oct 2019 10:07:41 -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=5tMGoiF9t/boGh0kEHW0o4fWTFNXXsWHgwaPBY0OK7M=; b=mr8LWpWz06bXNBC6cfj+Bh72qcMoLw/TLmVIQX1UIvPWdTBeaVwcayoUOdUdO3UCvL LgN2WD1u4JhtwdjJxz/4kK+Fu90YEyv5L/yuL519xCO8TiKIfzpXCqkXAmkJXATpAfhn WHOCgD68CRgYr4u4RIGbZHNUmzQujq4lQzH5Adr0zZmrKL8Kr6kDkPpBT2K67TyVVX4M gwblzsydgEflbz6dILORmR2sOoMFdUEVq+u9FEh13fnqguedZmHNKGFj++rBJSYsiCw+ 7swW2wbp4niO7TGf/Ugh1FYYDhIGQi2CwJe/AsjtSrj9GzvIEH/CyYoB/brYL6L0Q6JW f/LQ==
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=5tMGoiF9t/boGh0kEHW0o4fWTFNXXsWHgwaPBY0OK7M=; b=A+Qq1i/vSmR0C/m+l6rfba/aerLeLwO7SX4NXDpNi1ypvHfjVct7Q0jCogHSfodBJx m0YdGX5L4O4h+noiSpeAu7NBqBOXkfgZa6wnH4RB4SEcmtL4EREnxwCgKVuqOE7qL2Om 6lZ8PvV0IKtfBr4EHLeOKU6su9p8ftCn3LYZIbkW5po1iEwJbx9iVzzdtIDbSzLL4EEi tA3QnTHYQNdS1xtnpgdcf7nb9XR4UApuWVqit+Md54cCdRlJTekgS+dJpCC37qOU0tqU UCVCjPVmQHvAAGS3dzV+YWCmMuj5yBBXxea6Jwzzlu4bphDH3ALkuYIMwmTr1Miyi1Os fkuw==
X-Gm-Message-State: APjAAAWlyHhVXTy8OcjaGt9YX4Biw/4yZhQp0+idpaTEZJ2hkWUWV3IG yhf8Br5KDm89CRZ0aSkWjHs1sBitZgTHP5rxTes=
X-Google-Smtp-Source: APXvYqzEW0ra8GqR9YbMtMOALxUBnKL/ftWmdoNr9qZhTaQeZEIXvebFyIvgvvOo20kH8bvlgsDJV0za+y6D0MtPPiw=
X-Received: by 2002:a67:f5d7:: with SMTP id t23mr2412595vso.75.1572368860970; Tue, 29 Oct 2019 10:07:40 -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> <CA+9kkMBZUPfWov6B+pgLYuFmZh10dTzwF2PdKs5Vozzssqvzjw@mail.gmail.com> <edf53c16-3be9-786c-dcb1-0edc9fd9711c@icann.org> <CA+9kkMC5ynqK+8QO==5Pi_9edjTkJJ3yLHBHqJFOox8fi1_8HQ@mail.gmail.com>
In-Reply-To: <CA+9kkMC5ynqK+8QO==5Pi_9edjTkJJ3yLHBHqJFOox8fi1_8HQ@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Tue, 29 Oct 2019 10:07:29 -0700
Message-ID: <CAH1iCirFGNNH1xqhE5ANz1-Un77eshHQ7SMFhRuE9jg9qMvuFw@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Cc: Paul Hoffman <paul.hoffman@icann.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006a03e805960fa73a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/UQysbRUhA-bKYJFz8dF48l2MYao>
Subject: Re: [dns-privacy] [Ext] Re: 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 17:07:44 -0000

Top-reply, which I think can potentially address all the underlying issues:
Make DANE support a SHOULD, along with publishing corresponding TLSA
records at the FQDN of the DNS server a SHOULD. Make the recommendation
that the certificate served include the full chain including CA cert.
This would enable all forms of certificate issuance (public CA or not) and
validation type (cert chain or end entity) workable for doing certificate
validation.

I think this means that if both parties follow the recommended practice,
that even self-signed certs can be validated through the DNSSEC validation
plus the TLSA validation mechanisms.
The only reliance would be on the DNSSEC root trust anchor. That is
mandated when DANE is used, so it can be relied upon for all
implementations that follow the recommendations.
(Root trust anchor algorithms will always be a long-term thing to be
concerned about, but that is really a global issue for DNSSEC and
validating resolvers, not specific to this particular use.)

Brian

On Tue, Oct 29, 2019 at 9:01 AM Ted Hardie <ted.ietf@gmail.com> wrote:

> Hi Paul,
>
> On Tue, Oct 29, 2019 at 8:27 AM Paul Hoffman <paul.hoffman@icann.org>
> wrote:
>
>> On 10/29/19 8:02 AM, Ted Hardie wrote:
>> > 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?
>>
>> It continues. This is exactly how opportunistic encryption is defined.
>>
>>
> Just to be clear, it's my experience that accepting self-signed
> certificates from peers does not equate to accepting certificate errors.
> The situation in which you set up a connection to n.n.n.n and get a self
> signed certificate saying "example.com" and when you set up a connection
> to n.n.n.n expecting "example.com" and get a cert back for
> "accident.example" are pretty distinguishable. I would expect some
> configurations to accept the first without issue; I find accepting the
> second deeply odd.
>
>
>> > 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".
>>
>> TLS in application layers can specify that opportunistic encryption, yes?
>>
>>
> I think you are using "opportunistic encryption" to mean something
> different from what I mean by it.  What I mean by it is "use it when you
> can, even if you don't know in advance you can".  Testing for DoT before
> using a DNS resolver on UDP 53 and using it if you find it is
> "opportunistic encryption", for example.
>
>
>> >  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.
>>
>> Do you feel that there is a requirement that all recursive resolvers use
>> the same set of trust anchors?
>
>
> No.
>
>
>> If not, and if you are against the use of opportunistic encryption in
>> this case,
>
>
> See above.  I don't think I'm against opportunistic encryption.  I think
> I'm against starting to exchange traffic over a TLS connection with an
> identifiable error.  There are degrees there, obviously.  Some folks would
> say an expired but correct certificate should be logged but accepted, but a
> flat out "wrong name presented" would likely get different treatment.
>
> who will decide what set of trust anchors all resolvers in all
>> jurisdictions will use?
>>
>>
> Everyone will decide who they accept?  That's how the WebPKI works, for
> all its shuffling glory, and with ACME/Let's Encrypt it has gotten very
> easy to get a certificate that will often be accepted.
>
> Just my two cents,
>
> Ted
>
> --Paul Hoffman
>> _______________________________________________
>> dns-privacy mailing list
>> dns-privacy@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>