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

[David Benjamin <[e-mail]>]

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?
>
>