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

[Viktor Dukhovni <[e-mail]>]

On Thu, Sep 03, 2015 at 05:16:14PM -0400, Russ Housley wrote:

> >    2.5.  Cryptographic Key Management
> > 
> >       [...]
> > 
> > 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?

OK, so perhaps we're talking about negotiating "Key Establishment"
methods.  Or perhaps in fact "layered" security protocols where
the outer security protocol negotiates one of many inner security
protocols (opaque to the outer protocol) and the inner protocols
do the actual crypto.

In the SASL case when choosing between PLAIN, GSSAPI, EXTERNAL,
...  there may in fact be no integrity protection of the outer
negotiation and lack of transparency about the compative strengths
of the available alternatives.

Beyond repairing the heading (which is important), the content of
that section still needs work, because it should have been clear
what it means even with a misleading heading.

> 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.

[ Duplicate, yes good. ]

> 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.

Close enough I guess.  I hope protocol designers will make sensible
choices.  Thus, for example, in TLS I would not suggest different
suites for each of a small set of supported RSA modulus bit lengths.

On the other hand, in DNSSEC, I would in fact have been tempted to
nail down the modulus sizes as part of the algorithm id.  The good
news is that we get that with the EC algorithms for DNSSEC (one
algorithm id per-curve) and I expect that eventually the RSA
algorithms for DNSSEC will be deprecated (though it may take a
decade or more).

So the "right thing to do" here varies a bit by context.

-- 
	Viktor.