Re: [sidr] Key learning procedures in BGPsec?

[Eric Osterweil <[e-mail]>]

On Jan 23, 2012, at 3:28 PM, Stephen Kent wrote:

> At 10:38 PM -0500 1/19/12, Eric Osterweil wrote:
>> 
>> > This is a local matter, so each ISP can decide what approach they wish to adopt. I personally prefer installing the cert for the CA.
>> 
>> Yeah, I see.  I agree that it should be a local policy decision, but then how does this avoid my initial concern about relying on crypto material that has been dispatched through customs (or some other suspect medium), where key material could be intercepted and extracted?
> 
> The focus of BGPSEC is improving inter-AS routing security. The operator of any AS may not do a great job of securing the keys associated with some or all of its routers. Other ASes will not, in general, be able to evaluate the operational security of an AS. BGPSEC tries to limit the extent to which an AS  can lie about routes that it propagates. Local (within an AS) security errors or poor practices do not undermine this security feature.

This seems almost like a self-contradictory statement.  How is the system improving AS security if keys can only be deployed over a potentially compromised medium, and there is no provision for CAs, signers, RPs, etc. to express partial trust?  With BGPSEC, we are already assuming some degree of trust imparted by signatures, but your comment above suggests that there should be some further understanding that "other ASes" cannot evaluate the trustworthiness of what they are consuming...  If this is the case, I would worry that we are worse off with this false sense of security...

To put it differently, I think this highlights a misalignment between the design of BGPSEC and what operators are going to have to deal with.  We're not giving any choice to operators that will essentially have to risk compromise, or not play in this system at all...

> 
>> Also, is it safe to assume that you would need the CA(s) to restrict access to just your own routers (so that unknown routers/certs cannot issue KGReqs that result in KGReses)?
> 
> A CA issuing certs to routers in an AS must have a way to verify that a cert request is form a legitimate source. There are various ways this can be done and, ultimately, this too is a local matter.

Actually, I think this is a "turtles all the way down" issue.  I cannot see any silver bullet here that solves this (which is what I'm trying to highlight).  We can't bootstrap trust in a BGPSEC router's key w/o some external handshake, but we can't bootstrap that handshake without some external cert, but we can't bootstrap that without... etc.  Deploying a remote signer with sensitive information (private keys, shared secrets, etc.) seems to be a serious problem...

> 
>> > When key escrow has been required, it has usually been mandated for keys used for encryption, not for integrity or authentication. Since we're discussing integrity & authentication here, it is not clear that there are any applicable key escrow regulations.
>> 
>> Sorry if I'm confused, but in the diagrams in 1.2.1 and 1.2.2, don't the curly braces denote encrypted material?  I thought the responses in the key exchanges where necessarily encrypted in this protocol? Otherwise, the new private key is sent in the clear.  I fully accept the possibility that I'm confused here, but if the material is encrypted and needs to be decrypted, would the corresponding keys be subject to escrow policies?
> 
> Typically no, because the use of the key being issued is for signing.

But the diagrams show encryption.  Are the KGRes private keys to be sent in the clear then?

> 
>> > Also, the IETF general policy has been to ignore any nation-specific crypto regulations when  developing standards.
>> 
>> I see, I guess I had thought we should be worried about the eventual operational issues that might arise.  I didn't know this was taboo, but shouldn't we find a way to address these concerns in order to help ensure the design's operational relevance when it's finished? I'm just bringing this up in the sprit of making this design more relevant, not because I think there should be some official linkage to escrow policies or anything.
> 
> In general it is appropriate to worry about operational issues. But, I'd suggest that key escrow is not within scope, based on previous IETF experience in related areas.

OK, I suppose my parting thought on this escrow issue, then, is that having to negotiate key escrow is an issue that operators will be required to face with this system, and I am worried that our working group's secure design might be a non-starter for some unless we try to address this issue it in the design.  I really feel like we need to fix this to keep our design relevant.

Eric