Please post a PR for this and see what the WG thinks.

On Fri, Sep 9, 2016 at 7:35 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net
> wrote:

> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to