On Mar 6, 2018, at 5:35 PM, Colm MacCárthaigh <c...@allcosts.net> wrote: > There's a general conjecture that the more information that is provided to > attackers, the more easily they can leverage into a compromise. Personally I > believe that conjecture, and would actually prefer to see fewer signals, > ideally as few as one big error code. There is a trade-off against > debugability, but I've only seen a handful of people have the skills to debug > low level TLS issues and it doesn't seem worth the risk. Others disagree, > which is valid, but it's at least an area of reasonable contention.
This makes perfect sense. Stuart Cheshire and I were having the same discussion a while back about DNS Session Signaling, and he pointed out (I was playing Dale's role) that there's an important distinction to be made between "buggy implementation" and "actionable notification where no bug exists." Any alert that signals "buggy implementation" is bad, for the reason you've stated, and also because such signals are not actionable—if you've run into a bug you should probably just give up, and not try to somehow guess in your implementation what might work when the bug happens. The only reason to send a signal is if there is a known and clear action to take upon receiving the signal, other than "we're borked, give up."
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
