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.
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

Reply via email to