RE: Draft of workshop notes
Nicolls, J. Weston (jwnicol@missi.ncsc.mil)
Tue, 12 Mar 96 13:25:00 PST
Ralph,
I take issue with your take on "algorithm specified". Though the MSP spec
that is available now includes info on how the Fortezza algs are to be used
with MSP, they are not specified/required for the use of MSP. MSP can
standalone from the algs (this will be clearer once SDN.701 rev 4 gets put
into a draft RFC). If an implementer includes MSP in a UA with RSA and IDEA
as the only algs, they can do so without also implementing the Fortezza algs
(implementation would get a plus). Secure PKCS specifies the implementation
of a specific 'weak' 40 bit algorithm. Secure PKCS is viewed as unsecure per
you criterion (gets a minus). PGP gets a plus. MSP gets a blank because it
does not specify that you must implement a particular algorithm. The
cryptographic strength of MSP is undefined by the protocol. It depends.
Based on the above, then the exportability of MSP depends on the
implementation also (gets a blank).
Also, grading of algs depends on who the customer trusts for the evaluation.
Weston Nicolls
>>From: Raph Levien <raph@cs.berkeley.edu>
>>--------------------------------------------------------------------------
----
>>Housley, Russ wrote:
>>>
>>> Here is Raph's matrix and foot notes:
>>>
>>> PGP MOSS PGP/MIME S/MIME MSP
>>> Interoperable + ?(1) + +
>>> Int=>Secure + + -(2)
>>> Exportable + +
>>>
>>> (1) This is the question raised in
>>> http://www.imc.org/workshop/mail-archive/0112.html, which still
>>> hasn't been answered.
>>>
>>> (2) I believe the assignment of a "-" here is generous, given that
>>> the Fortezza cyphe has 80-bit keys (as opposed to the minimum 90
>>> recommended in the BSA report), is key escrowed, and is not
publicly
>>> available. Russ Housley of Spyrus seems to disagree with these
>>> assignments, but has not yet given me a convincing argument why
they
>>> need to be changed.
>>>
>>> Raph, you are correct. I disagree. Please do not confuse MSP and
>>> FORTEZZA. FORTEZZA provides one cryptographic suite for use with MSP or
>>> other security solutions. For example, TIS and SPYRUS have written an
>>> Internet-Draft that describes how FORTEZZA can be used with PEM and
MOSS.
>>> Further, MSP can be used with other cryptographic algorithm suites. Two
>>> companies are developing MSP implementations which use RSA signature,
RSA
>>> key transport, and DES. It could easily use Triple DES, but the
customer
>>> in this case does not need anything stronger than DES.
>>>
>>> I still think that algorithm independence is a paramount criteria. New
>>> algorithms will be developed, and old algorithms will be made useless by
>>> technology improvements, either the key size will be too small or
attacks
>>> will be discovered. Plan for algorithm replacement now!
>>
>>Mr. Housley,
>>
>> I agree that algorithm replacement is a worthy goal, but it is a
>>separate criterion from the ones I've proposed.
>>
>> I do not think you understand my "Interoperable implies Secure"
>>criterion. It refers to the security of the weakest algorithm specified
>>for use with the protocol. Although it is pretty clear that you and I
>>disagree on whether it's a useful criterion, I still do not see why
>>there should be any grounds for disagreement on which +'s and -'s to
>>fill in. If the minimum algorithm is secure, it gets a +. If not, then
>>not. PGP's minimum algorithm is RSA and IDEA, which at 128 bits, no key
>>escrow, and publicly available documentation, clearly rates a +. MSP's
>>minimum algorithm (that I know of) is Fortezza, which rates a - at best,
>>for reasons I've explained above.
>>
>> Note that algorithm replacement is not necessarily incompatible with
>>a + entry for "Int=>Secure". For example, a future version of PGP may
>>include both 168 bit triple-DES and IDEA, which would rate a + for both
>>matrix rows.
>>
>>Raph
>>