search

cloudflare / tls-tris

crypto/tls, now with 100% more 1.3. THE API IS NOT STABLE AND DOCUMENTATION IS NOT GUARANTEED.
Other
293 stars 50 forks source link

TLS13-WrongOuterRecord test fails #47

Open Lekensteyn opened 7 years ago

Lekensteyn commented 7 years ago

The TLS13-WrongOuterRecord bogo test expects that clients that receive a handshake content type fail while tris just ignored it.

https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-5.2 says:

opaque_type The outer opaque_type field of a TLSCiphertext record is always set to the value 23 (application_data) for outward compatibility with middleboxes accustomed to parsing previous versions of TLS. The actual content type of the record is found in TLSInnerPlaintext.type after decryption.

It has no MUST requirement on the receiver, so not sure if we should check it or not.

tmthrgd commented 6 years ago

I asked for clarification in the tls13-spec repo. It would seem that either behaviour is acceptable without any particular preference. https://github.com/tlswg/tls13-spec/issues/1127#issuecomment-353766020:

This sort of question tends to fall into a category where only a pragmatic answer is reasonable, namely that we can only enforce strict requirements once it is known that TLS 1.3 is definitively in use, which is the case here. But I am not entirely convinced that there is value in having a normative behavior in the spec; one could make reasonable arguments for a given implementation to go either way, and the question is irrelevant for the question of whether two compliant implementations will interoprate, so it seems just to be a venue for potential disagreement with no real upside.

That leaves the question of whether to take up BoringSSL's behaviour unbound by the spec.