Re: [TLS] Should we require implementations to send alerts?

[David Benjamin <[e-mail]>]

(Resending from the right address, again. Possibly I should have subscribed
with the other one...)

On Thu, Sep 17, 2015 at 6:23 PM David Benjamin <[e-mail]> wrote:

> On Thu, Sep 17, 2015 at 5:46 PM Brian Smith <[e-mail]> wrote:
>
>> On Thu, Sep 17, 2015 at 1:50 PM, Nico Williams <[e-mail]>
>> wrote:
>>
>>> On Wed, Sep 16, 2015 at 12:53:53PM -0700, Brian Smith wrote:
>>> > Further, the alerting mechanism has encouraged the unsafe practice of
>>> > "version fallback." It is clear from looking at the bug databases of
>>> > Firefox and Chrome that their attempts to make security decisions
>>> based on
>>> > what alerts they received was bad for security.
>>>
>>> Do we think that silent connection closings wouldn't also lead to
>>> version fallback?
>>>
>>
>> Let's ask the browser vendors:
>>
>> Browser vendors, if web servers were to stop sending alerts during
>> handshake failures, would you start doing version fallback when a
>> connection is closed?
>>
>
> Connection close is already a fallback trigger.
>
>
>> Fatal alerts are quite handy for diagnostics on the client side, really.
>>>
>>
>> I agree that they are often marginally useful. However, the risks
>> associated with the alert mechanism outweigh those benefits.
>>
>
> I don't think the existence of alerts at all increases the "risk" that
> people will do fallbacks. I think you've got causality flipped. It wasn't
> "we get alerts, ergo we can get away with a fallback" but "Servers are
> dumb, we want to fallback. If there's something easy we can do to constrain
> when fallbacks happen, we should. Being more lenient means even more
> unexpected dependencies on the fallback may crop up. (Not that this hasn't
> happened anyway.)".
>
> Besides, fallback conditions tend to be extremely liberal in my
> experience. Which makes sense since it's used against buggy servers. If a
> buggy server blew up because it's version-intolerant, it's not likely to be
> kind enough to tell you that.
>
> While I don't see much use in "your records don't authenticate" and
> "that's not even a syntactically valid ServerKeyExchange!", not all
> failures are protocol failures. There's also negotiation failures when
> parameters aren't okay. When removing cipher suites or bumping minimum
> versions, it's nice to show a dedicated error message when it goes wrong.
>
> And client certs break (even more) if you can't distinguish network errors
> from the peer complaining at you. I wish they would go away, but I'm stuck
> with supporting it right now and I doubt the world will rally behind
> "client certs on the web are deprecated; you do not get TLS 1.3 if you use
> client certs".
>
> David
>
>
>>
>>
> I'd rather keep them than remove them, but I'd be OK with clients never
>>> sending them.  I'm OK with fata alerts being SHOULD send.
>>
>>
>> I suggest that, at most, implementations SHOULD NOT send them. IMO it
>> would be better to remove the alert mechanism altogether in TLS 1.3.
>>
>> Most people that are arguing for retaining the alert requirements seem to
>> be concerned about alerts sent from the server to the client. Does anybody
>> think it is important to require clients to ever send alerts other than
>> close_notify?
>>
>>