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

[Donald Eastlake]

Hi Peter,

On Sun, Dec 27, 2015 at 8:30 PM, Peter Yee <pe...@akayla.com> wrote:
> Hi Donald,
>
> Responses below.
>
> -Original Message-
> From: Donald Eastlake [mailto:d3e...@gmail.com]
> Sent: Sunday, December 27, 2015 4:31 PM
> To: Peter Yee
> Cc: draft-ietf-dnsop-cookies@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
 d3e...@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
>
>
>

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Peter Yee]

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:d3e...@gmail.com] 
Sent: Monday, December 28, 2015 12:54 PM
To: Peter Yee
Cc: draft-ietf-dnsop-cookies@ietf.org; gen-art@ietf.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 <pe...@akayla.com> wrote:
> Hi Donald,
>
> Responses below.
>
> -Original Message-
> From: Donald Eastlake [mailto:d3e...@gmail.com]
> Sent: Sunday, December 27, 2015 4:31 PM
> To: Peter Yee
> Cc: draft-ietf-dnsop-cookies@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  d3e...@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
>
>
>

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Donald Eastlake]

Hi Peter,

Thanks for the comments, see below.

On Thu, Dec 24, 2015 at 8:27 PM, Peter Yee  wrote:
> I am the assigned Gen-ART reviewer for this draft.  The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comment.  For background on Gen-ART, please see the FAQ at
> 
>
> (Actually, I'm tardy on this review.  It inexplicably dropped off my radar.
> So deal with these comments when you get around to handling Telechat input
> or AUTH48 or whenever it suits you!  I'm still posting this review as it
> will be needed come the Telechat.)

I don't think it has been scheduled for a Telechat yet so we might as
well resolve these comments now.

> Document: draft-ietf-dnsop-cookies-08
> Reviewer: Peter Yee
> Review Date: December 24, 2015
> IETF LC End Date: December 14, 2015
> IESG Telechat date: TBD
>
> Summary: This draft is basically ready for publication, but has nits that
> should be fixed before publication. [Ready with nits]
>
> The draft provides a lightweight means to increase the difficulty of certain
> DNS attacks by off-path attackers, but it isn't designed to be the be all
> and end all of DNS security.  It can be deployed incrementally.
>
> Major issues: None
>
> 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.

> Nits:
>
> Page 12, Section 5.2, 3rd paragraph, 1st sentence: change "the the" to just
> "the".

OK.

> 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.

> Page 14, Section 5.2.4, 1st paragraph, 2nd sentence: delete the sentence.
> It's redundant with the 1st sentence.

OK.

> Page 15, Section 5.4, 2nd paragraph, 1st sentence: change first "a" to "an".

OK.

> Page 15, Section 5.4, 4th paragraph, 1st sentence: change first "a" to "an".

OK.

> Page 17, Section 6, 1st paragraph, 2nd sentence: change "indefinitely" to
> "indefinite".

OK.

> Page 21, Section 9, 2nd paragraph, 2nd sentence: change "WPAv2" to "WPA2"
> (the Wi-Fi Alliance's term).

OK.

> Page 23, Section 10: change "a" to "an".

OK.

> Page 27, Section A.1, 1st sentence: change "An" to "A".

OK.

> Page 29, 1st partial sentence: if you're going to drop beta earlier in the
> section, you might as well give the BIND version number here as well.  It's
> no longer apparent that a beta version was involved.

OK.

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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art