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

"Ross.Anderson@cl.cam.ac.uk" <rossjanderson@googlemail.com> Mon, 14 May 2012 15:18 UTC

Return-Path: <rossjanderson@googlemail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D7D21F8752 for <sidr@ietfa.amsl.com>; Mon, 14 May 2012 08:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAlB5pyjWcxr for <sidr@ietfa.amsl.com>; Mon, 14 May 2012 08:18:38 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4989621F8751 for <sidr@ietf.org>; Mon, 14 May 2012 08:18:38 -0700 (PDT)
Received: by wibhj8 with SMTP id hj8so1527656wib.13 for <sidr@ietf.org>; Mon, 14 May 2012 08:18:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=boJ+bXfPXWYFUfG8UST66DZlHqOJpcirvk/KN2t7Lmc=; b=BskSJqUUjyiSw0zxXa0v84TDweosAXp1TM2PX8VvqSWBYKfaKBUOuG5PKYybLvaHGm MNUzZP+5AbB79QlihQ414Pz1vLnAO+0ud93jcoj87gvL3FBJGe49nVmf8LF4G7vxb/Qk 0rxhLc8dfnw2/WnK9wcNbHpM95AuokEiwvCSOIG5BlBZ/61FIkarlR+Vx9Y0NiKXmXY+ ypyxLwxkKp0x2beUi01/lcGz0rDzICLcIoOgA23tu7FObJoNrzxItxlTT4jePzZ4y47W 4WtuqA9Wokw88iXqCtCpcO+LZbd6ZEXT0q6I21modT5WlNHhrAvCI+wUWupJXBH4w/2x Y7RA==
MIME-Version: 1.0
Received: by 10.50.222.200 with SMTP id qo8mr4454354igc.20.1337008716894; Mon, 14 May 2012 08:18:36 -0700 (PDT)
Received: by 10.50.108.73 with HTTP; Mon, 14 May 2012 08:18:36 -0700 (PDT)
In-Reply-To: <CAL9jLaYEjOhLvKV88QX_GygYqUWxV03J1CnRtDAPqXF0uENa2g@mail.gmail.com>
References: <CAH1iCiruThFzpef5u9NVt+3AokGnuFhq-GrbqEOkkKnVhav4zQ@mail.gmail.com> <CAL9jLab2XT-4NWr8KyHKOiQMTWqE5cTavmEr4Uw+S4zhrA=YLA@mail.gmail.com> <CAH1iCiq3so54pE9XBM5Bp13xaERbmShipmCg=ckEySiDsh5ZPQ@mail.gmail.com> <D7A0423E5E193F40BE6E94126930C4930B990A66A8@MBCLUSTER.xchange.nist.gov> <CAH1iCirMKm1TbtBzWSKy=vHGLdYHvbtnXcwO1G9aG00n3DXmyw@mail.gmail.com> <D7A0423E5E193F40BE6E94126930C4930B990A6710@MBCLUSTER.xchange.nist.gov> <D7A0423E5E193F40BE6E94126930C4930B990A6716@MBCLUSTER.xchange.nist.gov> <CABFLmSTVmEUMYZmXNkbhSac0_jb0o-2nPG2_58Si0SGmF0podA@mail.gmail.com> <D7A0423E5E193F40BE6E94126930C4930B985DEF48@MBCLUSTER.xchange.nist.gov> <24B20D14B2CD29478C8D5D6E9CBB29F60F70871E@Hermes.columbia.ads.sparta.com> <CAH1iCio4_PaLFACs_cDZRV9c3iYhn93XqCrQrR5PD48bpyM3BA@mail.gmail.com> <CAL9jLab0aSJBpQTtbNLq_qLbxwhXj7Y3-_aqZVeMPoTB5C8DTA@mail.gmail.com> <CAH1iCioDW_mBWNyMy8K-jOrjdNqtnpQjdneSvWdRg0NWLNYV3w@mail.gmail.com> <CAL9jLabs4RtS-EsHP6DwtMbsQz6GJSCZrv24N118HMHYCDe_Sg@mail.gmail.com> <CAH1iCioSxfswyorBr8R+VpHCDcMqyA9QqYgog7C3wcoh17mRMw@mail.gmail.com> <CAL9jLaYEjOhLvKV88QX_GygYqUWxV03J1CnRtDAPqXF0uENa2g@mail.gmail.com>
Date: Mon, 14 May 2012 16:18:36 +0100
Message-ID: <CABFLmSQGTGs4j-4K791qvYTNb1ns4vQ7x9x64MeQjj4=Y9JEmw@mail.gmail.com>
From: "Ross.Anderson@cl.cam.ac.uk" <rossjanderson@googlemail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "Murphy, Sandra" <Sandra.Murphy@sparta.com>, "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>, "sidr wg list (sidr@ietf.org)" <sidr@ietf.org>
Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Ross.Anderson@cl.cam.ac.uk
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 May 2012 15:18:39 -0000

Hardware cryptoprocessors raise the issue of export licenses. They are
also expensive. There will have to be software alternatives.

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.

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
will enable ASes to try, watch, and gain the confidence to turn it on.

Who's looking at security usability?

Ross


On 14/05/2012, Christopher Morrow <morrowc.lists@gmail.com> wrote:
> On Mon, May 14, 2012 at 10:27 AM, Brian Dickson
> <brian.peter.dickson@gmail.com> 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
>> <morrowc.lists@gmail.com> wrote:
>>>
>>> On Fri, May 11, 2012 at 5:27 PM, Brian Dickson
>>> <brian.peter.dickson@gmail.com> wrote:
>>> > The argument that "we can't do the crypto without HW"
>>>
>>> i didn't see anyone say that though.
>>
>>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>