Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt (IESG comment)

Toerless Eckert <tte@cs.fau.de> Wed, 07 June 2017 00:10 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27057126E01; Tue, 6 Jun 2017 17:10:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.714
X-Spam-Level:
X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 ofCMk-0DsoQK; Tue, 6 Jun 2017 17:10:14 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01CF7126DD9; Tue, 6 Jun 2017 17:10:13 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9194258C4EC; Wed, 7 Jun 2017 02:10:10 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 80ED4B0C1FE; Wed, 7 Jun 2017 02:10:10 +0200 (CEST)
Date: Wed, 07 Jun 2017 02:10:10 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, iesg@ietf.org, anima@ietf.org
Message-ID: <20170607001010.GC23319@faui40p.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/m7bzTxwddeIU6C7FgJ3fzvYdiT4>
Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt (IESG comment)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jun 2017 00:10:16 -0000

(slight rant about encryption, sorry, also Ccing IESG because this seems to have resulted from IESG feedback):

Which IESG feedback did raise the need to mandate encryption for GRASP in the text block you propose ?
If this does stem from IESG feedback, i would love to know any appropriate IETF security guideline
(RFC?) that defines this MUST as recommended for network signaling (such as GRASP).

IMHO: I think its bogus and an annoying proliferation of PerPass concerns into totally
different domains than end-user data. I think most network signaling works best if it is NOT encrypted
by default because it easily breaks monitoring, diagnostics, troubleshooting, analytics, optimizations. 

IMHO, networking signaling transport MUST support authentication and SHOULD enable this
by default. It MUST support enrcyption but SHOULD select the default for encryption (off/on)
based on weighting monitoring, diagnostics, troublehsooting, analytics and optimizations benefits
vs. data privacy concerns (eg: understood and documented increase in attack surface). 

Example: 

- TLS with zero-encrypt is IMHO a good default for network signaling (such as GRASP).
- ACP is a great solution to enable encryption by default because the zero-touch
  handling of domain certificates does allow to easily establish trust relationships
  for "third-party" monitoring, diagnostics, troubleshooting, analytics and optimization functions.

Thanks
    Toerless

> On Jun 5, 2017, at 4:22 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> This version includes a second round of responses to IESG comments.
> 
> We may not be done yet, but please check the diffs. Here are the main changes:
> 
[...]
> 
>          <t>As mentioned in <xref target="highlevel"/>, some GRASP operations might be
>          performed across an administrative domain boundary by mutual agreement, without the
>          benefit of an ACP. Such operations
>          MUST be confined to a separate instance of GRASP with its own copy of all GRASP
>          data structures. Messages MUST be authenticated and encryption MUST be used.
>          <!-- TLS <xref target="RFC5246"/> and DTLS <xref target="RFC6347"/> based on a Public Key Infrastructure (PKI)
>          <xref target="RFC5280"/> are RECOMMENDED for this purpose.-->
>          Further details may be specified in future documents.
>          </t></section>
> 

-- 
---
tte@cs.fau.de