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

Nico Williams <nico@cryptonector.com> Mon, 27 July 2015 19:40 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A37F1B3312 for <saag@ietfa.amsl.com>; Mon, 27 Jul 2015 12:40:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.966
X-Spam-Level:
X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0G_rNT7HLjyC for <saag@ietfa.amsl.com>; Mon, 27 Jul 2015 12:40:25 -0700 (PDT)
Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 65DBA1B329B for <saag@ietf.org>; Mon, 27 Jul 2015 12:40:23 -0700 (PDT)
Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 171FA10077; Mon, 27 Jul 2015 12:40:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=++6k0QBvWjIpd3 DodK+G40RvaIY=; b=yyhWz2p8A4LL6/oOleP8BYGSuEgy0ka+9K+iBXHjEpYshs PF/TzGGJMURdL+hEHo8egYGf9OLZBhgM66wMfpB8tca3snisSXXHM0eWDvdRJSBj nWdbHSJc1p7/DEoVH+ATxPzigSR2jELqOiEKVU4jcul54tt6CsG3+neyGEBZM=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPA id 6B3FB10057; Mon, 27 Jul 2015 12:40:22 -0700 (PDT)
Date: Mon, 27 Jul 2015 14:40:21 -0500
From: Nico Williams <nico@cryptonector.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Message-ID: <20150727194020.GD15860@localhost>
References: <55A938F1.9090404@cs.tcd.ie> <CD936D80-BEA2-4918-828C-E3A392761EC5@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CD936D80-BEA2-4918-828C-E3A392761EC5@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/J8stfKBkDCkVKyQnVTlWOf37hOU>
Cc: "saag@ietf.org" <saag@ietf.org>
Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2015 19:40:26 -0000

On Sat, Jul 18, 2015 at 10:30:19AM +0200, Kathleen Moriarty wrote:
> > On Jul 17, 2015, at 7:18 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> > 2.9: I'm not really a fan of blessing weaker algs for OS, but I lost
> > that argument before. I wonder if we would get consensus if this
> > said that weak algs are better than no encryption but still MUST be
> > deprecated as soon as feasible?
> 
> I don't think we've really debated this enough to get consensus.  I
> don't think weaker algs fit into our agreed definitions for OS.  I
> just recall your debate with Pete on another draft, but think a wider
> debate is needed to see what the consensus is.  I don't think weaker
> algorithms should fit into the definition.

If OS means "upgrade from cleartext when you can" (it does), then
failing to use weak crypto -> fallback on cleartext.

Even using 1DES is better than cleartext: because if everyone were using
1DES then the cost of massive eavesdropping (gather ciphertexts,
cryptanalyze) goes up significantly.

The key thing is that weak crypto must not lead to real-time exploitable
downgrade attacks.

Now, perhaps OS should mean "upgrade from cleartext when you can, but
fail if weak crypto is selected" (i.e., no fallback on cleartext).  But
then we have to have two OS definitions, one for SMTP, and one for other
protocols: because after all we do want [some, e.g., to postmaster]
e-mail to flow no matter what.  And even so, remember that the user
would gladly use no crypto if none is offered, so I don't think this
makes sense.

Think of OS as a migration strategy.  If we make the jump from cleartext
to encrypted too difficult/expensive, then we'll fail to complete the
migration.  Spurious failures resulting from attempting to upgrade could
mean failure to migrate: because users will simply turn off OS.  Yes, OS
could be required-to-be-enabled, thus preventing this social failure
mode, but we're still far from that.

Permitting weak crypto (with the above downgrade caveat) with OS is
rather necessary then.  We can only forbid weak crypto in OS
applications when the market share of such crypto is negligible.

Nico
--