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

Reply via email to