Re: [TLS] Update spec to match current practices for certificate chain order

Peter Gutmann <pgut001@cs.auckland.ac.nz> Mon, 11 May 2015 15:03 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 D85551A8A9B for <tls@ietfa.amsl.com>; Mon, 11 May 2015 08:03:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Y3djCG2l3B15 for <tls@ietfa.amsl.com>; Mon, 11 May 2015 08:03:28 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA521A8A29 for <tls@ietf.org>; Mon, 11 May 2015 08:03:28 -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=1431356609; x=1462892609; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Q/u1TjVzY/BB9VY38EAlF5A5lIC7RCLWL7xD9qN30m8=; b=rwWRy7VKkGVYPEDlqzGW44RYJhV1gyPaGFrsvfzOgr8X9LpKMrD5EcTs UJuQLlb6x2mtyRW/FVpWJfYTmsIqJUJHn9HLGptvPjpLN93adFfKkDYSq stJU+M24HVYao3HH3tusSKQIgs2NWbZW/Vc21sEKoe6K/hiKKNoLqf1KM U=;
X-IronPort-AV: E=Sophos;i="5.13,408,1427713200"; d="scan'208";a="4348932"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 12 May 2015 03:03:27 +1200
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Tue, 12 May 2015 03:03:26 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Update spec to match current practices for certificate chain order
Thread-Index: AdCL+6Ggvko2QiXYRsOnC3jKu9WpAg==
Date: Mon, 11 May 2015 15:03:25 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB01B158@uxcn10-tdc05.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/AtagA0JPYRuNV5SR4FKVL432Ow4>
Subject: Re: [TLS] Update spec to match current practices for certificate chain order
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: Mon, 11 May 2015 15:03:31 -0000

Martin Rex <mrex@sap.com> writes:

>As previously mentioned, all TLS specifications up to and including TLSv1.2
>have been extremely clear that the name contained in the certifcates is a
>matter of the protocols & software layers on top of TLS, and none of TLS
>business:
>
>https://tools.ietf.org/html/rfc5246#page-5
>
>                                  the decisions on how to initiate TLS
>   handshaking and how to interpret the authentication certificates
>   exchanged are left to the judgment of the designers and implementors
>   of protocols that run on top of TLS.

Oh, I thought that was just marketing fluff rather than a hard-and-fast
requirement.  If it is a set requirement for the protocol though then it shows
a major disconnect between the protocol designers and its users, you've got a
protocol that promises to do cryptographic authentication of the server so
that developers of apps running on top of it don't have to deal with this, and
yet in that one sentence it quietly makes it Someone Else's Problem.  So the
developers of the thousands of vulnerable apps will be assuming that the TLS
layer [0] will do the checking for them, while the TLS layer can conveniently
say "well, it's not my problem, and I've got the weasel-words to prove it".

Peter.

[0] There's probably a better term to use here than Transport Layer Security
    layer.