On Thu, Oct 1, 2009 at 1:44 PM, Michael Chen <[email protected]> wrote: > Eric Rescorla wrote: >> This is already true > > I don't see this being explained in the draft. Are you saying it based on > implementation?
5.5.1.13. The procedures of Section 11 apply to RELOAD as well. However, in this case, the "media" takes the form of application layer protocols (RELOAD or SIP for example) over TLS or DTLS. Consequently, once ICE processing completes, the agent will begin TLS or DTLS procedures to establish a secure connection. The node which sent the Attach request MUST be the TLS server. The other node MUST be the TLS client. The nodes MUST verify that the certificate presented in the handshake matches the identity of the other peer as found in the Attach message. Once the TLS or DTLS signaling is complete, the application protocol is free to use the connection. 12.6.2. Admission to an RELOAD Overlay Instance is controlled by requiring that each peer have a certificate containing its peer ID. The requirement to have a certificate is enforced by using certificate- based mutual authentication on each connection. >>> 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. Yes, this is a potential optimization. But unless something is seriously wrong with the design (or the overlay is essentially quiescent), then this sort of stabilization traffic should be a small amount of the overall traffic, so it's not clear what the overall savings is. > 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. No, this is not correct. Certificates are independently verifiable by chaining back to the overlay's root key. That's pretty much the point of certificates: you can verify them no matter how you received them. Now, it's true that there is no SECURITY value in sending the certificate along with the message. Data origin authentication authentication is supplied by a digital signature computed using the private key that corresponds to the public key in the certificate. The certificate is attached to the message to avoid the complexity of a system where you have to hold the message while you try to retrieve the certificate. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
