Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.txt

Geoff Huston <gih@apnic.net> Tue, 08 July 2014 05:13 UTC

Return-Path: <gih@apnic.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B15C1B2A35 for <sidr@ietfa.amsl.com>; Mon, 7 Jul 2014 22:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.442
X-Spam-Level:
X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMkHkvCR8Dee for <sidr@ietfa.amsl.com>; Mon, 7 Jul 2014 22:13:24 -0700 (PDT)
Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) by ietfa.amsl.com (Postfix) with SMTP id 79F101B2A34 for <sidr@ietf.org>; Mon, 7 Jul 2014 22:13:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=TtTxMstyr8Up1HzB4X/kQG4wd8m1nF/t8+lVOO2OnFQ=; b=Qj7ZMmCai1AD9QuqJeU2OuLRGvV98iaaYByRZeqYc8IYy+k4A3tqvaH3VNoXUapJFEA16BWwxuq86 N7bIgQqnQKDjpJjdZtUbOQdfXDV2MWVpZvwEX1qG7/45yiz0AtviMs9NbFq2QtXun4/6rWq2di26fL hvIH+FxkY/xkB1bA=
Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Tue, 8 Jul 2014 15:13:20 +1000 (EST)
Received: from [10.1.3.132] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 8 Jul 2014 15:13:20 +1000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <CANTg3aB-9L8pm9nXgBd+XEt=koxKH1mQuOMG6BezKvH4U91=7A@mail.gmail.com>
Date: Tue, 08 Jul 2014 15:13:19 +1000
Content-Transfer-Encoding: quoted-printable
Message-ID: <7901F9DB-74DF-48F1-8107-09C25B872D6C@apnic.net>
References: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> <0AD801E2-D37B-432C-91FE-7983235468A4@apnic.net> <CANTg3aAga4JsD93yR5uxkWELDiZqQduLLyUtu-MzwkEKcRrPCA@mail.gmail.com> <A435E54D-5CCD-4204-9738-5BA5CE1EF7DE@apnic.net> <CANTg3aBHmHgYC8aabXdszWT5XLTZRpHxXS3GZ9sbCzs+BvroKg@mail.gmail.com> <586E1AFE-895F-40AB-A101-271F07774FA6@apnic.net> <FD21BCCD-5E5C-4CAE-9898-792706FD91BF@tislabs.com> <6BF5F265-36EB-4D81-B12E-7207147266D3@apnic.net> <CANTg3aB-9L8pm9nXgBd+XEt=koxKH1mQuOMG6BezKvH4U91=7A@mail.gmail.com>
To: Matthew Lepinski <mlepinski.ietf@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/M8rTh7mQeLDX2B53LhQOe8zwsWQ
Cc: Sandra Murphy <sandy@tislabs.com>, sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Tue, 08 Jul 2014 05:13:25 -0000

On 8 Jul 2014, at 3:02 pm, Matthew Lepinski <mlepinski.ietf@gmail.com> wrote:

> So I have no preference with regards to one document or two. (That is, if the working group wants to merge the BGPSec algs document with 6485bis, I see nothing wrong with fewer documents.)
> 
> However, I believe that there is a good reason to have a distinct set of algorithms for creating BGPSEC signatures and for signing RPKI certificates.


I can understand that perspective, and it makes sense to me, But that does not necessarily imply two RFCs. I think we need to keep an eye on the entire framework, and as we add pieces to the RPKI we should clearly understand where and how they interlock. For that reason,  I would like to see a single RPKI algorithms and key length spec that encompasses the entire RPKI use domain. If there is a need to split this document to make the distinction between use in the certificate and authority domain and use within the router-to-router domain then thats fine, but that split would (in my opinion) be within a single specification document, rather than more documents.


Geoff


> In particular, the devices that we envision producing BGPSEC signatures are different than the devices that are currently signing RPKI certificates. Additionally, signature length seems to be a non issue today with regards to signing RPKI certificates, but signature length is a more important consideration for BGPSEC signatures. That is, the trade offs in what makes a good signature algorithm are somewhat different when it comes to BGPSEC and I don't think we want to artificially force the two signature algorithms (for RPKI certs and for BGPSEC) to be the same. That is the original reason for producing the bgpsec-algs document (of course, this document was first written before it became clear that we needed to do a bis for 6485, and so perhaps it we should revisit whether we want one document or two).
> 
> - Matt Lepinski
> 
> On Jul 8, 2014 12:49 AM, "Geoff Huston" <gih@apnic.net> wrote:
> well I would like to understand why there appears to be two parallel efforts
> to update RFC6485, and it was I suppose a question that is correctly passed
> to the chairs, given that the chairs wanted rfc6485bis produced, and
> I assume that the chairs similarly approved the WG adoption of bgpsec-algs.
> 
> The original desire was to isolate the structure and framework from the crypto,
> which is why RFC6485 was produced in the first place, but now it appears that we
> are fragmenting this and producing multiple crypto profiles.
> 
> 
> Geoff
> 
> 
> (I was told recently that the DNS specs now span a few hundred RFCs. For a widely deployed
> active protocol I can kinda see that, but I'm not sure that there is merit in SIDR at this
> point in time to take this same quantity of RFCs as an objective! :-) )
> 
> 
> 
> 
> 
> 
> 
> On 8 Jul 2014, at 9:42 am, Sandra Murphy <sandy@tislabs.com> wrote:
> 
> >
> > On Jul 7, 2014, at 7:00 PM, Geoff Huston <gih@apnic.net> wrote:
> >
> >
> >> the header of draft-ietf-sidr-bgpsec-algs-08 says:
> >>   "Updates: 6485 (if approved) "
> >>
> >>
> >> so I'm still confused about the two 6485 update drafts.
> >>
> >>
> >
> >
> > Ah.  So your original question was:
> >
> >>
> >> Whats the relationship between this draft and draft-ietf-sidr-rfc6485bis?
> >
> > So you want to know if bgpsec-algs is updating the original RFC6485 or updating rfc6485bis?
> >
> > --Sandy, speaking as regular ol' member
>