Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis

Peter Gutmann <> Sun, 30 November 2014 10:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7CEEB1A0018 for <>; Sun, 30 Nov 2014 02:10:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mOUdV6A8qL_Y for <>; Sun, 30 Nov 2014 02:10:00 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2BE281A0013 for <>; Sun, 30 Nov 2014 02:09:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=uoa; t=1417342202; x=1448878202; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=60698mBT7u5bg7t8OJUJDIvBPAnkwj0Lb7PNkmPa1JA=; b=ZRYkanic4qMLkszSktbXBtjLERBQ0VIuWotlq6NbS84ZqbH0fn+vp2lj R86WZOn1qJnP3qItKqidAt7HXowS+a6FPU07dy5Uv9/bqN5qZNJgbkrbv MGjWGENpb1MDEJcYbZbtHoknyymDUh0l1oXWexDhZ3WMKOPPNn1QXMdUJ w=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="293897385"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 30 Nov 2014 23:09:58 +1300
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Sun, 30 Nov 2014 23:09:56 +1300
From: Peter Gutmann <>
To: "<>" <>
Thread-Topic: [TLS] WG adoption: draft-nir-tls-rfc4492bis
Thread-Index: AdAMhcqRURR5jkHMSL26EXhLM3yQJw==
Date: Sun, 30 Nov 2014 10:09:56 +0000
Message-ID: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 30 Nov 2014 10:10:05 -0000

Stephen Checkoway <> writes:

>TLS 1.2 specifies
>   If the client provided a "signature_algorithms" extension, then all
>   certificates provided by the server MUST be signed by a
>   hash/signature algorithm pair that appears in that extension.

Which is one of the nonsensical requirements in TLS 1.2 that you pretty much
have to ignore in order to get an implementation that works (it's been
discussed on the list before).  Consider how this is supposed to work in
practice: A client connects to Amazon and asks for ECDSA_P521_WITH_SHA384.
Amazon puts the client on hold and goes to Verisign and requests that they
reissue their entire cert hierarchy up to the root using ECDSA-P521 with
SHA384, and then buys a new certificate using the requested algorithm.  They
then wait for Windows Update to propagate the new CA certs out to the client,
and after a few weeks on hold the client connects.

At the time this was discussed, the approach by everyone who contributed was
that the client got whatever the server had available.  In the rare cases
where the server had more than one cert then "signature_algorithms" could be
used to implement a MAY, but it still won't change the fact that beyond the
server cert you get what the CA gives you and nothing else, no matter what the
TLS 1.2 RFC may wish for.