[TLS] Proposed Errata for rfc5246

Loganaden Velvindron <loganaden@gmail.com> Wed, 14 November 2018 07:07 UTC

Return-Path: <loganaden@gmail.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 7D86A130DC7 for <tls@ietfa.amsl.com>; Tue, 13 Nov 2018 23:07:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 u99dfTgPt-K3 for <tls@ietfa.amsl.com>; Tue, 13 Nov 2018 23:07:26 -0800 (PST)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D179C130DD4 for <TLS@ietf.org>; Tue, 13 Nov 2018 23:07:25 -0800 (PST)
Received: by mail-io1-xd33.google.com with SMTP id b26-v6so10295064ioc.6 for <TLS@ietf.org>; Tue, 13 Nov 2018 23:07:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zcaX3GUIyMBap8TeHEOlYsJsSgdYzzAPFi+CyLkYKq8=; b=NxcP4z2axv/JobZHMxsJJIdsnnG7dR6N6dHu2pBKjkMEHBqo0Gsp8DP+Gjqd5kZEeM dnVNPZphLyjjepYJ4viUHt2SkUWvVYwqc7UH7lxL4Cdjv5Q9t3EhCPimrpzb0YXVbWao Ec7pQX8zfxxj5xGxzOEfO6CwjuXbG8BTxksMhENn+n5Ra8j7hWJamOUqhZrV2HdeOH61 1fxtQhXG2kIxWutt5fLXQitefX2Q9Ge8cyJ6oPZ32QPzqJunmL2p0GNVgfXP2Mv5fSlP 3FWcXSjtj2ro/4GGrurJYM3hTOXrVYLmw+FNgZbSECPwWKUxhZBoWpfkkN3i+moRy2Tk py2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zcaX3GUIyMBap8TeHEOlYsJsSgdYzzAPFi+CyLkYKq8=; b=JRZBBDiYA1zhH7aMNa96EKRwuVhXVorf8UTfeUOTLHhnoOxdBzHbY0i2WKj5i3YGnh jd0JfPKiC8dRqHR3vYnWPzEBK6iWZ/plYovpAOtLIdQ2LkQ3A+nWcWNlpTXVfQ08mL3D e+lp0JyC3AUYAoeFAwFX34viz7VOE/B5VIcO89uei/JpCGRBM7jB4XNSuzkQojGBNj9B 0RvF1uzKFVhcBDOlEXv63fvpZebzh6O2/2cQcBJ26Gq4MlRiafFlz71FV0sLdnIPBoC3 Iq3oOwv5PcPimPJkeoF+1Fwj6pmYcEdWOcPD/h++tDFqYfKb9X32P/s7Ws2Zc3V1LTbP bddw==
X-Gm-Message-State: AA+aEWZyAwwsEUzFmjNBSQ7ocX2Uh1eF8Iio+BbTUvITEV/RTCIEB1/W uufEsmtHBnyC6daoxNkw94JQL7Ux+WI2s+qc6JDp/k+O
X-Google-Smtp-Source: AJdET5c+BiDFMvEId7rdD6fe7n/co4bz5ly+BQmoN+14uROJ0kIp7S17EqQMQSXzDBkYi/Yqb/aC4Xkzd55SGiYrJOY=
X-Received: by 2002:a6b:1503:: with SMTP id 3-v6mr544584iov.7.1542179245049; Tue, 13 Nov 2018 23:07:25 -0800 (PST)
MIME-Version: 1.0
From: Loganaden Velvindron <loganaden@gmail.com>
Date: Wed, 14 Nov 2018 11:07:13 +0400
Message-ID: <CAOp4FwQVNmPqsx+BH9NmNCUfuw+UH1S1hpeO1AFKHr-g_bj02g@mail.gmail.com>
To: "<tls@ietf.org>" <TLS@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000014ccda057a9a9633"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/M9zcnPj899e1ZSgo4s3Qo9u1csk>
Subject: [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:07:27 -0000

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.