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

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 08 March 2017 04:29 UTC

Return-Path: <brian.e.carpenter@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 2FD3E128BA2; Tue, 7 Mar 2017 20:29:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 gRquJqhhWV44; Tue, 7 Mar 2017 20:29:23 -0800 (PST)
Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 C7AFE12706D; Tue, 7 Mar 2017 20:29:23 -0800 (PST)
Received: by mail-pf0-x242.google.com with SMTP id j5so2329993pfb.3; Tue, 07 Mar 2017 20:29:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=HqPOzg55qjp4ZzWG208uCxfeqRyjXmy0tNJVWMH4IOk=; b=BKdjQuU8hxJiZvLKFG3RfS1UO9oaFeGRBfag29JNIQlSHhmj3wRj8N41Iwtg+lpfqJ d+MMV4dCFuM26DSbDOjDy0L2cncG1NbbzivdaQxxCcazZx2VEfB3IgKDKB27OZNz1azA oydldAU118sXGK1mt/DICq1euVOIpZtiy8eqQf8HSiH/lwD/GK9nHSxJeYA2Y5mALeSy NKTu8NAzVs0gngrUpcWgOKxnT9w18EcGEePZN5M+ez+5nNLbD6bMR/f2C2YOBCBeu8Hi +QgXR7kF+7yHm2wT4nAVB3jdoHRY11L3XH/1O6ANd9xBgswaJl9CinW59SuaglVkEOpO ezIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=HqPOzg55qjp4ZzWG208uCxfeqRyjXmy0tNJVWMH4IOk=; b=T1AVEmW6Td0rPepvFAhYYhdh4fjx1e7sAIICSR/804kb7c2ng6kygTYWTq1SMTUtth TzpFCV5ifJoSN3RPfEeqWXNIreeiYggE1Nl0jB+P5cZJUYeET/4KKCi0dJR22oUxs2hv BLI0FzaTp1ixniTbCHn9P7N+6DKElF9b7yU2HZfI3ZLrAUVJQ3RSriYQtgDxcMGfrMWq qqVSl8q4gMtoMTaKJzQLIEuzE1ahTMqXdvGZc0T37tXemplTGCox3t8W4kmfTGmNeFd1 QO+Wn5CjOyKOx/7/OWJ6PleN80pEEO6BxIHDfOa1pjYMuZhFwZZ+WlNhCCFTAev6Hpja KweQ==
X-Gm-Message-State: AMke39nweQRh6GgYPUC8ab8aPtkJIHlpigWkxUAVjX8Bk0VC7onn0RVxISwgUZljGp8Z0w==
X-Received: by 10.99.147.68 with SMTP id w4mr4639730pgm.32.1488947363073; Tue, 07 Mar 2017 20:29:23 -0800 (PST)
Received: from ?IPv6:2406:e007:77b4:1:28cc:dc4c:9703:6781? ([2406:e007:77b4:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f205sm2622619pfa.35.2017.03.07.20.29.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 20:29:22 -0800 (PST)
To: Barry Leiba <barryleiba@computer.org>, draft-ietf-anima-grasp.all@ietf.org
References: <CALaySJ+rLh9ZBmydm0bG+TBxGK_dB-UmnkeJusd1C-3zMowwHg@mail.gmail.com> <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com>
Date: Wed, 08 Mar 2017 17:29:21 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/LPVvHt7CO1BQFRuSlCGAuljx4Wc>
Cc: anima@ietf.org, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] 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: Wed, 08 Mar 2017 04:29:25 -0000

Well, I take that back. I think all these points can be slipped into
this week's update of the draft (I plan to submit that on Friday
NZ time).

Two points for the WG:

> 
> — Section 3.5.1 —
> 
>    If there is no ACP, the protocol MUST use another form of strong
>    authentication and SHOULD use a form of strong encryption.  See
>    Section 3.5.2.1 for further discussion.
> 
> Both here and in 3.5.2.1: Why is encryption SHOULD, and not MUST?
> Looking ahead to 3.5.2.1, how could it be considered safe to use a
> network configuration protocol across administrative boundaries
> without encryption?

