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

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to