Watson,
On Tue, Aug 25, 2015 at 7:06 AM, Stephen Kent <[email protected]> wrote:
Watson,
On 8/24/15 4:37 PM, Watson Ladd wrote:
On Mon, Aug 24, 2015 at 1:08 PM, Stephen Kent <[email protected]> wrote:
Watson,
based on many years of experience dealin wit this sort of issue
I suggest that the relative merits (strength, etc.) of cipher suites
form a lattice, not a total order.
Every lattice has a compatible total order
more properly, a total order can be imposed on a lattice.
I don't see the difference between these two statements, and I don't
see the relevance.
pity, I tried.
....
Earlier people raised examples of ciphersuites with no comparison
between them. Why does what you are saying matter more? What's the
connection between being a lattice, and picking just one ranking not a
good idea.
they're equivalent, but since you seem to bring an academic perspective
to the discussion I thought you might like a more math-oriented response
;-).
into the reality of comparing ciphersuites justifies exposing all
possible ciphersuites, and permitting specifying arbitrary preferences
among them?
The preferences of others are "arbitrary" but yours are not?
Of course it's an arbitrary choice! My question is why is it not a
good idea to pick a single nothing-else-is better suite. and have a
mechanism designed to support migration if weaknesses are discovered?
So far as I can tell the argument has been that people have different
orderings, and should be allowed to express them. But this doesn't
actually get to the fundamental issue: how much more secure are people
if they will use X instead of Y if the other side wants it, then if
they prefer Y instead of X?
protocol design is a complex process where there often is not a
single "right" answer. preserving the ability of different sets
of folks to do what they perceive as the "right thing" has often
been a critical element of successful standards. Yes, this can lead
to bad outcomes, but trying to dictate one answer is also likely to
lead to a bad outcome, i.e., nobody adopts the standard.
Steve
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
