Colm MacCárthaigh <> 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.


TLS mailing list

Reply via email to