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

Thomas Clausen <thomas@thomasclausen.org> Wed, 30 July 2014 14:32 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 962451A00A7 for <manet@ietfa.amsl.com>; Wed, 30 Jul 2014 07:32:43 -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 uCVKg1crQFA2 for <manet@ietfa.amsl.com>; Wed, 30 Jul 2014 07:32:38 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF751A0039 for <manet@ietf.org>; Wed, 30 Jul 2014 07:32:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B56361D8B2C; Wed, 30 Jul 2014 07:32:37 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.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 mailb2.tigertech.net (Postfix) with ESMTPSA id 7058F1C023A; Wed, 30 Jul 2014 07:32:31 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CF125B43-65EB-40CA-9001-37D43A3ABEB0"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Thomas Clausen <thomas@thomasclausen.org>
In-Reply-To: <B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B881@GLKXM0002V.GREENLNK.net>
Date: Wed, 30 Jul 2014 16:32:28 +0200
Message-Id: <DA557FF2-340E-4DC3-B8C7-D0D2F22B8876@thomasclausen.org>
References: <BC5A3929-229B-4678-AFC1-8379D95D3618@thomasclausen.org> <B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B881@GLKXM0002V.GREENLNK.net>
To: Christopher Dearlove <chris.dearlove@baesystems.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/to-y6lDnuQ7SiLmR5peETvUX7UI
Cc: "<manet-chairs@tools.ietf.org>" <manet-chairs@tools.ietf.org>, manet-ads <manet-ads@tools.ietf.org>, manet <manet@ietf.org>, 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: Wed, 30 Jul 2014 14:32:43 -0000

Chris,


On Jul 29, 2014, at 17:16, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

> Some additional comments inline. I plan to put out a new version shortly, but technically all will be unchanged.

Comments below, but yes, what I suggest are in the “nits” category, which is why I would have been happy to see the current version WGLCed. If you have a new version that addresses my nits, then the WGLC will be even easier for me, though....

Below (snipping out the parts where we agree and stuff).
> 
> From: Thomas Clausen [mailto:thomas@thomasclausen.org] 
> Sent: 28 July 2014 14:19
> To: manet; <manet-chairs@tools.ietf.org>; manet-ads
> Cc: Christopher Dearlove
> Subject: Ready for WGLC: Advancing draft-ietf-manet-ibs
> 

<SNIP>

> I have, therefore, reviewed the document carefully. In my opinion, the author is right —in my opinion this document is ready for WGLC.

<SNIP>

> 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.
>  
> CMD: On the grounds that the biggest wasted effort is taking out, and then maybe putting back in, I’m going to leave as-is until our AD comments. But I’d have done the same if it were the other way round, I’m happy whichever way this is settled. 

I’m entirely aligned with you on this point. If we do not get an ADs input before, we just need to make sure that this will be included in the document write-up and dealt with then.


>             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
>  
> CMD: I made an earlier post on this. I think that some improvements in wording in the Introduction are indicated.
>  

Acknowledged, and that’s quite satisfactory.

>  
> 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.
>  
> CMD: I want to keep some of what’s lost by that edit, so will propose a third wording.

Looking forward to seeing that.

>  
>             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.
>  
> CMD: Simply removing the parenthesis removes the intended point, which was to say that the
> description assumes that the entities involved are routers – which isn’t actually the only possibility
> using 5444. I’ll propose something that borrows from the above to improve it.

OK, looking forward to seeing that, too.

<SNIP>

>  
>             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.
>  
> CMD: I prefer to stick with the forward reference, as I think by the time you’ve said enough, you’ve duplicated half of Section 6. But adding some words to say particularly regarding the role of the TA/KMS makes sense.

I think that we are aligned, that that’s what the last sentence in my comment seeks to capture. So, I look forward to seeing your proposal to this, too.

>  
>             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 ;)
>  
> CMD: See previous comments. Trying Google Scholar with ECCSI elliptic curve gets a very small number of hits, none useful here.

I’ve asked around, but I am not hopeful. Will let you know if I get something citable — most I spoke to said “this aligns with my intuition/experience/*” though.

<SNIP>

>                         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.
>  
> CMD: I could live with either, but will make the change.

I think it makes it clearer, so thank you for that.

>  
>             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?
>  
> CMD: I’m going to assume it is. I would always write Section X.Y of [Z] (or similar) if making an external reference.

OK, this was a throw-away comment, not important
 
>             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>
>  
> CMD: I’m including to be slightly less radical (and I’m not a fan on hanging text). But I will create another level.

Thank you, that will work nicely.

>  
>             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.
>  
> CMD: I think this comes under the heading of hand-holding IANA more than I would feel ought to be necessary. Except sometimes it has been. But this is a straightforward case, so while I agree that making it more explicit that this is a request for two new code points, I’m not going to repeat the full table from 7182 unless IANA really show they need hand-holding. Our previous cases where we had to repeat a whole table were a bit messier. But giving the exact name for the table as on IANA’s website is advisable.
>  

True, but…there’s perhaps something to be said for “the table being as complete as possible” for the reader, also? Well, your call, of course.

Once a new version hits the servers, I’ll let you know if I see any pending nits.

Cheers,

Thomas