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

Re: compression, privacy, and authenticity transforms



Phil,


We seem to disagree, but have the same goals to:

 -  limit the number of "Security Transforms"
 -  ensure that combinations of security services are provided correctly

I also have one additional requirement that you seem to not worry about:

 -  limit the overhead required to provide a set of security services

>Encryption, authentication, and compression are mechanisms intended for three
>orthogonal purposes.   When (i) the individual mechanisms are correct, (i)
>key-separation
>has been properly performed (for encryption and authentication), and (iii) the
>mechanisms are applied in the correct order, these mechanisms can not
>"interfere" with one another.   So wouldn't it be better to treat all of 
>these types of transforms completely separately -- i.e., no "composite" 
>transforms?  If we start supporting
>transforms like DES-CBC-MD5-LZ77, we're going to get a real explosion in the
>number of transforms we'd feel it useful to provide.

I disagree!  

In general your approach of providing complete flexibility by creating "single 
service" security transformations is interesting, but if I need DES with 
authentication the system is burdened with the extra header overhead.  This is 
obviously worse when you have three sets of headers for confidentiality, 
integrity (aka authentication), and compression.  These service should be able 
to be combined in a manner that provides the services in a single 
transformation.  The definition of the transformation will include the order of 
processing, the transform specific field locations, and so forth.

Users need security and typically will not care how the theoretical pieces of 
the mechanisms are put together.  Efficiency is important.  Combining the 
processing and the construction of transform specific fields improves 
efficiency.


  We're also unlikely to
>"get right" these composite transforms.  Better is to regard "DES-CBC-MD5-LZ77"
>as three different transforms:  first an LZ77 Transform (used in the context of
><TBD>);then a DES-CBC Transform (used in the context of an ESP); then an MD5-
KXK
>Transform (for example) (used in the context of an AH).

Yes, we will get the transforms "right" by definition.  They will be 
constructed with the processing defined in a specific order to provide specific 
services.  An interesting example is the 

  The only 
>"integration" issue we would have to worry about is (key separation 
>and) a statement in the architecture document
>explaining that you should not use a compression transform after an encryption
>transform, and you should not use an encryption transform after an
>authentication
>transform.

There are times that encryption after an integrity (aka authentication) 
computation might be desirable.  To define such broad rules limits the 
functionality of the system.  It is better to precisely define a set of 
processing steps (transforms, fields, key usage, etc.) and document the 
expected services for the transformation.




Paul


PS - I might read mail again May 24