IETF Logo Mail Archive

Re: [DNSOP] Martin Duke's No Objection on draft-ietf-dnsop-server-cookies-04: (with COMMENT)

Willem Toorop <willem@nlnetlabs.nl> Mon, 11 January 2021 15:56 UTC

Return-Path: <willem@nlnetlabs.nl>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328323A0FB5; Mon, 11 Jan 2021 07:56:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=nlnetlabs.nl
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 0ThcAY3HKv_O; Mon, 11 Jan 2021 07:56:56 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.218]) (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 C78563A0E15; Mon, 11 Jan 2021 07:56:55 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id DBCFB60199; Mon, 11 Jan 2021 15:56:50 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1610380609; bh=hVW8OYRZ5q3DP4uWO5crJGPfhlhLzn+XCU3s3+kdpDI=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=HIkmVYhzY3HXOYxaZtjcznkp/QGjdk0RZQGVRB48whyD4iokNhmebEVEDCIeiS1/U JgMhN9OCKcK1mhAf2qYMtR9D68alCvlDA7Ayjpox7DyyUBgwTfCg1PrxVtesB6Tavf 60bpDNlcFYaLqtcQmnDZ19S7P6mWnC7P90WU7tMeWI65JTL9rrUK/ReyzpPZbvewtR iXx0b5uBsVOrljacB9phknDBoO+2BpBgRjmqKg6pX6aJwOx8jifoFqWxEeJVGqRgFY iSgNSiraj84Q1yJCjpAl5QpkQZ3UpK8RF09v+V/+dN4MNsN2oF8xxAIC8l5WzL8GyN Fc38PPT635Vmw==
To: Martin Duke <martin.h.duke@gmail.com>, The IESG <iesg@ietf.org>
Cc: tjw.ietf@gmail.com, dnsop@ietf.org, draft-ietf-dnsop-server-cookies@ietf.org, dnsop-chairs@ietf.org
References: <160814495642.31798.14183403949248148049@ietfa.amsl.com>
From: Willem Toorop <willem@nlnetlabs.nl>
Message-ID: <599bde75-13a9-01a7-84b4-47608e9fecdd@nlnetlabs.nl>
Date: Mon, 11 Jan 2021 16:56:48 +0100
MIME-Version: 1.0
In-Reply-To: <160814495642.31798.14183403949248148049@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LRKieWAhilG3NMnxmhfo4cwih-0>
Subject: Re: [DNSOP] Martin Duke's No Objection on draft-ietf-dnsop-server-cookies-04: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jan 2021 15:56:58 -0000

Op 16-12-2020 om 19:55 schreef Martin Duke via Datatracker:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> It seems to me the mechanisms in Section 5 would be simplified by using some
> the reserved bit to have an identifier for the secret.

Thanks Martin for the suggestion,

We actually considered this idea ourselves in an early stage of the
document, but have rejected it, because it would require the identifier
to be derived from the Server Secret somehow so that all servers in the
anycast set associate the id with the same secret. Also, there is almost
always just 1 Server Secret. Only when a Server Secret is updated (which
should takes a limited amount of time), using an identifier for the
Server Secret would be slightly more efficient.

Cheers,
-- Willem

> 
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

v2.23.0 | Report a Bug | By Email