IETF Logo Mail Archive

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

Bill Frantz <frantz@pwpconsult.com> Fri, 30 March 2018 20:55 UTC

Return-Path: <frantz@pwpconsult.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 2E06B126DD9; Fri, 30 Mar 2018 13:55:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 zcI68Pf6Gpfv; Fri, 30 Mar 2018 13:55:33 -0700 (PDT)
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF94E126D0C; Fri, 30 Mar 2018 13:55:32 -0700 (PDT)
Received: from [47.143.125.159] (helo=Williams-MacBook-Pro.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from <frantz@pwpconsult.com>) id 1f213V-000FDV-01; Fri, 30 Mar 2018 16:55:25 -0400
Date: Fri, 30 Mar 2018 13:55:24 -0700
From: Bill Frantz <frantz@pwpconsult.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
cc: Steve Fenter <steven.fenter58@gmail.com>, "Dale R. Worley" <worley@ariadne.com>, gen-art@ietf.org, ietf@ietf.org, draft-ietf-tls-tls13.all@ietf.org, tls@ietf.org
X-Priority: 3
In-Reply-To: <1522377304060.20682@cs.auckland.ac.nz>
Message-ID: <r470Ps-10133i-7B3DEB3D7CF1410DB2E2FF250A811BB1@Williams-MacBook-Pro.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.4 (470)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec794e9b7f3b5bc28310a1d0bac7cd52e95f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 47.143.125.159
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/uw3OOja2zc9KlKu2wqUTUGg9ak0>
Subject: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24
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: Fri, 30 Mar 2018 20:55:35 -0000

On 3/30/18 at 7:35 PM, pgut001@cs.auckland.ac.nz (Peter Gutmann) wrote:

>As you mention, debugging TLS is unnecessarily painful if there's a problem,
>you typically just get a handshake-failed alert which is essentially no
>information at all.  Having a debug-mode capability to send back a long-form
>error message would be extremely useful, maybe an extension to say "send back
>a long-form alert with more than just 'BOOLEAN succeeded = FALSE' in it".

We have always avoided the long form error messages in TLS 
because they can be of great help to attackers as well as 
debuggers. I think this objection is much weaker if we write the 
long form error messages into a log that is kept with other 
server logs.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Ham radio contesting is a    | Periwinkle
(408)356-8506      | contact sport.               | 16345 
Englewood Ave
www.pwpconsult.com |  - Ken Widelitz K6LA / VY2TT | Los Gatos, 
CA 95032

v2.23.0 | Report a Bug | By Email