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

[Nico Williams <[e-mail]>]

Viktor asks me what the take-away from section 2.5 should be.  IMO it is
as follows.

Applications (app devs) and users are not in a good position to evaluate
cryptographic strength (and acceptability) of outcomes of protocol
negotiations, therefore this should be moved to local policy.  Local
policy includes defaults provided by implementors of security mechanisms
(TLS, Kerberos, etcetera).

This I-D, aiming to be a BCP, needs to outline a best practice as to
policy.  That best practice, IMO, is to give application developers and
users a very small control knob: a choice between named policies with
simple semantics.  "Strong", "normal", "opportunistic", "maximally
interoperable", "weak" -- these are both, good names and descriptions of
possible policies to apply; they are also good descriptors of outcomes.

Local policy should be expressible in some way, but it's OK if it's
hardcoded in implementations, as long as there are choices like the ones
I listed above, as those are the ones that applications and their users
need to apply.

It's OK -expected!- that the content of such policies will vary over
time because the relative strengths of cryptographic algorithms and
protocols vary over time as cryptanalysis improves.

Another take-away here is that implementors of security mechanisms and
frameworks really must provide interfaces by which to request a policy
to apply.  I.e., SASL, GSS, and others need a way for the application to
request a policy or check whether an outcome meets a given policy.  It's
not really enough to tell users to edit N configuration files,
especially if that makes it difficult to have more than one policy.

Now, local policy is NOT really part of a protocol.  So, this guidance
can't be for protocol designers.  It can be for framework API designers
(e.g., for us in KITTEN WG).  It can be for implementors of protocols
and frameworks.  That's OK, we can do that in a BCP.

Nico
--