Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-server-cookies

Benno Overeinder <benno@NLnetLabs.nl> Mon, 26 October 2020 23:25 UTC

Return-Path: <benno@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 8A12A3A10B9; Mon, 26 Oct 2020 16:25:50 -0700 (PDT)
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 LH7YJHGm5wSM; Mon, 26 Oct 2020 16:25:48 -0700 (PDT)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226B73A10AD; Mon, 26 Oct 2020 16:25:44 -0700 (PDT)
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 7F676609EF; Mon, 26 Oct 2020 23:25:42 +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=1603754742; bh=qlWj0xaxQRPTYtoiWghW4CXRftyg0wvjJqWH+P2FWos=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=N3hoicPUlFt4I3WILFNLfT5yub+xdUzZrA7F+elN5V69pYiAYwRINyMIHj5z7i2hQ xxdRlVcNfWVUIpghNMuh4ybvaKfPU8x3yfTip1EYDw1ReCTIYBbcPBVs10FmF0r7sa N+BMUzTzZGb/Yfbl4UCZXFAyQW7Z4xwKm8Y3lZqBEtL9L1tfR61sOjTvvREo7pt2TZ JNJGUDMRVNkkjZ/FBcD1MVoUGHkE4QYcRhb8gB8MXN5YYmvxa+yldpaO37b6QmN0Qk P8bu72wD2EqhAtE8oVAGlqPly9qLq1+ELltC2Of0HO6SpL7ds+MI73dX8+i50+NxPQ PdBrWpxyAWw6g==
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Benno Overeinder <benno@NLnetLabs.nl>
In-Reply-To: <3f1fd876-62d7-18db-30a9-0cade4cff7f4@nlnetlabs.nl>
Date: Tue, 27 Oct 2020 00:25:40 +0100
Cc: draft-ietf-dnsop-server-cookies.authors@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C617AE82-6E53-44A0-91D6-116D3B41A190@NLnetLabs.nl>
References: <894E9A77-1CE0-4513-AC89-15622A2ADABD@NLnetLabs.nl> <CAH1iCiqMWogWLr1Cw-3LYo_wkem4zV1adqUc0xna5qd+H5x3YA@mail.gmail.com> <3f1fd876-62d7-18db-30a9-0cade4cff7f4@nlnetlabs.nl>
To: DNSOP Working Group <dnsop@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/M-sxEXp3AmLaWig_RcdoUrcrGlA>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-server-cookies
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, 26 Oct 2020 23:25:51 -0000

Dear WG,

The WGLC period for draft-ietf-dnsop-server cookies has finished.  There are editorial comments that the authors have already addressed. The chairs feel that the draft is ready to move forward.

Thanks for the reviews,

— Benno


> On 12 Oct 2020, at 11:47, Willem Toorop <willem@nlnetlabs.nl> wrote:
> 
> Thanks Brian,
> 
> All but one nit resolved in these commits:
> 
> *
> https://github.com/NLnetLabs/draft-sury-toorop-dns-cookies-algorithms/commit/db51181a
> *
> https://github.com/NLnetLabs/draft-sury-toorop-dns-cookies-algorithms/commit/e1e763e8
> 
> For your convenience, a rendered possible future version of the document
> with these changes can be viewed here:
> 
> *
> https://raw.githubusercontent.com/NLnetLabs/draft-sury-toorop-dns-cookies-algorithms/master/draft-ietf-dnsop-server-cookies-04.txt
> 
> I've provided a bit more feedback inline below.
> 
> Op 10-10-2020 om 23:13 schreef Brian Dickson:
>> 
>> 
>> On Fri, Oct 9, 2020 at 8:38 AM Benno Overeinder <benno@nlnetlabs.nl
>> <mailto:benno@nlnetlabs.nl>> wrote:
>> 
>>    This starts a Working Group Last Call for
>>    draft-ietf-dnsop-server-cookies.
>> 
>>    Current versions of the draft is available here:
>>    https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/
>> 
>>    The Current Intended Status of this document is: Standards Track
>> 
>>    FYI, I will not shepherd this document, as it was written with one
>>    of my coworkers.
>>    Tim Wicinski will be Document Shepherd.
>> 
>>    Please review the draft and offer relevant comments.
>>    If this does not seem appropriate please speak out.
>>    If someone feels the document is *not* ready for publication, please
>>    speak out with your reasons.
>> 
>> 
>> I have read the document, and support publication (modulo very minor
>> nits that should be fixed).
>> 
>> In addition to these nits, I do have one further suggestion for Section 8.
>> 
>> I'm not sure if it is too late to make such a suggestion, but on reading
>> (and thinking about) the spec,
>> it could be useful guidance (particularly for clients which may not be
>> aware of changes to their Client-IP address):
>> 
>> "o   In order to determine that a Server has detected a change to the
>> Client-IP, a Client may consider
>>       a BADCOOKIE error sooner than would be expected from a Server
>> Cookie refresh as a signal
>>       that the Client-IP may have changed, and thus that a new Client
>> Cookie should be created for each Server."
> 
> This is too late. For privacy reasons, the server should not be able to
> discover that the Client-IP changed so it cannot *track* Clients with
> the help of a DNS Cookie.  The Client needs to detect source address
> changes before it uses it to send out queries.
> 
>> 
>> Nits:
>> Introduction - I believe "provides" should be "provide", to agree with
>> the singular "is" of the verb. (Sorry, grammar nit.)
>> 
>> Section 1.1 - I believe all the "Section Section" instances should
>> really just be "Section".
>> 
>> Section 4 - "too frequent" -> "too frequently". 
>> 
>> Section 4.3 - "in the anycast." -> "in the anycast set."
>> 
>> Section 4.4 - hash calculation, end of first line "Client-IP," ->
>> "Client-IP |"
> 
> (from Wikipedia)
> SipHash is not actually a cryptographic hash, bot only suitable as
> message authentication code: a keyed hash function like HMAC.
> 
> It has the form SipHash(message, key)
> 
> Thanks,
> -- Willem
> 
>> 
>> Section 5 - "anycast group" -> "anycast set"; "us used" -> "is used"
>> 
>> Section 8 - "like for example five minute." -> "for example five minutes."
>> 
>> Brian
>> 
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/