Subject: [P2PSIP] D/TLS with client authentication

From: Michael Chen <[email-masked]>
Date: Wed, 30 Sep 2009 20:10:19 -0700

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

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.

Thanks

--Michael

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Sep 2009 20:57:13 -0700

On Sep 30, 2009, at 8:10 PM, Michael Chen <[email-masked]>  
wrote:

> 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.
> 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:
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/p2psip