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

Re: compression, privacy, and authenticity transforms

Hi, Paul,

I think we can actually agree here.  As you point out, there are (at least) 
three goals for supporting compression + privacy + authenticity:

 1 -  limit the number of "Security Transforms"
 2 -  ensure that combinations of security services are provided correctly
 3 -  limit the overhead required to provide a set of security services. 
 
Let me expand on 3:

   3a - limit the added computational complexity 
   3b - limit the added communication complexity (= total # of bits)

My earlier note claimed that (3a) is NOT better achieved by supporting "composite" 
transforms.  (As a timely example, the suggestion just posted by Russ Housley is 
not correct.)  But you are right to suggest that I didn't think much about (3b).  
Thus I wrongly concluded that it is just as well to wrap your packets with independent 
carriers for privacy, authenticity, and compression.   You observe, correctly, that 
this would result in extra bytes of header -- overhead which we can avoid by having 
a single carrier with implicit instructions about what transforms to apply in what 
order.  I find your approach perfectly acceptable (in fact, better than mine).  
Of course I'd say that one must implement this suggestion in a way that provides 
orthogonality in the transforms the user wishes to select (but it sounds like 
that was exactly your intent).

I would like to make a minor suggestion on nomenclature: that we reserve the word 
"transform" to apply only to the "lower-level" meaning -- a function for
privacy or authenticity or compression divorced of details of packet formats, etc.
A Protected Packet Header (or whatever phrase you like) would specify what 
sequence of transforms to apply to its payload.  Let's use a word different 
from "transform", like "encapsulation mapping", for the function you get by 
applying, in order, the specified sequence of transforms.

Under the above approach I see no reason why we would maintain two distinct 
concepts (or documents) for ESP and AH: the encapsulation mapping would 
be computed in one packet type.

A final comment:  near the end of your note you say that there are
times that an encryption computation after an integrity/authenticity computation 
might be desirable.  Though I haven't seen such example, I have no reason to 
believe that one can't exist.   So I too favor an approach in which the 
underlying transforms can be applied in an arbitrary order.  The "customary" 
order should be made clear, and there should be a comment on possible 
problems which could result from deviating from this customary order.


Regards,
Phil