Re: [TLS] PR#625: Change alert requirements

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 09 September 2016 14:35 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 D67A512B039 for <tls@ietfa.amsl.com>; Fri, 9 Sep 2016 07:35:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.109
X-Spam-Level:
X-Spam-Status: No, score=-4.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.508, 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 qp9jtdZWfXYc for <tls@ietfa.amsl.com>; Fri, 9 Sep 2016 07:35:53 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69A912B183 for <tls@ietf.org>; Fri, 9 Sep 2016 07:35:52 -0700 (PDT)
Received: from [192.168.91.132] ([80.92.121.21]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LnwxU-1b6qEf39AW-00fzsa; Fri, 09 Sep 2016 16:35:49 +0200
To: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
References: <CABcZeBMeLgqjvr2cjWL=AHTQJbS9siNBB6U2=0654yigbBGkYA@mail.gmail.com>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Message-ID: <9c28d7a9-4a21-799d-00d8-24ddb7f151b8@gmx.net>
Date: Fri, 09 Sep 2016 16:35:49 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBMeLgqjvr2cjWL=AHTQJbS9siNBB6U2=0654yigbBGkYA@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:9jldkTD8KANStsadheUwyJDyOSgqcsBVtU3Qq+k87tYYbGj+/l1 j2s6o4U2q7Ggycb+d133FXu8aWjOw6fLJU/mpe4b2CoTyLnRvWrRcyc83EwZ5bG2CSzTmCd TjMln/2MRhuYap4Crg3Giv12RpnjclHU4R5IJ8MotX08Pf5pInvOL5iIiMSq987oY/yoo0E iUYLU+ynspQIphU9Fq2OQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:is9qtAmAG5g=:P1HEAGz5lvRkmjjr3qtyEG HhvbK/t5Y+BIAkmu5Z50W/0phX1IxvXKMdC+DSeD94hJSHNXSHmBQ0WKcoz5zWIl3T7lSr6J9 AHBSrYVrZmKYGsFyeFi4egcsaOgS8ITDXhKRl8V4hVcw+PgaZnJugwqmcK30k43Q/Mfuqm93M NrnUYTgLe7JDXrPQbIfXXwc3pqd/bs0mrCkLP/qeD4XjDNOxgAivWu+NLWwELQlUEtIwl8Rf6 8DSNR2yJssZNUaT3BbOOr6U0EXjcZqxFfgxqjmJqXnzGvunZec5msI195iMGHAUa5qmGOIloB Ea2f8rD5W2tfLDICYLJNb8/dd88BzFNM+0XZIvEDBfml2LBs8uhEXHgwWvDRl5sk3f5H/Cu8K to8qPKmotDglGEhyZmOdLIfHf5l/aAoZistfMw6fkVHFReZ68QQ7290Z7OpzUf+Oic57TwM4I tWpYuEHmSVy94tKbfKuboCYqY7AORIFvqiJXjCcJYOn/nGSsW4abfmkVMgdiGD58OcAG2xZNT VImpplOn8Se/BxNl/8n6L9J+pZtWYrn7TpkyD5y93sA2KryWJjdx9q0ySwo7wPoUu9PCDPqpx O5IO984z3sdqsCyYE0ak1SJi6ny7q6KXXA8gb8NeRA+KxGmV7ti0JwZKR/urh0sD25pjxY8Tt MTR1uOnvfLhRI+j5YCSw5oQiDrYVLmob0BeV8JOy/1tjpVmFsLGaBM2IhaXXJ89iVo49fsFj4 g2DwXfp6WX3TgVV6VYf5BPmq/7w6dbUIfJfIoaLb/V7/OCe7+0pII1TKVwIlwnMNmbcdwZ2qn Up9LGTB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bSPjC9GBAFBfHYDKvYoXqzZsWoM>
Subject: Re: [TLS] PR#625: Change alert requirements
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 09 Sep 2016 14:35:55 -0000

Hi Ekr,

I read through the text and I think it is an improvement.

I only had one question that is only slightly related to your edits 
because it came up in the interop testing with the Mint implementation.

"
Servers requiring this extension SHOULD respond to a ClientHello
lacking a "server_name" extension by terminating the connection
with a "missing_extension" alert.
"

I personally would find it more useful to have an alert saying 
"missing_server_name_extension" instead of just returning 
"missing_extension" for a number of different extensions since this 
gives the client no chance to fix the problem without human intervention.

Ciao
Hannes

On 09/05/2016 08:02 PM, Eric Rescorla wrote:
> PR: https://github.com/tlswg/tls13-spec/pull/625
>
> Currently the TLS spec requires implementations to send alerts under various
> fatal conditions. However, many stacks actually don't send alerts but
> instead
> just terminate the connection. Several people have argued that we should
> relax
> the requirement.
>
> At the September 2015 interim there was consensus to instead encourage
> sending alerts and require that if you send an alert, you send a
> specific one.
> I've finally gotten around to producing a PR that does this (link
> above). This
> PR:
>
> - Harmonizes all the language around alert sending (though perhaps I missed
>   a couple of places)
> - Tries to make which alerts to send clearer in the alert descriptions
> to avoid
>   having to specify individually how to handle every decision.
> - Relaxes the requirement as listed above.
>
> Note that these are to some extent orthogonal changes; even if we decide to
> continue mandating sending alerts, that should be listed in one location not
> scattered around the spec.
>
> I know that there wasn't universal consensus on relaxing the requirement to
> send, so I'll await WG discussion and the chairs decision on how to
> handle this PR.
>
> -Ekr
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>