On Wednesday, 21 September 2016 15:53:33 CEST Peter Gutmann wrote: > Andreas Walz <andreas.w...@hs-offenburg.de> writes: > >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." > > And how many implementations are going to do this? Consider the > error-message litmus test I proposed earlier, reasons for failing to > connect to (say) amazon.com: > > Error: Couldn't connect to Amazon because its certificate isn't valid. > > Error: Couldn't connect to Amazon because no suitable encryption was > available. > > Error: Couldn't connect to Amazon because <explanation for > decoding_error alert>
"received data was malformed." > If you're writing a strict validating protocol parser than disconnecting in > this case is a valid response, but if it's software that will be used by > actual humans then failing a connect based on something like this makes no > sense. We are talking about a cryptographic protocol. Being very strict about what you receive is the raison d'être of the whole thing. POODLE happened because SSL 3 in general and some TLS implementations in particular weren't strict. Researchers look at protocol itself and only a handful of popular implementations, they won't be analysing if the TLS-as-implemented-by-ACME- widget-7000 is secure even if it isn't strict. -- 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
