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

[Benjamin Kaduk <[e-mail]>]

I'm happy to make all alerts fatal.

I also like the state in the pull requests where some cases require that
if an alert is sent, it is a specific alert, while leaving flexibility
in other cases (and preventing us from having to exhaustively enumerate
all possible causes for alerts).

It would also be nice to standardize on using "terminate" for
post-handshake issues and "abort" for during the handshake (or, really,
any concrete split).  It looks like the intent of the pull request is to
make that distinction, but I wasn't really reading with a keen eye and
checking all cases for it.

-Ben

On 09/06/2016 04:33 PM, Sean Turner wrote:
> All,
>
> The chairs would like to get some eyes on this PR by this Friday (Sept 9th) so that we can draw it to close.
>
> Thanks,
>
> J&S
>
>> On Sep 05, 2016, at 14:02, Eric Rescorla <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls