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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 25 August 2015 17:55 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.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 B6B311ACF08 for <saag@ietfa.amsl.com>; Tue, 25 Aug 2015 10:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6XEkGbCyAxi for <saag@ietfa.amsl.com>; Tue, 25 Aug 2015 10:55:30 -0700 (PDT)
Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F7BB1ACEE6 for <saag@ietf.org>; Tue, 25 Aug 2015 10:55:30 -0700 (PDT)
Received: by qgeb6 with SMTP id b6so111048993qge.3 for <saag@ietf.org>; Tue, 25 Aug 2015 10:55:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:references:in-reply-to:to; bh=50xGzGIYKTOkqOwxFy6nBG7R0msGX6Pw2e4sy5zF6QQ=; b=VmL5TtcMRhBMtctlXEMGuIEUqOCqQg5JX1woeb4F0qrH9V8JWGCbAf/EAk3z3KadgL cTeWDrhXz+s83p/f//XfYZfjU5t/He9eqwt9lGoSbczf/y+CVgE8YtUBaXXVRC/1PLhc AbulJQsMpDo4SvP7qCUb9TxoW6DJhwdrm4cfAgyNRj7PzqgdM7Xbt2qOgVrShrZipz+z IyEK155r5jQGGo+Md+fdyFQu8l8ffnhpLI3mDnpUnl4jW0wM8AYDAg+gkRypIPDkNcrq EzNKJiVJqhSucykLi0wUPJJRShW93FoOIdBPr/MbowRnLLViVOQMGr02cSjDAot5M6ss xVlA==
X-Received: by 10.140.234.130 with SMTP id f124mr71572414qhc.103.1440525329352; Tue, 25 Aug 2015 10:55:29 -0700 (PDT)
Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by smtp.gmail.com with ESMTPSA id j30sm14271042qgj.20.2015.08.25.10.55.28 for <saag@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Aug 2015 10:55:28 -0700 (PDT)
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Google-Original-From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Message-Id: <7CEEF500-4530-4245-A3DC-C7D1ACB754B6@gmail.com>
Date: Tue, 25 Aug 2015 13:55:27 -0400
References: <20150728013020.GO4347@mournblade.imrryr.org> <DM2PR0301MB0655CF099FA7C56E9B9D24A9A88D0@DM2PR0301MB0655.namprd03.prod.outlook.com> <20150728053035.GR4347@mournblade.imrryr.org> <CAHbuEH7B3_G9vAhw=U2tuz-Uh8mKMUfL6s=H+BOG96FDZaACig@mail.gmail.com> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <CAHbuEH5r5s8ofChzt0_Rd8dxKqf8KXLDteYw8RSBX43nyFrN+A@mail.gmail.com> <2E7E9F38-DA68-4933-AD67-CF2A8E51B4F7@dukhovni.org>
In-Reply-To: <2E7E9F38-DA68-4933-AD67-CF2A8E51B4F7@dukhovni.org>
To: "saag@ietf.org" <saag@ietf.org>
X-Mailer: iPhone Mail (12H143)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/FPPobyOEgYiloOhYDkPvP3ZIYGY>
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: Tue, 25 Aug 2015 17:55:31 -0000


Sent from my iPhone

> On Aug 25, 2015, at 1:39 PM, Viktor Dukhovni <ietf-dane@dukhovni.org>; wrote:
> 
> 
>>> On Aug 25, 2015, at 12:26 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>; wrote:
>>> 
>>> 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 thought we reached "rough" consensus on this point during the rather
> intensive/extensive last-call discussions of the OS draft.  Specifically,
> that even weaker ciphers are better than cleartext, and may need to
> continue to be used if that's what it takes.

I don't this point was as clearly discussed in those threads, so I'd like to hear thoughts from the community.  Thank you for sharing your opinion.

If you think it was and have a pointer to the appropriate thread with adequate input to show support, please post it.  Otherwise, allowing others to chime in will be helpful.  I may be in the rough, but I'm not convinced of that with this thread so far.

Thanks,
Kathleen 

> 
>> 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'.
> 
> How to position deprecation is more of a marketing than a technical
> question.  I agree that we don't want to dilute the message that
> deprecated ciphers should be phased out as quickly as possible.
> OS is not a license to indefinitely ignore deprecation.
> 
> The key issue is what "as quickly as possible" means.  For OS, it is likely
> to mean that the process takes longer, because the relative priorities of
> interoperability and security are different than with non-OS designs.
> 
> So by all means, publish unequivocal deprecation of RC4, ... but expect
> that OS applications will take some time to act on such publications and
> rightly so.
> 
> -- 
>    Viktor.