Howdy WG folks. this seems to not have gotten much review (after the authors changed a bunch).. can we get some readin/reviewin/commentin going on here please? :)
On Mon, Apr 17, 2017 at 2:06 PM, Tim Bruijnzeels <t...@ripe.net> wrote: > Dear WG > > One thing the authors noted was that there may be discussion needed around > the filtering of BGPSec assertions based on matching SKI - as the document > currently says. This was added mainly in an attempt to make the spec > feature complete and give an operator full freedom on filter rules. > > SKIs use SHA-1. And recently it has been shown that SHA-1 collisions can > be generated. This could lead one to believe that filtering of assertions > based on a SKIs may not be a good idea. However, it should be noted that > such collisions are probably irrelevant here. A ‘malicious' CA can always > issue another router certificate for an existing (and requested) router > certificate SKI and public key. So ‘collisions’ can exist anyway and a more > secure hashing algorithm would not help. > > The more fundamental question here is if it is really useful to have > filtering based on the key itself - and if so - should it be possible to > filter on the key alone (as the draft allows) or only in combination with > an asserted ASN for that key (also allowed in this draft)? > > As said it was mainly added for feature completeness, but it would be good > to hear from this WG what the thoughts are. Personally I don’t see a big > issue here - and would leave it to operators to use the options as they see > fit. But if there are concerns and there is no clear use case then I for > one would be happy to take it out again in which case BGPSec assertions can > only be filtered on matching ASN. > > Cheers > Tim > > > On 10 Apr 2017, at 17:49, Sandra Murphy <sa...@tislabs.com> wrote: > > > > The authors of draft-ietf-sidr-slurm-04, "Simplified Local internet > nUmber Resource Management with the RPKI”, have indicated that they believe > the current version includes all wg comments and is mature and ready for > working group last call. > > > > This message starts a WGLC for draft-ietf-sidr-slurm-04. The WGLC will > end 24 April 2017. > > > > The draft can be found at https://tools.ietf.org/html/ > draft-ietf-sidr-slurm-04 or https://datatracker.ietf.org/ > doc/draft-ietf-sidr-slurm/. > > > > Please reply to the list whether the document is ready for publication > or you have comments that you think should be addressed. > > > > Please do read and respond to the list. Remember that responses are > required to gauge consensus, silence is not consent. > > > > —Sandy, speaking as wg co-chair > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
