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

Jeremy Harris <jgh@wizmail.org> Tue, 14 July 2020 21:05 UTC

Return-Path: <jgh@wizmail.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9743A09C0 for <tls@ietfa.amsl.com>; Tue, 14 Jul 2020 14:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=JFWNMY1r; dkim=pass (2048-bit key) header.d=wizmail.org header.b=keqWKrHT
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDvKYJ2BQlLM for <tls@ietfa.amsl.com>; Tue, 14 Jul 2020 14:05:30 -0700 (PDT)
Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E243A09A4 for <tls@ietf.org>; Tue, 14 Jul 2020 14:05:30 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Autocrypt:From:References:To:Subject :From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type :Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=EuocDoNWA0C+nbF/rUZaiLbIh6XwEO3eW/Y93aaN0lY=; b=JFWNMY1rpRVqgHCf/8fJFJHmMe M5yH6iNcVwqbUxZfIYqyCZvhCOv4HjQ9XDXdFkv/cSZwfv8RprYSXAD5/jDQ==;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Autocrypt:From:References:To:Subject:From:Sender :Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=EuocDoNWA0C+nbF/rUZaiLbIh6XwEO3eW/Y93aaN0lY=; b=keqWKrHTFuBzY4IRMVmtchEk+g W9yijKCyaGetudRu1HqeD+Hdjq6rEpG+Z0aF7d1SnbgPF7UXbK77jH0D7eacXqPZSnh7UKqpEzTWw yd7K9r9dSIBhQUPh1vYMV5jpRcP7cU5d6IyiyugShcVQW7v35iXvyiqFVMKgtiHzE1qLBaDefuE/s 118WvThRhgLbramShXjqz5Ou1ELbDWV35n4TXJGvlOkqJwJ1snGfUeNK+rlmorww3uO6dlfbuFXnT d1yTDV2uYXUtm2WF1Z99xKaS08NGEEwNBdh/SNYfPOYGvoQa07Ps3rO2RiOhr+gEXVqXg6UflBzYA rrNJUM0Q==;
Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org
Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.94.102) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1jvS7C-00ARrI-AK for tls@ietf.org (return-path <jgh@wizmail.org>); Tue, 14 Jul 2020 21:05:26 +0000
To: tls@ietf.org
References: <20200708042223.GB20623@akamai.com> <20200708150752.GL3100@localhost>
From: Jeremy Harris <jgh@wizmail.org>
Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= mQENBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAG0JkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+iQFOBBMBCAA4FiEE qYbzpr1jd9hzCVjevOWMjOQfMt8FAl4WMuMCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA CgkQvOWMjOQfMt946ggAvqDr2jvVnGIN2Njnjl2iiKyw4dYdFzNhZgjTaryiV90BftUDxRsB uTVFUC6XU+B13MEgSK0zRDyI5NpEH+JTW539gWlmz2k2WTTmoBsm/js1ELoAjGr/i32SByqm 0fo3JPctn/lc7oTo0muGYvB5xWhTHRlcT9zGTRUb/6ucabVLiJUrcGhS1OqDGq7nvYQpFZdf Dj7hyyrCKrq6YUPRvoq3aWw/o6aPUN8gmJj+h4pB5dMbbNKm7umz4O3RHWceO9JCGYxfC4uh 0k85bgIVb4wtaljBW90YZRU/5zIjD6r2b6rluY55rLulsyT7xAqe14eE1AlRB1og/s4rUtRf 8LkBDQRVgAbEAQgA6YSx2ik6EbkfxO0x3qwYgow2rcAmhEzijk2Ns0QUKWkN9qfxdlyBi0vA nNu/oK2UikOmV9GTeOzvgBchRxfAx/dCF2RaSUd0W/M4F0/I5y19PAzN9XhAmR50cxYRpTpq ulgFJagdxigj1AmNnOHk0V8qFy7Xk8a1wmKI+Ocv2Jr5Wa5aJwTYzwQMh4jvyzc/le32bTbD ezf1xq5y23HTXzXfkg9RDZmyyfEb8spsYLk8gf5GvSXYxxyKEBCei9eugd4YXwh6bfIgtBj2 ZLYvSDJdDaCdNvYyZtyatahHHhAZ+R+UDBp+hauuIl8E7DtUzDVMKVsfKY71e8FSMYyPGQAR AQABiQEfBBgBAgAJBQJVgAbEAhsMAAoJELzljIzkHzLfTegH/Aktgk6zEBXYZBhLQV5i+Inw /FBxZAUQRpjPGS9n1lAU2V0/Jq3UTDiurXD5ylmgr1ryq9JJ7fe9I/w8gIBZh/IYDot8nLYo BXnFQ444pQHgiTKt/LNbWCmIiw2wXR1rXZAPbh2cKt5X3d0MXBBDt0GpkBfnTu4fIADl5Rvq aPOx5vhNMM+LMCAfPkt+yc68fbrtC0hQ3yQkyvkyChmuVJ/C8T8cqvVp5zQ4e9syuwYkYnZP 7ONCnDaHfNzTOB5/7Gxn8i2vLEtBdzBNEvqHEjDorv2RxzosKS2DW8Eye7LWcRrK4Llnk/T/ mpsWwP2JSveS3nbLcLzflnB2e3fvgK65AQ0EXiRPygEIAMP9Z2LRciWF8OoKUbcnA50W0U60 zTBvb7IMm0Rfaeb+s5vk0bX6Hel8i7dxmQvy0yUBrQq/9NYa90MOcm54b9oETtKHcoe63U3i iZc62ERe5dRIr9EG1DAN3SW5fRc5H234mskCdl06ftOJCsXLL1enbunWF8WYQpn8hzsoQqzs klloqd24z8c/+3C5cPjI26hyGFR0W5Q1T8xBMqxgc5W0smyyqDdDs/H1VXrxfQdculDXkM3B EUkeZMsyT7Q8jr8qHv13T1dPCyObP4wXkaOSEtOcBAeF2B1TUVUEhqPzXbG6+oZWgVUKWB8o oHReboJUCkQC8jAIZrr9xpgCMPMAEQEAAYkBPAQYAQgAJhYhBKmG86a9Y3fYcwlY3rzljIzk HzLfBQJeJE/KAhsMBQkB4TOAAAoJELzljIzkHzLfjg4IAM2GxIUaXLfO22z2JWS3byFvfRNS eXLZx2cDokn8AGpzTY+k5mcCkOQVUUz9MuxM50VnrRuBaeH++LfzSghKRWLx2PdJlKzThyFi y23NagSwx4i/R2J8xiPtajZm5SS3slEg1pt3NhgDkkrTQUTHYcf4F0O3YgdoqGKR7m10jqXz gzwQE65Pb0QUX5clxy55oV1pXoq1qjELIYVH9aS8bpI0RE86axHwpOvG4cQrMWZ0tg1txwZ/ DSstczlx7/Ptxfdd+A0x27UhS7ijUuqXx/z8Vh7U/oj/lsVERXyxuUgojD5kkagRLURuYBef CxJ/k6RTKs8juRsbVGfJMmNdfyK4OAReJFQPEgorBgEEAZdVAQUBAQdAPr/8EgFM8AkB/CZz +BGJIezPAdpTYFLvRhsem2GoBicDAQgHiQE8BBgBCAAmFiEEqYbzpr1jd9hzCVjevOWMjOQf Mt8FAl4kVA8CGwwFCQPCZwAACgkQvOWMjOQfMt99PAgApNBPoJog4UKuiP4YP4vvntA4etz8 z7WzVU4uI2ep7++qEaZOafHlSaUILaGag4CSh7KmxrTUjtoJNeX2qx5AQ4pdlNIjMy/V/Z+z 8gJ5vQ3tXglN4P7S6ud6mYKzpGHCvNF2CdzSRa2DRizCy6+sHOrDiH5V7veKE+9LjF+aB9lw PYLeF6Dh4idnxIa3aVwQjAAn3NBYAuhymnqgLgWcrPNaiSP6VIrsu4aCCoeIuc7bCFks6hrR x805g1J6uxixrMu2bW+AbPpRObi5B0pTJhDaLBW1xQgOiwYIAdyu0H2YNMrCBsA0w40UWEIz xrAkJFP/CS+qkjMI47FKq1EzbQ==
Message-ID: <bf025bb2-e9cd-921f-6add-b819f60578cc@wizmail.org>
Date: Tue, 14 Jul 2020 22:05:24 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <20200708150752.GL3100@localhost>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/cQCN4w4-g32s8ZpN7Je0JrG-fNE>
Subject: Re: [TLS] invariant or not: one TLS connection per TCP connection?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2020 21:05:33 -0000

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