Re: automatic cipher ("none") selection?

From: Richard E. Silverman (slade@shore.net)
Date: 03/17/03 

From: slade@shore.net (Richard E. Silverman)
Date: 17 Mar 2003 13:28:12 -0500

>>>>> "KL" == Kyler Laird <Kyler@news.Lairds.org> writes:

    KL> Has anyone considered adding IPsec detection to SSH so that it
    KL> could be configured to automatically use a null cipher for already
    KL> encrypted paths?

    KL> I stream a lot of video over SSH and I'm realizing that once I
    KL> have IPsec, there's no reason for me to expend the processor time
    KL> (which is at a premium because it's also encoding video) to
    KL> encrypt the SSH session. This situation is going to be
    KL> increasingly common.

    KL> Sure, I can manually set the cipher or even use other protocols,
    KL> but in general I like using SSH and I want to encourage others to
    KL> use it all of the time without having to think about whether a
    KL> path is already secured.

This would be a very bad idea. It is an abstraction violation: protocols
in one layer should not be trying to second-guess what those in other
layers are doing. One of the useful properties of IPSec is that it
operates beneath UDP/TCP, and thus can secure them transparently. Someone
making IPSec policy decisions should not have to worry that the security
characteristics of the traffic in question will change merely by the act
of his trying to secure them.

What would you have the program try to "detect?" IPSec might by applied
end-to-end, or in tunneling (gateway) mode. Will you try to find out the
SA in use by your packets and divine the relationship of the protection to
your SSH server endpoint? And you can't even know if that really *is* the
endpoint: all you can see are TCP sockets. Your server socket might be a
proxy delivering over a further insecure channel to the actual server.

And even if you somehow did all this correctly (which you cannot do, in
principle)... IPSec is not connection-oriented. The SA's may change at
any time, your traffic may cease to be protected at any point after TCP
connection establishment, and your program would not be notified.

Further, the protections afforded by SSH and IPSec do not have the same
extent. IPSec protects traffic only host-to-host, while SSH protects
program-to-program. With SSH, data is not decrypted until it enters the
processing environment (address space, process context, etc.) of the SSH
peer; the distinction may be relevant or critical is some environments.

Now, one thing that might make sense, would be to make an SSH client which
is IPSec-aware, in the sense that it could use its local TCP API to
require appropriate IPSec protections for its traffic, and choose to
forego SSH-level confidentiality in favor of using IPSec for that purpose.
It would still be subject to some of the distinctions and limitations I
mentioned, but the user could choose whether to employ this option based
on the situation. Note that this is an optional feature, rather than
"detection," which is a very different thing. 

-- 
  Richard Silverman
  slade@shore.net

Relevant Pages