Input please, or else you will see this as an open issue in Chicago.

Personal opinion: encryption should be a MUST.

On UTF-8:

> The other question is whether there are any restrictions on what
> Unicode characters can be represented.  You make the colon a special
> character but give no other restrictions, so an objective name could
> include space characters (and various related Unicode characters such
> as tab, EN SPACE, ZERO WIDTH SPACE, and ZERO WIDTH NON-JOINER),
> control characters (FORM FEED, CARRIAGE RETURN, and the like),

Once we specify byte-by-byte comparison, do we need to worry about
this in a protocol document? If someone is silly enough to
specify an objective called 'example.org:Недостаточно握 déjà	vu
' do we care, in the protocol design?

Personal opinion: we don't need to say anything.

Regards
   Brian

On 08/03/2017 16:44, Brian E Carpenter wrote:
> Thanks Barry. Good comments, but we have to get a new draft out
> before the deadline, so I'm not sure these will all make it in
> until the one after.
> 
> Regards
>    Brian
> 
> On 08/03/2017 15:43, Barry Leiba wrote:
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the
>> IESG.  These comments were written primarily for the benefit of the
>> security area directors.  Document editors and WG chairs should treat
>> these comments just like any other last call comments.
>>
>> First, I'm sorry this review is a few days late, and I hope that isn't
>> a problem.
>>
>> Second, the document is "ready with issues".  Most of the comments
>> below are minor, and editorial.  The three that are substantive are:
>>
>> 1. SHOULD vs MUST with respect to encryption in Sections 3.5.1 and 3.5.2.1.
>>
>> 2. The UTF-8 issues in Section 3.10.1.
>>
>> 3. Guidance for the Designated Expert in Section 7.
>>
>> These should all be easy to resolve.
>>
>> — Section 1 —
>>
>>    A reference model
>>    for autonomic networking on this basis is given in
>>    [I-D.ietf-anima-reference-model].  The reader should consult this
>>    document to understand how various autonomic components fit together.
>>
>> Even though that document is an informative reference, I find it odd
>> that the draft that helps us understand how this all fits together. .
>> . is an expired draft.  It makes me wonder how well baked things are.
>>
>> — Section 3.1 —
>>
>>    The following additional terms are used throughout this document:
>>
>>    o  Autonomic Device: identical to Autonomic Node.
>>
>> It’s not a big point, but: Why?  Why is it important or useful to
>> specifically define a *new* term in this document that has the same
>> meaning as a similar term that’s already defined?
>>
>> And, actually, now that I check, I see that “autonomic devices” is
>> used in exactly one place, in the Abstract.  I suggest changing the
>> term in the abstract to “autonomic nodes”, and removing this
>> definition.
>>
>> — Section 3.2 —
>>
>>    Because GRASP needs to work whatever happens, especially during
>>    bootstrapping and during fault conditions, it is essential that every
>>    implementation is as robust as possible.
>>
>> There seems to be a missing word, or some such; I can’t parse “GRASP
>> needs to work whatever happens”.  And picky grammatical nit:
>> subjunctive mood is needed with “essential”, so it should be “it is
>> essential that every implementation be as robust as possible.”
>>
>> — Section 3.3 —
>>
>>       GRASP
>>       provides mechanisms to guarantee convergence (or failure) in a
>>       small number of steps, i.e. a timeout and a maximum number of
>>       iterations.
>>
>> Another nit. This is an outstanding example of why I don’t like to use
>> “i.e.”: in this case, it leaves me wondering whether that’s really an
>> exhaustive list, or whether you meant “e.g.”.  And, to me, it reads
>> awkwardly anyway.  I suggest one of these alternatives (the sorts that
>> can pretty much always stand in for the overused and unnecessary
>> “i.e.”):
>>
>> NEW-1
>>       GRASP
>>       provides two mechanisms to guarantee convergence (or failure)
>>       in a small number of steps: a timeout and a maximum number of
>>       iterations.
>>
>> NEW-2
>>       GRASP
>>       provides a timeout and a maximum number of iterations,
>>       which together guarantee convergence (or failure) in a
>>       small number of steps.
>>
>> — Section 3.5.1 —
>>
>>    If there is no ACP, the protocol MUST use another form of strong
>>    authentication and SHOULD use a form of strong encryption.  See
>>    Section 3.5.2.1 for further discussion.
>>
>> Both here and in 3.5.2.1: Why is encryption SHOULD, and not MUST?
>> Looking ahead to 3.5.2.1, how could it be considered safe to use a
>> network configuration protocol across administrative boundaries
>> without encryption?
>>
>> — Section 3.5.2.2 —
>>
>>       A responder
>>       SHOULD NOT send a Discovery Response message unless it cannot be
>>       avoided.
>>
>> Any clue about why it might be possible that it “cannot be avoided”?
>>
>> — Section 3.5.2.3 —
>>
>>    o  Any type of GRASP message MAY be sent.
>>
>> This doesn’t feel like a “MAY” to me.  You’re not saying that there’s
>> a protocol choice here, and how to handle it is optional and up to the
>> implementation.  You’re saying that all types of GRASP messages are
>> permitted when you’re using a SONN instance.  So maybe, “All types of
>> GRASP messages are permitted.”
>>
>> — Section 3.10.1 —
>>
>>    All objectives are identified by a unique name which is a case-
>>    sensitive UTF-8 string.
>>
>> Actually, “case-sensitive” isn’t a sufficient descriptor for UTF-8, as
>> there are issues of canonicalization and normalization, and the fact
>> that languages differ in whether “case” makes sense at all.  This
>> would be a bigger issue if you wanted case insensitivity, but as it is
>> I think the fix is easy: you should just say that the name is a UTF-8
>> string that is compared byte by byte.  This will have the effect of
>> being case sensitive when that makes sense, and will also eliminate
>> the issues of canonicalization and normalization: different ways of
>> representing characters such as “ä” and “ô” and “é” will compare as
>> different, and as these are protocol elements and not user strings,
>> that should be fine.
>>
>> The other question is whether there are any restrictions on what
>> Unicode characters can be represented.  You make the colon a special
>> character but give no other restrictions, so an objective name could
>> include space characters (and various related Unicode characters such
>> as tab, EN SPACE, ZERO WIDTH SPACE, and ZERO WIDTH NON-JOINER),
>> control characters (FORM FEED, CARRIAGE RETURN, and the like),
>> characters from every character set and language including Cuneiform
>> and Egyptian Hieroglyphs, and even such iconic characters as MUSICAL
>> SYMBOL G CLEF, ONCOMING POLICE CAR, and the famous PILE OF POO.  If
>> that’s all OK, then that’s fine (and maybe it is, as, again, this is a
>> protocol element, not a user string).  I just want to make sure you
>> thought about it.
>>
>> — Section 7 —
>>
>> The creation of the Specification Required registry for the Objective
>> Names Table needs to specify guidance for the Designated Expert (see
>> draft-leiba-cotton-iana-5226bis, Sections 4.6 and 4.5).  It doesn’t
>> have to be a lot, but it needs to be clear for future DEs who might
>> not have been involved with developing this document what they need to
>> consider as they review registration requests.  Why might they push
>> back on a registration request?  Should they, for example, allow
>> registration requests for two different Objective Names of “frobozz”
>> and “Frobozz”?  What sort of documentation is sufficient for a
>> registration (is “enough that you think implementations can be written
>> from it” good enough, or are there specific things that the
>> documentation ought to contain)?
>>
>