Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Christian de Larrinaga <> Sat, 05 December 2020 11:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD05D3A0147; Sat, 5 Dec 2020 03:50:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Status: No, score=-1.319 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, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rajBiFlL2tTt; Sat, 5 Dec 2020 03:50:58 -0800 (PST)
Received: from ( [IPv6:2001:41c8:51:8b8::184]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 252EE3A011B; Sat, 5 Dec 2020 03:50:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=tranquility; h=Content-Type:MIME-Version:Message-ID:Date:In-reply-to:Reply-To:Subject:Cc:To:From:References; bh=ixlEKVTgTuURG+tEu0vfZfcJcJxNaWGYIvcxfFBPPrI=; b=DSPamYNGKnWpMN/GQe5DB4UYkwIlC8UA1qpHwiZQpc5SkxYqYPZ/a+Tv0Jo1KrWXDI47SdiPPWZME4ESg4Bydv8e1P6r3jWIT1Ijz+9NXDh0IRcetm2EDneK4euDCXslDbUgE0RXCmwKj0LrxaPQ7+44R4zm9rBXXwxykJG3y0o=;
Received: from ([] helo=christian-yoga) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1klW5V-0007oO-6e; Sat, 05 Dec 2020 11:50:53 +0000
References: <> <> <>
User-agent: mu4e 1.5.5; emacs 28.0.50
From: Christian de Larrinaga <>
To: Nick Hilliard <>
Cc: Ted Lemon <>,, "Ackermann, Michael" <>,
In-reply-to: <>
Date: Sat, 05 Dec 2020 11:50:01 +0000
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 05 Dec 2020 11:51:00 -0000

Nick Hilliard writes:

> What's relevant to the IETF is that it needs to make sound technical 
> recommendations about the usability and appropriateness of standards. 
> If organisations choose not to keep supporting some or all of their 
> product lines, this shouldn't impact the IETF's ability to do its job.
> Nick

However governments are busy writing up standards for managing the
secure  deployment of devices. The UK's DCMS has been working on this for a couple  of years

The local ISOC chapter has been engaging on this. On that count IETF
participants might like to keep engaged with those ISOC chapter
liaisons? Who I'm sure would be grateful for informed input as well. 

As a general observation the issue of vendors falling away from
supporting  devices is at odds with the promoted market model of
licensing IPR and maintaining restrictions over IPR after support falls

Unless that IPR becomes public domain - or opened at least in regards
the scope of empowering the right to repair etc.

The practicalities of that is something IETF can think through as part
of its IPR policies?

Another observation is that manufacturer/vendors who force updates on
their  devices will tend to consider their own devices not others which
in context of "IoT" are very likely to also be interoperating from other vendors
or FOSS / hardware. That creates space for lots of stools for security to fall between. 

The issues around interoperability also means serving the responsibility
of user administrators across whatever pool of vendors or FOSS supply chains they choose to
deploy and commission support. Depending entirely on each vendor you use
has never been a good idea if you want a functional system.

So specifications to serve interoperability in terms of securing real world
installations of devices running from a selection of IETF defined
protocols is something IETF can think about too?

For discussion? I would expect that thinking to not assume "vendor" lock in but empower user
administrated support in concert with vendor support (if chosen (not
imposed)) as long as that is available and faciitate open alternatives particularly when that falls away.

This also seems a point where IETF specifications can offer

Christian de Larrinaga