Re: [TLS] invariant or not: one TLS connection per TCP connection?

[Jeremy Harris <[e-mail]>]

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