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

Hannes Tschofenig <> Fri, 09 September 2016 14:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D67A512B039 for <>; Fri, 9 Sep 2016 07:35:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.109
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qp9jtdZWfXYc for <>; Fri, 9 Sep 2016 07:35:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D69A912B183 for <>; Fri, 9 Sep 2016 07:35:52 -0700 (PDT)
Received: from [] ([]) by (mrgmx002) with ESMTPSA (Nemesis) id 0LnwxU-1b6qEf39AW-00fzsa; Fri, 09 Sep 2016 16:35:49 +0200
To: Eric Rescorla <>, "" <>
References: <>
From: Hannes Tschofenig <>
Message-ID: <>
Date: Fri, 9 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: <>
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: <>
Subject: Re: [TLS] PR#625: Change alert requirements
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


On 09/05/2016 08:02 PM, Eric Rescorla wrote:
> PR:
> 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