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

[Stephen Farrell <[e-mail]>]

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 <[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
>>>
>>