Re: [TLS] Empty CertificateRequest.supported_signature_algorithms in TLS 1.2

David Benjamin <> Wed, 21 November 2018 22:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8F7412D7F8 for <>; Wed, 21 Nov 2018 14:08:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.959
X-Spam-Status: No, score=-10.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4q-S82GgSgzA for <>; Wed, 21 Nov 2018 14:08:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::842]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D905312D4E9 for <>; Wed, 21 Nov 2018 14:08:57 -0800 (PST)
Received: by with SMTP id r14so5551446qtp.1 for <>; Wed, 21 Nov 2018 14:08:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lz/zqq8x16qsBBhFZQJ20gi2njNIA0on0ewqliF8p0U=; b=h0u0tNSNaYUopcWROrdzi97mxZmwLTekJHqxHDkhJD2EGMnEVpfTTGxBrmJq99oSjE sg5q0a6d/ZVJqMgYINPNdf18Ydk/e8sfsyO9x5Ta8NIhRHdsa3uSqi/Z/MrWE8W0Yekn yPveibSOBcxHR7j6FHb0Og+Zfys/X9Qz6q1qk=
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; bh=Lz/zqq8x16qsBBhFZQJ20gi2njNIA0on0ewqliF8p0U=; b=fiK/s56CvME+HsOyK9yEn19VLiBfm/FT1xxmOjiJrKERUw6DZMuL71yeBQA3QizHfO iFAVIXZXGzFc59jPDvsAG4FQluzr2xIIzlNCwtj03nj8uDuwuwhR6EWaBX95M2Pd4N8C 70FKQ7jEQIAoZiR40HTo7ZRKh196Y5atniFXRnK2Vcuyw4bkzvzurNJyF17kgUyONIcR rzySz+3uoljQg0p6czE1XVcKMpXMltpCQBTUGZchbo6jGV6vdLNfBrv4PhOnwYcIfRxa m9oSqzzp9aTmNWMkM75Wk6YLu0aggNDgSn30sm5apqV17e1OvzIzSa3MhxWYCoPMla20 mmIw==
X-Gm-Message-State: AGRZ1gI6jO1X12IaCYfCK6p8ffZG4S6GeVUscBJfucWerrmF39A9FMoa XHsqXIq5eRBxJJlNF8IctRuhZqBbAmh6s4glAA2F
X-Google-Smtp-Source: AJdET5cYheAA8B+cSyqIHKR2zaQrDjhc38oKd7beDTpa72lMthBs8qtclE27gcf7Q5gq1v26DxrHScnc1csx2FA6jWQ=
X-Received: by 2002:ac8:2fdc:: with SMTP id m28mr8097078qta.202.1542838136911; Wed, 21 Nov 2018 14:08:56 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: David Benjamin <>
Date: Wed, 21 Nov 2018 16:08:43 -0600
Message-ID: <>
To: Martin Thomson <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="000000000000193cac057b33ff77"
Archived-At: <>
Subject: Re: [TLS] Empty CertificateRequest.supported_signature_algorithms in TLS 1.2
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, 21 Nov 2018 22:09:00 -0000

On Wed, Nov 21, 2018 at 3:50 PM Martin Thomson <>;

> 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

In the ClientHello, I believe an empty signature_algorithms extension is
invalid. The structure is defined as:


BoringSSL enforces this. If your ClientHello has an empty
signature_algorithms extension, we will reject it. If it is missing, we do
interpret it as {*, SHA1}, as TLS 1.2 (mistakenly) prescribes.

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

Sadly, the structure itself has a syntax error, so it's unclear whether
empty is allowed or not. :-)

      struct {
          ClientCertificateType certificate_types<1..2^8-1>;
          DistinguishedName certificate_authorities<0..2^16-1>;
      } CertificateRequest;

We do tolerate empty and give it the same {*, SHA1} interpretation as
ClientHello, since they go through the same logic, but I agree with you
that the specification does not actually say it applies to both. Rejecting
the empty list sounds like a good idea, assuming it's compatible with
current implementations. The 7.4.8 citation looks right, and rejecting it
makes sense on general principle. IMO, the default {*, SHA1} bit in TLS 1.2
was a mistake. It's caused unnecessary confusion, resulting in buggy TLS
1.2 servers that only sign SHA-1.

Maybe we should errata this by fixing that <2^16-1> to <2..2^16-1>?