Re: [TLS] Thoughts on Version Intolerance

Watson Ladd <watsonbladd@gmail.com> Wed, 20 July 2016 18:12 UTC

Return-Path: <watsonbladd@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 E16F312D9CF for <tls@ietfa.amsl.com>; Wed, 20 Jul 2016 11:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=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 UUKu5aeJ2vji for <tls@ietfa.amsl.com>; Wed, 20 Jul 2016 11:11:58 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 69E4912D9E0 for <tls@ietf.org>; Wed, 20 Jul 2016 11:11:58 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id x130so80478403vkc.0 for <tls@ietf.org>; Wed, 20 Jul 2016 11:11:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=eTE09lquMOodjQ3xqsOuYWBlehbc/UkiWDPwqInHZyk=; b=iZMyaQewEpxVlD6eO+Tp9fugyluuzTkS52NLjY+3TM/j2pe0Squz/nhKb7qgrWfgXy cJCBSphl9EuV77pg1lSeu7J1IAp0pDyAQU5qtNJ3BtzsZgTHd2ahVdZjVevuhtg6OGB+ LSTHQkEMCJVvCXspJbaLIdlkda+7gZLrfFqbzHlo7Iq4k8Y3Ai9WZGdP1/G6/YXBZJqw 2ZuOjAdtij7DdYBHbFqEcvg4Y4lIRzmuVUX2iJCEHhLc97iL91AKXF1tn7QYP2qk84dN CD/rhqdM54w7Wyh9KB6rpBxwMInCUj6PoB2Ve1aeY1C4+oKCSAwifC1jngO4JljETFT2 nLVw==
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:date :message-id:subject:from:to:cc; bh=eTE09lquMOodjQ3xqsOuYWBlehbc/UkiWDPwqInHZyk=; b=BMB5D3NOjn4mS+4VEfvfrXBL4W0wsfe2hZJA/juVbg2m2r4hgI0bmqJ0qamAqEOccm CF5QSXMufEhG6IBJwWoEMiYhqpCrKeQQxIbD0qewIictNvA2bnRoCiISALq2/Fmeqznv eZ5r4apjwrhd7HgOqg0uRN3qCZc962jHVs5uKoaG3PrNjQb0t2rCJz6Z+K7pbPhJTTp0 CFVd2BzQSwuY/gQgerYv174oEKI2PhIbSQGreqzbnrUCU1UbTsW5qq6pj+EX+J5LawYD r73j9GenqWThIw/hFinAELbPmxcSAa7LCMwjQxvujnXo5MOleU+PKterPO7pkXjeCZMt VQLg==
X-Gm-Message-State: ALyK8tKZTqevP+lslIJ1UkiknDJI7tEh0bx7tIm652OGPF52WOT6g3213TjrwqgeCy0r+Qaj6oR6m/3mIxxUtQ==
MIME-Version: 1.0
X-Received: by 10.176.1.67 with SMTP id 61mr24462138uak.87.1469038317445; Wed, 20 Jul 2016 11:11:57 -0700 (PDT)
Received: by 10.159.39.194 with HTTP; Wed, 20 Jul 2016 11:11:56 -0700 (PDT)
Received: by 10.159.39.194 with HTTP; Wed, 20 Jul 2016 11:11:56 -0700 (PDT)
In-Reply-To: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp>
References: <7776970.MmWSFEWlvc@pintsize.usersys.redhat.com> <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp>
Date: Wed, 20 Jul 2016 11:11:56 -0700
Message-ID: <CACsn0c=vmuZqGQjGe=+GWTNNe5EGBKzc6qQeivxDzueELC4=Hg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=001a113cf70a12a6d005381523c4
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qa3sOpFTfmWK_76oVr40bHDMWTc>
Cc: 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: Wed, 20 Jul 2016 18:12:01 -0000

On Jul 20, 2016 10:31 AM, "Martin Rex" <mrex@sap.com>; wrote:
>
> Hubert Kario wrote:
> > Martin Rex wrote:
> >>
> >> Forget TLS extensions, forget ClientHello.client_version.
> >> Both in fundamentally broken, and led to Web Browsers coming up
> >> with the "downgrade dance" that is target&victim of the POODLE attack.
> >>
> >> We know fairly reliably what kind of negotiation works just fine:
> >> TLS cipher suite codepoints.
> >
> > please re-read my mail, they don't:
> >
> > 49% (6240) are intolerant to a Client Hello with no extensions but
> > big number of ciphers that bring its size to 16388 bytes)
> > 91.5% (11539) are intolerant to a Client Hello with no extensions
> > but a number of ciphers that bring it well above single record layer
limit
> > (16.5KiB)
>
> You're seriously confusing things here.
>
> Any ClientHello with > 200 Cipher suite code points indicates fairly
insane
> Client behaviour, so rejecting it is _perfectly_sane_ server behaviour.

The IANA registry contains
>
> Trying to support theoretical encoding size limits is a stupid idea,
> because it leads to endless security problems.  Imposing sane sizes
> plus a safety margin is solid implementation advice.

No, using languages that permit memory safety violations leads to problems.
Somehow I doubt you would call avoiding those languages sane implementation
advice. Yes, a device with 8kbyte RAM could have a problem with large
Client Hellos, but I doubt that is the issue here.

>
> Large stuff that doesn't need to be exchanged in abbreviated handshakes
> should *NEVER* be included in ClientHello, because of the performance
> penalties this creates (Network bandwidth for TLS handshake,
> and TCP slow start).
>
>
> >
> >>> I'm now also collecting some data and have some preliminary
> >>> suspicion on affected devices. My numbers roughly match yours that we
> >>> are in the more or less 3% area of 1.3 intolerance.
> >>
> >> The TLSv1.2 version intolerance is already a huge problem,
> >> and I'm not seeing it go away.  Acutally Microsoft created an
> >> awfully large installed base of TLSv1.2-intolerant servers
> >> (the entire installed base of Win7 through Win8.1 aka 2008R2, 2012,
2012R2).
>
> Please recheck with a vanilla (aka extension-free) ClientHello that
> has ClientHello.client_version = (3,3), to recognize all
TLSv1.2-intolerant
> implementations in your counts.

Since TLS 1.0 servers have been instructed to ignore extensions, which
finally got used in TLS 1.2. Hardly matters exactly what causes the problem.

>
>
> >>
> >> I would really like to see the TLS WG improving the situation
> >> rather than keep sitting on its hands.  The problem has been well-known
> >> since 2005.  And the "downgrade dance" was a predictably lame approach
> >> to deal with the situation, because it completely subverts/evades the
> >> cryptographic protection of the TLS handshake.
> >
> > it's not IETF's fault that the implementers add unspecified by IETF
> > restrictions and limitations to parsers of Client Hello messages or that
> > they can't handle handshake messages split over multiple record layer
> > messages, despite the standard being very explicit in that they MUST
> > support this.
>
> Nope, not really.  Limiting PDU sizes to reasonably sane sizes is
> perfectly valid behaviour.  X.509v3 certificates can theoretically include
> CAT MPEGs and amount to megabytes.  A TLS implementation that limits
> the certificate chain (i.e. the TLS Certificate Handshake message) to
> a reasonably sane size with safety margin, say 32 KBytes in total,
> is acting totally reasonable.  Anyone who creates an insane PKI deserves
> to loose, and deserves to loose quite badly.

Unless we specify minimum sizes that must be handled, this creates
difficult interop problems, particularly when sizes need to be expanded.
That size is less then one SPHINCS signature for instance.

>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls