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 >
- [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Sean Turner
- Re: [TLS] PR#625: Change alert requirements Watson Ladd
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Andrei Popov
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Martin Rex
- Re: [TLS] PR#625: Change alert requirements David Benjamin
- Re: [TLS] PR#625: Change alert requirements Timothy Jackson
- Re: [TLS] PR#625: Change alert requirements Ilari Liusvaara
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Martin Rex
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Hannes Tschofenig
- Re: [TLS] PR#625: Change alert requirements Benjamin Kaduk
- Re: [TLS] PR#625: Change alert requirements Martin Thomson
- Re: [TLS] PR#625: Change alert requirements Ilari Liusvaara
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Sean Turner
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- [TLS] (strict) decoding of legacy_record_version? Benjamin Kaduk
- Re: [TLS] (strict) decoding of legacy_record_vers… David Benjamin
- Re: [TLS] (strict) decoding of legacy_record_vers… Eric Rescorla
- Re: [TLS] (strict) decoding of legacy_record_vers… Brian Smith
- Re: [TLS] (strict) decoding of legacy_record_vers… Martin Thomson
- Re: [TLS] (strict) decoding of legacy_record_vers… Brian Smith
- Re: [TLS] (strict) decoding of legacy_record_vers… Martin Thomson
- Re: [TLS] (strict) decoding of legacy_record_vers… Benjamin Kaduk
- [TLS] Treatment of (legacy_record_)version field … Andreas Walz
- Re: [TLS] Treatment of (legacy_record_)version fi… Eric Rescorla
- Re: [TLS] Treatment of (legacy_record_)version fi… Andreas Walz