Re: SSH in ECC Internet Draft

[Sam Hartman <hartmans-ietf%mit.edu@localhost>]

>>>>> "Niels" == Niels Möller <nisse%lysator.liu.se@localhost> writes:

    Niels> Sam Hartman <hartmans-ietf%mit.edu@localhost> writes:
    >> I think you should look at how this will likely work in common
    >> implementations.  If your ECC library is likely to want to take
    >> ASN.1 parameters as input, then that's probably how you want to
    >> transport them.

    Niels> I don't buy that argument. By the same argument, the only
    Niels> reason not to replace the "ssh-rsa" keys by the asn.1 based
Niels> pkcs#x stuff formats is backwards compatibility.

Well, let's put it this way, I think using ASN.1 in that instance
would have been an entirely reasonable design tradeoff.



    Niels> The way I see it, when you specify asn.1 as the wireformat
    Niels> for anything, that forces every implementation (or the
    Niels> libraries it depends upon) to take asn.1 to its core.

So, my advice to the authors of the ECC draft is to listen to the
comments here about ASN.1, to the extent that you agree with them make
changes, but to have the debate about whether you are using too much
ASN.1 in the ietf-wide context not on this list.  I think that there
is a lot of anti-ASN.1 FUD here and you will get a much more balanced
viewpoint on the ietf list.  But if you are going to use ASN.1 at all,
USE IT CORRECTLY.  Arbitrary limits because you can't find out how to
write your constraints and lack of a module that compiles will be a
problem.



    Niels> I see the ssh RSA and DSA key formats as a good example on
    Niels> how to do things. It allows ssh implementatiions to use
    Niels> very simple and minimalistic libraries. Whenever
    Niels> compatibility with other formats is needed, that conversion
    Niels> can easily be done *off-line*, and without automatically
    Niels> making bugs in the conversion code into remote root
    Niels> exploits.

This is one valid approach.  If you are only going to have ssh, then
it is a clear savings in complexity and as you point out complexity is
tied to security.  However if I'm going to have a bunch of protocols
each of which does things lightly differently I eventually get to a
point where chasing down all the problems in all the implementations
of similar concepts actually provides worse security.  Like everything
else it is a balance between local complexity and global complexity.
Please do not confuse the tradeoff you have chosen with the right
answer: it is simply *a* right answer.