Re: [saag] AD review of draft-iab-crypto-alg-agility-06

[Russ Housley <[e-mail]>]

Viktor:

{ Dropping things where we have reached agreement. }

>>> I find section 2.5 too vague, not sure what point it is really
>>> trying to make.
>> 
>> I'm not sure how to handle this comment.  I guess the point that I am
>> trying to make is that there can be too many levels of indirection and
>> still preserve the integrity of the first part of the negotiation.
> 
>    2.5.  Cryptographic Key Management
> 
>       Traditionally, protocol designers have avoided more than one approach
>       to key management because it makes the security analysis of the
>       overall protocol more difficult.  When frameworks such as EAP and
>       GSSAPI are employed, the key management is very flexible, often
>       hiding many of the details from the application.  This results in
>       protocols that support multiple key management approaches.  In fact,
>       the key management approach itself may be negotiable, which creates a
>       design challenge to protect the negotiation of the key management
>       approach before it is used to produce cryptographic keys.
> 
>       Protocols can negotiate a key management approach, derive an initial
>       cryptographic key, and then authenticate the negotiation.  However,
>       if the authentication fails, the only recourse is to start the
>       negotiation over from the beginning.
> 
>       Some environments will restrict the key management approaches by
>       policy.  Such policies tend to improve interoperability within a
>       particular environment, but they cause problems for individuals that
>       need to work in multiple incompatible environments.
> 
> Reading section 2.5 again, and being well versed in both TLS and
> GSSAPI (I commit code to both OpenSSL and Heimdal), I still have
> no idea what it is saying.  In what sense is "key management" (which
> for me means how keys are deployed and rotated) "negotiated" in
> the protocol.
> 
> Is this talking about "Key Exchange" rather than "Key Management"?
> Is the problem you have in mind that when, for example, negotiating
> "GSSAPI" in SASL one might not know what that entails before deciding
> to use GSSAPI over some other SASL mechanism?
> 
> Whatever this section is trying to say, I'm just not smart enough
> to figure it out, even with the hint in this response.

Perhaps the section heading has been the problem all along.

Yes, the use of GSSAPI by SASL is another example.  In fact RFC 4422 makes the point:

   Note that the mechanism negotiation is not protected by the
   subsequent authentication exchange and hence is subject to downgrade
   attacks if not protected by other means.

Does "Cryptographic Key Establishment Techniques" work better for you?

>>> 	   Institutions, being large or dominate users within a large
>>> 	   user base, can assist by coordinating the demise of an
>>> 	   algorithm suite, making the rollover easier for their own
>>> 	   users as well as others.
>>> 
>>>   Somehow the meaning of the above eludes me.  It needs a rewrite.
>> 
>> The point is that big customers can help with the social part of the
>> transition by putting pressure on their suppliers.  I'm not sure what part
>> to change to make that more clear for you.
> 
>    Dominant, or otherwise sufficiently large, market players can ...

How about this:

   Dominant players in a market, or others with a sufficiently large
   user base, can assist by coordinating the demise of an algorithm
   suite, making the transition easier for their own users as well as
   others.

> 
>>> Section 2,7:
>>> 
>>>      When selecting or negotiating a suite of cryptographic algorithms,
>>>      the strength of each algorithm SHOULD be considered.  The algorithms
>>>      in a suite SHOULD be roughly equal;
>>> 
>>>   s/roughly equal/comparably strong/ or (to really spell it out):
>>>                  /have comparable best known attack work-factors/
>>> 
>>>   However if a particular element of a suite is believed stronger
>>>   than the rest, we don't need to get too pedantic about that.
>>>   Slightly lop-sided choices are OK if the stronger outlier is
>>>   adequately fast, and weaker variants are not widely used.
>> 
>> That was the point of "roughly".  Also, the second paragraph bring in the point about performance being a factor.
>> 
>> How about this:
>> 
>>   When selecting or negotiating a suite of cryptographic algorithms,
>>   the strength of each algorithm SHOULD be considered.  The algorithms
>>   in a suite SHOULD be roughly equal; however, the security service
>>   provided by each algorithm in a particular context needs to be
>>   considered when making the selection.  Algorithm strength needs to be
>>   considered at the time a protocol is designed.  It also needs to be
>>   considered at the time a protocol implementation is deployed and
>>   configured.  Advice from from experts is useful, but in reality, such
>>   advice is often unavailable to system administrators that are
>>   deploying a protocol implementation.  For this reason, protocol
>>   designers SHOULD provide clear guidance to implementors, leading to
>>   balanced options being available at the time of deployment.
> 
> I do not think the greater length makes it clearer, perhaps the
> original shorter version will do.

This is the text that went to the IESG yesterday, so if this is working, let's keep it.

>>>  Overall I think this text is wrong to weasel out.  Failure to
>>>  negotiate the DH parameter size has proved rather problematic
>>>  in TLS, with servers needing to guess at universally inteoperable
>>>  prime bit length.  This is being addressed, with the DH groups
>>>  extension now supporting standard prime groups as well as standard
>>>  EC curves.  Underspecified algorithms MUST NOT be used.  Either
>>>  fix the parameters, or negotiate them.
>> 
>> You raise an important point.  I suggest:
>> 
>>   Performance is always a factor is selecting cryptographic algorithms.
>>   Performance and security need to be balanced.  Some algorithms offer
>>   flexibility in their strength by adjusting the key size, number of
>>   rounds, authentication tag size, prime group size, and so on.  For
>>   example, TLS cipher suites include Diffie-Hellman or RSA without
>>   specifying a particular public key length.  If the algorithm
>>   identifier or suite identifier named a particular public key length,
>>   migration to longer ones would be more difficult.  On the other hand,
>>   inclusion of a public key length would make it easier to migrate away
>>   from short ones when computational resources available to attacker
>>   dictate the need to do so.  The flexibility on asymmetric key length
>>   has lead to interoperability problems, and to avoid these problems in
>>   the future any aspect of the algorithm not specified by the algorithm
>>   identifier MUST be negotiated, including key size and parameters.
> 
> Better, but of course negotiating the strength of long-term public
> keys is generally not possible, the server can't choose these on
> the fly.  So the MUST is perhaps too strong.  Rather, protocol
> designs SHOULD try to avoid unilateral choices of cryptographic
> parameters to the extent possible.  Thus we should encourage
> specification of a small set of explicit sizes or set of explicit
> groups, ... and then negotiate their use.

Stephen did not think the MUST was appropriate for a BCP.

The current wording is:

   Performance is always a factor is selecting cryptographic algorithms.
   Performance and security need to be balanced.  Some algorithms offer
   flexibility in their strength by adjusting the key size, number of
   rounds, authentication tag size, prime group size, and so on.  For
   example, TLS cipher suites include Diffie-Hellman or RSA without
   specifying a particular public key length.  If the algorithm
   identifier or suite identifier named a particular public key length,
   migration to longer ones would be more difficult.  On the other hand,
   inclusion of a public key length would make it easier to migrate away
   from short ones when computational resources available to attacker
   dictate the need to do so.  The flexibility on asymmetric key length
   has led to interoperability problems, and to avoid these problems in
   the future any aspect of the algorithm not specified by the algorithm
   identifiers need to be negotiated, including key size and parameters.

Russ