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

Thomas Clausen <thomas@thomasclausen.org> Mon, 28 July 2014 16:06 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 D9DA01A0367 for <manet@ietfa.amsl.com>; Mon, 28 Jul 2014 09:06:01 -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 VYkuq6bEwc_D for <manet@ietfa.amsl.com>; Mon, 28 Jul 2014 09:05:57 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC791A0362 for <manet@ietf.org>; Mon, 28 Jul 2014 09:05:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D162D2406B2; Mon, 28 Jul 2014 09:05:43 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at maila2.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 maila2.tigertech.net (Postfix) with ESMTPSA id 1185A2401A9; Mon, 28 Jul 2014 09:05:39 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_C1D89541-B8DD-4108-AB75-709A4A6E73E0"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Thomas Clausen <thomas@thomasclausen.org>
In-Reply-To: <B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1A664@GLKXM0002V.GREENLNK.net>
Date: Mon, 28 Jul 2014 18:05:37 +0200
Message-Id: <8D2A87A9-3296-4E44-B78C-BC5FB9E7F416@thomasclausen.org>
References: <BC5A3929-229B-4678-AFC1-8379D95D3618@thomasclausen.org> <5BAD70D6-1E6E-4CF5-803B-54CF3B7BD4E5@thomasclausen.org> <B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1A664@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/GnmlRnR3j8c7_kotwU9t0bpLytU
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: Mon, 28 Jul 2014 16:06:02 -0000

Chrism

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

> Thanks Thomas for this. I’m just going to pick up one point for this email (not meaning that I’m disregarding the other points).
>  

Sure thing - I was actually thinking about factoring this out in a separate email as it is of more general interest, then decided against it.

>             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 ;)
>  
> Unfortunately, no I don’t, though I must admit to not trying to look hard. The last interested academic that I spoke to on this matter was interested in our results, rather than providing any results himself.

Alright, I’ll try to ask around my local crypto wonks — it’d be good if everybody on the list would do the same.

Thomas

>  
> We have experimental results that I’m reasonably sure show faster signatures and verifications than other forms of IBS we have implemented (at least two others at various times). That’s in large part because ECCSI does not use pairings (see the companion RFC 6508 for an algorithm that does) and the expensive operations (both by repute and in our experience) are pairings and exponentiations of elements in the codomain of the pairing. However I don’t have a set of crystal clear results comparing the signature only with nothing else changed. In principle we could do this, but for various reasons that would take longer than I have time to spare. (They weren’t all created for the same purpose.) Any results would also be dependent on the choice of crypto library, and even decisions made within the library. For example I’ve had a significant factor speedup using a different option within a library in one case.
>  
> So, in short, that paragraph is about what I think I can say without stepping where I couldn’t back up comments. I’d like to strengthen it, but I think that’s where I can go.
>  
> Anyone who has a reference (and I will look a bit further) please let me know. Non-paywalled references in strong preference.
>  
> --
> 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: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Clausen
> Sent: 28 July 2014 15:38
> To: manet; <manet-chairs@tools.ietf.org>; manet-ads
> Cc: Christopher Dearlove
> Subject: Re: [manet] 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.
> 
>  
> 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
>  
> ********************************************************************
> 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