At 10:48 PM -0400 3/20/12, Eric Osterweil wrote:
On Mar 20, 2012, at 4:50 PM, Stephen Kent wrote:
...
For one: pedantic compilers are often helpful when it comes to
static analysis. By extension, _sometimes_ one can make the same
argument (about static analysis) to justify being pedantic for
technical discussions... I'm kinda surprised that you didn't know
that... ;)
I am not familiar with the term in the compiler context, only in the
context of people, i.e., are being referred to as teachers, i.e., to
be a pedagogue.
...
Indeed, I was attempting to paraphrase. To clarify, this was how I
interpreted your words, but our audit trail should clearly indicate
that you did _not_ say these things and that I was merely
paraphrasing the message I interpreted from you. Please accept my
apologies for any misunderstanding about this.
OK.
> Let me try another, more concise phrasing. When one adds secruity
to a protocol, the goal is to enable it to operate in a hostile
environment with the same semantics that it offered in a
non-hostile environment. Of course a secure version of a protocol
will exhibit some differences in its operation from an insecure
version, especially when one compares the two version in attacks
scenarios.
Exactly! This is exactly what a semantic difference is! :)
I think I see how we disagree. Historically (here comes those
annoying 30+ years of experience again) designers of most protocols
have not considered how assumed a benign (or at least
non-adversarial) environment for protocol operation. In the today's
world that is not a good assumption. So, when we add security
mechanisms to a protocol to try to allow it to operate successfully
in a hostile environment, one ought to expect the behavior to differ
in attacks scenarios. I assert that this does not change the
semantics, because protocol behavior outside of the benign
environment was out of scope for the non-secure protocol design.
If that were not the case, we would not bother adding security to
a protocol.
Very debatable. I wouldn't necessarily impugn the addition of
security semantics to a protocol (sometimes additional
expressiveness is needed).
impugn? I am not assailing the addition of secruity semantics. I am
asserting that the semantics associated with the additional of
security mechanisms does not constitute a violation of the semantics
associated with the original, non-secure version of a protocol.
The relevant question is whether the fundamental nature of the
protocol is altered by the addition of security.
That may be a question you care about... It might even be one that
the rest of us care about, but that is different than claiming you
have not added semantics (which is where this started). This
comment is changing the subject.
OK, where we started, to be brutally honest, was an attempt by you
and Brian to find a way for Brian's proposal on route leaks to be
considered in scope for SIDR. The SIDR charter is clear about the
scope, and route leaks are not part of what we are currently
chartered to do. So we really ought not be having this discussion.
I'll do my part to help, by not replying to further messages on this
topic.
> And, yes, maybe it is just you.
Or maybe a line of thought (``thinking'' as you put it) that has
gone unchanged in over 30 years is overdue for having its
assumptions challenged. Security (in particular) is a field in
which the landscape changes, and stale vision can lead to myopia...
Many things in the Internet security theater have obviously changed
in 30 years, so the age of lessons does not necessarily correlate
with their relevance. :)
Your comment suggests that no wisdom has accrued, at least to me,
with 30 years of experience. I beg to differ. When someone proposes
an approach that has been proposed and rejected previously, I usually
ask myself "why did we reject this before, and what has changed that
might make the decision be different this time?" Usually the answer
is that the reasons for rejecting an approach are still valid, but
the proposer of the "new" approach was unaware of the history. On
some occasions the answer is yes, we ought to revisit the decision
(which may of may not still be correct). I am fortunate to have had
firsthand experiences over the last 3 decades that allow me to have
this perspective.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
