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

Russ Housley <housley@vigilsec.com> Wed, 02 September 2015 21:18 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 29B2C1B4BA6 for <saag@ietfa.amsl.com>; Wed, 2 Sep 2015 14:18:54 -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 7Ra8ag8DURcT for <saag@ietfa.amsl.com>; Wed, 2 Sep 2015 14:18:52 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 50EEB1B4EEF for <saag@ietf.org>; Wed, 2 Sep 2015 14:18:52 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id CE595F2413C for <saag@ietf.org>; Wed, 2 Sep 2015 17:18:41 -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 x1J5ckC3Gm6n for <saag@ietf.org>; Wed, 2 Sep 2015 17:17:24 -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 B9913F24157 for <saag@ietf.org>; Wed, 2 Sep 2015 17:18:20 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1085)
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <20150726233935.GE4347@mournblade.imrryr.org>
Date: Wed, 2 Sep 2015 17:18:10 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <078FB0AB-23F6-4A1E-85DF-0E56EC93554B@vigilsec.com>
References: <55A938F1.9090404@cs.tcd.ie> <20150720044849.GY28047@mournblade.imrryr.org> <20150726233935.GE4347@mournblade.imrryr.org>
To: saag@ietf.org
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/A7Hbl8qZYiFEdELkoArFlVvNFIs>
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: Wed, 02 Sep 2015 21:18:54 -0000

Viktor:

You comments were provided in two message, so I am responding to them separately as well.

> Section 3.1 first paragraph:
> 
>    The sentence:
> 
>       It seems like the ability to use an algorithm of one's own
>       choosing is very desirable; however, the selection is often
>       better left to experts.
> 
>    is rather imprecise.  I would suggest something more concrete:
> 
> 	Explicit selection of concrete cryptographic algorithms
> 	should generally not be left to end-users.  Rather, end-users
> 	might select between configuration profiles defined by
> 	experts.

Your proposed rewording misses a point I am trying to make.  At first blush, people may think that their ability to pick any algorithm is a good thing.  This is rarely the case.

How aboutL

   It may seem as if the ability to use an algorithm of one's own
   choosing is very desirable; however, the selection is often better
   left to experts.  When there are choices, end-users might select
   between configuration profiles that have been defined by experts.

>    The next sentence is too confusing to suggest improvements:
> 
> 	  Further, any and all cryptographic algorithm choices
> 	  ought not be available in every implementation.

I have tried to make the point more clearly:

   Further, experts need not specify each and every cryptographic
   algorithm alternative.  Specifying all possible choices will not lead
   to them being available in every implementation.

>    The rest of the first paragraph:
> 
> 	s/that it has/that has/
> 	s/has alway had/has always had/

Done.

>    The last sentence of the same paragraph:
> 
> 	In addition, inclusion of too many alternatives may add
> 	complexity to algorithm selection or negotiation.
> 
>    might be better as:
> 
> 	Finally, standardization of too many alternatives will
> 	likely hamper security and interoperability.  When
> 	standardizing new algorithms it is prudent to consider what
> 	existing algorithms need to deprecated to make room for
> 	the new.
> 
>    [ For example, I'd like to see deprecation of many legacy DNSSEC
>      algorithm code points, once new code points appear based on
>      CRFG's new curves. (Of the existing algorithms, I'd keep only
>      RSASHA256(8) and ECDSAP256SHA256(13)). ]

I like what you are saying, but I do not want to loose the point about added complexity.

I suggest:

   In addition, inclusion of too many alternatives may
   add complexity to algorithm selection or negotiation.  Specification
   of  too many alternatives will likely hamper interoperability and may
   hamper security as well.  When specifying new algorithms or suites,
   protocol designers would be prudent to consider whether existing
   ones can be deprecated.

> Last paragraph of 3.1:
> 
> 	s/Sometime/Sometimes/
> 	s/depending of/depending on/

Done.

> Last paragraph of 3.4:
> 	
> 	s/roll out/roll-out/  (the first is the verb, the second the noun).

This is in section 3.3.  Corrected.

> Section 3.4:
> 
>    Amen for disabled by default "national" algorithms.  It would
>    be nice to explicitly see this recommendation for GOST in DNSSEC,
>    SEED in TLS, ...

That belongs in other documents.  Of course, the people that write those document want to see their national algorithm added to every implementation.

> Section 4:
> 
>       Sometimes application layer protocols can make use of transport layer
>       security protocols, such as TLS [RFC5246] or DTLS [RFC6347].  This
>       insulates the application layer protocol from the details of
>       cryptography, but it is likely to still be necessary to handle the
>       transition from unprotected traffic to protected traffic in the
>       application layer protocol.  In addition, the application layer
>       protocol may need to handle the downgrade from encrypted
>       communication to plaintext communication.
> 
>    What's the relevance of a possible transition from cleartext
>    to encryption (and perhaps back again???).

It is the security considerations, and this seems like a possible attack vector.

> Overall:
> 
>    I found the document to be too "hand-wavy".  I think that it
>    could be shorter by leaving out more text where no specific
>    recommendations are or can be made.
> 
>    The wording could use a lot more polish, my list of nits is
>    far from comprehensive.

Again, thanks for you thoughtful review.  You have made the document better.

Russ