IETF Logo Mail Archive

Re: [dns-privacy] Some additional signalling ideas

Alexander Mayrhofer <alexander.mayrhofer@nic.at> Mon, 01 April 2019 08:32 UTC

Return-Path: <alexander.mayrhofer@nic.at>
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 BFA591200D5 for <dns-privacy@ietfa.amsl.com>; Mon, 1 Apr 2019 01:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nic.at
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 UylyLDCWTNHx for <dns-privacy@ietfa.amsl.com>; Mon, 1 Apr 2019 01:32:22 -0700 (PDT)
Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 CF97A1200CE for <dns-privacy@ietf.org>; Mon, 1 Apr 2019 01:32:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nic.at; s=it2019; h=From:From:To:CC:Subject:Date:Message-Id:Content-Type:Received:Received; bh=gCxhsjfyE0K9mf61+vF1/BcYp1i0mWaM30QyWbwzHuw=; b=h7vUP+m6D3pnCgHhJ6Fp8AlBolFbozvrKQjLeema900jW5yQLR2SuPXQOpx/GSGlC67r1OgGT+Z2Fbn1NirF8UasSYnHnvgvW1oABTX+EuTXOOm04bG0/N3uOpAFM2ycDIo/qtL0xrTem0Tp0zsbWaWHaNvnY+s9Pb+CM5HSshdOavHUncK5NAolKgZJgvVNNzfWk5zUIhT6E/iaSkrtkzLLWnKjWUNm2BFMZr2Qliw8dn0nz5zn7p2uhX7k8bBE/X/S1UV44Qu39ql0puhtHXXHdbQI6TW6SpGYRtzgPLAlvzeHVwtKaXixiGCUuDka97EE4PLnyqtFSI2W6ZeRzA==;
Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at with XWall v3.53 ; Mon, 1 Apr 2019 10:32:15 +0200
Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0439.000; Mon, 1 Apr 2019 10:32:12 +0200
Thread-Topic: [dns-privacy] Some additional signalling ideas
Thread-Index: AQHU58AuNE4qfzB6P06AJ4MnkGMQqKYm1ZRggAABL4CAACQIEA==
References: <CACsn0ck-SNweieak5Fn7TOLLZTvsQNo6+w3nezxKuZPq0Z4QNA@mail.gmail.com> <19F54F2956911544A32543B8A9BDE0759FC0E5B8@NICS-EXCH2.sbg.nic.at> <ade0a4a8-27dc-b2a5-ffbe-8693953876ef@cs.tcd.ie>
In-Reply-To: <ade0a4a8-27dc-b2a5-ffbe-8693953876ef@cs.tcd.ie>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.10.0.110]
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Watson Ladd <watsonbladd@gmail.com>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Date: Mon, 01 Apr 2019 10:32:11 +0200
X-Assembled-By: XWall v3.53
Message-ID: <19F54F2956911544A32543B8A9BDE0759FC0E6DC@NICS-EXCH2.sbg.nic.at>
X-XWALL-BCKS: auto
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/eoUq-ccAMACP93AipdD_4QvBoyM>
Subject: Re: [dns-privacy] Some additional signalling ideas
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: Mon, 01 Apr 2019 08:32:24 -0000

> On 01/04/2019 07:19, Alexander Mayrhofer wrote:
> > I have some experience in creating drafts for "funny" EDNS0-options
> > (RFC7830), so I'd volunteer :-P
> Actually, that maybe raises a point. If use of DoT to secure recursive to
> authoritative traffic also requires padding (and I can't see why that's
> different from the stub-recursive situation), then presumably deployment of
> this EDNS0-option is needed in any case, so does that imply that a new
> option for signalling would actually be just as practical, in deployment terms?

[AM] Hmm.. It's April 1st, so why not abuse the EDNS0 padding payload to convey certificate fingerprints? Oh, well, we excluded the use of Padding for unencrypted transport.. hmm.

;)

Best,
Alex

v2.23.0 | Report a Bug | By Email