Hiya, On 13/12/16 14:27, Sean Turner wrote: > On Dec 13, 2016, at 06:54, Stephen Farrell > <[email protected]> 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
