Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys)

[Christopher Morrow <[e-mail]>]

On Mon, May 14, 2012 at 11:18 AM, [e-mail]
<[e-mail]> wrote:
> Hardware cryptoprocessors raise the issue of export licenses. They are
> also expensive. There will have to be software alternatives.

the vendors who've been involved so far didn't mention
export-problems, but that's a fair thing to keep in mind. The cost is
also interesting, but on the other side of a 200k USD device, is the
coprocessor (if needed at all, and if ONLY used for this function) a
show stopper at 100 USD/item? (at 1000? what is an average cost
Sriram?)

> If we want widespread adoption, there must be an option to "just turn
> it on" without having to shell out a load of extra money and fill a
> lot of forms.

sure.

> Security usability means more than just a zero-marginal-cost software
> implementation. It means easy setup of keys and certificates, and
> probably the option of running in "advisory more" where verification
> failures raise error messages but do not cause routes to fail. That

I think in no case will the validation just drop a route, or the plan
so far has simply been adding an ability to mark an update with some
key (community, localpref, etc) and use that in determining what to do
with the route. If you can match on validity state you COULD simply
DROP the route, but I don't think that'll be the end state for a very,
very long time.

> will enable ASes to try, watch, and gain the confidence to turn it on.
>
> Who's looking at security usability?

smb? would you like to help? :)
^^^ - probably others as well, but he's been a voice so far, as has mr turner.

-chris

> Ross
>
>
> On 14/05/2012, Christopher Morrow <[e-mail]> wrote:
>> On Mon, May 14, 2012 at 10:27 AM, Brian Dickson
>> <[e-mail]> wrote:
>>> We can't do the crypto without HW on some of the routers involved in
>>> deployment of bgpsec.
>>>
>>> I've heard just about everyone say that, quite possibly including
>>> yourself.
>>
>> I don't think I've said that recently, one of the items brought out
>> during discussions of this was that often the hardware accelerators
>> for this are optimised for 'use one key a lot', not for 'swap in a new
>> key for every operation' (the key swap is very costly).
>>
>> Sriram has some numbers for different co-processors which are
>> interesting, but I don't think that means we need on-board crypto
>> accelerators.
>>
>>> One of the reasons for questioning the choice of crypto, is exploring the
>>> feasibility of solutions which do not require on-router HW for doing
>>> signing.
>>
>> sure, but you also invented a whole other (seemingly complex) system
>> to keep track of data (nonces and such) across multiple
>> trust/administrative domains. it seems unwieldy, to me at least.
>>
>> One of the larger stumbling blocks though is ram for RIB storage. (or
>> that seems to be one of the larger problems to address)
>>
>> -chris
>>
>>>
>>> Brian
>>>
>>>
>>> On Fri, May 11, 2012 at 9:23 PM, Christopher Morrow
>>> <[e-mail]> wrote:
>>>>
>>>> On Fri, May 11, 2012 at 5:27 PM, Brian Dickson
>>>> <[e-mail]> wrote:
>>>> > The argument that "we can't do the crypto without HW"
>>>>
>>>> i didn't see anyone say that though.
>>>
>>>
>> _______________________________________________
>> sidr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidr
>>