Re: [TLS] Suspicious behaviour of TLS server implementations

Martin Thomson <martin.thomson@gmail.com> Wed, 21 September 2016 23:54 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF9012B3A1 for <tls@ietfa.amsl.com>; Wed, 21 Sep 2016 16:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qn7e42zjeFX7 for <tls@ietfa.amsl.com>; Wed, 21 Sep 2016 16:54:05 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5454712B6DF for <tls@ietf.org>; Wed, 21 Sep 2016 16:54:04 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id z190so61829700qkc.3 for <tls@ietf.org>; Wed, 21 Sep 2016 16:54:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.55.15.146 with SMTP id 18mr44648190qkp.164.1474502043475; Wed, 21 Sep 2016 16:54:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.22.146 with HTTP; Wed, 21 Sep 2016 16:54:02 -0700 (PDT)
In-Reply-To: <1474473207998.35647@cs.auckland.ac.nz>
References: <57D2E218020000AC0011B17E@gwia2.rz.hs-offenburg.de> <20160909152901.9008C1A552@ld9781.wdf.sap.corp> <1473853106532.3256@cs.auckland.ac.nz> <57D96E34020000AC0011B73F@gwia2.rz.hs-offenburg.de> <57E25106020000AC0011BF3A@gwia2.rz.hs-offenburg.de> <CABkgnnX7X+21wjChxkW-uhd8WXAMyp5f1F74H5ja=1mui4POiQ@mail.gmail.com> <57E272CB020000AC0011BF63@gwia2.rz.hs-offenburg.de> <1474473207998.35647@cs.auckland.ac.nz>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 22 Sep 2016 09:54:02 +1000
Message-ID: <CABkgnnWUwPeSeLBO8OyvKmb6MBBfNxPWEXw59_Kzkuby-WqDNQ@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HWsdEoLERgXVTLDeNozYbBfDtrk>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Suspicious behaviour of TLS server implementations
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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 <pgut001@cs.auckland.ac.nz>; wrote:
> Andreas Walz <andreas.walz@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>.
>
> 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.