I'd like to echo Dale's sentiments on the error codes. I've done a fair amount of TLS handshake troubleshooting, and it's usually long and painful because the error codes are so vague. Another factor in debugging is that people troubleshooting TLS in the enterprise are typically not the same level of experts as those who are writing TLS code. The TLS working group folks seem to have their fingers in TLS every day and know it backwards and forwards, so debugging a problem is not so difficult for them. They can also read code to figure out what is going on. In contrast, I see a TLS handshake problem once every few months. The rest of the time I'm looking at HTTP, SQL, SMB, or whatever. So enterprise troubleshooters are not going to be as deep in their understanding of TLS by the nature of their jobs, and they need all the help they can get (like from descriptive error messages). The vague error messages are leading directly to more downtime, and this should be balanced with the other security needs. I'm not saying this needs to be fixed immediately, but it should be considered somewhere down the road.
> On Mar 6, 2018, at 9:35 PM, wor...@ariadne.com (Dale R. Worley) wrote: > > Colm MacCárthaigh <c...@allcosts.net> writes: >> On the specific suggestion of having more granular error codes, I think >> this is a dangerous direction to take lightly; there's at least one >> instance where granular TLS alert messages have directly led to security >> issues by acting as oracles that aided the attacker. >> >> 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. > > I believe I've heard that position stated before, and I give it > credibility. I retreat to the statement I made at the top of my review, > that I'm not experienced in security. OTOH, I've spent a lot of the > previous couple of decades debugging SIP call flows, so I've learned to > appreciate any aid to debuggability that exists. > > I'm tempted to consider this a classic case of conflicting requirements, > and ask if our cryptographic experience can help us square this circle. > > Dale > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
