Brian,
I would like the group to reconsider my optimization proposal discussed in this thread:
http://www.ietf.org/mail-archive/web/p2psip/current/msg05112.html
In short, the draft should allow single hop (direct) communications void of certificates and signatures, because the underlying D/TLS transport layer already guarantees the authenticity of the sender and the integrity of the content.
Jouni Mäenpää who runs apps in PlanetLab (OpenDHT?) has expressed his approval, while Eric dismissed it on the ground of complexity. I still believe it is well worth it.
Please consider adding the following text at the end of draft-06 section 5.3.4 Security Block:
===================
If and only if all of the following conditions are met, the Security Block MAY contain an empty certificate bucket and a null signature.
1) ForwardingHeader.ttl is 1.
2) ForwardingHeader.via_list_length is 0.
An empty certificate bucket is two octets of zeros, and a null signature is also two octets of zeros. Therefore, the Security Block under the above conditions MAY consist of 4 octets of zeros. Further, if the empty security block is used, the null signature MUST also be used in other parts of the message such as the signature in StoredData of a STORE message (see section 6).
The above conditions limit the use of empty security block to only those messages sent between two peers with direct connection to each other. It relies on the trust already established between the two peers in the D/TLS transport layer. It serves as an optimization for reducing PDU size, avoiding fragmentation and improving DHT rebustness.
===================
I would like the group to reconsider my optimization proposal discussed in this thread:
http://www.ietf.org/mail-archive/web/p2psip/current/msg05112.html
In short, the draft should allow single hop (direct) communications void of certificates and signatures, because the underlying D/TLS transport layer already guarantees the authenticity of the sender and the integrity of the content.
Jouni Mäenpää who runs apps in PlanetLab (OpenDHT?) has expressed his approval, while Eric dismissed it on the ground of complexity. I still believe it is well worth it.
Please consider adding the following text at the end of draft-06 section 5.3.4 Security Block:
===================
If and only if all of the following conditions are met, the Security Block MAY contain an empty certificate bucket and a null signature.
1) ForwardingHeader.ttl is 1.
2) ForwardingHeader.via_list_length is 0.
An empty certificate bucket is two octets of zeros, and a null signature is also two octets of zeros. Therefore, the Security Block under the above conditions MAY consist of 4 octets of zeros. Further, if the empty security block is used, the null signature MUST also be used in other parts of the message such as the signature in StoredData of a STORE message (see section 6).
The above conditions limit the use of empty security block to only those messages sent between two peers with direct connection to each other. It relies on the trust already established between the two peers in the D/TLS transport layer. It serves as an optimization for reducing PDU size, avoiding fragmentation and improving DHT rebustness.
===================
Thanks
--Michael
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
