Re: [TLS] Banning implicit CIDs in DTLS

Hanno Becker <Hanno.Becker@arm.com> Thu, 28 May 2020 14:19 UTC

Return-Path: <Hanno.Becker@arm.com>
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 35B183A0F5F for <tls@ietfa.amsl.com>; Thu, 28 May 2020 07:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=5Z1amCFA; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=5Z1amCFA
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 dx9PpoHqFU67 for <tls@ietfa.amsl.com>; Thu, 28 May 2020 07:19:55 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20051.outbound.protection.outlook.com [40.107.2.51]) (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 6B6433A0F54 for <TLS@ietf.org>; Thu, 28 May 2020 07:19:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GCJnCTz4t63GBx1kU+R38dbT0pV5Bb/Y3ngqMe+EGCc=; b=5Z1amCFA3CFMqyq8AC4mspIDt2knmpVsXusV4m5aLZBy/O6Rrd193/DZ3+ZYOrBpR7Bg4THmZk+R+LYZFdT1vdLNc4q1sQzMqtuzEtgAGJhC7A8l0v5Vesxh3gpkPmhXcAdVOIKBod4N96rmPHvdwDP7q4h07aQcpicy1t9dVTE=
Received: from DB6PR0501CA0016.eurprd05.prod.outlook.com (2603:10a6:4:8f::26) by AM0PR08MB3649.eurprd08.prod.outlook.com (2603:10a6:208:d3::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.24; Thu, 28 May 2020 14:19:51 +0000
Received: from DB5EUR03FT018.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:8f:cafe::82) by DB6PR0501CA0016.outlook.office365.com (2603:10a6:4:8f::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.17 via Frontend Transport; Thu, 28 May 2020 14:19:50 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT018.mail.protection.outlook.com (10.152.20.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23 via Frontend Transport; Thu, 28 May 2020 14:19:50 +0000
Received: ("Tessian outbound cff7dd4de28a:v57"); Thu, 28 May 2020 14:19:50 +0000
X-CheckRecipientChecked: true
X-CR-MTA-CID: 6d89fbe27b9a9a52
X-CR-MTA-TID: 64aa7808
Received: from 1cbdd8b08f3b.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 9F523DD2-1571-464F-B4BB-3657545CFDB3.1; Thu, 28 May 2020 14:19:45 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 1cbdd8b08f3b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 28 May 2020 14:19:45 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jZJNpCGV32boFkJyA81AwQDcN453gSh62c79DDwSaR6n91UjISQZYINRvZgTUfTHbEWQZcy0HyjyQVOUWhceLkygN0cKM0DD2a3b6fMV1dpFs2KB/h3OFUld8/lm8czkzaKzR6owlEPJeJGxWoaFoqRFNhnk5iy8VGAlPAsIURn7rXUPaFcxfp/YFxbQJc6Tns/WLNg1vSxKyr6ehHs26CWJBLgQ6Qe2TJOBbEoBjTTe04XJmx38EqNngzl5p9ur1wML25ybyMCeuNtTXu0H3xrLTQJiiULvL+maYYaU/eHO+xJaeKcbh8BhcaJ98R+BF7MeW4LBzHmqCOs+w6Qv8w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GCJnCTz4t63GBx1kU+R38dbT0pV5Bb/Y3ngqMe+EGCc=; b=NbIsDovrEe75FPJuYDT48Q/bQfRrtyWCf+Vd6hrrmLhYtIB7qiAKtdeR8lrGAhey5OAucquva5tvVn7vY6pBoG1uYh6S4bNuKhqCHY+YWsu81RLJASiTpIan1uHkbFkt50vP85Hf8UgLqcr6ux47Pt3/zqgfhjnopx+z3fg+W5FDPY3OVnL2pOLjhRQyXn/qFb4/OV3lttaBGA3vPKf95fKrhGyZ7VIXNnzj/ebPB2900b8j74sVV8AhSgniAM6v+kvyN4wIlD/aPq7nMtaZME3sbYvOiCqMnUgwilNd+Z/su7DgbHPi4pfF16p/AyynK7eYhgypr9Gzg1WacV4tIw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GCJnCTz4t63GBx1kU+R38dbT0pV5Bb/Y3ngqMe+EGCc=; b=5Z1amCFA3CFMqyq8AC4mspIDt2knmpVsXusV4m5aLZBy/O6Rrd193/DZ3+ZYOrBpR7Bg4THmZk+R+LYZFdT1vdLNc4q1sQzMqtuzEtgAGJhC7A8l0v5Vesxh3gpkPmhXcAdVOIKBod4N96rmPHvdwDP7q4h07aQcpicy1t9dVTE=
Received: from DB8PR08MB5177.eurprd08.prod.outlook.com (2603:10a6:10:e3::27) by DB8PR08MB4970.eurprd08.prod.outlook.com (2603:10a6:10:e7::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.19; Thu, 28 May 2020 14:19:43 +0000
Received: from DB8PR08MB5177.eurprd08.prod.outlook.com ([fe80::f86c:9fc9:baa8:48e0]) by DB8PR08MB5177.eurprd08.prod.outlook.com ([fe80::f86c:9fc9:baa8:48e0%3]) with mapi id 15.20.3021.030; Thu, 28 May 2020 14:19:43 +0000
From: Hanno Becker <Hanno.Becker@arm.com>
To: Achim Kraus <achimkraus@gmx.net>, "TLS@ietf.org" <TLS@ietf.org>
Thread-Topic: [TLS] Banning implicit CIDs in DTLS
Thread-Index: AQHWL4jlVazT6tbHlkGZvgKpDlUBs6iyuNyAgACCdQCABFAXAIAAHR+AgAQUqwCAAXBxAIAAAKzJgABiXpk=
Date: Thu, 28 May 2020 14:19:43 +0000
Message-ID: <DB8PR08MB51775E1C41AFAD4B9BD3D1FA9B8E0@DB8PR08MB5177.eurprd08.prod.outlook.com>
References: <df70e06b-ffdf-4402-b640-d99b2aafac6b@www.fastmail.com> <17230F7E-0983-4519-8BA3-50D3F1A66C22@arm.com> <b45dea1f-506a-420e-aa3b-4d6c0fae5028@www.fastmail.com> <780181FE-B9FE-452F-93F4-4268DFB4E47E@arm.com> <CABcZeBOfswLafAP+-LwNFwty2CA+pEx=pr6ixP0htqsVyPFcSw@mail.gmail.com> <F3DB7E1E-EA6C-4579-B77D-397F90FB3CF3@arm.com>, <6d475bc4-2cb9-5801-e7bc-e165d99502d3@gmx.net>, <DB8PR08MB5177E491B87DF519CB173DFC9B8E0@DB8PR08MB5177.eurprd08.prod.outlook.com>
In-Reply-To: <DB8PR08MB5177E491B87DF519CB173DFC9B8E0@DB8PR08MB5177.eurprd08.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Authentication-Results-Original: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=arm.com;
x-originating-ip: [62.7.191.216]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 4fe83394-a2d4-4cf9-5030-08d803122f2f
x-ms-traffictypediagnostic: DB8PR08MB4970:|AM0PR08MB3649:
X-Microsoft-Antispam-PRVS: <AM0PR08MB364948483BFCC40CE964783F9B8E0@AM0PR08MB3649.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;
x-forefront-prvs: 0417A3FFD2
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: w7Rhyhtl6BMx5OIuLoaYTPS8U5Ca0F3k6o5qF3QEmjU6MsYzsdO4lU4Dx9fVB/wcPMCKizPAlNmOiS+xHLyaGvpFwhMGzn5Au7yjguNL84jy439CT8vwqxBUqMJo1dGOtaGp0VN2Rc37JL2dRAv7ftpDTVfOLPMNagTgggvYhpW7w7XHKvbJ/TklAptz9nTkSdQDA6aPVwnuexhX9sPTnPXQlofBgOxXh0VihOhd6wtDoLyG8Ua21xxFsUbCTKRupUx2SeVOwnkesDL1poCENLsqG1R2ttq2vvKchYipfAiDZIQadhgu4gfg56F4283+8zbj8/fb2VX6kjOCrqyF6zyy6F7lOnMxer3yTKmqiM1h0zn0553QSGy6FTGDyyH61qUIJtMWWBn7092pNT9Kqw==
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8PR08MB5177.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(136003)(376002)(366004)(346002)(26005)(966005)(2940100002)(7696005)(53546011)(110136005)(316002)(6506007)(86362001)(33656002)(5660300002)(71200400001)(2906002)(66946007)(9686003)(52536014)(66476007)(66556008)(64756008)(66446008)(55016002)(186003)(19627405001)(76116006)(8676002)(83380400001)(478600001)(8936002)(166002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: VxdcF1wrXyUttO9ae6vb8mgbtKOWpzXbWspsIciWFqb23lNjkJSHyBLr9XmRLVjCaTLpU36ShsElqKSNVzr9FXPJz6yR7AW7LeO9GKKhUbincGAhpxvSCItPGdR59mO2i0ooD5xekvRR0aPa7RNZvluK1gb1cEMFkTIEKWC9zM94kstWnTvIhSxaaOZ7yNVUGtBOJW9RMAYvT7+jBjinpPG2E74bJ5+kjHCvCnZmwEU1sO8HfD93Zvv9bVKaS5DdzbQOMMgA2O+Mkww5VKXu0NZ2W89gGOaVZms7FeVcxrLqmiriNxIaj6SkbE7pwsqwQJkG6T7sIYg5/T4oOajQki5CwQrjgYMxnWRL/dwI/wRMc/ZV+B9w76Z3JTV29InXy1nh+iuGU42cBDM5QZVpoHIEc0Kux2KHdxU/Q39KY3lvAWyz9RHgM0fvAolj8Vpn7TPnqFH5YdK28a0fSGYtEo7vdThUiHAmJgOqKjZQw9c=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DB8PR08MB51775E1C41AFAD4B9BD3D1FA9B8E0DB8PR08MB5177eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB4970
Original-Authentication-Results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT018.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(39860400002)(396003)(346002)(46966005)(186003)(8936002)(6506007)(53546011)(82310400002)(478600001)(2906002)(33656002)(83380400001)(86362001)(81166007)(26005)(7696005)(30864003)(19627405001)(70586007)(82740400003)(5660300002)(52536014)(966005)(70206006)(110136005)(55016002)(316002)(356005)(9686003)(2940100002)(47076004)(8676002)(336012)(166002); DIR:OUT; SFP:1101;
X-MS-Office365-Filtering-Correlation-Id-Prvs: 3bf2bf9f-5d07-4574-33ea-08d803122b10
X-Forefront-PRVS: 0417A3FFD2
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: ZTVa/beQvf8XWk61VaOLUxs2sgz0qq0adA0W+ex4UporR2Rv8IhJMP5L6cnaucjPwNwpd1bX6ufyk2lVSg6oGUnxfQPiPr1SWDOeOe8cBG5YDb81V3nii3Ca/jPUYbbC811uud2Uuhgo5rrW31h4SJBVJ1GRENbtun5YM2gNQ2LX1Tkir4TLK5Bdm6GfA0bDZkdFF+J5BENCSnBeR5Ixm0imbz+cwMQSz3p/9aY5QLr+pcmjJtjzWqNj/TSqvZm148HTCMKaDIzWj/s4XDGObd1kse/rnNGhhj1EMFGaDFR8+CW83yQOv4GPHTj3et6iqFUpreIK8Yy8ulVIZCh7PIsoRWqbdtvlj47mWv7GYkz3ZOMocByo7izEUmXain0EkiznCbzLbz9zkIQvAJSwsK7ZFCeEUl/xRv7GL3zraOjF+qNnk1I67RDXtVtX2m7qLKJsRkgJ0g7qnJnkQs911NUcI8/H0rk0q9BMvOdl+nI=
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2020 14:19:50.8769 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4fe83394-a2d4-4cf9-5030-08d803122f2f
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3649
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0WDHb39Pu72yViWv1nT44qnZ7yg>
Subject: Re: [TLS] Banning implicit CIDs in DTLS
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: Thu, 28 May 2020 14:19:59 -0000

Hi,

I changed my mind and support PR #148 on removing implicit CIDs.

Reason, FWIW: The main use of implicit CIDs is reduced transmission bandwidth
in case of multiple records within a single datagram, which I still consider valid.
However, firstly there doesn't appear to be consensus on the relevance of this
case, and secondly, if so, there's more to optimize than just the CID: Concretely,
going down the route of adding a new content type as suggested by Achim, or
alternatively adding a framing in the already existing intermediate layer given
by the DTLSInnerPlaintext, seems preferable, since it saves the header plus the
record protection overhead, instead of just parts of the header. Such a change
could moreover be added as an extension to DTLS 1.3 at a later point, if desired.

My support for the use of a pseudo header for the AAD isn't impacted by this,
but that's not the point of this thread.

Cheers,
Hanno

________________________________
From: TLS <tls-bounces@ietf.org> on behalf of Hanno Becker <Hanno.Becker@arm.com>
Sent: Thursday, May 28, 2020 9:17 AM
To: Achim Kraus <achimkraus@gmx.net>et>; TLS@ietf.org <TLS@ietf.org>
Subject: Re: [TLS] Banning implicit CIDs in DTLS

Hi Achim and all,

> > Now, it turns out in the specific situation (and whenever the data
> > framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one
> > might as well buffer and coalesce all the application stuff into one
> > single record, making the need for CID compression moot.

> I'm not sure, how CoAP (RFC 7252) offers framing. AFAIK it uses the size
> of the UDP message (or that of the DTLS "application_data" part).. Only
> for TCP the size is explicitly encoded in the CoAP messages (but that's
> not RFC7252). If I miss something about that, it would be great, if you
> share some details to help me out.

> In my opinion, introducing a new TLS Content Type
> "multi_application_data" would help in a more general way. Even without
> the "implicit CIDs" discussion it may help in some cases, where a couple
> of "very small" "application_data"-messages are sent at once.

As mentioned before, I second that wish for more efficient stacking
of multiple records within a single datagram.

Note that this goal could also be achieved without an additional content
type if we'd go for the pseudo-header AAD. Namely, in this case, one could
generalize the implicit CID to allow dropping further header fields and
defining their implicit value for non-initial records, as Thomas mentioned before:
(a) For CID, the value is the same as for the previous record in the datagram
(perhaps transitively continued). (b) For record sequence numbers, an omitted
sequence number means that it's the successor of the one used in the previous
record. (c) For epochs, the value is the same as for the previous record in the
same datagram.
If you follow this through, you end up with the extreme possibility of having
multiple DTLS records within a single datagram, where the explicit headers
of the non-initial records consist solely of their length. This would still be
longer than what you'd get with a multi_application_data content type,
or application layer framing, because the authentication tag overhead occurs multiple
times, but it comes at the benefit of not changing the protection of the records, since
the input to the AEAD algorithm is unchanged.. It's only the record  header _format_
that can be chosen freely and optimized dynamically.

Regards,
Hanno

________________________________
From: TLS <tls-bounces@ietf.org> on behalf of Achim Kraus <achimkraus@gmx.net>
Sent: Thursday, May 28, 2020 9:02 AM
To: tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] Banning implicit CIDs in DTLS

Hi Thomas,

 > Now, it turns out in the specific situation (and whenever the data
 > framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one
 > might as well buffer and coalesce all the application stuff into one
 > single record, making the need for CID compression moot.

I'm not sure, how CoAP (RFC 7252) offers framing. AFAIK it uses the size
of the UDP message (or that of the DTLS "application_data" part). Only
for TCP the size is explicitly encoded in the CoAP messages (but that's
not RFC7252). If I miss something about that, it would be great, if you
share some details to help me out.

In my opinion, introducing a new TLS Content Type
"multi_application_data" would help in a more general way. Even without
the "implicit CIDs" discussion it may help in some cases, where a couple
of "very small" "application_data"-messages are sent at once.

best regards
Achim

Am 27.05.20 um 12:03 schrieb Thomas Fossati:
> On 24/05/2020, 20:45, "Eric Rescorla" <ekr@rtfm.com> wrote:
>> In what context do you have a use for implicit CIDs?
>
> The specific use case I had in mind is that of an endpoint sending small
> and frequent application data units to the same peer - e.g., sensor
> readings through CoAP observe.  In this (and similar) situation(s) where
> the payload / header ratio is low one wants to have as little transport
> overhead as possible.
>
> Now, it turns out in the specific situation (and whenever the data
> framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one
> might as well buffer and coalesce all the application stuff into one
> single record, making the need for CID compression moot.
>
> So, I am now convinced I don't have a compelling case to bring to the
> table and might as well move into Martin's "vanishingly small use cases"
> camp, therefore subscribing the gist of PR#148.
>
>
> PS  A note about the more general argument of a pure pseudo-header
> approach: it'd enable compression boxes at ingress into a constrained
> network, which would be really useful.  Without a thorough analysis wrt
> header malleability this is unfortunately out of reach.
>
> --
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf..org/mailman/listinfo/tls<https://www.ietf.org/mailman/listinfo/tls>
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.