Re: [TLS] new error alerts?

Eric Rescorla <ekr@rtfm.com> Thu, 23 July 2015 23:32 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6F81A1EEA for <tls@ietfa.amsl.com>; Thu, 23 Jul 2015 16:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 lML1yWv90v9o for <tls@ietfa.amsl.com>; Thu, 23 Jul 2015 16:32:23 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (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 268071A1BD1 for <tls@ietf.org>; Thu, 23 Jul 2015 16:32:23 -0700 (PDT)
Received: by wicmv11 with SMTP id mv11so43642828wic.0 for <tls@ietf.org>; Thu, 23 Jul 2015 16:32:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MMcMWPNTzNXIPxT2lFzFG9rDMaiSPRBMnvr/NkgvWmE=; b=H4NMvdg6fsgDo1lnxyycfd0hjnl4osokjTxbbFVSAInjeTHz34DPI/jj600JICmaO8 WEzGjKZnQmL359OHa0vZ2hqywOsiN9nloMVhR15RNEO796PLMNP643BAmW5lWwTvH0Ao 6OvCSYrdm8uhde++z0mSj7hl2NHC466SrcLWJQGNLnKo7M6eRkHF+newoZTLdU7/8rzL bUyyAY+8iDntT96X8coqpb+GB+YxrjoudfZUqvLeZhlze4bjwHQCV+uln8DP610bxN+g PReSQSyQSE9SaQWRaiLNXQ2nodCvtSliTpT/GZnjtkmFPyl6f7FbOROLj9QhaeYnx8O9 EHjg==
X-Gm-Message-State: ALoCoQkwi65UPlFDljmMUIam5PKEUsA4/jZ8N16DY4CVh4KlxnAL8s3tZzZcBfVtVKGHHTR8zgn4
X-Received: by 10.194.158.42 with SMTP id wr10mr19853611wjb.81.1437694341952; Thu, 23 Jul 2015 16:32:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.85.75 with HTTP; Thu, 23 Jul 2015 16:31:42 -0700 (PDT)
In-Reply-To: <201507222139.46391.davemgarrett@gmail.com>
References: <201507222139.46391.davemgarrett@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 24 Jul 2015 01:31:42 +0200
Message-ID: <CABcZeBO=VjGVYZ2B803Emaco62tz9jX_5nbAn7Nk6UCP9Q76PQ@mail.gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary=089e013c64788c4ef2051b934c59
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/xWQu4Gn2SoyWBwmSVuWZtoVnpbg>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] new error alerts?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Jul 2015 23:32:25 -0000

It's not clear to me that there is consensus that more granular error
codes are a good idea. I'll defer to the chairs on the process question.

-Ekr


On Thu, Jul 23, 2015 at 3:39 AM, Dave Garrett <davemgarrett@gmail.com>
wrote:

> Hubert Kairo found quite a few more spots in need of explicit error
> designations, which have been amended into PR #201.
> https://github.com/tlswg/tls13-spec/pull/201
>
> I just noticed one error in the current draft text that was wrong and
> added a fix for that as well. The Server Hello section said that lack of
> acceptable group would result in an "insufficient_security" error, which is
> incorrect. That error is clearly defined to be for lack of acceptable
> cipher suite. The Negotiated Groups section says lack of acceptable group
> is a “handshake_failure” error. I changed the text to state the error for
> suites, as the other is already noted elsewhere. (this change is now in PR
> #201) This brings up a problem, however: there is no distinct error for
> lack of group support. The “handshake_failure” is a bit of a catchall, so
> there's no way for a client to really know what's wrong if this happens.
> This is also why I don't want to change the definition of the
> "insufficient_security" error. Clients rely on these being relatively
> precise in order to show error messages that are hopefully meaningful
> enough to get them fixed. As such, I'd like to propose adding a new error
> just for this and renaming the old one to focus precisely on its long
> defined meaning. While we're at it, a failure of client authentication
> doesn't have its own error alert code either.
>
>   enum {
>        handshake_failure(40),
>        unsupported_cipher_suites(71),  /* formerly insufficient_security */
>        unsupported_dh_groups(72),  /* new */
>        client_authentication_failure(73),  /* new */
>        (255)
>    } AlertDescription;
>
> Pretty straightforward. Are there any other errors that can't be clearly
> identified by the returned code? Debugging shouldn't be guesswork. ;)
>
>
> Dave
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>