Re: [TLS] Suspicious behaviour of TLS server implementations

Martin Thomson <> Wed, 21 September 2016 23:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CEF9012B3A1 for <>; Wed, 21 Sep 2016 16:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qn7e42zjeFX7 for <>; Wed, 21 Sep 2016 16:54:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5454712B6DF for <>; Wed, 21 Sep 2016 16:54:04 -0700 (PDT)
Received: by with SMTP id z190so61829700qkc.3 for <>; Wed, 21 Sep 2016 16:54:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6VeRbZlq0qyuPZ1CQGacmE/fZ3VwDem4ROy3YOrywqY=; b=aGgw8ZDYbKsgjrYkjZxpNjN0ohhLNbVL0vEpnZYW+a/B2qLSphFnNk3eoTuO6KxRRe mX0KzHYEER1yn2cE11rr9aFnbYfR27c1HOTDuN66dql+RXBB5sRObkb8czQeJaI2ZhM5 eBCV7/R7QZ3nG1IsizlHNvvezwtXCsEFf5KtBhFmk1fyoZPhC68eBMJFS6yyf1+dEJT6 FQU5FQfaa4ZynwHecd/8i4mA0ozGPGycE/DggNV9UdxaCUrjpZuEsQN8ZbJkld2BpqW5 qvFFa1acwOGUQJZNZtjm6PR6zqGtMfVAq3NQKo0o11adLfX+dXWKpTuaTGxYQoX/8xGF TuGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6VeRbZlq0qyuPZ1CQGacmE/fZ3VwDem4ROy3YOrywqY=; b=Z2KKwMOw2DzWBe6dm2aMTsqLcklEraB1M+iIvGKT1QSkeBxzzxdM1o6fB/B6YKG5rU UNBmUJFUQ5w2wr6Zf23shujH/I2C9357bQ/RcPVrNlGrhPz7MlZIwINeNygEuDuYLjA8 vSb7z/wivj6Kds8NmIVME5YTQ7X231r2HLAkqB/kpG9ByOLyt0AjigPQPGaybPHlKZyj 3F57RLIwwPYiXhl0Ax8TcvCyXjrYQRJ/iEQ1TQayFvCVr8ZvsR/c4juYZh9v7KveZ/Sf SyLOxBcLXgHnPys6g8e8abJ5nsoQciJRpSODxldhViVr6LjtQhyD8bmNZEwQQO0g+daN F0pA==
X-Gm-Message-State: AE9vXwORoy81kHv27xRQ5IVOOniclVJE+54n4uNlHEFwNytPwqgEWvfPPXt3R7N/7k88dv9P6Ka9UvgstB0aBw==
X-Received: by with SMTP id 18mr44648190qkp.164.1474502043475; Wed, 21 Sep 2016 16:54:03 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 21 Sep 2016 16:54:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Martin Thomson <>
Date: Thu, 22 Sep 2016 09:54:02 +1000
Message-ID: <>
To: Peter Gutmann <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Suspicious behaviour of TLS server implementations
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Sep 2016 23:54:07 -0000

You describe the observation that leads to Postel's maxim, namely that
if you found the internet in a mess when you got there, then you have
to be tolerant of rubbish.

The advantage with deploying a new protocol is that you can be strict.
If, for example, all of the browsers implement TLS 1.3 and are strict,
then Amazon won't be able to deploy a buggy 1.3 implementation without
noticing pretty quickly.  You might suggest that that's aspiration to
the point of delusion, but in fact it worked out pretty well with
HTTP/2 deployment.  We didn't squash ALL of the nasty bugs, but we got
most of them.

On 22 September 2016 at 01:53, Peter Gutmann <> wrote:
> 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
>          available.
>   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
> sense.
> Peter.