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