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

Hubert Kario <hkario@redhat.com> Tue, 07 June 2016 14:34 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 C194C12D694 for <tls@ietfa.amsl.com>; Tue, 7 Jun 2016 07:34:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.328
X-Spam-Level:
X-Spam-Status: No, score=-8.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 G6PqrctyYwFH for <tls@ietfa.amsl.com>; Tue, 7 Jun 2016 07:34:18 -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 80EAB12D69C for <tls@ietf.org>; Tue, 7 Jun 2016 07:34:14 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 00131627EC; Tue, 7 Jun 2016 14:34:13 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-122.brq.redhat.com [10.34.0.122]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u57EYCuF002173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jun 2016 10:34:13 -0400
From: Hubert Kario <hkario@redhat.com>
To: Kyle Rose <krose@krose.org>
Date: Tue, 07 Jun 2016 16:34:06 +0200
Message-ID: <2698023.3YM6Cv9mer@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: <CAJU8_nU6dN7_GgjkC9c5VJawi91B4SpyvgyYU+_F4HeLtHWUaw@mail.gmail.com>
References: <CAF8qwaDuGyHOu_4kpWN+c+vJKXyERPJu-2xR+nu=sPzG5vZ+ag@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C9D3F0@uxcn10-5.UoA.auckland.ac.nz> <CAJU8_nU6dN7_GgjkC9c5VJawi91B4SpyvgyYU+_F4HeLtHWUaw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1524470.ggfxFv7uvX"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 07 Jun 2016 14:34:14 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/vPplCEe2-7IFRBXsdYsimZ1xNU4>
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: Tue, 07 Jun 2016 14:34:22 -0000

On Tuesday 07 June 2016 10:22:20 Kyle Rose wrote:
> I'm a big fan of the idea of a very strict qualification suite, as
> well, to try to head off some of these problems before (faulty)
> implementations proliferate.
> 
> Hackathon?

I have two approaches I'm working on, they are missing a nice interface 
though.

The first one is:
https://github.com/tomato42/tlsfuzzer
and aims to be a comprehensive test suite 

and the other one, simpler (aimed only at detecting incompatibilities) 
is cscan that lives here:
https://github.com/tomato42/cipherscan/tree/cscan-2

Both require just python and have minimal dependencies.

> Kyle
> 
> On Jun 7, 2016 2:00 AM, "Peter Gutmann" <pgut001@cs.auckland.ac.nz>; 
wrote:
> > Dave Garrett <davemgarrett@gmail.com>; writes:
> > >Also, as with any new system, we now have the ability to loudly
> > >stress to> 
> > TLS
> > 
> > >1.3+ implementers to not screw it up and test for future-proofing
> > >this> 
> > time
> > 
> > >around.
> > 
> > I think that's the main contribution of a new mechanism, it doesn't
> > really matter whether it's communicated as a single value, a list,
> > or interpretive dance, the main thing is that there needs to be a
> > single location where the version is given (not multiple locations
> > that can disagree with each other as
> > for TLS < 1.3), and the spec should include a pseudocode algorithm
> > for dealing
> > with the version data rather than just "implementations should
> > accept
> > things
> > that look about right".
> > 
> > Peter.
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls

-- 
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