On Wednesday, 4 July 2018 15:46:04 CEST Salz, Rich wrote: > > if the interpretation of "I know this _message_ _length_ is wrong > > because of > > some other values I negotiated before, so I'll send illegal_parameter" > > was correct, then overflow_error, decrypt_error and probably few > > others > > would also need to be replaced with illegal_parameter... > > I think the rigorousness of error codes is not at the same level as the rest > of the document. I'm fine with that. I can understand why people > developing test suites are frustrated.
It's not about developing test suites. It's about software the test suites are running against. Inconsistent behaviour is usually a sign of a bug (I already had to deal with two security bugs, including one remote crash, that were/could have been found by verifying the sending of alerts and description of alerts), if not a security issue by itself (see ROBOT). To reiterate: I'm not doing it because it brings me perverse pleasure or because I'm obsessive about details or because it makes writing test suites easier (it doesn't, that's why first tests I was writing didn't do that), I insist on specific, explicit and correct error handling _because it finds bugs_ And I think we can all agree that a secure implementation of TLS needs not to have bugs. And we all primarily want to see such implementations, don't we? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
