IETF Logo Mail Archive

Re: [TLS] Adoption of TLS-LTS

Hubert Kario <hkario@redhat.com> Tue, 14 June 2016 10:23 UTC

Return-Path: <hkario@redhat.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 DAE6912D143 for <tls@ietfa.amsl.com>; Tue, 14 Jun 2016 03:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.348
X-Spam-Level:
X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 IL93Eeu5ndZ1 for <tls@ietfa.amsl.com>; Tue, 14 Jun 2016 03:23:19 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F369512D097 for <tls@ietf.org>; Tue, 14 Jun 2016 03:23:18 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D536C7D0FD; Tue, 14 Jun 2016 10:23:16 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5EANFJJ019092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jun 2016 06:23:16 -0400
From: Hubert Kario <hkario@redhat.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Date: Tue, 14 Jun 2016 12:23:05 +0200
Message-ID: <1843800.YErRuY4C85@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.4.12-200.fc22.x86_64; KDE/4.14.17; x86_64; ; )
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CA0C94@uxcn10-5.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C73F4C9CA49@uxcn10-5.UoA.auckland.ac.nz> <22902566.AuEvmjhU12@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4CA0C94@uxcn10-5.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart5844766.OFXazMUsBD"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 14 Jun 2016 10:23:18 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/wLcr5gxmVi4L99KIb2yXlVrKc_M>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Adoption of TLS-LTS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 14 Jun 2016 10:23:21 -0000

On Monday 13 June 2016 19:51:42 Peter Gutmann wrote:
> Hubert Kario <hkario@redhat.com> writes:
> >to be pedantic, the RFC describes itself "a profile" while in reality
> >it modifies the protocol in a way that will make it incompatible
> >with "vanilla" TLS 1.2 implementations
> >
> 
> Oh, right.  Well that's easily fixed, I used "profile" because I
> couldn't think of a better term, the best I could come up with is
> "plan", but it's not really a plan either.  If people think "plan" is
> better than "profile", and it deals with Russ' objection, I'll change
> it to that.  Alternatively, if you can think of a better term than
> "plan", let me know (or forever hold your peace
> :-).

"TLS refitting for Long Term Support"

"Adaptation of TLS for Long Term Support"

"LTS revision of TLS"

"LTS addendum to TLS 1.2" (amendment?)


If "revision" does not overload the word too much in this context, it's 
the one I would vote for.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

v2.23.0 | Report a Bug | By Email