On Wednesday, 21 September 2016 11:45:15 CEST Andreas Walz wrote: > Ok, thanks. This is close to my sense of it. Actually, I wasn't aware of the > fact that the TLS 1.3 draft now explicitly addresses this in the > Presentation Language section: > > "Peers which receive a message which cannot be parsed according to the > syntax (e.g., have a length extending beyond the message boundary or > contain an out-of-range > length) MUST terminate the connection with a "decoding_error" alert."
technically TLSv1.2 also is like this, it's just not explicit. All the messages and structures must match their definitions exactly, that means any kind of trailing data is an encoding error and as such should cause connection abort. at least in theory if implementation does not reject such malformed fields or messages, it may be possible to trick it into talking with a different protocol that just happens to be parseable as TLS. Multiple checks on self- consistency of messages make that unlikely. -- 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
