IETF Logo Mail Archive

Re: [Gen-art] Expanded alert codes. [Was Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24]

worley@ariadne.com (Dale R. Worley) Fri, 06 April 2018 02:25 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 7E15912D94B for <gen-art@ietfa.amsl.com>; Thu, 5 Apr 2018 19:25:53 -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 46yspI9lZifh for <gen-art@ietfa.amsl.com>; Thu, 5 Apr 2018 19:25:52 -0700 (PDT)
Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (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 2BB6E124235 for <gen-art@ietf.org>; Thu, 5 Apr 2018 19:25:51 -0700 (PDT)
Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-03v.sys.comcast.net with ESMTP id 4H3nfrLvFF0FK4H4YfC5FJ; Fri, 06 Apr 2018 02:25:50 +0000
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-19v.sys.comcast.net with SMTP id 4H4VfRi688pS64H4WfTxD5; Fri, 06 Apr 2018 02:25:49 +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 w362PkjF026617; Thu, 5 Apr 2018 22:25:46 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w362PjQH026612; Thu, 5 Apr 2018 22:25:45 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Eric Rescorla <ekr@rtfm.com>
Cc: pgut001@cs.auckland.ac.nz, kathleen.moriarty.ietf@gmail.com, frantz@pwpconsult.com, steven.fenter58@gmail.com, gen-art@ietf.org, ietf@ietf.org, draft-ietf-tls-tls13.all@ietf.org, tls@ietf.org
In-Reply-To: <CABcZeBNB50jY1odzgVZVKqn8F7TCj1b+A_95yG6f=Nde0KVv+g@mail.gmail.com> (ekr@rtfm.com)
Sender: worley@ariadne.com
Date: Thu, 05 Apr 2018 22:25:45 -0400
Message-ID: <877epl136e.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfNkOzsOtIn1IziHA4X3nmRCTTTbBBXDZ7xakuaOYKekiuwXdDIWslQ3FXMvw/k665IQKBPobP9AiFiEwvKB5I0A5wbejLVzBexDOpiiDng/ZqAHY/nHr STmaUirBZ1wdpHwgKZy8PKuV6ZcIng10XscKrJFpZ07fPwnjKlCiM/X0by18HPe+9o5rJwtnnP6FNAoY78L/AOoPPl47BMdDC+CePonHySt8ewfiP0LCGpbQ FGnsuliET8HgnYEdQ1PH+z3ULu0i+wgN1udBrM1dsIUmeqF8+tlv8zerVFS0SosI5W3R2kEXol1Fk7vl9PTZGtz+6oMOhOcbl2fIIdzPeBq6hReV93sE06dY up47xuh1GzlAwXxNbHZnoUnRpJ6qGRrJmfKEc0HWVMnj0ftNjvS7AMu8Th0pb4VHVf6uA7JWCWom2FpiDlm83ON3KbY3dA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/6jbcgYHWOwtRFrnPvsamczV-evE>
Subject: Re: [Gen-art] Expanded alert codes. [Was Re: [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:25:53 -0000

Eric Rescorla <ekr@rtfm.com> writes:
> I guess there might be some intermediate category 1.5 that's kind of in
> production so you don't want to print out complete logs, but you'd like
> more detail than you would probably want to expose in general, but my
> experience is that that's not super-common.

My expectation is that the useful case is when there *aren't* any logs,
or what logging is done does not tell the specific reasons that
particular interactions were rejected.  That's pretty common in SIP
systems.

Of course, anything like this would be an extension.  But would it be
reasonable for one endpoint to present a "debug password" in its request
which, if it matched the debug password set in the other endpoint, would
cause the other endpoint to provide fuller error information?  That
would allow a "debug window" that could be exploited only between
endpoints that had some sort of administrative coordination.

Dale

v2.23.0 | Report a Bug | By Email