[linux-cifs-client] 2 New encryption capability bits in, UNIX extensions.

[Steve French (smfltc)]

>>If we use a flag in spnego negotiation itself to negotiate 
>>encryption someday down the road - why don't
>>we first simply do the easier SetFSInfo based encryption of the portion 
>>of the SMB that follows tid.   I doubt that
>>exposing smb flags/flags2 is very harmful, and although having SMB 
>>command and error in the clear is not ideal from
>>one perspective.  If the header (up to mid) were in the clear it would 
>>be a huge performance win - with the advantage
>>of allowing the client to discard some easy response frames that don't 
>>have to be returned back for parsing (there are
>>lots of "empty" responses - for which all we need to know is that the rc 
>>was zero and that the frame was signed properly).
>>    
>>
>
>Transport encryption means complete transport :-). It does
>in NFS and we can't do otherwise.
>
>Nothing significant after length must be in the clear.
>It's not (IMHO) an advantage to have a 1/2 encrypted
>1/2 cleartest protocol. Just flip the global switch
>  
>
Considering that we can do transport encryption over IPSec over a 
particular
socket already, this does not seem to add much - and it will have the 
same performance
problem that ipsec does (although I admit that it should be orders of
magnitude easier to configure) - the client will have to decrypt the whole
frame for all frames.

If we do what you suggest and encrypt the whole thing after RFC1001 length
why not set it at sessionsetup (especially if we already have the flag 
defined)
seems counterintuitive to use a tid based operation for something 
affecting all tids - even
over IPC$.  If we have to do it after sessionsetup - wouldn't it be 
simpler to
define something that does not require a tid? 

There is one obvious problem with this though ... for the Linux/Unix case it
will be common to have multiple uids over one socket ... this prevents that.
We will have to go to one socket per user per server when somone turns 
this on for a session.
If we allow multiple uids over one socket - one user who turns on 
encryption to a server
can slow all other users down by more than 90% (and those users might 
not want to
pay the > 90% performance penalty)