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

Thomas Clausen <thomas@thomasclausen.org> Wed, 30 July 2014 14:22 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 A1CDC1A0039 for <manet@ietfa.amsl.com>; Wed, 30 Jul 2014 07:22:29 -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 7PhbBaDZLbyU for <manet@ietfa.amsl.com>; Wed, 30 Jul 2014 07:22:24 -0700 (PDT)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9151A004E for <manet@ietf.org>; Wed, 30 Jul 2014 07:22:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 5EB891BDA0D2; Wed, 30 Jul 2014 07:22:23 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c2.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 mailc2.tigertech.net (Postfix) with ESMTPSA id 634791BDA0CB; Wed, 30 Jul 2014 07:22:17 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E440EFF7-46AD-49D5-9DBD-2C1B8A8F279F"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Thomas Clausen <thomas@thomasclausen.org>
In-Reply-To: <B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B83F@GLKXM0002V.GREENLNK.net>
Date: Wed, 30 Jul 2014 16:22:15 +0200
Message-Id: <E358949C-607D-4DC6-82E8-D7F7CAE6EC7D@thomasclausen.org>
References: <BC5A3929-229B-4678-AFC1-8379D95D3618@thomasclausen.org> <B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B83F@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/IO0spwwVYI1_xygXYSfoIZsm_aw
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:22:30 -0000

Chris,

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

> (Apologies for the previous accidental empty send.)
>  
> I’ll pick up a separate point this time, namely
>  
>                         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
>  
> 7182 contains both symmetric and asymmetric ciphers, on the one hand DSA, HMAC, 3DES, AES, on the other hand RSA, ECDSA.
>  
> How the keys are organised is not discussed in 7182, it is rather implicit. In the symmetric case we need to share keys, this
> Could be as simple as a single shared key, but as exemplified by 7183 (which uses one of the symmetric cases) this could
> Be multiple keys. In the asymmetric case we have pairwise keys, pre-distributed or with public keys certified, and a PKI
> On top of that. So 7182 implicitly (but not explicitly) offers us these three options (shared keys, pre-shared pairwise keys,
> PKI – and the overhead of certificates).
>  
> As this document is about 7182, not 7183 (which is NHDP/OLSRv2 only) I’d rather stick to just referencing and discussing 7182,
> But a wording tweak may be in order.
>  

Alright, so I see that there’re two things that can happen: reference 7183, and keep the text unchanged — or word-tweak so that the citation to 7182 can remain. Either can work for me, seems you prefer the latter, so I am looking forward to seeing an update.

Thomas


> --
> Christopher Dearlove
> Senior Principal Engineer, Information Assurance Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
> 
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>  
> 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
>  
>  
> *** WARNING ***
> This message originates from outside our organisation, either from an external partner or the internet.
> Consider carefully whether you should click on any links, open any attachments or reply.
> For information regarding Red Flags that you can look out for in emails you receive, clickhere.
> If you feel the email is suspicious, please follow this process.
> 
> 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. 
>  
> 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
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet