Hi all, Trying to catch up with you all here.
>From reading the mail thread it seems to me that: - tcp-md5 is available but undesirable - tcp-ao is desirable but unavailable so far - ssh is available and slightly undesirable for performance reasons but desirable in security terms That would imply that an answer might be: MUST implement SSH; SHOULD implement TCP-AO and MUST/SHOULD prefer TCP-AO over SSH if both available Would that garner (rough) consensus? We really do want to deprecate tcp-md5. Cheers, Stephen. On 04/06/11 03:26, Christopher Morrow wrote: > On Fri, Jun 3, 2011 at 10:15 PM, Uma Chunduri <[email protected]> > wrote: >> >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On >> Behalf Of Christopher Morrow >> Sent: Friday, June 03, 2011 6:11 PM >> To: Uma Chunduri >> Cc: Sandra Murphy; [email protected]; [email protected] >> Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? >> >> On Fri, Jun 3, 2011 at 5:28 PM, Uma Chunduri <[email protected]> >> wrote: >>> >>> >>> -----Original Message----- >>> From: Sandra Murphy [mailto:[email protected]] >>> Sent: Friday, June 03, 2011 1:43 PM >>> To: Uma Chunduri >>> Cc: [email protected]; Sean Turner; [email protected] >>> Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? >>> >>> >>> On Fri, 3 Jun 2011, Uma Chunduri wrote: >>> >>>> >>>> >>> .... >>> >>>> >>>> True, privacy through SSH is overkill but strong AUTH is *critical*, I >>>> feel: >>>> - TCP-MD5 should not be considered (as it is any ways deprecated >>>> and it's MD5) >>>> - TCP-AO has only slight advantage as it has less overhead than >>>> ipsec-AH even when >>>> deployed with manual keys >>>> - but it's better if it is "MUST support authentication of nodes >>>> with TCP-AO or ipsec-AH" because >>> >>> Just to be sure: >>> >>> Did you understand the part about implementations of TCP-AO and ipsec-AH >>> not being available at present? >>> >>> I.e., you recognize this forces a delay in implementation of the protocol >>> (and accept the consequent impact on deployment of the RPKI)? >>> >>> [Uma] Yes, I did. Even though operators don't like ipsec-AH today, it >>> is still deployed for OSPFv3 protection as that (of course now there are >>> other drafts to mitigate complexity with reasonable trade-off). >>> >> >> So, speaking as just another guy on the bus here... it's not about 'dont >> like it' it's about "THE CODE ON THE ROUTER DOES NOT DO IPSEC" >> >> Keep in mind that a router is not a generic CPU + intel ethernet PCI card, >> and often the OS on it is optomized for a particular duty, in large iron >> routers it's NOT ipsec. >> >>> Problem with MD5 is, it can present the *weakest* link for the whole RPKI >>> infa. >>> At least new infrastructure like RPKI should avoid deprecated stuff. >> >> exactly how is MD5 the weakest link here? some particular words about the >> threat model + ability to subvert a running session which ships a few >> megabytes/minute around would be in order here. >> >> [Uma] >> >> 1. Wang, X., H. Yu, "How to break MD5 and other hash >> functions", Proc. IACR Eurocrypt 2005, Denmark > > depends on creating 2 items to hash I believe? shows that if you do > the right thing for 2 very large items you create you can get a > collision in some instances. not picking random bits off the wire, not > relevant, move on. > >> 2. RFC 4270 > > talks about the above, not relevant. > >> >> 3. long back even OSPF, ISIS etc.. moved away from MD5 > > fear, uncertainty, doubt. > > we aren't talking about a permanent use of md5, we're talking about: > Use something that provides authentication/assurance NOW so we can > move forward, knowing full well we'll change to the better/required > solution when it's available in the right places. > > There's not a single AO implementation available today... it's DOA > until there is. (frankly it's kind of a failure that there aren't > widely deployed implementations of this... given all the time to > invent it and all) > >> 4. ... >> >> For that matter SHA1 is getting deprecated >> http://securitymusings.com/article/1587/algorithm-and-key-length-deprecation >> > > again, not relevant. > > please find something relevant that's not just fear mongering. Or, > alternately, find implementations of AO in the servers and routers > that matter. (if there are AO implementations w00t! we all win, until > then we spin) > > -chris > <regular guy socks==on> > >> >> Getting public keys from a server with a deprecated auth mechanism to >> verify RSA signature? >> it's obscure..and not sure why it's not considered weak. >> Well, one can still use and design systems around this if this is still seen >> adequate. >> >> -Uma >> >> >> >> >> -chris >> <just a guy> >> >>> -Uma >>> >>> >>> --Sandy, speaking as wg co-chair >>> >>> >>>> as both support >>>> - strong auth algos >>>> - algo agility >>>> - can be deployed with manual and auto key management >>>> (auto key probably required eventually, once with lot of >>>> connections at >>>> cache/global RPKI/server side and for automatic key >>>> changes periodically) >>>> - key changes for existing sessions >>>> >>>> One would get flexibility with this. >>>> Also Section 7 (page 16) >>>> "It is assumed that the router and cache have exchanged keys out of >>>> band by some reasonably secured means" >>>> This will be still applicable but only if TCP-AO/ipsce-AH are deployed >>>> with manual keys. >>>> >>>> 2 cents, >>>> -Uma >>>> >>>> >>>> _______________________________________________ >>>> 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
