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

Derek Atkins <> Thu, 27 August 2015 13:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 34D971B3A8F for <>; Thu, 27 Aug 2015 06:35:10 -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] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LhZxgbknzoSo for <>; Thu, 27 Aug 2015 06:35:08 -0700 (PDT)
Received: from ( [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 47CDE1B3A88 for <>; Thu, 27 Aug 2015 06:35:08 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F38FE2035; Thu, 27 Aug 2015 09:35:07 -0400 (EDT)
Received: from ([]) by localhost ( []) (amavisd-maia, port 10024) with ESMTP id 23151-10; Thu, 27 Aug 2015 09:35:05 -0400 (EDT)
Received: from (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by (Postfix) with ESMTPS id D8141E2034; Thu, 27 Aug 2015 09:35:04 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1440682504; bh=C2wqTD0inMtchyX5oceB0SEz1haxEwPjxOKv5tVVJqc=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=aQMdaihngEwlImcI/LdsVDclD/MvZF1+YuR+ws8o6zeZi/H3Lmgs4SLVLEX3VKhCs +dEnzsabiGHCmS2DPjkbWzf9Ll9r6+oR76STDr2K2ZN37MHkZwjW5IKRq7fuJEsAXe gfbcvVWnOips9oQ/xnUZzFJMfvkb6gyMr1TAMfjg=
Received: (from warlord@localhost) by (8.14.8/8.14.8/Submit) id t7RDZ4Vk019622; Thu, 27 Aug 2015 09:35:04 -0400
From: Derek Atkins <>
To: Martin Thomson <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Thu, 27 Aug 2015 09:35:04 -0400
In-Reply-To: <> (Martin Thomson's message of "Tue, 25 Aug 2015 11:13:44 -0700")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
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, 27 Aug 2015 13:35:10 -0000

Martin Thomson <>; writes:

> Since Kathleen asks so nicely, I'd like to register my disagreement
> with Victor on this point.
> There are compatibility reasons *today* that exist as a result of
> having to interoperate with old software that was built or deployed
> without due regard to security updates or continuous maintenance.
> However, if we expect software to be updated in order to get
> opportunistic security, then I don't think it unreasonable to also
> expect it to be maintained on an ongoing basis.  A sudden once-off
> isn't going to cut it if we want to prepare for the eventuality where
> one of the current ciphers turns out to be irredeemably busted.
> If you accept that software that is updated once can be continuously
> maintained thereafter, then it's not a stretch to conclude that
> deploying good ciphers is equally feasible.

I disagree.  Most IT players I know set something up and basically don't
touch it unless something breaks.  They don't regularly update stuff
unless they have to (and I'll hand-wave at what indicates they "have to"
-- some people are definitely more proactive and a CVE might be enough
to trigger the update).  The fact that we're still seeing 12-year-old
software in deployment (Exchange 2003) seems to back up my point that
once stuff is deployed and "worked" it tends to be left alone.

My personal feeling that "some" crypto is better than "no"
crypto.... MOST of the time.  I think all of us would argue that "rot13"
is probably *not* better than no crypto.  So where do we draw the line
as to what's a step forward and what's a false sense of security?  Do we
draw the line at rot13?  RC4-40?  RC4-128?  DES?  3DES?

And once we agree that we need to have that line, does that line need to
move over time?  And how do we move that line?

Is there some way we can pop errors up the stack in a way that the end
users can be notified that something is wrong?  Just returning a "45x
Cipher Too Weak" SMTP error code isn't going to help, because I know of
nobody that actively monitors those logs sufficiently to even NOTICE
that they get that message.  Often you'll only start to check the logs
once you notice mail isn't flowing at all, and even then you'll only
really know for outbound email, not inbound email!

       Derek Atkins                 617-623-3745   
       Computer and Internet Security Consultant