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
