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

worley@ariadne.com (Dale R. Worley) Fri, 06 April 2018 02:33 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E96D12D947 for <gen-art@ietfa.amsl.com>; Thu, 5 Apr 2018 19:33:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.686
X-Spam-Level:
X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 StDSdQBh9iYc for <gen-art@ietfa.amsl.com>; Thu, 5 Apr 2018 19:33:07 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 240F61201F2 for <gen-art@ietf.org>; Thu, 5 Apr 2018 19:33:07 -0700 (PDT)
Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-08v.sys.comcast.net with ESMTP id 4HBOf7EieeJyT4HBafFbj8; Fri, 06 Apr 2018 02:33:06 +0000
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-07v.sys.comcast.net with SMTP id 4HBYf8mO7fa8F4HBYfXeRD; Fri, 06 Apr 2018 02:33:05 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w362X3EO026994; Thu, 5 Apr 2018 22:33:03 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w362X3g5026991; Thu, 5 Apr 2018 22:33:03 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Bill Frantz <frantz@pwpconsult.com>
Cc: pgut001@cs.auckland.ac.nz, steven.fenter58@gmail.com, gen-art@ietf.org, ietf@ietf.org, draft-ietf-tls-tls13.all@ietf.org, tls@ietf.org
In-Reply-To: <r470Ps-10133i-7B3DEB3D7CF1410DB2E2FF250A811BB1@Williams-MacBook-Pro.local> (frantz@pwpconsult.com)
Sender: worley@ariadne.com
Date: Thu, 05 Apr 2018 22:33:02 -0400
Message-ID: <871sft12u9.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfM2Mi9ywbjZLJda4eyFMnRtLFV9gfic9x//UBxZLWtjJ4oqgx2AxmSB1w14oS31RNF+BJ8aFFlb+afycc1cOrfoct7gjadzLB/Gzv6SsLvtCENf0hMfL ZTC2xJeyj6YtPUCKSocczD32Yq19dvF31TJT8GL+9euBwDylSIpyTEC5Vczk5jQY1Ok0uH4klh14kXqJX9KExsHwHfITvCX2urn/yjQNA6b0fG0TZwIUewiv Dgyha3C4YYymwAV47Caf7/bcO1xYFWGj2A48iHxmR/74RPsjhx9tAVTGiJQf+MUtNZen9mb4NC3UEGFwu04D239jTXyuzahwXutbUYR7Nvg70q25sNNwUGGM N0KTJKK7
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/Gi2ebdJOGiaIuLW9ZlOhPTB5ZeU>
Subject: Re: [Gen-art] [TLS] Genart last call review of draft-ietf-tls-tls13-24
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Apr 2018 02:33:08 -0000

Bill Frantz <frantz@pwpconsult.com> writes:
> 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.

I'd not considered textual messages.  What struck me is that the draft
has dozens, maybe more than 100, conditions that must be satisfied, and
only a few different error codes.  It strikes me that each particular
rule could be assigned an error number, so an implementation could point
out which of the dozens of rules was violated in a particular handshake.

Dale