+1. If anything, the existing "buggy implementation" alert codes should get folded together. (But I don't think it's worth making that change at this stage either.) E.g. decode_error vs illegal_parameter vs unexpected_message are rather useless distinctions and trying to get them "right" adds complexity. Even with the granularity is it is, TLS's alert codes needlessly expose benign differences in implementation strategy. Adding even finer granularity would make all this worse.
My experience is also that this sort of thing would not actually help much.
On Tue, Mar 6, 2018 at 11:05 PM Eric Rescorla <ekr@xxxxxxxx> wrote:
Without taking a position on the security matter: this has been part of the TLS design for 20+ years, and therefore has had multiple LCs and WG and IETF consensus, so it would take a pretty strong set of arguments to change now. I've debugged a lot of TLS interop issues, and as a practical matter, I don't think this would help that much to justify making a change.-Ekr_______________________________________________On Tue, Mar 6, 2018 at 2:35 PM, Colm MacCárthaigh <colm@xxxxxxxxxxxx> wrote:On Fri, Mar 2, 2018 at 8:00 PM, Dale Worley <worley@xxxxxxxxxxx> wrote:- There are about 28 error codes but nearly 150 places where the text
require the connection to be aborted with an error -- and hence,
nearly 150 distinct constraints that can be violated. There are 19
alone for "illegal_parameter". I would like to see an "alert
extension value" which assigns a distinct "minor" code to each
statement in the text that requires an error response (with
implementations being allowed to be a bit sloppy in providing the
correct minor code).Your review is incredibly deep, comprehensive and I learned a lot from it. I want to pick out just one small piece, but don't mean that to diminish how thorough it was!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.--Colm
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls
