IETF Logo Mail Archive

Re: [TLS] Thoughts on Version Intolerance

David Benjamin <davidben@chromium.org> Sat, 23 July 2016 06:03 UTC

Return-Path: <davidben@google.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 2257512D5AE for <tls@ietfa.amsl.com>; Fri, 22 Jul 2016 23:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level:
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 3nNlAVhlvs7H for <tls@ietfa.amsl.com>; Fri, 22 Jul 2016 23:03:54 -0700 (PDT)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 A595212D17B for <tls@ietf.org>; Fri, 22 Jul 2016 23:03:53 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id f93so98256881lfi.2 for <tls@ietf.org>; Fri, 22 Jul 2016 23:03:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pJsV/dSDdzq8h2epWA6YVLMdlw+UJeIk60Y/lANLDKU=; b=IiDlzCCRgIbmz6Wy7B975i/h9UNCXy/yIj+SPr7pgsK0vOq0k3RaiZVL2cF4X99web D8r3E0gWUWtzEg4PM8VleKusLkj0BJNK8uToVLBqdsDFGgsMQSLptHfBrlop6J/p4q8Z gWbmAwBLvOT6MjDusOLUi9Mhyv1GvI0IbZDjM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pJsV/dSDdzq8h2epWA6YVLMdlw+UJeIk60Y/lANLDKU=; b=JKLuooP/M40CtJZWwMh5kYNgnCd3uPIDG5ifXL1Ut7KasKAS11acNBPySTHg54Kz9t nTgpcBAxES8ssUO2/i0lJoNK3R/rr7QuPdyiKUsx+mdWQARJIS0995qfo9iiRI0kHbfE vARNM7LsGOtjAcBaF6xWq0xDOub7F3o6LKQsfADcWh4KWfxlYtDB4y2eBM737Hlqum/d 1Ve9Thg3yubNWCyBBTnd2AigU3c9Y0GrgUwPwsZNRSFRD10AvClVtjNtSkIQkE0IBaTg xhxbBYdgXXRFyZeL1cv5jvZB6AG9xpfx/gwLBRjz4Ff09rhpkmx3hIlqg1gMAsWg51B2 J/PQ==
X-Gm-Message-State: AEkoousCxlPRtX4QwC5ZWstrvX6LBjlmMn1ltcn4NEBBXHvYdQN1GNGI1sgfjYII61F7L7MnibVZaas78SiylZHI
X-Received: by 10.25.168.212 with SMTP id r203mr4351665lfe.85.1469253831542; Fri, 22 Jul 2016 23:03:51 -0700 (PDT)
MIME-Version: 1.0
References: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> <4902846.OLd9Rrk6Df@pintsize.usersys.redhat.com> <201607211604.25745.davemgarrett@gmail.com> <2581885.dP5x8nd4GP@pintsize.usersys.redhat.com> <CAFewVt760KsO6oX5u-ZQJmKB-M5FcTb7mUTz4Z4FaT2QopwCxw@mail.gmail.com>
In-Reply-To: <CAFewVt760KsO6oX5u-ZQJmKB-M5FcTb7mUTz4Z4FaT2QopwCxw@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Sat, 23 Jul 2016 06:03:41 +0000
Message-ID: <CAF8qwaCmguZOpSV6HZEQyeusEVmSDX2vpFkx+3h__a3uLmi5Rg@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>, Hubert Kario <hkario@redhat.com>
Content-Type: multipart/alternative; boundary="001a114032a2b71ecd05384750d4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/BXK1dQePL1vO3SohGe0GYcdoxhY>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Thoughts on Version Intolerance
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: Sat, 23 Jul 2016 06:03:56 -0000

On Sat, Jul 23, 2016 at 3:37 AM Brian Smith <brian@briansmith.org> wrote:

> Hubert Kario <hkario@redhat.com> wrote:
> > I'm quite sure that if I were sending a huge extension or many big
> extensions,
> > the percentage of servers that are incompatible to them would be
> similar, if
> > not worse. A relatively small 3KiB client hello already causes issues
> and this
> > is not exactly something impossible to achieve with just TLSv1.2 and
> session
> > tickets.
>
> Don't expect a server to accept a ClientHello with a session ticket it
> didn't produce. In particular, a server could very reasonably reject a
> session ticket larger than the ones it produces, and it might produce
> only very small ones.
>
> More generally, when assessing compatibility, generally it is better
> to consider only initial handshakes, using the data one would normally
> send in an initial handshake. And, if you are considering 0-RTT key
> shares, then it would be better to measure the case where only ECC key
> shares are used separately from the case where non-ECC (old-school DH)
> key shares are used.


Indeed I just finished a probe that tested many more handshake variations:

1. 1.2 ClientHello
2. 1.3 ClientHello with all curves predicted[*]
3. 1.3 ClientHello with only X25519 + P-256 predicted
4. 1.2 ClientHello with 1.3 sigalgs
5. 1.2 ClientHello with fake 1.3 version

I still need to fully analyze the data and experiment with the servers that
behave strangely, but the overwhelming majority of 1.3-intolerant servers
are intolerant to just the version. (They fail to connect with only 2, 3,
and 5.)

(Note that one must complete the handshake to get a full picture. Sending
the ClientHello isn't enough. Full analysis pending, but sending a 1.2
ServerHello and failing around the Finished message seems to happen often
enough.)

I did find one group of servers which is intolerant to the new signature
algorithms in some inexplicable way. (It's not as straight-forward as
avoiding numbers that end in 0-3 or having too many. Hopefully I'll manage
to figure out what's up with them.)

I have not found any servers which are sensitive to 2 vs 3. (That said,
there is a group in my data which is consistent with being intolerant to
large ClientHellos. But every one I've looked at so far was a transient
network error in probing. I'll need to re-run a few of these hosts to get
better data.)

But the one thing that is extremely clear is the problem is
ClientHello.version. This should not be surprising. We've done this three
times already, and it's always been ClientHello.version. There may be the
occasional satellite problem beyond it, but we will never be rid of
fallbacks if we continue to try something which reality is desperately
trying to tell us doesn't work.

David

[*] Our implementation doesn't do FFDHE. Although between X25519, P-256,
P-384, and P-521, that's decently large.

v2.23.0 | Report a Bug | By Email