Subject: Re: [P2PSIP] Review of draft-birkos-p2p-security-key-refresh-00

From: Konstantinos Birkos <[email-masked]>
Date: Thu, 25 Mar 2010 20:12:13 +0200

Dear Mr Rescorla,

Thank you for the first detailed review of our draft. In the meantime, I 
had the opportunity to read your objections against rekeying in Educated 
Guesswork. In the following, I am providing some responses to your 
comments, which we can further discuss later in the p2psip session.

 > When a node refreshes its key, it authenticates its request using its 
existing cryptographic key pair. How does this provide additional 
security value over simply using the same key pair indefinitely?

 From a first point of view, it may seem worthless. However, both the 
intruder and the legitimate peer will eventually need to  inform  their 
neighbors  about  the refreshed credentials  and/or refresh  
themselves.  Consequently,  other peers in the overlay will  become 
aware that there have been two attempts  to  establish security 
credentials for the same peer and this is a strong indication of an attack.

 > Why is message-based encryption superior?

I do not by any means imply that message encryption is superior to TLS. 
It can only be seen as a second line of defence complementary to TLS.

 >How do nodes become super peers?

Yes, it has to be thoroughly described. It will be specified in 
following versions if the draft gains consensus.

 >And since all nodes in the overlay know the MSK, I don't see that htis 
adds any additional security.

At this point, our aim was to offer protection from outsiders.

 > When you generate a StoreReq (for instance) you don't know what peer 
is responsible for that region. Under what PK do you encrypt it?

It is encrypted with the first peer the StoreReq is addressed at. In 
order for decryption in the final recipient to be feasible, each 
intermediate peer should decrypt, re-encrypt and forward the message. 
Since it introduces computational cost without adding match to the 
initial goal, this feature may be removed.

 >Doesn't this turn the super peer into a replacement CA? This is a 
remarkable amount of trust to put in a peer.

Our initial thought was to produce extensions for a system with strict 
security requirements (like communication between authorities) in which 
the existence of trusted peers would be meaningful.

 >How can we not define which algorithms work? Interop requires this.

It will be addressed in next versions.

 >What is your threat model here? How does an attack  who has RP's 
private key not have MSK, which is known to every node in the overlay.

At a practical level, usually yes, once a peer is compromised, an 
intruder will probably acquire the whole set of security credentials. 
This is a point we need to elaborate.

Regards,
Konstantinos Birkos

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Mar 2010 12:08:22 -0700

2010/3/25 Konstantinos Birkos <[email-masked]>:

>> existing cryptographic key pair. How does this provide additional security
>> value over simply using the same key pair indefinitely?
>
> neighbors  about  the refreshed credentials  and/or refresh  themselves.
>  Consequently,  other peers in the overlay will  become aware that there
> have been two attempts  to  establish security credentials for the same peer
> and this is a strong indication of an attack.

I agree that this isn't a crazy goal (though I don't find it
particularly compelling
either). It's not like we worry about the problem of covert key theft overmuch
in any other cryptographic setting. However, why not simply rekey at the CA?

> I do not by any means imply that message encryption is superior to TLS. It
> can only be seen as a second line of defence complementary to TLS.

I don't see how it provides any additional value if, as you describe,
it terminates
at the next hop peer.

> Yes, it has to be thoroughly described. It will be specified in following
> versions if the draft gains consensus.
>
>>And since all nodes in the overlay know the MSK, I don't see that htis adds
>> any additional security.
>

But outsiders can't connect at all if you use the shared key mechanism.

>> When you generate a StoreReq (for instance) you don't know what peer is
>> responsible for that region. Under what PK do you encrypt it?
>
> It is encrypted with the first peer the StoreReq is addressed at. In order
> for decryption in the final recipient to be feasible, each intermediate peer
> should decrypt, re-encrypt and forward the message. Since it introduces
> computational cost without adding match to the initial goal, this feature
> may be removed.

This seems to offer exactly the same security as TLS, then.

-Ekr