Re: [secdir] [Anima] SecDir review of draft-ietf-anima-grasp-09

Barry Leiba <barryleiba@computer.org> Thu, 09 March 2017 20:00 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E687129413; Thu, 9 Mar 2017 12:00:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level:
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 iNMMoQUMKquG; Thu, 9 Mar 2017 12:00:00 -0800 (PST)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 91F311293E1; Thu, 9 Mar 2017 11:53:48 -0800 (PST)
Received: by mail-io0-x22c.google.com with SMTP id l7so35439382ioe.3; Thu, 09 Mar 2017 11:53:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DkCF+UmvGJ0tMtALYFtN6asNkMdqkAbikZguw1tQcbI=; b=iob793nxeXmuzsztqtVrfSS1kf7UC8qN6VAc32fSQonTmsiU/quEf2HyTVJdxW9ULJ HrgR3W3MygO8gG2+Byu5baDduVibjzp+q6YgXoh4/a1/yZqdysddTSB8M1qi5t1Lgohj WaqB+SM9gpFTWd2rLcIKtcp9M8IozStm85cnSaY3TEhktHtgecP7kL3q7+dRAcoorrQq bDnuzQlWyMqlGvjWlqyncTibGAuVCmxKGpLu0nx7JuapcYGEPXROGC7U7X5Vp/i8xwbE tgjgyiYPbz9a3SeRmkg+Z93Gv36exJK3DQT97Y0+d1BPaH5RbyP2CIF2sjEFv0IPmsaN NJlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DkCF+UmvGJ0tMtALYFtN6asNkMdqkAbikZguw1tQcbI=; b=nDbnuo2qO7CBycYMDsUp0ehrq36EME/hZ+ELjSbjeowxRmTmhZURfSxhbfdM7nGMiA aUfFa7fj3JBq+JCL4fF+JfCaCOg+rD6eXTlYtZi70si8YeGGOCAdSOWkOlL6RTwquikx u0BfhhvGyMIwSGh9HixSIRYg+YjTrROh2k1QET/92i3vezkvgFOUVletnCHCzoUzqDD9 kKrVa7d4QsG58/zxVz1c9kBNLoIpHjNCM2wy7zgnldNDAs4GTCbWfRRwcXuj+rxtheC0 Xuvfa0CTUWXrjydjP0JaIUeoC950YNJjyaW1FO+vsmkce7gaJRWHH5hf53xY878WgPeJ /5qw==
X-Gm-Message-State: AMke39nBpR44BFEAsLUyL2UVS7nt9ko0a+UJoCfT6lidEk8PixZPlrpyfmORIBeQOFL5yaT+K4IIkEdsGCcy4A==
X-Received: by 10.107.182.9 with SMTP id g9mr11747515iof.233.1489089227965; Thu, 09 Mar 2017 11:53:47 -0800 (PST)
MIME-Version: 1.0
Sender: barryleiba@gmail.com
Received: by 10.107.187.7 with HTTP; Thu, 9 Mar 2017 11:53:47 -0800 (PST)
In-Reply-To: <63103cc5-1c99-78eb-04a4-d8e44c2e6185@gmail.com>
References: <CALaySJ+rLh9ZBmydm0bG+TBxGK_dB-UmnkeJusd1C-3zMowwHg@mail.gmail.com> <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> <17893.1489070987@obiwan.sandelman.ca> <CALaySJ+50GcJAjSzQKfwi4bEfjYUWFP44uhHtAeXQsR_yOvF=w@mail.gmail.com> <63103cc5-1c99-78eb-04a4-d8e44c2e6185@gmail.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Thu, 09 Mar 2017 14:53:47 -0500
X-Google-Sender-Auth: 6P0-7rtfBkJQ3IxvciGz9hs6mWo
Message-ID: <CALaySJJjKcCWmhsz+d7X0=5+J-n1pZww-3ATV0wkiGCOn0YAFg@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/knkeqDM9knThhR0Ha04mtf7kH_Y>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] [Anima] SecDir review of draft-ietf-anima-grasp-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Mar 2017 20:00:01 -0000

>> This brings up a common rant that I have:
>> We should be putting into our protocol specs what we want the protocol
>> to be, not some compromise that comes from knowing that not everyone
>> will comply with everything from the start.
>>
>> If the right thing is to say "MUST encrypt", but we know there'll be a
>> transition period during which that's not fully practical, then we
>> should say that.  Something like this added to Section 3.5.1:
>>
>> NEW
>> In some cases there will be a transition period, in which it might not
>> be practical to run with strong encryption right away.  It's important
>> to keep this period as short as possible, and to upgrade to a fully
>> encrypted setup as soon as possible.
>> END
>
> or perhaps more precisely:
>
> During initialization of nodes there will be a transition period...

Yep; better.

> Whether this is phrased as an exception to the MUST or as the justification
> for ignoring the SHOULD is a matter of taste, I think.

I don't think it's a question of taste.  If there's a long-term reason
to run nodes without encryption, then SHOULD might make sense.  But if
we do expect the stable state to always be encrypted, and avoiding it
is a short-term expedient that we want to have go away as soon as
possible, then the protocol should say MUST, and the exception is
clearly specified as a brief thing that mustn't last.  It's a
substantive difference, not one of writing style.

> My thought was that these names will sometimes be visible to humans so why
> not allow localized names? If GRASP succeeds it might be used for local
> applications, not just generic applications. So I'd rather allow it
> from the start, and if we have to add character-set restrictions later,
> so be it.

Makes sense to me.  Carry on.

Barry