[TLS] Client certificate alerts

David Benjamin <davidben@chromium.org> Sat, 17 September 2016 20:09 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 73F4412B24A for <tls@ietfa.amsl.com>; Sat, 17 Sep 2016 13:09:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.115
X-Spam-Level:
X-Spam-Status: No, score=-3.115 tagged_above=-999 required=5 tests=[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_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] 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 nV4zfUsCT57Q for <tls@ietfa.amsl.com>; Sat, 17 Sep 2016 13:09:53 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 19C7F12B255 for <tls@ietf.org>; Sat, 17 Sep 2016 13:09:53 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id 15so14733346ita.1 for <tls@ietf.org>; Sat, 17 Sep 2016 13:09:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=lzanMLH5g6Stll7vbVK/Pt91zkKnitoFOXZCFNx7Y2U=; b=oG4ldL2Qyj417PuUmgZW9f3uaUYmvj911c4y2cspxH8K/XjJpIIpmX0Oir7LZMEYXh EJnuHuf3yPO0QVO54/3QzOTGBvWZTbFMYgmTKDqHCjlnnFDblpIH3S25xUUzXji3ZnEe 2Yq9wTb97cZPotyL+S03moG3uugk/ybnxHg4A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lzanMLH5g6Stll7vbVK/Pt91zkKnitoFOXZCFNx7Y2U=; b=IKcSV/GTsKgw/XXPY520NJMiju0uWbdmOZ3Uj8ZeWyro/ri9EuUnmHcsRVkM4h5nfM IartbaNWOKom0DomfvzQY3E+XdjD6guQckVE6obVl1jyF6zfJyr0o4mJt/ajljBNMIZt jstZv6DSKY4iGwXUtpZswxxEEBp+WpyNyTesprsfsNJ57U7Nx3o0B/nso3MfcGqKoa6T 7WfFp5C4f00GozA7+YgzLIvXUebO2GWyzom3xrLS4RBj+fXlef0pxmMvL2doRHAgoorF gPwgNbj95ANtJHXUJKtL4fvQnYqxmQ/hS0Z6z6/LlUPfz8Y5zlAM2pADOn9l0ecjqjmE ZDGw==
X-Gm-Message-State: AE9vXwMSu/uVWblMDG3YyDxVxLdJyhNgPsc2CM4jN4mdTdGTLOHaLDTfoB+0ND8KMIPGvuCLiH87EDNqljvJWwdC
X-Received: by 10.36.123.212 with SMTP id q203mr3797754itc.13.1474142992095; Sat, 17 Sep 2016 13:09:52 -0700 (PDT)
MIME-Version: 1.0
From: David Benjamin <davidben@chromium.org>
Date: Sat, 17 Sep 2016 20:09:40 +0000
Message-ID: <CAF8qwaDp+mqimkq_euXtjkhZRrb_f=86Q_RgdEE27teTwpWHxA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a1146c9de64ad24053cb9a9ac
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fNuusFQd4SdJ-snlxgM6SiZG_u4>
Subject: [TLS] Client certificate alerts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 17 Sep 2016 20:09:55 -0000

Hi folks,

We've run into some problems with client certificate alerts in Chrome that
I'd like to fix going forward.

The first is easy. handshake_failure is an unhelpful alert for server which
required client certs. This confuses users, so we're planning to
heuristically map it to a client certificate error if it's received after
declining to send certs. This seems poor, so I've uploaded this PR which
adds a certificate_required alert:
https://github.com/tlswg/tls13-spec/pull/640

Second, there is the access_denied alert. This alert has an unfortunate
name. Per spec, it is for:

   access_denied
      A valid certificate [TLS1.3: or PSK] was received, but when access
control was
      applied, the sender decided not to proceed with negotiation.  This
      message is always fatal.

Accordingly, Chrome maps it to a client certificate error. But, by the name
alone, it sounds much more general. We're seeing evidence of some kind of
network filtering software mistakenly sending it to block a connection. (I
can't blame them too much, since we ourselves mistook it for an alert to
send in a server-side DoS handler! This has since been fixed.)

>From an unscientific survey of recent Chrome user complaints about this
error, this is twice as prominent as actual client cert errors! So we'll
want to add another heuristic: if we see access_denied without a
CertificateRequest, map it to a more generic TLS error. This also seems
worth fixing going forward.

Does anyone actually send this alert? OpenSSL does not appear to. My best
rename is certificate_denied if we drop 1.3's "or PSK", but perhaps we can
remove the alert completely? You haven't gotten application data yet, so
you don't really have anything to apply access control on, particularly for
PSK. (For certs, there's post-handshake auth, but I would think you'd send
an application-level error there?)

David