Re: [TLS] Adoption call for draft-rescorla-tls-ctls

Daniel Migault <daniel.migault@ericsson.com> Mon, 25 November 2019 19:11 UTC

Return-Path: <mglt.ietf@gmail.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 BFAFC120D2E for <tls@ietfa.amsl.com>; Mon, 25 Nov 2019 11:11:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.406
X-Spam-Level:
X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.244, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 F2kf8C5VwgN3 for <tls@ietfa.amsl.com>; Mon, 25 Nov 2019 11:11:30 -0800 (PST)
Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE48120CF6 for <tls@ietf.org>; Mon, 25 Nov 2019 11:11:27 -0800 (PST)
Received: by mail-vs1-f48.google.com with SMTP id m5so6214918vsj.3 for <tls@ietf.org>; Mon, 25 Nov 2019 11:11:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WjZVB6ai0Y2/w+kibbsGHokhRrQfBNqjcWXFZhhDNL4=; b=G3hEHdSxVJUT4ZeR2EHqvwDcjVptBrBZ0IivdJMqjRXgvZrl0rIobqcYQYRkpU/8BF JdLma4t7p7AInhfzicxmIMikRd4cERNbIAMH2QgvdMotQFAvBlQxymCzFNoAR6ApomI/ 7mnOCHRfO0E0dkyrPhKYi/D+lmgk+245kU3iYtfIpR441hVM0M10PK5n+L78VX9Pii1Q nSfp6Yd4yzvvoHzbbPmzKUkHp9rsOnXDuJA2bX0BjQj0hbBHxgRkI6F9/WnYfgLY6VY6 8Fwx1qXQPaIhaXhGLSgvTlBDW6lnccvSSXciKHDgs6cTwPYCuS64p6prYXO8LuYy9/PX RCBw==
X-Gm-Message-State: APjAAAX0P3m7WWGD5TIEPTuUgzPJpRTSXziWL/UlIyredB1Fkgs/LIp+ MTwjCfjBburcAQlVb2HhaFyJB74gZ7I0axu6CM0=
X-Google-Smtp-Source: APXvYqytfnhQBI7GuJ5Dr1JQIiuHo+csbXuJZ9aalSfIvM8mJ34ZXJP38R8fbuVdo1b32FuK+J0H4bJKueo6FlDE3Bc=
X-Received: by 2002:a67:bd05:: with SMTP id y5mr20045420vsq.180.1574709086189; Mon, 25 Nov 2019 11:11:26 -0800 (PST)
MIME-Version: 1.0
References: <D938B161-77F8-4C5A-A407-4E6B7609D02A@sn3rd.com> <CADqLbz+Hmw6EV6b2MjoLMq+Gnvs4KxQceZgrCEkxtqv9Db+0gQ@mail.gmail.com> <BN7PR11MB25472D90A2F91F2DDD3A9609C94E0@BN7PR11MB2547.namprd11.prod.outlook.com> <CADZyTkn5+za-=ObFdcUnXjNEJusfKowPi1owE6i1L2xoDzBmhA@mail.gmail.com> <000201d5a0e5$a47e6740$ed7b35c0$@gmx.net>
In-Reply-To: <000201d5a0e5$a47e6740$ed7b35c0$@gmx.net>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Mon, 25 Nov 2019 14:11:14 -0500
Message-ID: <CADZyTkkCiAvPzk92Nun-1yOaDKoe1=UcWPVFwZ7XYjAdZap0hQ@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Cc: Daniel Migault <daniel.migault=40ericsson.com@dmarc.ietf.org>, "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, TLS List <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b4fc2a05983087c8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/l-CJrOIUTRxn7FpSenb7zVUgIJg>
Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls
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: Mon, 25 Nov 2019 19:11:32 -0000

Hi Hannes,

My reading is that only compression/decompression applies to our case.
Fragmentation is optional and only concerns ipv6. I did not intent to make
the comment at an inappropriate time, but if so, please consider it when it
is appropriate.

Yours,
Daniel

On Thu, Nov 21, 2019 at 10:34 PM <Hannes.Tschofenig@gmx.net>; wrote:

> Hi Daniel
>
>
>
> Although inappropriate to discuss at the time of the adoption call I
> wanted to point out that I looked at SCHC and was surprised to learn that
> it is more than a compression scheme but also includes a protocol for
> adding reliability. In my reading is essentially a replacement for 6lowpan.
> Unfortunately, this design decision does not make it a well suited
> mechanism for a generic compression mechanism. I am happy to get convinced
> otherwise.
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* TLS <tls-bounces@ietf.org>; *On Behalf Of *Daniel Migault
> *Sent:* Friday, November 22, 2019 10:20 AM
> *To:* Panos Kampanakis (pkampana) <pkampana@cisco.com>;
> *Cc:* TLS List <tls@ietf.org>;
> *Subject:* Re: [TLS] Adoption call for draft-rescorla-tls-ctls
>
>
>
> I clearly support the adoption of the work, but it seems important to
> ensure cTLS integrates or remains in line with the work on compression that
> has been accomplished at the IETF - SCHC defined in lpwan might be a
> starting point. It also seems important to me that cTLS defines mechanisms
> that could be reused as TLS 1.3 evolves.
>
>
>
> Yours,
>
> Daniel
>
>
>
> On Fri, Nov 22, 2019 at 12:39 AM Panos Kampanakis (pkampana) <
> pkampana@cisco.com>; wrote:
>
> +1, support adoption.
>
>
>
> *From:* TLS <tls-bounces@ietf.org>; *On Behalf Of *Dmitry Belyavsky
> *Sent:* Thursday, November 21, 2019 4:46 AM
> *To:* Sean Turner <sean@sn3rd.com>;
> *Cc:* TLS List <tls@ietf.org>;
> *Subject:* Re: [TLS] Adoption call for draft-rescorla-tls-ctls
>
>
>
> I support the adoption.
>
>
>
> On Thu, Nov 21, 2019 at 8:36 AM Sean Turner <sean@sn3rd.com>; wrote:
>
> At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG
> and the LAKE BOF, which is now a chartered WG [3].  After some discussions,
> the ADs suggested [4] that the TLS WG consider whether this draft be
> adopted as a TLS WG item. LAKE could then later specify/refer/adopt/profile
> it, as appropriate. The authors revised cTLS and presented the revised
> draft at IETF 106 [5].  At IETF 106 there was support for adoption of cTLS
> as a WG item..  To confirm this on the list: if you believe that the TLS WG
> should not adopt this as a WG item, then please let the chairs know by
> posting a message to the TLS list by 2359 UTC 13 December 2019 (and say
> why).
>
> NOTE:
> : If the consensus is that this draft should be adopted as a WG item, then
> this will necessarily result in a WG rechartering discussions.  We would
> have gotten to this rechartering discussion anyway now that DTLS 1.3 is
> progressing out of the WG.
>
> Thanks,
> Chris, Joe, and Sean
>
> [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/
> [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/
> [2] https://github.com/ekr/draft-rescorla-tls-ctls
> [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/
> [4] https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk
> [5]
> https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tls-13-00.pdf
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
>
> --
>
> SY, Dmitry Belyavsky
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>