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

[Watson Ladd <[e-mail]>]

On Thu, Sep 3, 2015 at 6:18 PM, Nico Williams <[e-mail]> wrote:
> 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).

I don't understand what this means. Should the curl developers let
sysadmins or distributions configure ciphersuites, or use the default
in OpenSSL? Should OpenSSL express the flexibility it now does with
regards to configuration? If we want to say something about these
questions, it should be clear.

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

Why should we deploy weak crypto knowingly? We know that transitions
away take years, and tend to start late.

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

Let's say I write protocol X. Protocol X uses TLS. I know a lot about
the domain that X deals with, but not the domain that TLS deals with.
Shouldn't this be enough to ensure security? And if it isn't, isn't
that a sign that we need a replacement that will be sufficient.

>
> Nico
> --
>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.