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

Kathleen Moriarty <> Tue, 25 August 2015 16:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7CE6F1A0334 for <>; Tue, 25 Aug 2015 09:26:35 -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 fmtuZ3luafx6 for <>; Tue, 25 Aug 2015 09:26:30 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 783561A0252 for <>; Tue, 25 Aug 2015 09:26:29 -0700 (PDT)
Received: by widdq5 with SMTP id dq5so20022253wid.0 for <>; Tue, 25 Aug 2015 09:26:28 -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 :content-type; bh=5A5w7VEduh0jBOf4TVOM3rRgYm6+h1Ll68ABRjJ+0TU=; b=DBqwS2x1/GovpKxIxXMAQa6fcBnOpydz7rJIaXI/qAPV/1VAqKR2O6knrVnsNjvc8H J5IXjR4fCVcEEzEBrLNguoeLaGMORk5AF37f90a+RgoMtZVOJWapxnlLWygzT5mnY53s +3ZJ/tob7gzLU72zsZgQgyLikj7DcTprKeU8m+O4ChNFQHrJRmRG7nv2d9OY918qO+zr QHlUQk6xfmMWMDuZuKvKGAjgeNT4SRPo/0nHxau3mOdF1M3zXiNP4RqH4ehHMQwSlYqa qV0ASlrPk9h3wI+q+afea/mrNjyWYRZO1kFwYGeEdR9gCjhFE8OieXzBUFscZy9iYdSd skrA==
MIME-Version: 1.0
X-Received: by with SMTP id ld5mr54443528wjc.14.1440519988220; Tue, 25 Aug 2015 09:26:28 -0700 (PDT)
Received: by with HTTP; Tue, 25 Aug 2015 09:26:27 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 25 Aug 2015 12:26:27 -0400
Message-ID: <>
From: Kathleen Moriarty <>
To: "" <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
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: Tue, 25 Aug 2015 16:26:35 -0000

On Tue, Aug 25, 2015 at 12:06 PM, Viktor Dukhovni
<>; wrote:
> On Tue, Aug 25, 2015 at 03:44:12PM +0000, Salz, Rich wrote:
>> > Opportunistic TLS is supported in at least Exchange 2007 and later.
>> > I don't recall what Exchange 2003 did outbound, I only recall helping
>> > Microsoft to design fixes for various issues prior to the release of Exchange
>> > 2007.  Some flaws remain, but it is largely workable without a CA tax.
>> This is important.  It means that for SMTP, OS really started in 2005 with
>> Postfix and 2007 for Exchange?   If so, then there is really no need to
>> support RC4.  STARTTLS, as Peter was saying, can imply more than just OS,
>> as MS really wants a CA to be involved.  Since a principal tenet of OS is
>> *unauthenticated* privacy, it appears that the discussion has conflated
>> the two.
> You're reading too much into the tea leaves.  Exchange as a server
> supported inbound STARTTLS since 2003 and a non-trivial number of
> deployed systems are of that vintage.  There was STARTTLS support
> in Postfix as shipped in some Linux distributions, well before the
> feature was officially adopted and improved by Wietse for Postfix
> 2.2 in 2005.
> Yes, Exchange support for STARTTLS was improved (for outbound TLS)
> in 2007.  However, exchange was not and is not a dominant edge MTA.
> It is used inside networks a lot more than at the edge.
> There is longstanding STARTTLS support in Sendmail, Qmail, Exim,
> Ironport appliances, Kerio appliances, ...
> STARTTLS for SMTP has a large deployed base, with many of the
> systems running less-capable "vintage" software.  How long ago they
> got there is not especially relevant.  Your conclusions about RC4
> with SMTP are I'm afraid wishful thinking.
> Users are having real issues delivering email to RC4-only systems.
> Downgrading those to cleartext (and sometimes failing delivery
> entirely) is not a win.  I'll deprecate RC4 in Postfix as soon as
> possible, but not sooner.
> In any case, whether it is RC4 now, or some other deprecated
> ciphersuite in the futre, with opportunistic security one needs to
> pay more attention to what interoperates than what is unequivocally
> strong.  The goal is as much security as can be realistically had,
> not "all or nothing".  I like to make an analogy with vaccination,
> we're protecting the infrastructure as a whole, rather guaranteed
> security for a particular flow.

I'm not sure we have consensus and would like to see more opinions as
to what we collectively think the statements on OS should include.  I
don't think anyone is saying that bad crypto isn't better than no
crypto, but how we define OS and continue to use the definition may
matter for algorithm and cipher suite deprecation efforts.  It's long
been a practice for legacy systems to continue to use deprecated
protocols, algorithms and cipher suites, but we've said they are not
in compliance with RFCXXXX.  Do we really want to start down a path of
saying it's okay because it falls under OS?  I'd rather not.  We would
get to about the same result, but perhaps we could have more success
with deprecation transitions if these older options are not 'blessed'.

If others would like to offer their thoughts, it would be appreciated.
I know the specific argument around this was for RC4 and SMTP, but
let's think about the generalized statement and what we want that to
be going forward.

Thank you,

> --
>         Viktor.
> _______________________________________________
> saag mailing list


Best regards,