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

Dave Garrett <> Mon, 06 June 2016 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3EB1712D75B for <>; Mon, 6 Jun 2016 11:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bDVAihn5On3X for <>; Mon, 6 Jun 2016 11:53:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 185DE12B05A for <>; Mon, 6 Jun 2016 11:53:56 -0700 (PDT)
Received: by with SMTP id s186so57083218qkc.1 for <>; Mon, 06 Jun 2016 11:53:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=UX9Rco2BCC7lDORxrSiq24Nhqte8EvCMCVi7HAsIYjU=; b=eDrl4c5mslFUf+nlMZ+7yRtoLHNnaQey1gCI5NG6dzbcL12+9I89TcpNV19sEePNBG mjKnXZ9HsDN46uHY50YZOGnOPn0b8obr+m0HxswDWBIsgmah6QgzNHKEUC2tITeCuKm9 AD26wZ1vXxXzfdkjZ5z5xhk4FmN41GnCjxBYJFFQKT1bZ8YguvYXzEpbSu9YjK54FJfF YJ+SdNA8HLc/Z9bGJm3zezUFWnVTaI7AWTtmM801/BmdO4tGh7eqN5GunGovKy6IlVJo GA8KudC3FPQU8SiwV3IOczkRl3IDShSMmfeYmFLylfsKa+7Hcybvv7ggNsker7G/O1mS /3jA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=UX9Rco2BCC7lDORxrSiq24Nhqte8EvCMCVi7HAsIYjU=; b=kuMev1l2XBPMTBZUdSp1wNVZvJ5828SFcAXTz+Mf3CTWiKL2sGrAcLVNTt19R+c+Re LJkIYBKel9NBDgZxJ9kkOUIarYGp08otD/fKkIMRcokrOh1wzvldeP7O4KLNC9ksD51/ QtXao5keiYIknAZfwSXaaJyH8wkV6gQJ1LLJYffxhkhDOiEAqKP3/pB6hw9QxM/zcHJK ovdP428I/ykXEj1FFm0pwejbn+Vto3qFUj7ZiKSB8WgDbH5jP4Sjk8cwRIezWxmSzkVC sdGXSq5pYtLZUb7+tnilCjXX/aC+ET9YOu/7uPQLWMMvaQdwxc+O0h/0/0s7IdF0hPjc aT2g==
X-Gm-Message-State: ALyK8tKYJVGgir3dKkSTcC2fcCl42KGrZ5wOikyAHVKjEm7GjTATo8LWMLwrs+3Tl2iP4w==
X-Received: by with SMTP id b81mr17802260qkc.177.1465239235238; Mon, 06 Jun 2016 11:53:55 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id m25sm6028221qta.43.2016. (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 06 Jun 2016 11:53:54 -0700 (PDT)
From: Dave Garrett <>
To: Hubert Kario <>
Date: Mon, 6 Jun 2016 14:53:53 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
Archived-At: <>
Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Jun 2016 18:53:58 -0000

On Monday, June 06, 2016 06:48:20 am Hubert Kario wrote:
> What makes you think that a new version negotiation that works more or 
> less in the same way will _not_ be implemented incorrectly?

The list-based extension doesn't work in quite the same way. The current mechanism compares two values and picks the lower one. This new mechanism compares two lists and picks the highest mutually listed. Also note that I wish to officially drop any meaning from the version IDs such that we're using an arbitrary 16-bit serial number rather than two 8-bit major & minor numbers. The new supports discontinuous lists, e.g. support of 1.0, 1.2, & 1.4, but not 1.1 or 1.3, without risking accidental negotiation of a lower version that isn't desired. (if 1.3 is eventually declared less ideal than 1.2 or 1.4 due to some unforeseen problem, this gives us a safe mitigation, and it extends to arbitrary future scenarios) 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. At a minimum, implementations will not be able to use the exact same code to negotiate in both systems and would have to go out of there way to add intolerance stupidly, rather than stumble into it stupidly again. Just sticking a new field in an extension lets implementers route it into the same code and risk the same mistakes; adding a bit of complexity here is an unfortunate cost of fixing this mess. Just adding a new _empty_ extension, as was more recently proposed, is something I think could also work ok. Again, if we're more likely to get consensus on that, I think it's viable too.

The idea of a compliance test suite has come up before and I will again say: YES, PLEASE!

I certainly don't claim anything proposed here is perfect, but nothing is or will be in a 20 year old protocol.