Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs

Thomas Clausen <thomas@thomasclausen.org> Mon, 28 July 2014 14:37 UTC

Return-Path: <thomas@thomasclausen.org>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D0B1A0385 for <manet@ietfa.amsl.com>; Mon, 28 Jul 2014 07:37:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 WM-mgb7OPSEh for <manet@ietfa.amsl.com>; Mon, 28 Jul 2014 07:37:43 -0700 (PDT)
Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3598A1A0252 for <manet@ietf.org>; Mon, 28 Jul 2014 07:37:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id EB4DBD548F9; Mon, 28 Jul 2014 07:37:42 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net
Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id BB2B2D54AE5; Mon, 28 Jul 2014 07:37:39 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7BF11797-648E-4E3B-BCBC-920B5AF3DFA6"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Thomas Clausen <thomas@thomasclausen.org>
In-Reply-To: <BC5A3929-229B-4678-AFC1-8379D95D3618@thomasclausen.org>
Date: Mon, 28 Jul 2014 16:37:36 +0200
Message-Id: <5BAD70D6-1E6E-4CF5-803B-54CF3B7BD4E5@thomasclausen.org>
References: <BC5A3929-229B-4678-AFC1-8379D95D3618@thomasclausen.org>
To: manet <manet@ietf.org>, "<manet-chairs@tools.ietf.org>" <manet-chairs@tools.ietf.org>, manet-ads <manet-ads@tools.ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2ri4drUoWc4dqhpKrk5P-0wN58c
Cc: Christopher Dearlove <dearlove@manet-routing.net>
Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Jul 2014 14:37:49 -0000

On Jul 28, 2014, at 15:19, Thomas Clausen <thomas@thomasclausen.org> wrote:

> Dear WG Chairs, 
> Dear Chris, all,
> 
> As the author indicated by email recently, he believes that draft-ietf-manet-olsrv2-management-snapshot is ready for WGLC. 
> 

And, Ulrich just pointed out to me in private that the above should be "draft-ietf-manet-ibs”, of course — I thought I was being clever using email templates, and all. Apologies, and thank you Ulrich for catching my screwup.

Thomas

