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

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 07 April 2018 04:49 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 4DDBA126B6D for <tls@ietfa.amsl.com>; Fri, 6 Apr 2018 21:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 PZyTyQ9lZ_It for <tls@ietfa.amsl.com>; Fri, 6 Apr 2018 21:49:35 -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 96C13124319 for <tls@ietf.org>; Fri, 6 Apr 2018 21:49:35 -0700 (PDT)
Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 0C70A7A330D for <tls@ietf.org>; Sat, 7 Apr 2018 04:49:34 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CABcZeBNg+xog6hAfXtPS18VRFf-txmc1f4_wkoXKDaBmjGnVng@mail.gmail.com>
Date: Sat, 07 Apr 2018 00:49:32 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <0F36675A-206C-4B17-8E74-6B18C5F0D1EF@dukhovni.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> <20180406231127.GN3322@mournblade.imrryr.org> <CABcZeBNg+xog6hAfXtPS18VRFf-txmc1f4_wkoXKDaBmjGnVng@mail.gmail.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UDEGgpb1G7iWPYhVAej7CBdR_CA>
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: Sat, 07 Apr 2018 04:49:37 -0000


> On Apr 6, 2018, at 7:39 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> That would depend on how you designed the feature. Because the client would have
> to opt-in in any case, it could provide its locale in that opt-in message.
> 
> I'm not saying that this (or even the feature at all) is necessarily a good idea, but
> it's not like it's impossible.

Yes, it is not impossible, but it is much too brittle.  There's little reason (in general)
to expect the server to have support for the client's locale, let alone have locale-specific
translation tables for TLS errors.  Numeric codes are much better if the error reasons are
easily to classify in advance. Otherwise, numeric codes + UTF8 text in English.

This works with enhanced status codes in SMTP, which some MUAs (Outlook) render in local
languages based on the status code, but the remote postmaster will want the original text,
so that's often more useful for debugging when there's a problem (and not just a wrong
email address).

-- 
	Viktor.