Re: [TLS] Banning implicit CIDs in DTLS

Achim Kraus <achimkraus@gmx.net> Thu, 28 May 2020 08:02 UTC

Return-Path: <achimkraus@gmx.net>
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 3EBE83A0BD9 for <tls@ietfa.amsl.com>; Thu, 28 May 2020 01:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmx.net
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 t0FwisnLJMV7 for <tls@ietfa.amsl.com>; Thu, 28 May 2020 01:02:43 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 8100A3A0BD8 for <tls@ietf.org>; Thu, 28 May 2020 01:02:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1590652959; bh=eAWpfiJaqxv70LQ58c7yj1IR5V37WDOzaHsWJzKojCk=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=e1AZUkj4EEHGOK7NoJEk+fYbj4Pw9kORyFrtvF0n9aHcfHSE2puEPTvAMaSddCUAL D8x2PwmOjMwG8uOBkkFveslH+mNOODGRjU+PVOa3EqQD1y8pcouvzaHNMqVIQXILEZ aC52p3lkjHlTZ4yvv4fL3QnVkbPsMLtRPqNxoICc=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.45] ([88.64.94.227]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MQMuR-1jQeqs1GbZ-00MN4n for <tls@ietf.org>; Thu, 28 May 2020 10:02:39 +0200
To: tls@ietf.org
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>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <6d475bc4-2cb9-5801-e7bc-e165d99502d3@gmx.net>
Date: Thu, 28 May 2020 10:02:38 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <F3DB7E1E-EA6C-4579-B77D-397F90FB3CF3@arm.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:7/diauCSV2HehG2DpHs05LX/aaAVjJrY5D13izTZRRw2JwF4nsF nkj6xMWafkdnF0I4hEnbHZp4YpBY7QNdSyVpqp+ScBMKXMZI/xCE2CrSf4Zapcd1uHJzvEG e5BI49+ns4PlDNoMI/gcpebmkADeL6tmqkLod2rqtVAdqTGHc14bgnyhHQyKF75EjB6Fhu3 J/HW/lw7BC20rpkg3rMdQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:opSbWvKOEO4=:X05UVaiS3AtcQi6YG+64xO 1iR0ZZrMWd8eSttbwdMpjOvysNRwyDOV9zmbHDsheufZ0FO8DkDhiEYOSE1S8x+YdYhKVkDY+ I4oyigEhYW5WyKSYKX3xKwSAa56YHa7tzYma9yJpq6KFmYzDXWkGrYP/ruVbMgHSyuSf/Bbrl WwidtMt3/cbAKSdKEMTxFud3XZ4BLpiuCC/QQmNU44Mfw82ydojSBwbf5+oaEKhVGkrZFistr cnSGTST3yVyqVfe4MB8oV9DwaluIaXB52xtTtbA3FuHX+/nxCTsnmtb0yG/7MYOZ0TRNdczLo eNXta7kd1pw4uSfV5NxI5m+pNs1E9Lgt7ywkps/kyCYrR2poGBJVz6YJR41jbQMmpZ2CObWey yoXyzFmEFTlKFcVMvngZPIKFqGdeOHeEi/Z620I30uKkP6IcEJZTqGuBDFZmFhLLh6MJ+Q1zl dJSrCUBTDspM289AZfHPImhcoZXn6G2fBo1yEocYgOvVoHczKjRT9+9ECzc1zrwl58bTiTorR S3CnHa1VHGY1EYSi1qAcG37iUonG+dROZh6RVozEVrleXw3uX0Gfd6JMDipvdRR6amm1FxiXV 9S5tQL+penDqkESRHUKIFPF0Rx/FVJXMQyeW0tCmDPQmNoFQ6+r0aw1rgi5MI65BiCfPKrmw2 qorTNO8eLO6mCp0V9h3dgnrA11taHj56gLtcFruzsBQqNEuHfTvVbiDGDpVAW9Nw/uyXhTEno ApCM7Ey+HZurpCYmhfPoNnFR/EAnzFWD/hsH/7NXfikWdXdfc+YlgnWg7XnyfVEGHwed5/YpU hOUIqRa8mGwh09qpJbKS8M4A75G33q+IA/e6O80XTRZw3N/aCS87k6tezjK+IKEkWlt3421kJ MJo6td6qf8APapUxlLyCMCalaaVUW43Q3GtL+eZ1A5tK40AI/9sA3wXu05Ug742EXbveeLztO J+Y4wJNCWJafbC/o6c0vCLP1yy3V88C+3Fj1G+a6mzwriVZaFwObEXwg9bS5XAU8oH3YQmAqu n16oh56GABgjhg7DRpt0rnjqluNYN9XPbnqLGzBLRhjNrYLBwW+ZLL1mprHzSJrbF8sGSHi4B zLR23GMprn/4bL1Hub/bYVA0RlgeBVjEZhianzRosID7mcW55gzGSB/0Ogz+lUSWchBK6fLBH shNrllMD5hwUn2xe8vpGQZ/uwTEwxU8exXHTmITWUO+9s590HWKwPsnC1rhLcBUfsycn+bulX siMLRIxB9wfyohB3w
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0eomDKrnTNWjjNt9hfYk9OkMuGE>
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 08:02:44 -0000

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
>