IETF Logo Mail Archive

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

Yoav Nir <ynir.ietf@gmail.com> Tue, 07 June 2016 14:36 UTC

Return-Path: <ynir.ietf@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 89D2812D6A1 for <tls@ietfa.amsl.com>; Tue, 7 Jun 2016 07:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 ObumoFPqbHBB for <tls@ietfa.amsl.com>; Tue, 7 Jun 2016 07:36:09 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 02E8F12D694 for <tls@ietf.org>; Tue, 7 Jun 2016 07:36:08 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id m124so117366160wme.1 for <tls@ietf.org>; Tue, 07 Jun 2016 07:36:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=3cn1sVl4E44FKe1PSdOrWtwVGXx1j9l9rS3IIxo9rLw=; b=Sh5Vm30kefCC4kkQxnRmBBuZVkxieBJKa3WRHLvK8yI4QZbaljH5gnk8zz61iBodWL TQukTc1yWBCJXL/BkY2pqspEtSvGO+nRH3ogHg6Isbe3lMhCMejo1XBo+iaf8uer8kH5 VJc403/ILNfqZ7wKnOzlOw13oncoqTiNu3VhHf3BSVVhyIdnU4coks6K06bztkGICCRV 5pxD5NozfId1KxYHNJLvSAm0EWbsl4mbAjAtqUh7LM8ipz2Ct4OiZ/e8qH5AYBSRcLTu 93dMXqkmvMj6dy9mmeS/fUHnlIvrN9b5HAoaKDWnxre0noWsaASJ/d8i+r3EAK7YFOoq FR0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=3cn1sVl4E44FKe1PSdOrWtwVGXx1j9l9rS3IIxo9rLw=; b=JZq5TUQQVLTtH5HPU1NzQggY3ZqFOGgrSGPfWeRxMf2rkNFsN2L5GgV+C5prm1nsn1 7nO9OgS9uIKLt2oFEhF0vukjldPHWcZmuF8XSEMt6uVZO0EGdbCW9FiZ6vVsOFuWnX2B XARn+ST82aayqBdqw5nIProNnbUNWle2IqzBNzujO8io5ndjGSJBLfDpCNrg/u3ELZbj 7y2R3zGpuN6xMwOCuQJRHbeze829LhcxrDXBtrd0DUzU2IC63792JgJqNZQTx7GS5YK5 mhLsYeNCTTWyo45lVgSs5AAXByh2P7wcHKF0+F642ZOSC8Z4BZSvUXRFhwHbb6/D9mD9 TGdg==
X-Gm-Message-State: ALyK8tJXm70Rx/9Ee/6igN9qsoOJvaLQwT6Hn/ndVjBtxqH+KKghvo8kuKFUi5kTF3LtYQ==
X-Received: by 10.28.30.16 with SMTP id e16mr69083wme.20.1465310167554; Tue, 07 Jun 2016 07:36:07 -0700 (PDT)
Received: from [172.24.250.135] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id db6sm25795343wjb.2.2016.06.07.07.36.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Jun 2016 07:36:03 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_67589B2F-99F8-4C43-9E05-16423BB27102"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <CAJU8_nU6dN7_GgjkC9c5VJawi91B4SpyvgyYU+_F4HeLtHWUaw@mail.gmail.com>
Date: Tue, 07 Jun 2016 17:36:01 +0300
Message-Id: <19D9A152-3801-44DA-ADF0-345011EDF54D@gmail.com>
References: <CAF8qwaDuGyHOu_4kpWN+c+vJKXyERPJu-2xR+nu=sPzG5vZ+ag@mail.gmail.com> <201606031616.14451.davemgarrett@gmail.com> <1612869.mrh4f7qht5@pintsize.usersys.redhat.com> <201606061453.53336.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C9D3F0@uxcn10-5.UoA.auckland.ac.nz> <CAJU8_nU6dN7_GgjkC9c5VJawi91B4SpyvgyYU+_F4HeLtHWUaw@mail.gmail.com>
To: Kyle Rose <krose@krose.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/frpT1yGhdeMhNxmcCpylnqXbnOg>
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:36:10 -0000

I’m not sure this helps. 

I’ve never installed a server that is version intolerant. TLS stacks from OpenSSL, Microsoft, Java, and most any implementation we can name have been version tolerant forever. Certainly none of us can name any implementation that at any point had a version out that was tolerant (or implementing) TLS 1.2 but intolerant of TLS 1.3.

And these are the same implementations we’re likely to participate in a bakeoff or run the suite we create in the hackathon.

Yoav

> On 7 Jun 2016, at 5:22 PM, Kyle Rose <krose@krose.org> 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?
> 
> Kyle
> 
> On Jun 7, 2016 2:00 AM, "Peter Gutmann" <pgut001@cs.auckland.ac.nz <mailto:pgut001@cs.auckland.ac.nz>> wrote:
> Dave Garrett <davemgarrett@gmail.com <mailto: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 <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email