Re: [TLS] Proposed Errata for rfc5246

Martin Thomson <> Wed, 14 November 2018 11:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66FAF126F72 for <>; Wed, 14 Nov 2018 03:58:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tVEs9hVzBZsX for <>; Wed, 14 Nov 2018 03:58:56 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A01E124408 for <>; Wed, 14 Nov 2018 03:58:56 -0800 (PST)
Received: by with SMTP id u3so9346531ota.5 for <>; Wed, 14 Nov 2018 03:58:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=g86R1yWI/AqiabhZRG1O5SDGPc7IKyTeFX1yJMudEwo=; b=DRhBjgi6jBEa/aHAdWo7MdTJiTxBIghHcIXyOt+EmwfGpP94sXGojgYD8hS7Bk6RQo t1oXB3+LTHilL1EVly3c724UBfoFUg3NWbWud6bPQkE+fbn7+z/QYafa6g4YAQVOI2Ig 86RZtPQ874OBmQqFCJrXbbX4zeMxAziP2QXzCTgfrLZ+ZVaCFrG7kKzs/+M93JZP3MV1 qp8KQItpL8JDqoSuMVeuWqoVmwtentZNrqXknv3bCnjtyigIoI6NW2RzQPgPB4g6ePVz 1UtNK7c/9Taho731Q+tyUS7JsKOhdUWbUka6AJanfJU9kbDPIgwIg8kWFbL5KeHxFTsc Vbqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=g86R1yWI/AqiabhZRG1O5SDGPc7IKyTeFX1yJMudEwo=; b=GQXw3W+oRh0gbur4fQeMZq4d6Yb2mHmbH7/icI0/Df8teMvsXcKBcc6rf3AZdttzAW CvqoRM3Cm8wTxkfoWOjfrSFwhXI7+NtOQOtK6fvhIk6V1h3yi21bktfOmlJNooj9n0sj gcLeTv3L1VDG9mXJCeSBGSTPMYQWj4FsdEVUaN5VUWhAWoPml6eWxt7hK4jbGv/XbiX1 kcXCmqFhjoTAonc8GRali85h9TNNm4eejXHBOZYQRAaUS15ObKjb2Ik7v4InKQPnyMDw r33YsMVc9WLM56liXTO9cvZqKOlTFBCQskV6uZn8pwG6iTThsXNDw8aP6GCa1EAI5gLC 5lKg==
X-Gm-Message-State: AGRZ1gIazFkdf3nu/l4f6Zi7BURR1UVFge6GqaYq7ERboXDIvRfA1ogS Kjb1MRNgzQjeNLKWFWeMtDtVo43dVlo5m8CGiJ8=
X-Google-Smtp-Source: AJdET5dOw0/hX5RkAHL9EISW2pCjmBGF/EWTCbfgPNIciPxlSuTj6eZJjpmeQ0nZSUDqo5gUwUbLHxlBXdxdO0Mh/KI=
X-Received: by 2002:a9d:f44:: with SMTP id 62mr901557ott.299.1542196735059; Wed, 14 Nov 2018 03:58:55 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Martin Thomson <>
Date: Wed, 14 Nov 2018 22:58:45 +1100
Message-ID: <>
To: Russ Housley <>
Cc:, "<>" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [TLS] Proposed Errata for rfc5246
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Nov 2018 11:58:59 -0000

For the record, NSS servers always pick their choices first, except
for key shares in TLS 1.3 where P-256 and X25519 are considered equal
and the one with a share wins.  Some servers do similar things for
ChaCha20Poly1305 vs. AES-128-GCM, where maybe client ordering
indicates a preference where the server doesn't care.  For instance,
the client might not have AES-NI or equivalent and so prefer not to
use AES.  We never got around to implementing that one, but its the
other case I'm aware of.  Otherwise, servers can and do pick what they
like, which is usually the right way around in my opinion.
On Wed, Nov 14, 2018 at 6:12 PM Russ Housley <> wrote:
> 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 <> 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.  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 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.
> _______________________________________________
> TLS mailing list