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)? >> >
- [secdir] SecDir review of draft-ietf-anima-grasp-… Barry Leiba
- Re: [secdir] SecDir review of draft-ietf-anima-gr… Brian E Carpenter
- Re: [secdir] SecDir review of draft-ietf-anima-gr… Brian E Carpenter
- Re: [secdir] SecDir review of draft-ietf-anima-gr… Barry Leiba
- Re: [secdir] [Anima] SecDir review of draft-ietf-… Michael Richardson
- Re: [secdir] [Anima] SecDir review of draft-ietf-… Barry Leiba
- Re: [secdir] [Anima] SecDir review of draft-ietf-… Brian E Carpenter
- Re: [secdir] [Anima] SecDir review of draft-ietf-… Barry Leiba
- Re: [secdir] [Anima] SecDir review of draft-ietf-… Michael Richardson
- Re: [secdir] [Anima] SecDir review of draft-ietf-… Barry Leiba