Re: [psg.com #460] IESG - Transport - Oakley

[nisse%lysator.liu.se@localhost (Niels Möller)]

Jeffrey Hutzelman <jhutz%cmu.edu@localhost> writes:

> > I don't think this is needed at all. To me, the rules are the same as
> > for all the other algorithm lists: Each client lists the algorithms it
> > is willing to use, in the client's preferred order.
> 
> I'm not sure if you're commenting here on the proposed ARCH/9.2.8
> text, or on the TRANS/7.1 text which Chris actually quoted at this
> point.

Sorry if I was unclear. I didn't want to comment the old text in
section 7.1 of the transport draft, which is about how to select the
algorithm to use from the given lists. That's a little too hairy for
my taste, but if it works (I don't know, I haven't really tested the
"algorithm guessing" part), then we should *not* touch it now.

I wanted to comment the new text, which says in which order a client
should or must list its algorithms. I.e. the text which restricts the
set of allowed input to the algorithm selection procedure.

> The security considerations section is a perfectly reasonable place
> for advice on algorithm selection, to the extent that we want to give
> such advice.

This is partly a question of taste. The way I see the architectures
document, it should describe the overall structure of the protocol and
the components, which roles the various parts play, what security
properties the parts are expected to have, data types and background
needed in many places, etc.

I'd find it easier to accept a general recommendation that if there
are no other particular reason to prefer a certain algorithm over the
other, clients should list algorithms ordered by strength, strongest
first. Such a recommendation applies equally to all of the key exchange,
host key, encryption and mac algorithm lists.

Comments on particular algorithms seem out of place. If we really need
that, the security considerations section of the transport draft seems
like more natural place to me.

> On further reflection, I think it gets even more fun...
> For some symmetric ciphers, group1 will be good enough.
> For others, it will not.

> What this means is that we should avoid selecting a cipher for which
> the kex does not provide enough keying material.

I don't buy this reasoning at all. The security requirements are
determined by the context in which the connection is made, not by the
key size of negotiated ciphers.

Say you have estimated that you need "100-bit security" (I'm not going
to try to define this rigorously, I hope you understand what I mean).
Then you can use a 110-bit key exchange method, and a 256-bit cipher
and a 256-bit mac. That's fine. The important thing is that *both* are
strong enough.

Or you can also use a 200-bit key exchange, a 128-bit cipher and a
160-bit mac. That's fine too.

It *doesn't matter* if the weakest link happens to be the key exchange
or the cipher, as long as it's strong enough. And it makes no sense to
strive towards a system where all links are of equal strength; if some
link happens to be much stronger than necessary, what's the problem
with that?

And I agree with Bill that if we want to replace preferences of the
form "I want group14 and aes256" (like in the implementations I'm
aware of) with preferences of the form "I want at least 100-bit
security", then that's excellent. It can be implemented in servers and
clients, and in all cases it affects *which* algorithms are listed,
not their order. As long as only algorithms that have adequate
security are listed, order doesn't matter.

> As it stands now, we could end up negotiating
> diffie-hellman-group1-sha1 and, say, aes256-cbc, which woule not be
> very good.

In this case, depending on the circumstances, either group1 is harder
to crack than your enemies can afford, or it isn't. If group1 is
strong enough, then (diffie-hellman-group1-sha1 + aes256-cbc) is
adequate, and so is (diffie-hellman-group1-sha1 + 3des-cbc). And I'd
choose aes256-cbc, since the overall security will be the same, and
aes256 likely is significantly faster.

And if your enemies do have a discrete log table for group1, or you
suspect that they might have, *don't* list that group, in any order,
ever.

Regards,
/Niels