Re: [Gen-art] Gen-ART LC review of draft-ietf-dnsop-cookies-08

Donald Eastlake <d3e3e3@gmail.com> Mon, 28 December 2015 20:54 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60371ACC83; Mon, 28 Dec 2015 12:54:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 abScyAO7ORMu; Mon, 28 Dec 2015 12:54:40 -0800 (PST)
Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78FDF1ACAD8; Mon, 28 Dec 2015 12:54:40 -0800 (PST)
Received: by mail-ob0-x22c.google.com with SMTP id ba1so147844406obb.3; Mon, 28 Dec 2015 12:54:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=c+wZuyAw8muzTuJsQeE24cc/M+HzQEgtq0xdfXtLL2I=; b=Xxd9gLMzztfHXkEsJYmda4kiE/ZsICd8/ezPKJkxLXHOfSVi7LTTuZ/x3mQmVXlf+k JNBLl8MwPbOni5E3RhEh0TmiW7IM3+dKMJDO632RpaIQOPCLXGpSs3rvD8gpg95PBo8T SPB1shfa3fOqLe2YMLbLKzgfMWci7YnLRGPWBQdNPO6x4ZuvYdnBKxTTwI+BYK5DpEXh eiIozo6n82hGl3uvpxfwGebSq6hfCSy+Ji7nWmvk6oLAuxtRE1S5HdKJZoJjJr4MHoXo FMgevNKhqAyTCjZ67JVTSOwuGubvQOJ9UzhIyjvu9NEHNbIRqy4h42I2KF6GyWf4T9fC MPmw==
X-Received: by 10.182.103.167 with SMTP id fx7mr33651495obb.36.1451336079619; Mon, 28 Dec 2015 12:54:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.157.161 with HTTP; Mon, 28 Dec 2015 12:54:25 -0800 (PST)
In-Reply-To: <029101d1410f$4ca0b350$e5e219f0$@akayla.com>
References: <011001d13eb3$63339cd0$299ad670$@akayla.com> <CAF4+nEGeK9u47LZKD8D_LX75RXLiVdzJVi9LQMkt=eA3mN6a_Q@mail.gmail.com> <029101d1410f$4ca0b350$e5e219f0$@akayla.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Mon, 28 Dec 2015 15:54:25 -0500
Message-ID: <CAF4+nEGxK22B+SP9tA=URe6hhhUq1sew0+f1gTfLHmNYu+xKrw@mail.gmail.com>
To: Peter Yee <peter@akayla.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/OuSRAJKqo8Xqd0AJzIorWJh_G0U>
Cc: "gen-art@ietf.org Review Team" <gen-art@ietf.org>, draft-ietf-dnsop-cookies.all@ietf.org, IETF Discussion <ietf@ietf.org>
Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-dnsop-cookies-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Dec 2015 20:54:42 -0000

Hi Peter,

On Sun, Dec 27, 2015 at 8:30 PM, Peter Yee <peter@akayla.com> wrote:
> Hi Donald,
>
>         Responses below.
>
> -----Original Message-----
> From: Donald Eastlake [mailto:d3e3e3@gmail.com]
> Sent: Sunday, December 27, 2015 4:31 PM
> To: Peter Yee
> Cc: draft-ietf-dnsop-cookies.all@ietf.org; gen-art@ietf.org Review Team; IETF Discussion
> Subject: Re: Gen-ART LC review of draft-ietf-dnsop-cookies-08
>
>>> Minor issues:
>>>
>>> Page 14, Section 5.2.4, 1st paragraph, 1st sentence: It might be
>>> useful to mention what the examination entails as it would help in
>>> understanding the 3rd sentence in the paragraph.  There's an implied
>>> recalculation of the Server Cookie value based on the received Client
>>> Cookie and client IP address as opposed to a simple lookup of the received value.
>
>>I'm not so sure of that. If the server wanted to, it could generate a random Server Cookie for each {Client Cookie, Client IP} and, in fact, do a look up.
>
> Section 5.2.4 is the invalid server cookie one.  Let's say just the client's cookie changed, but all else remained the same.  The server wants to do a lookup.  If it looks up a stored, expected server cookie based on the client IP address, the server cookie looks valid.  If it just takes the received client cookie and client IP address (plus server secret) and generates the expected cookie value, then the received server cookie will appear invalid because of the change in client cookie.

(well, presumably there is a 1 in 2**64 chance it just happens to be
valid anyway :-)

It SHOULD take the received Client Cookie into account, whether it is
doing a look-up or recalculating in a stateless manner. But it is all
potentially a bit more complex. If it is re-calculating, which is the
general assumption in this draft, it may need to try with both a
current and previous server secret. And the server could be using a
scheme such as that described in Appendix B.2, in which case the hash
portion of the server cookie can be considered an authentication code
over the other parts of the server cookie as well as over the server
secret and client cookie. In which case, after authentication, the
server might apply some restriction to the time stamp or some other
fields included in the server cookie. So determining validity could be
a bit complex.

> That's the line of thinking that led to my comment.  It appears that you're expecting to do the calculation, otherwise you wouldn't have reason to notice the client cookie changing since this is an examination of the server cookie.  Sure, you could index off the client cookie, but that seems extreme.  And you would presumably not update the server cookie value to be used in future responses until you've done the initial examination, so you unless you're doing an involved cookie rollover scheme, the client cookie wouldn't be used until it's needed to create the updated server cookie.

Well, how about inserting a second sentence into the first paragraph
of Section 5.2.4 (keeping in mind that, based on another comment, the
existing second sentence has been deleted) something like: "This
determination normally involves re-calculating the Server Cookie (or
the hash thereof) based on the server secret (and/or the previous
server secret if it has just changed), the received Client Cookie, the
client IP address, and possibly other fields -- see Appendix B.2 for
an example."

By the way, since its Server Cookies include a nonce, I believe the
BIND implementation always sends a different Server Cookie.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

>>> Nits:
>
>>> Page 13, Section 5.2.2, 2nd paragraph: append "bytes" after "40".
>
>>Why after 40 but not after 8 or 16? Seems like me it would be an improvement to add "bytes" after all three.
>
> That works for me too.  I just wanted to get the unit in there.  If you prefer to tie the unit to each value, that's fine.
>
>>Thanks,
>>Donald
>
> My pleasure,
>                 -Peter
>
>
>