[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: user-to-user vs. host-to-host keying




Dan Nessett says:
> I believe misses the point of the original message. The concrete
> justification for user-to-user keying is that one user might be able
> to cryptoanalyze the traffic encrypted by a common host-to-host key,
> thereby obtaining the plaintext from another user's
> communication. If reasonable session key managment techniques are
> used, this is not a viable threat. Consequently, the justification
> for mandatory support of user-to-user keying evaporates.

Dan;

No they don't. There are large numbers of reasons for wanting per
socket keying. The IETF works on consensus, and you can be damn well
sure I'm not going to be part of a consensus -- ever -- for a system
that doesn't permit per-socket keying. I'm obdurate on this point.

Ultimately, Dan, what you are trying to do is push SKIP. I would
suggest that rather than attack the concept of per-user keying you be
honest and say "I don't think SKIP can support per-user keying and
since I'm a SKIP proponent I have to find ways to justify why we can
live without having it". It would be far more honest. Your recent
trend of posting abstract broadsides that make no mention of SKIP and
your underlying motivations feels rather, well, distasteful. I feel
people should be honest and say what their biases are out front.

At the moment, my bias is towards something that looks far more like
Photuris. I see SKIP as a cute bunch of cryptographic hacks done by
clever cryptographers. It doesn't strike me as having any real
advantages, however, and it does strike me as having many
disadvantages.

1) It is tied intimately to a single cryptographic trick. If anyone
   ever finds a way around that trick, SKIP is dead. Other protocols,
   like Photuris, are ultimately tied more to the idea of exchanging
   keys than particular key exchange protocols. This might not be
   obvious to people with more cryptography experience than
   engineering experience because they will see both proposals as
   being tied intimately to things like the discrete log
   problem. However, this isn't really the case -- Photuris like
   protocols can be altered. SKIP is a one trick horse.
2) It ultimately has no performance benefits no matter what Ashar and
   Dan vigorously assert.
3) It claims to be "sessionless" but this is in the end meaningless
   semantic play -- it keeps at least as much state around as any
   other proposal.
4) It doesn't support per user keying.
5) It can't really support perfect forward secrecy.
6) The proposal uses X.509 certificates, which in and of themselves
   are a problem, but they aren't even conventional X.509 certificates
   and depends on a non-existent key management
   infrastructure. Photuris and company can use Eastlake-Kaufman style
   key infrastructure without much trouble.
7) It doesn't match up well with the layered security architecture
   that we were following from the start.

There are more -- Steve Bellovin has noted a large number of problems
-- but these are things that just come to mind off the top of my
head. Doubtless Danny will be posting complete (in his opinion)
refutations of all my points -- without mentioning SKIP by name, for
whatever reason. Doubtless Ashar will disagree vigorously with me as
well. However, at this point, my mind is very solidly trending away
from SKIP unless very strong evidence in another direction shows
up. 

To me, the worst part of SKIP is that it really does feel like Yet
Another Very Clever Cryptographic Hack, of the sort that fill the
Crypto and Eurocrypt proceedings. These clever hacks certainly get
papers published, and I can see why professional mathematical
cryptographers have a fondness for them for that reason, but they
rarely have pragmatic engineering potential, and I'm not sure that we
should be elevating a hack to the status of a standard.

Overall, I'm not sure that SKIP is going to have much success in
winning my support unless I see substantially more evidence in favor
of it than I have seen thus far.

Perry


References: