Nico Williams <n...@cryptonector.com> writes:
>SSHv2 has a this approach and it has not been a disaster there.
It's still quite a mess. To compare the two, my TLS suite-choosing code is
more or less:
highestSuite = 0;
foreach suite
suite = readInteger();
if priority( suite ) > priority( highestSuite )
highestSuite = suite;
For SSH I have an entire code module to handle the complexity. For those who
aren't familiar with how the TLS vs. SSH handshake works, for TLS you have a
series of fixed-length integers denoting suites, the client offers a
selection, the server chooses the one they like best, and that's it. For SSH,
both sides can start talking at the same time (!!) and then there's a complex
disambiguation protocol for sorting out what happens next. Also all
algorithms are lists of variable-length comma-delimited text strings, you can
have different algorithms in different directions (!!), and all sorts of other
horrors. If it wasn't for that fact that many (most? all?) implementations
act in very stereotyped ways (e.g. there are no known implementations that try
and negotiate algorithm X in one direction and algorithm Y in the other,
heaven knows what would happen if someone did try that one), you'd get no end
of interop problems.
I actually wrote an RFC draft that tries to nail down canonical behaviour that
third-party implementations expect, but never published it. In general SSH
relies on the fact that as an implementer all you need to do is talk to
OpenSSH (server) or Putty (client) (both of which are incredibly tolerant
implementations) and you're OK. If you try and get two third-party
implementations to talk to each other, and one or both don't exactly follow
the stereotyped exchange, you start running into problems. Conversely, the
complexity of the handshake negotiation means you can crash the do-everything
implementations without too much trouble (well, at least for Putty you can
[0], I haven't tried it with OpenSSH).
Oh, and I've inadvertently done it with some of the third-party
implementations. At one point I had a pre-auth vulnerability that would take
down a certain brand of Internet backbone router, it took me quite awhile to
figure out a message flow that wouldn't trigger the problem. Hmm, and also
advertently done it, SSH carries out a lot of its auth negotiations with
multiple round-trips of negotiations (rather than just "here's my name, here's
my password"), and you can vary the bits and pieces you send on each
iteration, so you can get interesting effects by changing things that aren't
supposed to change from one round of negotiation to the next, like the
username from <whatever> to "root", or "root" with an empty authenticator (for
which the server comes back to you with a request for more info) to which you
then send a standard user name + authenticator, triggering a TOCTOU condition
in the sever's checking.
(If anyone wants to do a conference paper on messing with SSH servers, I have
a list of stuff to try :-).
>What's the issue exactly? ECC curve parameters? Something else?
Quoting the draft:
[TLS-ECC] provides an extremely flexible, and by extension extremely
complex means of specifying a large number of options involving the
use of ECC algorithms for [TLS]. As such the "cipher suites" in
[TLS-ECC] aren't suites in the conventional TLS sense but more an
indication of intent to negotiate a Chinese menu, with details to be
decided on later via various TLS extensions and parameter settings.
This makes deciding on a particular suite nondeterministic, since
later parameter choices and settings can negate the initial "cipher
suite" choice, requiring returning to the suite list to try with
another Chinese-menu suite in the hope that later parameter choices
allow it to be used.
In practice no currently deployed implementation actually does this,
either dropping the connection or aborting the handshake with a
handshake-failure if the expected parameters aren't present
throughout the various locations in the TLS handshake in which ECC
parameters can be specified. This means that establishing a TLS
connection using ECC often requires trial-and-error probing to
ascertain what the other side is expecting to see before a connection
can be established.
Experience with deployed implementations indicates that all of them
appear to implement a common subset of fixed ECC parameters that work
in all cases (alongside the more obscure options), representing a de
facto profile of standard cipher suites rather than Chinese-menu
selection options. For example one widely-used implementation didn't
send out TLS ECC extensions and yet other implementations had no
problems interoperating with it, indicating that what this document
specifies is already a de facto profile of implementations. This
document standardises this de facto usage by defining a small number
of standard ECC cipher suites with unambiguous parameters and
settings.
Peter.
[0] Not meant as a criticism of Putty, it bends over backwards to be
compatible with everything and implement every nuance of the SSH spec,
which makes it vulnerable to valid but unexpected messages, valid
but odd items in PDUs, and so on.
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
