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

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/