Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]

Hubert Kario <hkario@redhat.com> Wed, 08 June 2016 09:58 UTC

Return-Path: <hkario@redhat.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 6817012D192 for <tls@ietfa.amsl.com>; Wed, 8 Jun 2016 02:58:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.348
X-Spam-Level:
X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 WzXrFY3sGTS5 for <tls@ietfa.amsl.com>; Wed, 8 Jun 2016 02:58:24 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3BD912D178 for <tls@ietf.org>; Wed, 8 Jun 2016 02:58:24 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5CC93C05B1FB; Wed, 8 Jun 2016 09:58:24 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-122.brq.redhat.com [10.34.0.122]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u589wN4p025955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jun 2016 05:58:24 -0400
From: Hubert Kario <hkario@redhat.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Date: Wed, 08 Jun 2016 11:58:22 +0200
Message-ID: <3076488.KRSuv77WAr@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.4.11-200.fc22.x86_64; KDE/4.14.17; x86_64; ; )
In-Reply-To: <BN3PR03MB1445876F534D9F09882F7B3F8C5D0@BN3PR03MB1445.namprd03.prod.outlook.com>
References: <CAF8qwaDuGyHOu_4kpWN+c+vJKXyERPJu-2xR+nu=sPzG5vZ+ag@mail.gmail.com> <CAF8qwaByu9+Smb7Bt9H+ffDozO7J49RBzOez1dVGmfi_3w-jXw@mail.gmail.com> <BN3PR03MB1445876F534D9F09882F7B3F8C5D0@BN3PR03MB1445.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart28184795.m22O2xIyVR"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 08 Jun 2016 09:58:24 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/srV1Nsd-A7bq7pGktsfXtlf5Wg0>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]
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, 08 Jun 2016 09:58:26 -0000

On Tuesday 07 June 2016 21:14:32 Andrei Popov wrote:
> Jumping to the end of the thread, it looks like this is an FTP issue
> that repros when TLS 1.2 is negotiated. Not a TLS version
> intolerance.
> The conclusion seems to be that
> https://support.microsoft.com/en-us/kb/2888853 resolves the issue, by
> updating FTP binaries. 
> Cheers,

yes that thing should be fixed now

that being said, I've seen reports that IIS 7.5 does support TLSv1.2 
while at the same time being intolerant to TLS 1.3 Client Hello.

Unfortunately I don't have access to a server that I'm certain is 
running IIS 7.5 that I could test this hypothesis with.


To continue my reply to Yoav, so just because we sometimes not see 
different intolerancies, doesn't mean they are not there. TLS library 
programmers do actively shape their Client Hello's to trigger as little 
issues as possible.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky┼łova 99/71, 612 45, Brno, Czech Republic