At Sat, 8 Aug 2015 10:19:34 -0400,
Donald Eastlake <d3e...@gmail.com> wrote:
> > - Section 4.1
> >
> > In order to maintain the security properties of this protocol, a
> > client MUST NOT use the same Client Cookie value for requests to all
> > servers.
> >
> > Specifically what does this mean? Does this mean, for example, the
> > client generates a different cookie value for a different server
> > (identified by its IP address) and maintain the cookie values per
> > server basis?
[...]
> Actually, the wording in the draft doesn't seem that good. Perhaps it
> should be more like
>
> "In order to provide minimal authentication, a client MUST send
> client COOKIEs that will usually be different for any two servers at
> different IP addresses."
It basically looks good to me. One possible concern is that the term
"usually" is vague/ambiguous especially when used in the context of a
MUST. So, if I were an author I'd add a sentence like this at the
risk of sounding too verbose: "Specifically how to make them usually
different is implementation dependent, but it should be generally good
enough to use a good hash function with the server address being a
part of its seed."
> > - Section 4.2
> >
> > In order to maintain the security properties of this protocol, a
> > server MUST NOT use the same Server Cookie value for responses to all
> > clients.
> >
> > I'm also not sure how I should interpret this. Can't we basically
> > assume this condition is met because the server cookie contains (in
> > some way) the request source address and client cookie? Of course,
> > a naive implementation of how to "contain" them could lead to the
> > same server cookie value regardless of the difference of these
> > values, but if this sentence tries to avoid such naiveness, I'd make
> > the point clearer.
>
> Can you suggest replacement text? You seem to understand what is being
> said. As above, it could be reworded as
>
> "In order to provide minimal authentication, a server MUST send
> server COOKIEs that will usually be different for clients at any two
> different IP addresses or with different client COOKIEs."
Same comment as the previous point applies.
>
> > - Section 5.2.3
> >
> > Servers MUST, at least occasionally,
> > respond to such requests to inform the client of the correct Server
> > Cookie.
> >
> > By saying "occasionally", it could read (to me) as if it intends to
> > mean maintaining per-client state. While a server implementation
>
> I don't know why you would think that.
See below.
> > could actually do that, I guess that's something that this draft
> > wants to avoid to see. If so, perhaps something like "randomly"
> > instead of "occasionally" may be a better choice.
>
> I don't think there is much difference between "randomly" and
> "occasionally" but randomly implies some attempt at an actual
> pseudo-random mechanism. "Occasionally" can be satisfied by a
> pseudo-random mechanism but also by some simple rule like responding
> to every tenth request or every Nth request for some reasonable N.
Right, so "randomly" is just one way to implement "occasionally" and
was too restrictive. And it's related to the other point: one other
way to make it "occasional" is to keep a per-client counter and
respond to every Nth request for that client or something. I wouldn't
be surprised if some implementor develops this specification that way
to meet this MUST, and I thought we wanted to avoid that to happen.
So we might emphasize that in an additional sentence, e.g., "However,
servers MUST NOT maintain per-client state to implement that in order
to prevent resource consumption attacks on that state".
> > - Section 5.5
> >
> > Clients and servers MUST NOT continue to use the same secret in new
> > requests and responses for more than 36 days and SHOULD NOT continue
> > to do so for more than 26 hours. Many clients rolling over their
> >
> > It would be helpful if the rationale (if any) of these constant
> > values (36 days and 26 hours) is explained.
>
> The rational is cryptographic hygiene. The longer you use any secret,
> the higher the probability it has been compromised. The specific
> values are to be sure in one case that the secret will not be used for
> much more than a month and in the other case for not much more than a
> day. The numbers may seem a bit odd but are designed to allow for
> weekends and holidays and time changes for daylight savings time and
> the like. While I don't think these times should be any longer I'm not
> sure the precise value is that important.
I didn't mean the rationale about the very specific number like 36 or
26. It was more about the sense of scale of these constants, e.g.,
"not more than a month". But I'd leave it to you whether or how to
update the text to address this point.
> > - Section 5.5
> >
> > When a server or client starts receiving an increased level of
> > requests with bad server cookies or replies with bad client cookies,
> > it would be reasonable for it to believe it is likely under attack
> > and it should consider a more frequent rollover of its secret.
> >
> > It's not very clear to me how a more frequent rollover helps in this
> > case. In such a case the attacker basically keeps trying random
> > cookies (right?), so whether or not we do rollover more frequently
> > the attacker's odds wouldn't be different. Or, does this intend to
> > minimize the risk in case an attacker actually identifies the valid
> > cookie by the random try (by reducing the attackable window)?
>
> The more you re being attacked the higher the probability that one or
> more such attacks will succeed. More rapid rollover decreases the
> benefit to the attacker when an attacker succeeds.
Okay, so I interpret it as the answer to my question in the last
sentence is "yes". I'd also leave it to you, but I'd personally
clarify that a bit more explicitly, e.g.:
When a server or client starts receiving an increased level of
requests with bad server cookies or replies with bad client cookies,
it would be reasonable for it to believe it is likely under attack
and it should consider a more frequent rollover of its secret. This
will help minimize the duration when the attack is successful even
if the attacker happens to identify one valid cookie.
--
JINMEI, Tatuya
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
