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

Russ Housley <housley@vigilsec.com> Thu, 03 September 2015 20:51 UTC

Return-Path: <housley@vigilsec.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 C84711B3F67 for <saag@ietfa.amsl.com>; Thu, 3 Sep 2015 13:51:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 ywwHLqoKOlW4 for <saag@ietfa.amsl.com>; Thu, 3 Sep 2015 13:51:22 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2C61B3F62 for <saag@ietf.org>; Thu, 3 Sep 2015 13:51:22 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id E0729F2414D; Thu, 3 Sep 2015 16:51:11 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id Wz7FCEOF-y4c; Thu, 3 Sep 2015 16:49:54 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 14153F24153; Thu, 3 Sep 2015 16:50:51 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <20150903203422.GS9021@mournblade.imrryr.org>
Date: Thu, 03 Sep 2015 16:50:40 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <59B012CE-06B4-46E6-A909-F4DECD92B32C@vigilsec.com>
References: <20150901165526.GU9021@mournblade.imrryr.org> <4F6E430F-61E7-46BA-9B4A-8E12156B62FA@vigilsec.com> <20150901211906.GA9021@mournblade.imrryr.org> <E44EE5B3-1469-49D7-9C15-299230E13779@vigilsec.com> <tsl8u8pmzta.fsf@mit.edu> <92D9378E-4724-4721-A5F4-26614D96831E@gmail.com> <20150902040145.GD9021@mournblade.imrryr.org> <CAC4RtVBJQX+B3XvnGnUpHbHdyw08Yn+CEGXML7K+c3q2pLNa7w@mail.gmail.com> <20150902223418.GS9021@mournblade.imrryr.org> <C1143EE0-499A-4DD5-B412-53F03A8C28BE@vigilsec.com> <20150903203422.GS9021@mournblade.imrryr.org>
To: Viktor Dukhovni <ietf-dane@dukhovni.org>
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/rOuXMrR9OqcYXgbuk0U6SGKmMHg>
Cc: IETF SAAG <saag@ietf.org>
Subject: Re: [saag] Section 2.9: was Re: 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: Thu, 03 Sep 2015 20:51:23 -0000

Viktor:

> On Thu, Sep 03, 2015 at 04:08:59PM -0400, Russ Housley wrote:
> 
>>> It can be a sentence or two, just enough to not give the impression
>>> that weak crypto is preferred with OS.
>> 
>> The words in my current edit buffer are:
>> 
>>   Despite the guidance in Section 2.4, opportunistic security [RFC7435]
>>   also deserves consideration, especially at the time a protocol
>>   implementation is deployed and configured.  Using algorithms that are
>>   weak against advanced attackers but sufficient against others is one
>>   way to make pervasive surveillance significantly more difficult.  As
>>   a result, algorithms that would not be acceptable in many negotiated
>>   situations are acceptable for opportunistic security when legacy
>>   systems are in use for unauthenticated encrypted sessions as
>>   discussed in Section 3 of [RFC7435] as long as their use does not
>>   facilitate downgrade attacks.  Similarly, weaker algorithms and
>>   shorter key sizes are also acceptable for opportunistic security with
>>   the same constraints.  That said, the use of strong algorithms is
>>   always preferable.
>> 
>> Would it help to change "As a result" to "As a result, when communicating
>> parties do not have strong algorithms in common"?
> 
> You're heading in the right direction, but I think this is a sentence
> or so too late.  The sentence that starts with "Using algorithms
> that are weak ..." is troublesome.  How about:
> 
>    Using the strongest available encryption (even if not strong
>    enough for mandatory security) is one way ...
> 
> And then perhaps still make the additional change you're proposing.

Trying to pull the idea into the earlier part of the paragraph...

Current Text:

   Using algorithms that are weak against advanced attackers but
   sufficient against others is one way to make pervasive
   surveillance significantly more difficult.

Possible Alternative:

   Opportunistic security, like other reasons for encrypting traffic,
   needs to make use of the strongest encryption algorithms that are
   implemented and allowed by policy.  When communicating parties do
   not have strong algorithms in common, using algorithms that are
   weak against advanced attackers but sufficient against others is
   one way to make pervasive surveillance significantly more difficult.

Russ