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

[Jeremy Allison]

On Mon, Mar 26, 2007 at 03:26:22PM -0500, Steve French wrote:
> 
> I like your idea of having a SetFSInfo for this capability, but don't 
> like the idea of having it be the only "global" (rather than
> per-tid) property.   The good news about the SMB header is that the tid 
> is one of the first fields - so we can encrypt
> starting with the next byte and get pid/uid/mid/wordcount etc. encrypted 
> - which is good enough - and better than NFS in
> some ways. 

No, I completely disagree with that. If we do this
we've exposed the SMB command, and flags, error codes
etc.

> 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
and do the whole damn thing :-).

Jeremy.