Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols
RFC 7859

I support Stephen's DISCUSS comments.

Thanks for adding the text about public analysis being needed as part
of the experiment. I've cleared my DISCUSS on that basis.

I do think the text you've used in -05 could be improved still though,
you say that "it is intended" to promote this to the standards track,
but, while that is of course a good intention for the authors, I do not
think that the IETF can be said to have that intention - whether or
not that'll happen will depend on the experiment surely and the IETF
is not making promises about that. So I'd prefer if you had said "it
may be appropriate" instead, as suggested below. But I'm fine with
letting whoever is the sponsoring AD handle that as it'd not be 
reasonable to block an experimental RFC on just that basis.

I'm also moving to an ABSTAIN on this, as I'm not convinced that 
IBE is at all valuable here, given it's IMO fatal flaws in terms of
inherent key escrow. That is also not a DISCUSS as a) that's my
personal opinion and we don't have an IETF consensus against
IBE for that reason, and b) this is experimental so even if we did
have such a consensus, I'd bet it'd be limited to standards track
specifications. If you do intend for this to end up on the standards
track, then I'd suggest you also try to establish some IETF 
consensus for when it is appropriate (if ever) for an IETF 
standards-track specification to incorporate inherent key escrow.
(But, I would imagine establishing such a consensus would be
hard, if it's even possible.)

--- OLD DISCUSS BELOW

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.

-- OLD COMMENTS BELOW

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?