IETF Logo Mail Archive

[dns-privacy] draft-ietf-dprive-unilateral-probing support/implementation

Peter Thomassen <peter@desec.io> Thu, 01 December 2022 15:47 UTC

Return-Path: <peter@desec.io>
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 AC275C14F6E7 for <dns-privacy@ietfa.amsl.com>; Thu, 1 Dec 2022 07:47:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0UOgIiFbrZu for <dns-privacy@ietfa.amsl.com>; Thu, 1 Dec 2022 07:46:58 -0800 (PST)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (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 34F87C14F6E5 for <dns-privacy@ietf.org>; Thu, 1 Dec 2022 07:46:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:Subject:From:To: MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=mUbGb5Ximfc6edMFDxMjFJKwJ019CcxoCFkLACx6GzI=; b=dTwWLEXl3Kw/W5fCeqkHuFuajs IMUmOaMCwq48jC3/av145qUdaEJr5vH1Ost/4+/VKpo6tNlhty9O3wO3M3POoZEcmwfzXY+LF7nxp nzx4+si/hr0ZDVIj6iXT0MOYv062859PFQ3iwy6A18d+IUaH4hKmitZ8LDmdtXBvcI0oV4TjPQIai m5+4mDTMJ/6ZFGyPOniUGj9CUGOpluxqpX+5GvZziuFoLvLUj9r5IAHKrbvDMs14mt4h97Mq3YA7y WB36W4N7Xrx0JeLGIQj8GJBLah9pZnViSk0cCeMEgux5inaqhA+hQtsw44e0+ogjeYTygm+D/n6uw vpGEcDfA==;
Received: from [90.187.67.221] (helo=[192.168.188.94]) by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <peter@desec.io>) id 1p0llx-00088H-KA for dns-privacy@ietf.org; Thu, 01 Dec 2022 16:46:49 +0100
Message-ID: <00d24ff7-45cc-5ec0-5783-57008fcc3e26@desec.io>
Date: Thu, 01 Dec 2022 16:46:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2
To: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Content-Language: en-US
From: Peter Thomassen <peter@desec.io>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/keTQ78G6SLGDn5FtlDEwNpzk8ZU>
Subject: [dns-privacy] draft-ietf-dprive-unilateral-probing support/implementation
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Addition of privacy to the DNS protocol <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: Thu, 01 Dec 2022 15:47:02 -0000

Dear WG,

deSEC has been observing the development of draft-ietf-dprive-unilateral-probing, and we think that opportunistic encryption is very much worthwhile doing. Of course we hope for a long-term solution for defending against active attackers as well, but in the meantime, this is great.

We're glad to announce support for DoT and DoQ on our authoritative anycast deployments.

We are trying our best to adhere to the draft's provisions, and fully support Section 3 ("Guidance for Authoritative Servers"). So far, padding has not been fully implemented, but we are planning to follow up on this once some preconditions have been sorted out upstream.

Is there a collection of resolver and/or authoritative operators who have implemented or started implementing the draft? If not, perhaps we can gather them here.

Best,
Peter

PS: We are grateful for financial support from RIPE NCC's Community Projects Fund for this work.

-- 
Like our community service? đź’›
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

v2.23.0 | Report a Bug | By Email