Subject: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-bgpsec-algs-16: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 13 Dec 2016 03:54:21 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-sidr-bgpsec-algs-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- As Randy commented, if the goal is to smallerise the
packets, it'd have been nice to use eddsa here but I assume
that wasn't practical due to the timing and the number of
RPKI elements that'd need to be defined for that? Is that
right? Did the WG consider using 25519 instead of p256?  If
not, is it worth asking, just in case everyone loves the
idea more than this?

- Documents like this are better with test vectors included
or referenced. Couldn't you add those or some pointers to
those?

- To answer Mirja's point: Anyone who knows RFC6090 knows
that it more or less only exists because of IPR silliness.
And sadly, even though 6090 only references documents that
predate relevant IPR filings by >20 years, even 6090 still
got an (IMO also silly) IPR declaration.  [1] Sheesh, but
whaddya gonna do? :-( Anyway, I don't think there's a need
to, or benefit from, adding text here about the well-known
situation with ECC IPR that I believe stymied deployment
for at least a decade.

   [1] https://datatracker.ietf.org/ipr/search/?rfc=6090&submit=rfc

---

From: Sean Turner <[email-masked]>
Date: Tue, 13 Dec 2016 09:27:23 -0500

> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/

We weren’t trying to optimize for the smallest possible packets just smaller than RSA because at the time we were deciding on the algorithm suite, which was circa ’11, 25519 (or really any other EC-based algorithm) wasn’t far enough along the standardization path.  And, you’re right there was a grunch of timing/elements that needed to be come together to make any other EC-based algorithm realistic.

Since we’re now cc'ing the WG on IESG ballot positions it kind of feels like it just got asked ;)  Personally, I think it’s fine the way it is and for what it’s worth there are now interoperable implementations (see below).

> or referenced. Couldn't you add those or some pointers to

Would they be better in this draft or in the protocol draft (on the 20170115 IESG telechat)?  Either way I reached out to Oliver Borchers @ NIST who did some interop testing between QuaggaSRx and BIRD [0].  Hoping that doing some packet captures with a simple example (BGPsec packets, private key+certs) wouldn’t be too hard to pull off; it’ll double the size of this draft that’s for sure.

Cheers,

spt

[0] https://tinyurl.com/hdsux2d

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Dec 2016 14:40:39 +0000

Hiya,

On 13/12/16 14:27, Sean Turner wrote:
>> When responding, please keep the subject line intact and reply to
>> all email addresses included in the To and CC lines. (Feel free to
>> cut this introductory paragraph, however.)
>> 
>> 
>> Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
>> information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> packets, it'd have been nice to use eddsa here but I assume that
>> wasn't practical due to the timing and the number of RPKI elements
>> that'd need to be defined for that? Is that right? Did the WG
>> consider using 25519 instead of p256?  If not, is it worth asking,
>> just in case everyone loves the idea more than this?
> 
> We weren’t trying to optimize for the smallest possible packets just
> smaller than RSA because at the time we were deciding on the
> algorithm suite, which was circa ’11, 25519 (or really any other
> EC-based algorithm) wasn’t far enough along the standardization path.
> And, you’re right there was a grunch of timing/elements that needed
> to be come together to make any other EC-based algorithm realistic.
> 
> Since we’re now cc'ing the WG on IESG ballot positions it kind of
> feels like it just got asked ;)  

Yep.

> Personally, I think it’s fine the
> way it is and for what it’s worth there are now interoperable
> implementations (see below).

I'm also ok with p256 for this, given the set of things that'd
all need a bit of updating for 25519.

> 
>> - Documents like this are better with test vectors included or
>> referenced. Couldn't you add those or some pointers to those?
> 
> Would they be better in this draft or in the protocol draft (on the
> 20170115 IESG telechat)?  

A reference to that as a place to find test vectors would
be just fine. Or inline in this one is also fine.

Cheers,
S.

> Either way I reached out to Oliver Borchers
> @ NIST who did some interop testing between QuaggaSRx and BIRD [0].
> Hoping that doing some packet captures with a simple example (BGPsec
> packets, private key+certs) wouldn’t be too hard to pull off; it’ll
> double the size of this draft that’s for sure.
> 
> Cheers,
> 
> spt
>