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

Willem Toorop <willem@nlnetlabs.nl> Tue, 12 January 2021 08:41 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 3338B3A0B9F; Tue, 12 Jan 2021 00:41:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, 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 yNAD0XZVdR6t; Tue, 12 Jan 2021 00:41:04 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::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 C59843A0AFB; Tue, 12 Jan 2021 00:41:03 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.24]) (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 479EE600E9; Tue, 12 Jan 2021 08:40:58 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1610440857; bh=frQGUdL2woJQVJE7xnNlq4mrDd3+dXhVQ7eeGphNwFY=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=KW8N4eCGpJbDw6svw4sClLbpPlVaB0fUWN+SUcafMoc1FHZJ+xeiy6+MDcfl5x/tN 63s9xG0Uz+9ZIS5nIjtS82JKTsLQjDH/RBU3WSPB6aLjNMoCcdhQg6/JxowWUVai9p Ibv5j11iX6Gy9xHTTvD426/LxUnzoxTpN+NFxgeGbBMzJCwNWj7JIZYKzJlShIkCAU YUN/myZ9QxFIL86x1WUByILBwg7CKDZUDdIaxIZV4U2sQpW4IU8M+Q0aVnUhSBUsEQ XdN9FUgRmvkuMf5GZs3YFBYbrXpvd/ok0OMkiaAIjU7LeMLrKefz10lAOXdNaPjETt j5MWh8AvZgrBA==
To: Éric Vyncke <evyncke@cisco.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: <160819065136.28993.1105069299288196175@ietfa.amsl.com>
From: Willem Toorop <willem@nlnetlabs.nl>
Message-ID: <0afa7d66-a980-7e79-5ca5-a9b3ffb7ca2a@nlnetlabs.nl>
Date: Tue, 12 Jan 2021 09:40:54 +0100
MIME-Version: 1.0
In-Reply-To: <160819065136.28993.1105069299288196175@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/IKN9hBAntmgKMFMA4E2w1nOWPxc>
Subject: Re: [DNSOP] Éric Vyncke'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: Tue, 12 Jan 2021 08:41:07 -0000

Op 17-12-2020 om 08:37 schreef Éric Vyncke via Datatracker:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------

Thank you for your feedback Éric,

> -- Section 3 --
> I like that a Client cookie must be changed upon local IP address change but I
> am afraid that there is no way to detect that a provider Carrier Grade NAT
> (CGN) is using round robin among a pool of public address; this still allows
> for client tracking as the client cookie is unchanged even if the public IP
> address has changed. Should there be some text around this issue or in the
> security section ?

Agree, I have a soon to be submitted revised document that has a
paragraph on tracking of public IP of a NAT devices being beyond the
scope of the document. See:

	https://github.com/NLnetLabs/draft-sury-toorop-dns-cookies-algorithms/pull/23/commits/83155e4bfed1afb08611723a13f9ebc045179e63

> 
> -- Section 4.4 --
> Should there be a recommended minimum length of the shared secret (or entropy
> level) ?

With SipHash-2-4, the secret is fixed length: 128 bits.

> -- Section 6 --
> In "This document REQUIRES compliant DNS Server to use SipHash-2.4 as a
> mandatory and default algorithm for DNS Cookies", I wonder whether "a mandatory
> and default" is required as only one algorithm is specified and there is a
> "REQUIRES".

Well, there could be more algorithms in the future, but in that case
this one will be the default one.


Your other comments and nits are addressed in the revised document.
Except for the suggestion for a different title, which we're still
discussing.

Cheers,
-- Willem