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

From: "Stephen Farrell" <[email-masked]>
Date: Mon, 18 Jan 2016 08:00:05 -0800

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?