Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

Peter van Dijk <peter.van.dijk@powerdns.com> Wed, 20 May 2020 13:55 UTC

Return-Path: <peter.van.dijk@powerdns.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 3C80D3A09FD for <dns-privacy@ietfa.amsl.com>; Wed, 20 May 2020 06:55:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level:
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 qHLSFfzNKNpp for <dns-privacy@ietfa.amsl.com>; Wed, 20 May 2020 06:55:52 -0700 (PDT)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FAF3A09FB for <dns-privacy@ietf.org>; Wed, 20 May 2020 06:55:52 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx4.open-xchange.com (Postfix) with ESMTPS id 678326A243; Wed, 20 May 2020 15:55:49 +0200 (CEST)
Received: from plato (ip545136af.direct-adsl.nl [84.81.54.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 48D883C03A7; Wed, 20 May 2020 15:55:49 +0200 (CEST)
Message-ID: <99d90d39c730f620e89adaf2edeef53ae99597ae.camel@powerdns.com>
From: Peter van Dijk <peter.van.dijk@powerdns.com>
To: dns-privacy@ietf.org
Date: Wed, 20 May 2020 15:55:48 +0200
In-Reply-To: <alpine.DEB.2.20.2005191147500.7596@uplift.swm.pp.se>
References: <158987990316.29446.4343920282978207647@ietfa.amsl.com> <a15e2d1df86820f2483516662d3712d8a60161cd.camel@powerdns.com> <alpine.DEB.2.20.2005191147500.7596@uplift.swm.pp.se>
Organization: PowerDNS.COM B.V.
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5-1.1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/b3ecaimO5dbu7IAuoAubTcx4UuU>
Subject: Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
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: Wed, 20 May 2020 13:55:54 -0000

On Tue, 2020-05-19 at 11:51 +0200, Mikael Abrahamsson wrote:
> On Tue, 19 May 2020, Peter van Dijk wrote:
> 
> > please find below all details about our proposal for enabling DoT from 
> > resolver to authoritative.
> 
> Thanks, interesting approach.

Thanks!

> Some thoughts...
> 
> "If the DoT connection is unsuccessful or the public key
>     supplied the server does not match one of the DS digests, the
>     resolver MUST NOT fall back to unencrypted Do53."
> 
> Can we somehow make this behavior configurable by means of a flag (or 
> something) by the domain holder? To say if fallback is ok or not?

Yes, we have imagined a few ways to make that possible:

* careful use of DNSKEY flags
* a special DNSKEY value ('empty')

But we've had trouble figuring out a decent use case for allowing the
fallback.

With my 'resolver developer' hat on, I don't want probing/fallback code
in the hot resolution path, it adds complexity and hurts performance.

> Also, when I want to roll keys, can I specify multiple keys during this 
> key roll period?

Yes, specifying multiple keys (i.e. placing multiple DS records) is allowed. This is necessary because separate NSes might have different keys, and conveniently this enables key rolling as well.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/