While the specification already details a lot of situations that "MUST NOT" happen or that are errors, it doesn't specify how those situations should be handled by peers.
Add information that they need to cause the receiving side to send a fatal alert with appropriate description. Most of the additions in this pull request[1] should be uncontroversial, one I'm not sure sure about is the alert type to send in case of invalid value in Finished message, do we want to hide it in bad_record_mac, or should it be typical for such cases illegal_parameter? (Currently what a peer is supposed to do if the Finished value does not match the expected one is not specified) 1 - https://github.com/tlswg/tls13-spec/pull/621 -- 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
