Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

[Christopher Morrow <[e-mail]>]

On Fri, Jun 3, 2011 at 10:15 PM, Uma Chunduri <[e-mail]> wrote:
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Christopher Morrow
> Sent: Friday, June 03, 2011 6:11 PM
> To: Uma Chunduri
> Cc: Sandra Murphy; [e-mail]; [e-mail]
> Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?
>
> On Fri, Jun 3, 2011 at 5:28 PM, Uma Chunduri <[e-mail]> wrote:
>>
>>
>> -----Original Message-----
>> From: Sandra Murphy [mailto:[e-mail]]
>> Sent: Friday, June 03, 2011 1:43 PM
>> To: Uma Chunduri
>> Cc: [e-mail]; Sean Turner; [e-mail]
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sidr
>>>
>> _______________________________________________
>> sidr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidr
>>
>