Hi Rob/ George, I had raised issues about SIDR and we had a long healthy discussion on it in February on the SIDR as well as the OPSEC lists.
I had written a draft too but I guess it did not get promoted enough. Do have a look at : www.archivum.info/[EMAIL PROTECTED]/2008-02/msg00035.html and let me know what you think about the ideas of the draft. Thanks, Vishwas On 10/7/08, George Michaelson <[EMAIL PROTECTED]> wrote: > clearly, I am not Geoff. > > But in any case, I don't understand why you only analyze the costs of > this test in the context of complete chain-validation tests, > validating signed objects. > > Why can you not test signed objects and the EE certificates against a > *pre-validated* information structure for the hierarchy, and so only > have to test the EE cert, and object validation at one level, instead > of completely to the root? > > what am I mis-understanding about end-sign validation? > > I don't believe at this time that any multi-sign outcomes would exist > except at the edge: end-entity objects. > > so I don't see why an entire tree-validation is needed, if you have a > pre-validated repository of known good certificate chains. The end- > entity certs, the signed objects, surely the validation is far simpler > than you imply? > > On 07/10/2008, at 12:23 PM, Rob Austein wrote: > >> I look forward to reading your code, Geoff. >> >> The process of retrieving and checking an RPKI tree is already a >> fairly complex recursive tree walk with many fiddly checks that have >> to be done in the right order to avoid various attack scenarios. The >> last thing this traversal algorithm needs is a gratuitous requirement >> that at each ROA it finds it must be prepared to go haring off after >> an arbitrarily large number of new certificate chains in different >> parts of the tree on a pointless quest to solve a non-problem. >> >> Do you have ANY evidence whatsoever for compelling real world cases? > > post rundown, the likelihood that resources do not compress simply to > single certificate chains seems to me a likely scenario. ie, people > will be holding large sets of dis-aggregated resources, and need to > assert route validation over them effectively. > > if they do this as a set of disjoint end objects you move validation > costs to a simpler process per object, that then has to be > (re)combined to make the real information you need. > > If we can find a way to make multi-sign work, there could be > significantly less objects in play, in the system as a whole. > > Rob, I don't mean to be dis-respectful, but I find the vehemance "this > can't work: its too expensive" over-stated. I don't buy it. I think > you're at risk of entrenching a view that is as equally shakey as my > belief multi-sign may turn out to be needed. > >> >> Don't talk theory. Show me a real case where this would matter. > > Its hard for anyone to do that in a world where no routing security > exists. But I am tempted to observe that in the WG discussions we > seemed to be confident the *intended* security model in respect of IRR > demanded more than one participant sign information to validate the > relationship between AS in routing, and prefix being routed. (I do not > mean ROA here, I am talking about things beyond the ROA. So I have > moved the agenda sideways) > > I know that others believe this is irrelevant, but I still see it > documented in the RFCs and in the actual code which implements checks > on who authorizes updates in WHOIS.. > > cheers > > -George > >> >> _______________________________________________ >> sidr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
