Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

[Watson Ladd <[e-mail]>]

On Tue, Aug 25, 2015 at 7:06 AM, Stephen Kent <[e-mail]> wrote:
> Watson,
>
> On 8/24/15 4:37 PM, Watson Ladd wrote:
>
> On Mon, Aug 24, 2015 at 1:08 PM, Stephen Kent <[e-mail]> 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.
>
> , and preferences are
> expressed as total orders.
>
> The issue here is that reasonable people can disagree about
> the total order imposed on the lattice.
>
> Could you explain how your supposed insight
>
> "supposed insight" seems rather pejorative; better watch out for the
> IETF mail list PC police

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.

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

What happens in practice is that we end up with copypasta in config
files. And then when we do need to have a migration, instead of the
next version of the software automatically prefering the new thing,
configurations need to be changed. Of course you can always wash your
hands of this by saying software could have expressed the preferences
differently. But if software is going to do that, then we might as
well chop down on what the mechanism needs to express. There are real
benefits from shrinking code and reducing the complexity of the
versioning mechanism.

Downthread David Menzies is saying we only need three ciphersuites,
with one explicitly as a backup for the other. So what's gained from
being able to reverse that ordering? I do think we can't actually
specify a backup until the primary is weak: remember when RC4 was the
solution for Bard's attack on TLS 1.0?

Sincerely,
Watson Ladd
>
> Steve
>
> _______________________________________________
> Tcpinc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpinc



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.