Re: [TLS] Alerts

Matt Caswell <frodo@baggins.org> Thu, 11 May 2017 08: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 C5433129AEA for <tls@ietfa.amsl.com>; Thu, 11 May 2017 01:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.201
X-Spam-Level:
X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ihwyzXEj7zpX for <tls@ietfa.amsl.com>; Thu, 11 May 2017 01:21:39 -0700 (PDT)
Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [IPv6:2001:8d8:968:7d00::19:7e53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4191B129AC9 for <tls@ietf.org>; Thu, 11 May 2017 01:21:39 -0700 (PDT)
Received: from mail-it0-f42.google.com (mail-it0-f42.google.com [209.85.214.42]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id 84E138BD for <tls@ietf.org>; Thu, 11 May 2017 09:21:33 +0100 (BST)
Received: by mail-it0-f42.google.com with SMTP id c15so39487270ith.0 for <tls@ietf.org>; Thu, 11 May 2017 01:21:33 -0700 (PDT)
X-Gm-Message-State: AODbwcD7+QhtRV4NIFSTUTGb/lA8Vw0qXv2zENQDK1LAT+Q4zhWoUEBL pSj7Or9CfZ8z538tgTXVK1aJM2G67g==
X-Received: by 10.36.127.200 with SMTP id r191mr9494400itc.91.1494490892025; Thu, 11 May 2017 01:21:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.127.79 with HTTP; Thu, 11 May 2017 01:21:31 -0700 (PDT)
In-Reply-To: <CABkgnnVdY7esjLTPakjV6i781eFMdXbZg+PbgLoVmGLdxMh_Bg@mail.gmail.com>
References: <CAMoSCWYokkJO7NdJ78SpviiUoZdDzD225JnS+QW0KZcVMty2Hg@mail.gmail.com> <CABkgnnVdY7esjLTPakjV6i781eFMdXbZg+PbgLoVmGLdxMh_Bg@mail.gmail.com>
From: Matt Caswell <frodo@baggins.org>
Date: Thu, 11 May 2017 09:21:31 +0100
X-Gmail-Original-Message-ID: <CAMoSCWaQNP2AG1+U0hVQUjcT0qUnwzzi6sfQZfpY=Q+A--zW9w@mail.gmail.com>
Message-ID: <CAMoSCWaQNP2AG1+U0hVQUjcT0qUnwzzi6sfQZfpY=Q+A--zW9w@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/M7O5lJr2rVJNlVAlhq9r8PMnArk>
Subject: Re: [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: Thu, 11 May 2017 08:21:41 -0000

On 10 May 2017 at 21:51, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 11 May 2017 at 01:21, Matt Caswell <frodo@baggins.org> wrote:
>> Do we really need all of these alerts?
>
> NSS uses these, but in ways that I don't really understand.  I think
> that this is part of the general issue that TLS does and doesn't
> really include requirements about how to handle the certificate chain.

OpenSSL is quite inconsistent in its use of alerts. That's how this
issue came up for me - I was reviewing what the spec said about alerts
and comparing it to the OpenSSL implementation (checking we failed
everywhere we are supposed to fail, and with the correct alert).
OpenSSL is currently using the more specific alerts for certificate
failures, although this is in contradiction to what it says in the
"Server Certificate Selection" section.

If the view is that the more specific alerts are helpful, then I'd
suggest amending the wording in the "Server Certificate Selection"
section to remove the bit about the "unsupported_certificate" alert
and (possibly) replace with a reference to the set of alerts that
might be sent instead.

Alternatively, if the more specific alerts are not helpful, then
perhaps we should prune down the list in section 6 to a much smaller
list.

Matt