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

[Stephen Farrell <[e-mail]>]

Hiya,

On 13/12/16 14:27, Sean Turner wrote:
> On Dec 13, 2016, at 06:54, Stephen Farrell
> <[e-mail]> wrote:
>> 
>> 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?
> 
> 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
> 
> [0] https://tinyurl.com/hdsux2d
>