On Friday, 9 September 2016 18:13:04 CEST Benjamin Kaduk wrote: > I'm happy to make all alerts fatal. > > I also like the state in the pull requests where some cases require that > if an alert is sent, it is a specific alert, while leaving flexibility > in other cases (and preventing us from having to exhaustively enumerate > all possible causes for alerts).
I have one scenario in which a the difference in alert type sent is actually quite crucial for properly testing an implementation. Say you have a server that implements NPN. In case that extension is negotiated, client will send EncryptedExtensions between CCS and Finished, something that is a big no-no in standard TLS. Now, if client misbehaves and sends the EncryptedExtensions despite NPN not being negotiated, server should respond with an unexpected_message alert. But if a server is expecting some message (by mistake) it won't match what it expects and by standard definition it should then send decode_error. The end result of detailed specification is not only easier testing, but also higher confidence in test results. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, 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
