[TLS] Empty CertificateRequest.supported_signature_algorithms in TLS 1.2

Martin Thomson <martin.thomson@gmail.com> Wed, 21 November 2018 21:50 UTC

Return-Path: <martin.thomson@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 BD002130DC5 for <tls@ietfa.amsl.com>; Wed, 21 Nov 2018 13:50:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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 txqVL49vLb4i for <tls@ietfa.amsl.com>; Wed, 21 Nov 2018 13:50:33 -0800 (PST)
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 D8E7F12F295 for <tls@ietf.org>; Wed, 21 Nov 2018 13:50:32 -0800 (PST)
Received: by mail-ot1-x32a.google.com with SMTP id 40so6333657oth.4 for <tls@ietf.org>; Wed, 21 Nov 2018 13:50:32 -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:cc; bh=ltCtWBL53wAVmmG4mwfsWBy0ewd8qKspJt4f5fSsctQ=; b=pbI5MNSK2aOJ+0VoEDykO+nhALIdWeKg16GavE8NPkRJaLkiAG9s3033koG60o7aaT 0UoGblGw23IXkAq5RFDwKaaXsno0VPelIuCPueitnkbO1Pvpo5Ibbm8UdSnp7Kjj/rwR ndyfqksMaw3dCqa8iCUSKNfQYtXL6Xr0jPh/3jS2FiAZbgCmQdt9uWFrHZDgREk7nROz lXeoTxbOs4rFrk5ByB4P3ggM+xb1v9Z/DbAXb5xHvxR0VzwIBcMkxAw5xNW2fPt0kGpA JnJ7hFE+Vqem6nU7SJ3DLJjgiDWcKp6sXnU2GVzjUUKV2jZfn/K57cUJDrHYJTLtJMpE 0Fpw==
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:cc; bh=ltCtWBL53wAVmmG4mwfsWBy0ewd8qKspJt4f5fSsctQ=; b=afoTy6/KF2E4aKbzNF5psHuX993YBOaeGPN5t3fowzxrLSvBcNzaEWaf9P8+sAXIZe h2cuvtqBVk5ghOyPU+6pQXyIxiw8W09fCPSIIUn0cLMK6BqquMpocTyvGNlE54Bm+pNG fg05i1hNdMLyUo/w8+/GKqIkq4Muq+sH9mIlD5ykiQYA4nW6++6zQPnXuoU0yw6DgcGO JkkfK3BVCYUW/zYE23Et4UbsLoF8xflIBE6t+uPsYWcTTIKu4+5cIWShft+9nkICGOD8 xF70EqIrVd1+w7xR3KDM0s8Fo4+yUyX3Yt/INPWNoYWmvcioRIUoltajSTG4JJybG5ZP txtA==
X-Gm-Message-State: AA+aEWYia/jnLkew24+q+LUeOrOAgWhinUuF0wXvBrMyvai3XCscwz3y eEyfuOlawJ+VQnPLMW18uyHgTD2TjRu6nEP7fpsrhMSo
X-Google-Smtp-Source: AFSGD/UE6pqDjWdr0giSW9+vDKLtPEZKacfrvr+FaIiRlCcGGpPPyjkK57iDdQYFoNhOebG2xlu3L3D5+EeOimKGwEk=
X-Received: by 2002:a9d:7c86:: with SMTP id q6mr5279578otn.257.1542837031902; Wed, 21 Nov 2018 13:50:31 -0800 (PST)
MIME-Version: 1.0
From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 22 Nov 2018 08:50:21 +1100
Message-ID: <CABkgnnUxd_cbh-kASTTyPbGvk1fg2cUfUWwNa4cvB2DV8kMRSw@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2mm9eCTGrmI8G9V05botNT2qb0Q>
Subject: [TLS] Empty CertificateRequest.supported_signature_algorithms in TLS 1.2
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, 21 Nov 2018 21:50:35 -0000

In attempting to fix a bug related to this, a question came up about
what the semantics of an empty value is here.  Some implementations
seem to infer that empty means {*,SHA1}, which effectively assumes
that an empty value is equivalent to an absent signature_algorithms
extension (Section 7.4.1.4.1)

The text on CertificateRequest is less clear about what to do.  That's
understandable because it doesn't have to deal with the value being
absent because it's not optional.  All we have to go on is this from
Section 7.4.8:

   The hash and signature algorithms used in the signature MUST be
   one of those present in the supported_signature_algorithms field
   of the CertificateRequest message.

We think that treating an empty supported_signature_algorithms field
as an error is the best response and plan to implement that change.
We'll send a fatal alert if we receive one.

This is consistent with our handling of the signature_algorithms
extension, where we treat an empty list as a failure.