[TLS] Alerts

Matt Caswell <frodo@baggins.org> Wed, 10 May 2017 15:21 UTC

Return-Path: <frodo@baggins.org>
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 B0B3B129465 for <tls@ietfa.amsl.com>; Wed, 10 May 2017 08:21:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.58
X-Spam-Level:
X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
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 vjs7ai12DXHX for <tls@ietfa.amsl.com>; Wed, 10 May 2017 08:21:27 -0700 (PDT)
Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [217.160.92.157]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FED127698 for <tls@ietf.org>; Wed, 10 May 2017 08:21:27 -0700 (PDT)
Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id 9FF2ADA7 for <tls@ietf.org>; Wed, 10 May 2017 16:21:25 +0100 (BST)
Received: by mail-it0-f41.google.com with SMTP id g126so3473507ith.0 for <tls@ietf.org>; Wed, 10 May 2017 08:21:25 -0700 (PDT)
X-Gm-Message-State: AODbwcCk2SwD9+iLM/FstcqoccnWcO7Zv/I1etks0AAE3B9B8LPfT4sk QoZNaD2+vYInzzccqTfNgoKlmv2HYA==
X-Received: by 10.36.0.23 with SMTP id 23mr5885935ita.108.1494429683998; Wed, 10 May 2017 08:21:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.127.79 with HTTP; Wed, 10 May 2017 08:21:23 -0700 (PDT)
From: Matt Caswell <frodo@baggins.org>
Date: Wed, 10 May 2017 16:21:23 +0100
X-Gmail-Original-Message-ID: <CAMoSCWYokkJO7NdJ78SpviiUoZdDzD225JnS+QW0KZcVMty2Hg@mail.gmail.com>
Message-ID: <CAMoSCWYokkJO7NdJ78SpviiUoZdDzD225JnS+QW0KZcVMty2Hg@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/IgzyjSybDfIv4Kp3fbrCLpG0OwM>
Subject: [TLS] Alerts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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, 10 May 2017 15:21:28 -0000

Draft-20 currently contains this text in the section "Server
Certificate Selection":

'If the client cannot construct an acceptable chain using the provided
certificates and decides to abort the handshake, then it MUST abort
the handshake with an"unsupported_certificate" alert."'

However, section 6 lists a number of other generic certificate related alerts:
certificate_revoked
certificate_expired
certificate_unknown
unknown_ca

While section 6 provides descriptions of these they are not mentioned
elsewhere in the spec, so there is no guidance as to when they might
be used.

So, given the text in the "Server Certificate Selection" section,
should a client always send "unsupported_certificate" for all
failures? Or should one of the other alerts be used instead if it
seems more appropriate? E.g. If a client attempts to "construct an
acceptable chain", but finds an expired certificate - should it
respond with "unsupported_certificate" or "certificate_expired"?

There seems to be some inconsistency between server certificate
selection and client certificate selection, i.e. in the former it is
mandated that a specific alert be sent, but in the latter there is no
such requirement.

Additionally, there are a number of other alerts mentioned in section
6 (not just certificate related ones), that are never mentioned
anywhere else in the spec. Do we really need all of these alerts? If
they are needed, shouldn't they be explicitly mentioned elsewhere in
the spec in the locations where they are relevant (associated with
some MUST/SHOULD/MAY requirement)? As things stand the interpretation
of when they should be sent seems quite loose.

Matt