Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT)

[Stephen Farrell <[e-mail]>]

Hiya,

On 04/01/17 18:48, Sean Turner wrote:
> 
>> On Jan 4, 2017, at 08:53, Stephen Farrell
>> <[e-mail]> wrote:
>> 
>> Stephen Farrell has entered the following ballot position for 
>> draft-ietf-sidr-bgpsec-protocol-21: Discuss
>> 
>> 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-protocol/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>>
>> 
DISCUSS:
>> ----------------------------------------------------------------------
>>
>>
>>
>>
>> 
I have a couple of fairly straightforward things I'd
>> like to briefly discuss...
>> 
>> (1) 3.2/Figure 7: A fixed 20 byte SKI being a sha-1 hash of the
>> public key is a bad plan, for all the usual reasons. Why is it ok
>> for that to be hardcoded here when it could change if/when new alg
>> choices are made for the RPKI? If it is not too late then I think
>> you should add a length or alg field to that. If it is too late to
>> do that, then are we really ok that you will need to rev the
>> BGPsec version number in order to get rid of all sha-1 code from 
>> your implementation? That seems like a bad plan for a new 
>> protocol.
> 
> Not sure it absolutely needs a length field; if the RPKI does ever
> decide to change to another hash algorithm for SKI, e.g.,
> SHA-256/384/512, or to change to a hash of the SubjectPublicKeyInfo
> they could always the procedures from
> https://datatracker.ietf.org/doc/rfc7093/ to generate the values for
> a 20-byte value.

Something like that could work I guess e.g. if this draft
said "if a router cert contains an SKI that's != 20 bytes
long, then here's what you do..." that'd be fine. I'm not
sure that's identical to what's in 7093 though but it is
close and should be fairly obvious and uncontroversial.

I do think it very worthwhile though to not so closely
couple the code for generating SKIs with that for BGPsec
as they will (I guess) tend to be different codebases not
evolving in a tightly coupled manner.

Cheers,
S.

> 
> spt
>