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

David Benjamin <davidben@chromium.org> Wed, 21 November 2018 22:08 UTC

Return-Path: <davidben@google.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 D8F7412D7F8 for <tls@ietfa.amsl.com>; Wed, 21 Nov 2018 14:08:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.959
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 4q-S82GgSgzA for <tls@ietfa.amsl.com>; Wed, 21 Nov 2018 14:08:58 -0800 (PST)
Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (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 D905312D4E9 for <tls@ietf.org>; Wed, 21 Nov 2018 14:08:57 -0800 (PST)
Received: by mail-qt1-x842.google.com with SMTP id r14so5551446qtp.1 for <tls@ietf.org>; Wed, 21 Nov 2018 14:08:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; 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; d=1e100.net; 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: <CABkgnnUxd_cbh-kASTTyPbGvk1fg2cUfUWwNa4cvB2DV8kMRSw@mail.gmail.com>
In-Reply-To: <CABkgnnUxd_cbh-kASTTyPbGvk1fg2cUfUWwNa4cvB2DV8kMRSw@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Wed, 21 Nov 2018 16:08:43 -0600
Message-ID: <CAF8qwaDZs56VczH6nxgy0aBNtE2mMqsa-+g-Bvd43MZt4sanyg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000193cac057b33ff77"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/coHzUG7An3TT7afojuBJfw31w2s>
Subject: Re: [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 22:09:00 -0000

On Wed, Nov 21, 2018 at 3:50 PM Martin Thomson <martin.thomson@gmail.com>;
wrote:

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

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

      SignatureAndHashAlgorithm
        supported_signature_algorithms<2..2^16-2>;

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>;
          SignatureAndHashAlgorithm
            supported_signature_algorithms<2^16-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>?

David