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

>> 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.

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?


>> 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.

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


>>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.

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
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip

Reply via email to