Donald,
I'm fine with the text you suggest for 5.2.4. That clarifies what goes
into the process of making the determination.
Kind regards,
-Peter
-----Original Message-----
From: Donald Eastlake [mailto:d3e3e3(_at_)gmail(_dot_)com]
Sent: Monday, December 28, 2015 12:54 PM
To: Peter Yee
Cc: draft-ietf-dnsop-cookies(_dot_)all(_at_)ietf(_dot_)org;
gen-art(_at_)ietf(_dot_)org Review Team; IETF Discussion
Subject: Re: Gen-ART LC review of draft-ietf-dnsop-cookies-08
Hi Peter,
On Sun, Dec 27, 2015 at 8:30 PM, Peter Yee <peter(_at_)akayla(_dot_)com> wrote:
Hi Donald,
Responses below.
-----Original Message-----
From: Donald Eastlake [mailto:d3e3e3(_at_)gmail(_dot_)com]
Sent: Sunday, December 27, 2015 4:31 PM
To: Peter Yee
Cc: draft-ietf-dnsop-cookies(_dot_)all(_at_)ietf(_dot_)org;
gen-art(_at_)ietf(_dot_)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(_at_)gmail(_dot_)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