IETF Logo Mail Archive

Re: [TLS] Proposed Errata for rfc5246

Russ Housley <housley@vigilsec.com> Wed, 14 November 2018 07:12 UTC

Return-Path: <housley@vigilsec.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 078FF130DD4 for <tls@ietfa.amsl.com>; Tue, 13 Nov 2018 23:12:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 KA2JkbhFcPcz for <tls@ietfa.amsl.com>; Tue, 13 Nov 2018 23:12:04 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1AC12896A for <TLS@ietf.org>; Tue, 13 Nov 2018 23:12:03 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id AD376300AB6 for <TLS@ietf.org>; Wed, 14 Nov 2018 02:12:01 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jGZLz5fNbBKS for <TLS@ietf.org>; Wed, 14 Nov 2018 02:12:00 -0500 (EST)
Received: from dhcp-9bbe.meeting.ietf.org (dhcp-9bbe.meeting.ietf.org [31.133.155.190]) by mail.smeinc.net (Postfix) with ESMTPSA id 3CBF2300A4E; Wed, 14 Nov 2018 02:11:58 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <1717ABFE-0D75-4546-AC95-2D2B88D84BAD@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_52F94E5D-E34A-4A7E-BBEE-1E072D765A7A"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 14 Nov 2018 02:11:01 -0500
In-Reply-To: <CAOp4FwQVNmPqsx+BH9NmNCUfuw+UH1S1hpeO1AFKHr-g_bj02g@mail.gmail.com>
Cc: IETF TLS <TLS@ietf.org>
To: Loganaden Velvindron <loganaden@gmail.com>
References: <CAOp4FwQVNmPqsx+BH9NmNCUfuw+UH1S1hpeO1AFKHr-g_bj02g@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Fd1LTwYMgZJdU98LGsrpbaaZVOE>
Subject: Re: [TLS] Proposed Errata for rfc5246
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 14 Nov 2018 07:12:06 -0000

The intent is that the server pick the most preferred signature algorithm that is supported and meets local policy.  Given the local policy aspect of the server's choice, it can be any one offered by the client.  The client should not offer any that are not acceptable according o their local policy.

Russ


> On Nov 14, 2018, at 2:07 AM, Loganaden Velvindron <loganaden@gmail.com> wrote:
> 
> Hi folks,
> 
> Bob Beck of OpenBSD/LibreSSL reported this issue with an implementation:
> "
> Fun fact: The TLS 1.2 signature algorithms extension is sent in client preference order. http://outlook.office365.com  <https://t.co/EOcbx3oZpI> then chooses the least preferred. every time.
> Additional fun fact: I believe it is still standards compliant. RFC5246 says only that it must be sent by the client in preference order. It does not say the server must respect the order.
> "
> My suggestion would be something like:
> Section 7.4.1.4.1 <https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1>. current text:
> 
>  Servers MUST NOT send this extension.  TLS servers MUST support
>    receiving this extension.
> 
> Suggestion:
> Servers MUST NOT send this extension. TLS servers MUST support receiving this extension. TLS servers MUST respect the order in which the signature algorithms are sent by the client.

v2.23.0 | Report a Bug | By Email