Please post a PR for this and see what the WG thinks. On Fri, Sep 9, 2016 at 7:35 AM, Hannes Tschofenig <[email protected] > 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/tls >> >>
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
