On Wed, Sep 07, 2016 at 06:57:43PM +0000, Timothy Jackson wrote: > 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.
IMO, no-alert (not even tried) closes are only acceptable if: - Association was never created (bad HelloVerifyRequest or HelloRetryRequest in DTLS). - Association has been lost (transport error). - The association state is corrupt. The bad alerts that leak info are: - Depend on secret values and - Substantial probability to not trigger alert for first cause(s). IIRC, TLS 1.0-1.2 blockmode had one of those. Note that if you have an alert which could leak information, very probably it is a timing attack vector as well. And there just closing the connection won't help. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
