Hi all, On 04 Aug 2014, at 23:47, Sandra Murphy <[email protected]> wrote:
> speaking as a regular ol' member > > On Aug 4, 2014, at 4:42 PM, "George, Wes" <[email protected]> wrote: > >> Late to the discussion because I needed to have cycles to read and think >> about this draft... >> >> >> On 7/31/14, 4:03 PM, "Stephen Kent" <[email protected]> wrote: >> > >> This is probably true for routes that transition from >> Valid to Unknown, but not if they are actually found to be Invalid, which >> is what I understand would be the result of the problem discussed in this >> draft - invalid certs = invalid routes. > > Well…. > > invalid EE certs = invalid ROA (for the most part - there's operational > consideration about not removing an EE cert if a repository is unavailable, I > suppose) > > An invalid ROA does not necessarily mean an invalid route. > > If there is no other covering ROA, then a BGP route for that prefix becomes > unknown, as Terry pointed out. > > If there is another ROA which covers the same prefix, then a route may be > invalid -- if no covering ROA authorizes the ASN that the invalidated ROA > mentions. I think we are dealing with a low-risk, but high-impact scenario here. Arguments have been made to depict this as a virtually-no-risk and low-impact problem, but I am not convinced. I want to reduce the impact because low-risk, low-impact is a much better place to be.. I believe this is possible without any serious adverse effects. With regards to impact: ======================= = Origin validation: Indeed: routes would (almost certainly*) go from Valid to Unknown. But, what are we trying to achieve here by this whole origin validation thing? Valid is preferred over Unknown, why else would we bother with this stuff in the first place? Sure, being pushed to Invalid is much worse, but a complete failure of origin validation for a large part of the internet (e.g. a whole RIR region) still counts as a high impact event in my book. *: If a valid ROA exist through another certificate chain then routes could become Invalid. This scenario is less likely to happen by accident, because the parent would have to issue the same resource to more than one child certificate. = Path validation: For path validation it was mentioned that there is no ‘unknown’ state. And I am not sure if it’s even possible to differentiate here between ‘Invalid’ vs ‘Unknown’. I expect that the difference would be: knowing that that a path has been tampered with (key known, signature invalid) vs not being able to verify (unknown key). This looks attractive, but I think it opens an easy attack to just sign with a random key and the path is suddenly ‘unknown’ and not ‘invalid’.. Maybe I am missing something, if someone has an idea about how this could work that would be great. Unknown is still a better place to be than invalid, but only if there is a real difference between the two. So, all in all, I still believe that this *is* a high impact problem. The solution the authors have been suggesting to this problem consists of *limiting* the impact to just the affected resources. If we had that we could turn this problem into a low-risk, and much-lower-impact problem. With regards to risk: ===================== Low risk does not equal no risk. And combined with high impact this is problematic. While all RIRs and other responsible CAs are using precautions, there are many moving parts and problems can happen. Bugs in software, human error, timing issues in publishing parent and child certificates can all result in inconsistencies between the certificate issued and published by the parent at a point in time, and what the child believes they have. Currently RIRs maintain their own TAs, and this puts them in a position where they have full control and knowledge of when changes occur, so currently the risk these inconsistencies is fairly limited (but not absent). In case this changes the risk increases. And because it’s child certificate that ends up being rejected the immediate impact is on the party that has the least control over this. Tim _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
