On 13-Feb-06, at 11:15 AM, Eric Rescorla wrote:
Dick Hardt <[EMAIL PROTECTED]> writes:
On 13-Feb-06, at 10:51 AM, Eric Rescorla wrote:
What do you mean "binary crypto code"? You've got a hash algorithm,
no? At worst, you could share a pairwise secret between the MS and
the HS during the initial discovery phase and use that to key
a MAC. (This is of course only safe if you're doing that exchange
over SSL/TLS, but that's true of your scheme too...)
Anyway, I don't really find this that convincing. Java certainly
comes with built-in public key functionality and there are modules
for Python, Perl and PHP (it's actually a compilation flag for PHP).
Yes, it's not zero effort, but it's not exactly prohibitive either.
Yes, hash algorithms are widely available on the platforms. (but even
SHA-1 is not everywhere)
Well, since your scheme requires SHA-1 implementations
(see S 5.10.2.2), I don't see how non-universality of
SHA-1 can be an objection. And as I indicated, it's
possible to attack this problem using only SHA-1 (though
the solution is inferior to when PK is used).
Sorry I was not clear, my point was that even SHA-1, which we
require, is not universally available.
Public Key algorithms are not widely available on the dynamic
language platforms.
Easy for Perl, Python, PHP and Ruby developers in addition to Java
and .Net developers was a core goal of DIX.
I don't think you've addressed my point here. There are PK
modules for all the major dynamic platforms for the price of
a recompile. I don't see how this is prohibitive.
Having been a tool vendor for those languages, it is not as simple as
that. Our experience with SXIP 1.0 was that it was prohibitive for
many, even when we supplied the binary.
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
