We probably want to discuss the potential for side-channels introduced by alerting. I’ve seen at least one case where there were two possible classes of errors at a particular state in the protocol. One caused an alert, the other caused the TLS stack to close the channel. Unfortunately, this difference in behavior could give information to an attacker. The only viable solution was to modify the TLS stack to close the channel in both cases.
If we’re going to continue having alerts, I think we would need to be sure that an implementations following the RFC will not wind up in this situation. I suspect that will be difficult at best. Tim From: TLS <tls-boun...@ietf.org> on behalf of David Benjamin <david...@chromium.org> Date: Wednesday, September 7, 2016 at 11:46 AM To: Eric Rescorla <e...@rtfm.com>, Andrei Popov <andrei.po...@microsoft.com> Cc: "tls@ietf.org" <tls@ietf.org> Subject: Re: [TLS] PR#625: Change alert requirements On Wed, Sep 7, 2016 at 2:21 PM Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> wrote: On Wed, Sep 7, 2016 at 11:19 AM, Andrei Popov <andrei.po...@microsoft.com<mailto:andrei.po...@microsoft.com>> wrote: > > the only popular stack I found that does not seem to send alerts is > > the schannel from Microsoft To clarify, schannel does generate alerts per RFC, but the HTTP stack (which actually owns the socket) sees no value in sending them. My impression is that this sometimes applies to Chrome as well. Chrome doesn't send close_notify. I'm not sure if error alerts get swallowed or not. I thought they did, but they do seem to make it through some layers in the stack. Probably whether they manage to get sent depends on how long higher layers happen to hold on to objects when an error is reported. For Chrome, writing to a socket is asynchronous (we have some callback-based interface which ultimately uses select/poll/whatever + non-blocking write/send on POSIX), but tearing down a socket or its owners is synchronous (it's just C++ delete), so we would attempt to post the write but then immediately cancel everything if it's just before everything gets torn down. Trying to wait for that write to actually clear (and then account for timing it out if it takes forever, etc) would be a ton of trouble and not actually do much useful. I imagine Andrei's story with the HTTP stack is similar. David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
