Re: [TLS] Suggestions in draft-mavrogiannopoulos-tls-cid

[Ilari Liusvaara <[e-mail]>]

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