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

Watson Ladd <> Thu, 03 September 2015 23:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 73FA21B30B5 for <>; Thu, 3 Sep 2015 16:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A8mHarGVLI5N for <>; Thu, 3 Sep 2015 16:34:46 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB5FA1B306F for <>; Thu, 3 Sep 2015 16:34:45 -0700 (PDT)
Received: by wiku15 with SMTP id u15so211571wik.1 for <>; Thu, 03 Sep 2015 16:34:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=97I//xW2os7ISiWaXOGRGAtAdqvczD7vsekDCWkE4no=; b=1JzVFgLNz8Jp61uNSMlw85L7unYIFxAUTY7FkGLmM8+dovwUQCYZKH2UimfCs1HMJw iQO5l/veuDIDvTFwuEG2X7NQfUms13WaUT7Lsq/vWj9wrsNEpB4+rP/UYtNRuvpgjBEc ETCbkrEVfi6cgrv5lATIigod13rUdXCVaaVMpCG2cs8EToa+Uiw9ACoPxh9MECHY1knt 6wxJh9DNO+IqcALnSoH/SF8YG+A1PGfdXslE2mPB/4y7YlsFZC0xA5tudYpq9a9KgID9 b8Fjg86NxjPsLOX+uYctFJ+ekX2XlY7ibKOD7Zz2ulaSOXmP678RDiQKU1jhGVHZgzsA BP7w==
MIME-Version: 1.0
X-Received: by with SMTP id gr2mr1488441wib.18.1441323284374; Thu, 03 Sep 2015 16:34:44 -0700 (PDT)
Received: by with HTTP; Thu, 3 Sep 2015 16:34:44 -0700 (PDT)
In-Reply-To: <20150903221855.GF1541@localhost>
References: <> <> <> <> <20150903221855.GF1541@localhost>
Date: Thu, 3 Sep 2015 19:34:44 -0400
Message-ID: <>
From: Watson Ladd <>
To: Nico Williams <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Sep 2015 23:34:49 -0000

On Thu, Sep 3, 2015 at 6:18 PM, Nico Williams <>; 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

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