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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 7 Jul 2020 21:22:24 -0700

Hi all,

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.

Thanks,

Ben

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Jul 2020 05:45:23 -0700

> non-D TLS)?  If not, I can give them guidance that this type of statement

This may turn out to be permissible with cTLS, so I think we should not
remove it.

-Ekr

> Thanks,
>
> Ben
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 Jul 2020 10:07:53 -0500

> non-D TLS)?  If not, I can give them guidance that this type of statement

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.

Nico
--

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 14 Jul 2020 22:05:24 +0100

> 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

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 15 Jul 2020 16:42:10 +1000

> non-D TLS)?  If not, I can give them guidance that this type of statement

Are we forgetting HTTP CONNECT in HTTP/2?