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

Stephen Checkoway <> Sun, 30 November 2014 21:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 663681A1A9F for <>; Sun, 30 Nov 2014 13:52:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gcpuEXZUcs6b for <>; Sun, 30 Nov 2014 13:52:40 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E46FA1A1A99 for <>; Sun, 30 Nov 2014 13:52:39 -0800 (PST)
Received: by with SMTP id j7so6502132qaq.1 for <>; Sun, 30 Nov 2014 13:52:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=KTEBDFe6or6hMJvXo3/hD3ANkt3UX97/Kv8oCqkDmPg=; b=bQ+I8fMxu+0KPcYWCGOo0n+Ho6+gQ70PhGI/soSJmLhoycy9GUroixduC4JvxgVqfv bnUbYHXNerRWDa4tWRuq1vxadyHw9ep0ek01oqH3j1jV8tKVTAyJeep9MKuxx63pg54e fL/dLsJ52kYYHmJCPsqIWRWFhq+SZ5xoP9txcF21bi2kzxg+xkXgzubyHMaxwUdW4bVw WyInEMWAjBtFay7jXga8GxkjY06II26ZAacp7t09QLI8qbCM8dADxgmq/SRjy/qhxgta 2SfbIosgWRJNHH4UKZrtV7OTtguyHlaiZ9OYvGwn4ekhDLVB/JifHWbdLXLkpXiE29SP afmA==
X-Gm-Message-State: ALoCoQk6rBUkoJIh6Ub8Hc6h2dtuK2+MLT5SCDy8OwYZCjaZ6m4aQEl8A/5icdU/Lj4MZorl4P79
X-Received: by with SMTP id l5mr7869578qad.44.1417384359130; Sun, 30 Nov 2014 13:52:39 -0800 (PST)
Received: from ([]) by with ESMTPSA id e6sm15579043qab.42.2014. for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Nov 2014 13:52:37 -0800 (PST)
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 208D2AC2841; Sun, 30 Nov 2014 16:52:36 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Stephen Checkoway <>
In-Reply-To: <>
Date: Sun, 30 Nov 2014 16:52:35 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Peter Gutmann <>
X-Mailer: Apple Mail (2.1878.6)
Cc: "<>" <>
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 21:52:41 -0000

On Nov 30, 2014, at 5:09 AM, Peter Gutmann <> wrote:

> 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).

Sorry, I missed the prior discussion.

> 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.

That seems wrong. In practice, a client connects and says I'm willing to communicate using protocol parameters X, Y, and Z. If the server can't accommodate the client, it closes the connection. How is the signature algorithm any different from the cipher suite in this respect? If the client says it can only do ECDSA, what's the point of giving it an RSA cert that it cannot use?

> 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.

Why does this same reasoning not apply to the symmetric algorithm? E.g., the client wants AES but the server decides 3DES.

Stephen Checkoway