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

David Benjamin <davidben@chromium.org> Thu, 02 June 2016 15:27 UTC

Return-Path: <davidben@google.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 383A912D5C3 for <tls@ietfa.amsl.com>; Thu, 2 Jun 2016 08:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.125
X-Spam-Level:
X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 topuEhVLntPt for <tls@ietfa.amsl.com>; Thu, 2 Jun 2016 08:27:17 -0700 (PDT)
Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 140CD12D111 for <tls@ietf.org>; Thu, 2 Jun 2016 08:27:17 -0700 (PDT)
Received: by mail-io0-x22e.google.com with SMTP id t40so49421515ioi.0 for <tls@ietf.org>; Thu, 02 Jun 2016 08:27:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=agyofZPP5Qzh1XOKG5RfIVEQtpAfQmo00gbLrJVfn4k=; b=fqXEPIGwRQJ3mQDqHq7eZYqrzdZiG+2f00mytmmYCRccpDuELIlopK4lS8cI1KH/Gj /jbZG6igsZywIH7yWBSE9pzEWCGKPmxFhk8kMnG5txHHn8V4wAYzt3qI/TqzuCQDhfrl yQdvZcaDNKk8uyd+VNdT8IWUyq6UQz5aB+Iis=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=agyofZPP5Qzh1XOKG5RfIVEQtpAfQmo00gbLrJVfn4k=; b=dq6HINg1si1E/hgzfPQSJstL37REGVzLZdfpDEAoHqmfnlOykCCrtf4vBSSnK07hXb HyAvs7DmIFpFuqps2cv9G+L0Vqxi9ZjnkRR8M3GOuShWznzjvldM64XDB/xi8bU+SuVV CIFW0uyRKfJpsxeot063H1hv/4Oi785xI+HyTy3wSIeQkhlBiFOznfiC4PNCkEwGDt8w ombGy1YXuf6oqs8I+7h0KME/iYd0g5DAXkr4XLECwYqhG/ug2kIwBFgPTIv9UFlyzXVK dCUqOq3W44l90F6k8gPbQg0i1Rn16inSMVUhtNgK9qZJ1PYc3w18QNVpfzWqKxWpFx3A xFrA==
X-Gm-Message-State: ALyK8tKjY/Js3+T+R820AcAcGJwVlBQaQJ+AKVWo8MRqT10iJG7jhfSnV6G/oXg+6VD765lvkfHoJb08y7fTb8Fq
X-Received: by 10.107.173.66 with SMTP id w63mr4468467ioe.110.1464881236180; Thu, 02 Jun 2016 08:27:16 -0700 (PDT)
MIME-Version: 1.0
References: <CAF8qwaDuGyHOu_4kpWN+c+vJKXyERPJu-2xR+nu=sPzG5vZ+ag@mail.gmail.com> <6238043.DCePXUsCVt@pintsize.usersys.redhat.com> <CAF8qwaCx-AyconwmB+mXMtNFYxhRrt7Kkqw+x5xZUgajXw1ZkQ@mail.gmail.com> <2454213.pazTbBCOtZ@pintsize.usersys.redhat.com>
In-Reply-To: <2454213.pazTbBCOtZ@pintsize.usersys.redhat.com>
From: David Benjamin <davidben@chromium.org>
Date: Thu, 02 Jun 2016 15:27:06 +0000
Message-ID: <CAF8qwaBcgJuKX5SkFaG+oQE4w6SYh0EBGppwoY4YcqOL7C6trw@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Content-Type: multipart/alternative; boundary=001a114467c2b8e8ad05344d3d5e
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/uqAmfOZEGvtQ0ObpmXtHUBTus90>
Cc: tls@ietf.org
Subject: Re: [TLS] 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: Thu, 02 Jun 2016 15:27:19 -0000

On Thu, Jun 2, 2016 at 11:20 AM Hubert Kario <hkario@redhat.com>; wrote:

> > > Speaking of version number, does the text say that a server _MUST_
> > > accept any version higher than the one that is specified in the RFC,
> > > but reply with 0x03,0x04 in case it doesn't support any future
> > > version of the protocol? It would be nice to have some kind of
> > > stick for the broken implementations...
> >
> > I'm not sure I follow. The specification certainly spells out how
> > version negotiation is supposed to work. That hasn't stopped servers
> > from getting it wrong. Fundamentally this is the sort of thing where
> > bugs don't get noticed until we make a new TLS version, and we don't
> > do that often enough to keep rust from gathering.
>
> yes, but I don't see it spelling out anywhere that a server MUST accept
> higher numbers, it just describes how the mechanism works up to this
> point, not how it will continue to work
>
>
I added an entry here a bit ago:
https://tlswg.github.io/tls13-spec/#rfc.appendix.B.4
"When processing a ClientHello containing a version of { 3, 5 } or higher,
do you respond with the highest common version of TLS rather than requiring
an exact match?"

The ServerHello section says:
https://tlswg.github.io/tls13-spec/#rfc.section.6.3.1.2
"This field [server_version] will contain the lower of that suggested by
the client in the ClientHello and the highest supported by the server. For
this version of the specification, the version is { 3, 4 }. (See Appendix C
for details about backward compatibility.)"

Although the ClientHello section says:
https://tlswg.github.io/tls13-spec/#rfc.section.6.3.1.1
"The version of the TLS protocol by which the client wishes to communicate
during this session. This SHOULD be the latest (highest valued) version
supported by the client. For this version of the specification, the version
will be { 3, 4 }. (See Appendix C for details about backward
compatibility.)"

I'll go put together a PR to change that to say the highest version
supported or something. "which the client wishes to communicate" is
somewhat ambiguous...

David