Eric Rescorla wrote:
On Sep 30, 2009, at 8:10 PM, Michael Chen <[email protected]>
wrote:
Hi,
In an earlier thread, David A. Bryan asked about implementation
experience of this draft. Two things pop out immediately from my head
(they both feel like reinventing the wheel):
1. Digital signature related requirements seem rehashing what's being
done in TLS and DTLS.
2. Fragmentation handling seems to be reinventing TCP using UDP.
The second one may be unfounded, but I like to toss around an idea
while implementing the first. What if this draft mandates the
following regarding TLS and DTLS connections:
A. Client authentication is required for all TLS and DTLS connections;
B. Both parties (peers) in a D/TLS connection uses the same digital
credentials (certificates and public/private keys) for the DHT overlay.
For example, say peer X connects to peer Y via TLS. X will get Y's
overlay certificates and public key during the first part of the TLS
handshake. Then Y request X (the 'client') to send its certificates
and public key during client authentication. The TLS session will be
honored if and only if the overlay information in the certificates
are validated on both sides. This is fully supported by TLS and DTLS
(plus a few callbacks).
This is already true
I don't see this being explained in the draft. Are you saying it based
on implementation?
The level of trust established this way is equivalent to that
provided by the current draft-03. The intend is that with these
mandates, the RELOAD protocol itself can be simplified by removing
all certificate and signature related requirements. For example, in
my earlier post, an overhead of 1292 bytes can be trimmed down to
only 69 bytes!!! (removing the security block and the STORE signature).
I still need to think about messages forwarded by instead of
originated from a peer, but let the discussion begin.
Uh this is the base case. Which is why the messages have signatures
Ekr
Let's give it some more thought. With client authentication, any two
directly connected peers "trust" each other based on their overlay
credentials. Therefore, single hop messages like DHT stablization can
be exchanged between them with no signature/certificates attached.
That's a great saving to consider.
If a message is forwarded, say X->Y->Z, Y can doing man in the middle
attack. For Z to truly ensure that the message is from X, Z must FETCH
X's certificate from the overlay to verify the signature. For that
reason, sending the certificate has no real security meaning.
--Michael
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
