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

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 06 April 2018 23:11 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 7FC32126C3D for <tls@ietfa.amsl.com>; Fri, 6 Apr 2018 16:11:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 rjrXgJ_MWyLY for <tls@ietfa.amsl.com>; Fri, 6 Apr 2018 16:11:29 -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 C5B64126BF0 for <tls@ietf.org>; Fri, 6 Apr 2018 16:11:28 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 177D77A330E; Fri, 6 Apr 2018 23:11:28 +0000 (UTC)
Date: Fri, 06 Apr 2018 23:11:28 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20180406231127.GN3322@mournblade.imrryr.org>
Reply-To: tls@ietf.org
References: <1522377304060.20682@cs.auckland.ac.nz> <r470Ps-10133i-7B3DEB3D7CF1410DB2E2FF250A811BB1@Williams-MacBook-Pro.local> <CABcZeBMFrnSUddraBps-b=CujitVfaQuqBFHD9WCAcCKg9M7Tw@mail.gmail.com> <CDC57F65-C88C-43BB-B4DB-77AEE9B437EF@gmail.com> <1522462562850.29528@cs.auckland.ac.nz> <2C1F7A14-45B0-49DE-98B1-897223F7A1B0@akamai.com> <1522559738688.99197@cs.auckland.ac.nz> <7EBF2F91-6FEA-4705-BB1A-3FB5D7E33949@akamai.com> <2DA08233-1EC4-4371-943B-E41BF5D8DA8C@dukhovni.org> <109337BE-3299-46B5-A2F8-9583107AB537@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <109337BE-3299-46B5-A2F8-9583107AB537@akamai.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4bJOYgCptErKgQLql0VmFn3g_bM>
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, 06 Apr 2018 23:11:30 -0000

On Fri, Apr 06, 2018 at 12:10:35PM +0000, Salz, Rich wrote:

> >    For debugging messages, I'm with Peter, they'll only be implemented if they're
> >   simple enough to support.  I can't see having to have localization files on the
> >   server for debug messages that might be requested by a client is some other locale
> >   and only when debug is enabled, and the consumer is a developer and not an end-user.
>    
> The table stakes have increased, and I don't think it is reasonable any
> more for any IETF protocol to have "just use ASCII" for text messages.
> It could be UTF8, or it could be codeset/tagged.  Why two developers in,
> say, Russia need to speak English to debug their TLS implementations.

Because the server has no idea what locale the client is in.
Localization is not an option.  The only option (which is essentially
"use-ascii") is to use UTF-8, and then the error messages are in
whatever language the developer of the server used.  So the Russian
developer will be seeing Chinese debug messages from the server.
That's not progress.

If you want localization, the messages need to be numeric codes,
with localized string tables on each client.  But then older clients
might not understand some new server messages (perhaps OK if the
message list is sufficiently stable given a client protocol version
and set of client supported extensions).

-- 
	Viktor.