-----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 2. RFC 4270 3. long back even OSPF, ISIS etc.. moved away from MD5 4. ... For that matter SHA1 is getting deprecated http://securitymusings.com/article/1587/algorithm-and-key-length-deprecation 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
