Re: [TLS] Alerts

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 11 May 2017 20:12 UTC

Return-Path: <ietf-dane@dukhovni.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 C9CD912EAB4 for <tls@ietfa.amsl.com>; Thu, 11 May 2017 13:12:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-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 iHWCnX2tnwl6 for <tls@ietfa.amsl.com>; Thu, 11 May 2017 13:12:33 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0F0131452 for <tls@ietf.org>; Thu, 11 May 2017 13:06:39 -0700 (PDT)
Received: from [10.70.192.184] (unknown [38.86.167.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id B15247A32F1 for <tls@ietf.org>; Thu, 11 May 2017 20:06:37 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAMoSCWaQNP2AG1+U0hVQUjcT0qUnwzzi6sfQZfpY=Q+A--zW9w@mail.gmail.com>
Date: Thu, 11 May 2017 16:06:37 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <29AB09F3-AD52-4DE8-AD28-B76CB6AB6B1D@dukhovni.org>
References: <CAMoSCWYokkJO7NdJ78SpviiUoZdDzD225JnS+QW0KZcVMty2Hg@mail.gmail.com> <CABkgnnVdY7esjLTPakjV6i781eFMdXbZg+PbgLoVmGLdxMh_Bg@mail.gmail.com> <CAMoSCWaQNP2AG1+U0hVQUjcT0qUnwzzi6sfQZfpY=Q+A--zW9w@mail.gmail.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OE3puVxX1uvLW2JXtBToBFtzyjQ>
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 20:12:35 -0000

> On May 11, 2017, at 4:21 AM, Matt Caswell <frodo@baggins.org> wrote:
> 
> 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.

It can be quite difficult for users to understand why a remote peer
aborted the TLS handshake.  More specific alerts are quite helpful.
Distinguishing between expiration and insufficiently strong keys or
digests, etc., makes troubleshoots easier and does not compromise
sensitive cryptographic material.

-- 
	Viktor.