Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-04: (with DISCUSS and COMMENT)

["Dearlove, Christopher (UK)" <[e-mail]>]

Sorry about delay, I had someone to either square or leave long enough to fail to square. A -05 has been submitted.

Hoping this meets the DISCUSS issue. With regard to the comment on 4.1, there already was a not quite complete specification in 4.3, I've now cross-referenced and fleshed out that specification as a recommendation.

-- 
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  [phone]  |  E: [e-mail]

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

-----Original Message-----
From: Stephen Farrell [mailto:[e-mail]] 
Sent: 18 January 2016 16:00
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Stephen Farrell's Discuss on draft-ietf-manet-ibs-04: (with DISCUSS and COMMENT)

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

Stephen Farrell has entered the following ballot position for
draft-ietf-manet-ibs-04: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-manet-ibs/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


My main discuss point on -02 of this was:

(1) I am concerned that RFC6507 may not be ready for use in standards-track RFCs. So far it has not been and I have found no peer reviewed security or cryptographic analysis that indicates that it is has been studied to see if it is good enough for that. I've also not seen any MANET list discussion of that aspect (and indeed the MANET list discussion I did see seems to involve very few people).  I asked on the CFRG list about RFC6507 and it seems [1] to be the case that no-one has so far really evaluated its security, other than folks associated with the author's institution. (Which applies to both 6507 and this I think.) I also didn't find any references to 6507 in Google scholar.  Lastly, I think we should be, and be seen to be, more careful than usual with this draft - given the situation with DUAL-EC-DRBG, and that this is a new signature scheme that allows the KMS to fake anyone's signature and the author involved.  Note that that last is not any imputation of misbehaviour, but the IETF would not be  doing due-dilligence if we didn't explicitly consider that aspect.

  [1] https://www.ietf.org/mail-archive/web/cfrg/current/msg05540.html

The authors have added section 6.1 and changed the intended status to experimental which does almost entirely resolve the above. I have one issue with the text of 6.1 though that I think needs fixing before we can proceed. I'll state that in the form of an OLD/NEW suggestion in case that just works:

OLD:
	   This specification is thus published as experimental, in order to	
 	   encourage its use and reports of its use.  Once experiments have
been	
 	   carried out and reported, it is intended to advance this	
 	   specification, with any changes identified by such
experimentation,	
 	   to standards track.

NEW:
	   This specification is thus published as experimental, in order to	
 	   encourage its use and reports on its use.  Once experiments have
been	
 	   carried out and reported, and when some public analysis of the underlying 
           cryptographic algorithms is available, it may be appropriate 
to advance this	
 	   specification, with any changes identified by such experimentation and
           analysis, to standards track.

My reasoning is as follows: the main problem (I see) with this being on the standards track is the total lack of public analysis of the signature

algorithm. That is not fixed via usage or reports of usage.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


The text below were additional discuss points. 

While I'm ok with these not being specified in an experimental RFC, I think the absence of those bits of specification means that this is clearly not a complete spec that'd allow interop. 
(So that would need to be fixed before trying to get this back on the standards track.) The text does now at least ack that the revocation trick or some equivalent is needed, but fails to specify a concrete way of doing that. And while the authors don't agree with me that private key provisioning needs to be specified in an interoperable manner, I think that if one was to produce any IBC standard that has to be a part of the work, otherwise nodes are limited to working with a KMS in a proprietary fashion, which is a kind of vendor lockin.

The old discuss points are below. I think this would be better if these issues were also called out in section
6.1 but I'll not block on that basis. Perhaps the responsible AD might think about whether that really needs to be mentioned or not.

(2) How does a router get its private key? Why is it ok to not specify that? Seems like an interop fail if that is not done.

(4) 4.1: The usual revocation trick of including a time value in the name is referred to at the end of this section but without sufficient detail to allow interop. Why is that ok?


********************************************************************
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.
********************************************************************