Andreas Walz <> 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)

  Error: Couldn't connect to Amazon because its certificate isn't valid.
  Error: Couldn't connect to Amazon because no suitable encryption was

  Error: Couldn't connect to Amazon because <explanation for 
         decoding_error alert>.

What would you put for the explanation for this case?  And if you say "decode
error" the user's response will be to switch to some less buggy software that
doesn't have problems connecting.

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

TLS mailing list

Reply via email to