[TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda)

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 11 March 2015 05:19 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979081A0121 for <tls@ietfa.amsl.com>; Tue, 10 Mar 2015 22:19:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.81
X-Spam-Level:
X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 m6A8KnrF2OiV for <tls@ietfa.amsl.com>; Tue, 10 Mar 2015 22:19:22 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B6BB1A01D5 for <tls@ietf.org>; Tue, 10 Mar 2015 22:19:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1426051162; x=1457587162; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=HeWZTHaZyFzKS7eBi6uCZLu85UyFr4uXCnJNpK+HE7M=; b=hYeVqEbwhS/lr69+id7KpjNPJnb1HTVVJ0AWGjSiOAiKcYBFrh/ZWQOD NNGBz4b+V9wEPa3AagvHH7+slW8f0bqn8vDJbHtepNtcCT122rDZ8OdwK 1hM1j1T9O4oU32LMQz3eR3A6h8hIbCKYJMNUj8lSbPgo60p3b/hW7GrSh M=;
X-IronPort-AV: E=Sophos;i="5.11,379,1422874800"; d="scan'208";a="312779946"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 11 Mar 2015 18:18:56 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Wed, 11 Mar 2015 18:18:45 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda)
Thread-Index: AdBbutj/GQoOkX6CQ860U24KvSczcQ==
Date: Wed, 11 Mar 2015 05:18:45 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFAD5D2@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/onnbpDeEm_VPdOG7x89j2crIgZ4>
Subject: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 11 Mar 2015 05:19:26 -0000

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:

>Backwards compatibility:
>
>Is this about what is needed for compatiblity with past TLS versions?

TLS 1.3, which I've already pointed out several times has so little backwards
compatibility that it should be called TLS 2.0, doesn't need to be hamstrung
with retaining stuff from the other TLS 1.x versions, for example the totally
pointless:

>- The first byte of record header needs to remain subprotocol id (for
>  muxing TLS with other stuff)

(and many others).  It's already so different even to TLS 1.2 that there's no
point in retaining some crufty old artefact of SSL 3.0 just because we've
always done it this way.  If there's a feature that's useful or important to
the functioning of the protocol then by all means include it, but there's no
point in dragging along old protocol misfeatures "for backwards compatibility"
when so much else has changed incompatibly.

Peter.