Re: [TLS] TLS Flags and IANA registration policy

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 25 October 2021 18:20 UTC

Return-Path: <ilariliusvaara@welho.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 EBADC3A1316 for <tls@ietfa.amsl.com>; Mon, 25 Oct 2021 11:20:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=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 nVErYQET1Ez2 for <tls@ietfa.amsl.com>; Mon, 25 Oct 2021 11:20:10 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2b.welho.com [83.102.41.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4E33A12F7 for <tls@ietf.org>; Mon, 25 Oct 2021 11:18:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 40BF3D00F0 for <tls@ietf.org>; Mon, 25 Oct 2021 21:18:02 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id ktXrAyutBj8z for <tls@ietf.org>; Mon, 25 Oct 2021 21:18:02 +0300 (EEST)
Received: from LK-Perkele-VII2 (87-92-216-160.rev.dnainternet.fi [87.92.216.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 089692A9 for <tls@ietf.org>; Mon, 25 Oct 2021 21:18:00 +0300 (EEST)
Date: Mon, 25 Oct 2021 21:18:00 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: IETF TLS <tls@ietf.org>
Message-ID: <YXb02ETjp3dbFrXh@LK-Perkele-VII2.locald>
References: <DBBPR08MB59153B444624CEA8EC6E9A66FA819@DBBPR08MB5915.eurprd08.prod.outlook.com> <YXPSz6Uw9CDgl7tX@LK-Perkele-VII2.locald> <DBBPR08MB59157A0F39745E84309DDD8DFA839@DBBPR08MB5915.eurprd08.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <DBBPR08MB59157A0F39745E84309DDD8DFA839@DBBPR08MB5915.eurprd08.prod.outlook.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/nhTjhPkfPsK3hCHcSS8G_LZF42w>
Subject: Re: [TLS] TLS Flags and IANA registration policy
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 Oct 2021 18:20:20 -0000

On Mon, Oct 25, 2021 at 05:13:07PM +0000, Hannes Tschofenig wrote:
> Hi Ilari,
> 
> > "If an item is not marked as 'Recommended', it does not necessarily
> > mean that it is flawed; rather, it indicates that the item either
> > has not been through the IETF consensus process, has limited
> > applicability, or is intended only for specific use cases."
> 
> I think the flags draft should state that (if that's how it should be interpreted).
> 
> FWIW I looked through the current list of extensions and their Y/N
> assignment for "recommended". The assignment appears random. This is
> not surprising that extensions are, by their nature, related to
> specific use cases and therefore have a certain applicability only.

Yeah, the assignments are pretty strange, here are some recommended
ones I think are odd:

- trusted_ca_keys: Wasn't that supposed to be deprecated?
- client_certificate_url: No replacment in TLS 1.3, security issues.
- user_mapping: No replacement in TLS 1.3, who uses this?
- ec_point_formats: No replacement in TLS 1.3, who uses this?
- heartbeat: The most infamous extension of them all.
- token_binding: No replacement in TLS 1.3.
- status_request_v2: Who uses this (at least TLS 1.3 has a replacement)?
- session_ticket: Nasty security issues (destroys forward secrecy of
  any connection it is used on).
- transparency_info: Similar to signed_certificate_timestamp, which is
  not recommended.

On the reverse side, not recommended extensions, there does not seem
to be any really strange ones (I presume some are due to procedural
matters, and will be changed to recommended later).

I dinged extensions for not working and not having replacment in TLS 1.3,
as one would think that all the common stuff would have replacements.


Then on stuff other than extensions, there are some other odd ones:

- ciphers TLS_DHE_RSA_WITH_*: Negotiation is flawed.
- ciphers TLS_DHE_PSK_WITH_*: Who uses this?
- exporter label "client finished": Actually reserved.
- exporter label "server finished": Actually reserved.
- exporter label "master secret": Actually reserved.
- exporter label "key expansion": Actually reserved.
- exporter labels: Why is there recommended column at all?


-Ilari