On Fri, Jul 07, 2017 at 01:44:41PM +0000, Raja ashok wrote: > Hi Nikos, Hannes & Thomas, > > This ConnectionID concept is really a useful feature for a client > node which faces a change in transport and network layer. I am > having few suggestions in the proposed draft, which are listed below. > > 1) In section 3 of this draft, explains about the modification in > "DTLSCiphertext" structure. I feel instead of modifying existing > DTLS and TLS record header, we can directly introduce a new record > type (ContentType) for app data (application_data_with_cid(25)). > For this new record type, we can propose a modified record header > for both TLS and DTLS.
IMO, it is property of connection if CID is used, and what CID to use (including any possible backup CID or two). > 2) More over section 3 says modification only in "DTLSCiphertext", > not for "TLSCiphertext". I hope this CID mechanism should be used > for both TLS and DTLS. Because this transport layer change problem > is there for TLS based applications (HTTPS) also in Smartphone( > when it switches from Wifi to LTE). But this TLS application problem > is solved by MPTCP, but I dont think all webservers are supporting > this MPTCP. So I feel CID is required for both TLS and DTLS. Deploying CID with TLS over TCP is bit nontrivial. The following factors need to be considered: - TLS assumes only single stream of application data. - DoS by invalid address change. - Datastream integerity in dirty switch. The last one is pretty nasty. > 3) As part of defining new record type, we can remove some unused > fields like version, epoch. After removing epoch we can mandate that > both entity should not start renegotiation. Sample design for new > record header with CID is mentioned below DTLS 1.3 uses epoch field for rekeying. It is however uncler if it needs 2 octets for epoch, or if just sending the lowest octet of the epoch would be OK. > 5) Section 3.1 and 3.2 talks about the new extensions for > negotiating this feature support. But I feel no need of new >extensions to negotiate this, we can make client to add new SCSV > cipher in its cipher list. Ugh, no SCSVs. This isn't some critical security fix that has to work even with bad TLS stacks that don't support extensions. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
