On 08/07/2020 16:07, Nico Williams wrote: > On Tue, Jul 07, 2020 at 09:22:24PM -0700, Benjamin Kaduk wrote: >> There's an interesting note in draft-ietf-nfsv4-rpc-tls-08 (currently >> in IESG Evaluation): >> >> The protocol convention specified in the current document assumes >> there can be no more than one concurrent TLS session per TCP >> connection. This is true of current generations of TLS, but might be >> different in a future version of TLS. >> >> Can we envision wanting to do such a thing (e.g., with connection IDs for >> non-D TLS)? If not, I can give them guidance that this type of statement >> is not needed. > > I can see an application that starts TLS in a TCP connection, ends TLS > without also ending the TCP connection, then starts TLS again. But > multiple concurrent TLS connections in one TCP connection? I don't see > that happening. Maybe with DTLS, but they are using TLS. I would just > remove the above paragraph.
Devil's advocate: It would let one overlap the command phase of a second smtp message transfer while the previous was committing the end of data-phase - and still get congestion-control fate-sharing and TCP buffer sharing. Without either complexifying SMTP-level pipelining, invoking TCP-CC state copying, or use of SCTP/QUIC. Mind, I'd not want to implement it. Or any of them. -- Cheers, Jeremy _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
