Re: LL11 Security consideration for the threat where an attacker forces address reconfiguration

    Date:        Tue, 1 Jul 2003 11:57:34 -0700
    From:        Stuart Cheshire <[email protected]>
    Message-ID:  <[email protected]>

  | 3. What is the typical implementer to conclude from this?

That there is an issue that needs careful consideration, and for which
there is not one right answer that will necessarily suit everybody.

  | If Robert thinks this, then how many inexperienced implementers will 
  | think the same thing?

It has nothing whatever to do with being an experienced implementor.
Rather, it is probably more likely (from what I have observed) that
your average inexperienced implementor will simply follow the text of
the doc, and ignore side issues that require thought and making choices.

  | I do not want a document with this ambiguity in it.

I do.   Even more than is there now preferably.   I seem to recall saying
way from the early days that that particular MUST is bogus.   But it is not
"ambiguity" (or should not be), it is a choice.   There is nothing wrong
with allowing choices where there is no one answer that is always correct.

  | If there's a hidden agenda that some people do want 
  | implementers to make products that cling to their address no matter what, 
  | then we need to get that out in the open and discuss it properly.

There is nothing hidden about it - there's no question but that for
some environments (not all, certainly) keeping addresses rather than
silently releasing them is the right choice.

  | That's all I'm asking for: Make the document say 
  | exactly what it means in plain and clear language.

I have no problem with that.

  | I'm not asking for any change of direction for the document. If the true 
  | intent of the document is as I believe it is (and as you say, "A MUST is 
  | a MUST,") then all I am asking is that we explicitly close the loophole 
  | that will otherwise be used to justify "cling to your address" behaviour.

Which is another way of saying that you'd really just prefer to hide the
security issue, not mention it at all - keep the MUST release the old address
and generate a new one, and ignore the issues that raises.   That's not
good enough.

kre