> As a reminder, this document aims for publication as a Proposed Standard.
> 
> I have, therefore, reviewed the document carefully. In my opinion, the author is right — in my opinion this document is ready for WGLC.
> 
> Moreover, I believe that it is a highly important document for the WG to produce, as it fills a real need, and does so by relying on already-published crypto RFCs, rather than by coming up with something esoteric.
> 
> I have two issues, and handful nits, that I expect the author will consider along with any other WGLC comments they may receive. Of course, if a new version is spun before WGLC is requested, then I’ll gladly review that, also. Point being: let’s get a call started on this document, none of my nits and issues are of the sort that should be blocking.
> 
> One of the issues is “need a non-jetlagged ADs advice to be sure we do the right thing”, the other is — I think — a minor mix-up with a trivial editorial resolution and zero technical impact on this specification.
> 
> Either way, for information, I include all issues and nits that I’ve found in the below.
> 
> Issues:
> 
> 	o	In my opinion, “Updates 7182” is inappropriate. What this document does is:
> 			(i) 	only things permissible by RFC7182, and 
> 			(ii) 	makes registration from IANA registries set up by RFC7182
> 				(noting, of course, that RFC7181 doesn’t “Updates 5444” 
> 			 	 when making registrations for TC messages from the repositories 
> 				 set up by RFC5444 as a case of precedent)
> 		Consequently, I believe that the abstract, introduction, and document 
> 		header, needs updates to reflect that this is not an update.
> 		
> 		Caveat Lector: I have bounced this around with the author, and I 
> 				think that the conclusion is that we need just a friendly 
> 				ADs opinion — my understanding is that the author
> 				“wants this out, but wants it done right, also”, something
> 				to which I can but adhere.
> 		
> 				I believe that we should WGLC the document. If the AD
> 				finds the time to address this issue during WGLC, great -
> 				otherwise, we can reflect this in the “Document Writeup”
> 				that the AD will consider with the publication request — as
> 				this (imo) is procedural/editorial, and certainly not technical.
> 
> 	o	Introduction, 4th paragraph:
> 
> 		Isn’t it RFC7183 which does shared-secret-key ICVs? I just did a quick
> 		grep through of “shared” in 7182, and found just a few mentions, notably
> 		setting a side a value for key-id-length in that case. And “secret” is not
> 		mentioned anywhere in 7182
> 
> 
> Nits:
> 	o	Introduction, 1st paragraph:
> 		OLD:
> 			This specification extends the TLV definitions
> 			therein by defining two new cryptographic function code points that
> 			allow the use of an identity-based signature (IBS) as an ICV.
> 
> 		NEW:
> 			This specification defines two new cryptographic function 
> 			code points from within the registries set up by [RFC7182], 
> 			that allow the use of an identity-based signature (IBS) as an ICV.
> 
> 	o	Introduction, 2nd paragraph, 1st line:
> 		I took a double-take when I saw the parenthesis 
> 		“(protocol participant)” — that seems a little odd, and I am on a crusade
> 		against redundant and hard-to-parse terminology ;)
> 
> 		I think that what is meant is “router, which is running a routing 
> 		protocol which is based on RFC5444”, so could the document not say
> 		that?
> 
> 		In any event, I do not see “protocol participant” defined or anywhere else,
> 		and so it seems unfortunate to *not* be explicit here.
> 
> 	o	Introduction, 3rd paragraph:
> 
> 		OLD:
> 			Two options for the choice of identity are supported (the two code
> 			points allocated).
> 
> 		NEW:
> 			Two options for the choice of identity are supported (as reflected
> 			by the two code points allocated).
> 
> 
> 	o	Introduction, 7th paragraph:
> 		Caveating that using this introduces the danger that “if you catch the 
> 		trusted authority, then you’re screwed” is awesome. I see that 
> 		this is repeated and reworded in the Security Considerations section,
> 		and I approve. 
> 
> 		Now, my question is then, if this should not be stated in the Applicability 
> 		statement, also? Something to the effect of that this applies to networks
> 		where all routers can (at some point) be in contact with the TA (to be
> 		keyed), but that this can be off-line — and probably should be off-line
> 		since the TA really, really should be protected.
> 
> 		It might be argued that the forward-reference to Section 6 captures
> 		this — I still think, that a few choice words in the applicability statement
> 		would help greatly.
> 
> 	o	Introduction, 9th paragraph:
> 		Any [academic? otherwise] work that you can cite to quantify the 
> 		computational load? I asked a crypto-wonk-colleague, who said
> 		something to the effect of “the document is perfectly right, on this
> 		point, but I do not have a paper just off the top of my head with 
> 		interesting data to offer”. For that reason alone, it’d be interesting 
> 		if you did ;)
> 
> 	o	Throw-away comment, I appreciate particularly the last
> 		paragraph of the introduction.
> 
> 	o	Section 4.1, first bullet
> 
> 		OLD:
> 		   o  The ICV is not calculated as cryptographic-function(hash-
> 		       function(content)) as defined in [RFC7182], but (like the HMAC
> 		       ICVs defined there) uses the hash function within the
> 		       cryptographic function.  The option "none" is not permitted for
> 		       hash-function, and the hash function must have a known fixed
> 		       length of N octets, as specified in Section 4.2.
> 
> 		NEW:
> 		   o  The ICV is not calculated as cryptographic-function(hash-
> 		       function(content)) as defined in [RFC7182], but (like the HMAC
> 		       ICVs defined in [RFC7182]) uses the hash function within the
> 		       cryptographic function.  The option "none" is not permitted for
> 		       hash-function, and the hash function must have a known fixed
> 		       length of N octets, as specified in Section 4.2.
> 
> 	o	While we are at it, it it crystal-clear to everybody that “Section 4.2” in
> 		the bullet above is to *this* document, as not RFC7182?
> 
> 	o	Section 4.3, 2nd bullet
> 		There’s a LOT of information embedded in this bullet, and reading it
> 		suggests that it, readability-wise, might benefit from embedding a:
> 			<list style=“hanging”>
> 				<t hangText=“Packet TLVs”>…</t>
> 				<t hangText=“Message TLVs”>…</t>
> 				<t hangText=“Address Block TLVs”>…</t>
> 			</list>
> 
> 	o	IANA Considerations:
> 
> 		Given recent experiences in this WG and with requesting IANA 
> 		registrations, may I suggest that this be modified to say, more
> 		explicitly:
> 
> 			1)	IANA is requested to reserve ECCSI with description ___ 
> 				and reference “This Specification”
> 
> 			2)	IANA is requested to reserve ECCSI-ADDR…. (similar)
> 
> 			3)	The “Cryptographic Functions Registry”, defined in 
> 				[RFC7182], with these registrations made, will look
> 				like Table 1, which replaces Table 11 of [RFC7182]
> 
> 			4)	Obviously, include in Table 1 the registrations from
> 				RFC7182.
> 
> 			5)	That this document does not modify the expert
> 				review guidelines as set forth in RFC7182 for
> 				future allocations.
> 
> That’s all. Thanks for writing this document, Chris.	
> 
> 
> Respectfully,
> 
> Thomas
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet