IETF Logo Mail Archive

Re: [TLS] inappropriate_fallback

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 09 August 2018 12:56 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 A6243130E40 for <tls@ietfa.amsl.com>; Thu, 9 Aug 2018 05:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 zJtKjeaguQHM for <tls@ietfa.amsl.com>; Thu, 9 Aug 2018 05:56:48 -0700 (PDT)
Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C80C128B14 for <tls@ietf.org>; Thu, 9 Aug 2018 05:56:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1533819408; x=1565355408; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pmiriic3M930glCunzl+fVXYai7w6I6xBpkMxYkcJ+4=; b=hx6jorhKw5AcmuiZaOruOIwb2guNwlvA8dtExrtSVMoVsqFDEfxwPH6Q Ql6cw0nguG4JsFtakSywKNgriHN90FKWESeM4zXz6L5L/Lbx+J4osvPTU YvMPtGCQdZrMq8yArBHbczpdbPDBhhmW4Kb6C6lf5I8fZJ4MK7/Gf0+wl +cptrAIbiPHEKe/s4Abf7B9tdB7dZQ7/8cvaDQgtFBhZ2dmcfg9e+glSx wofDI1tNlCYU1Xel9gjS+wajAgeRNuilcrazGjH1HaN8YDkxe5r2uw95w C4ij/y9yRgo7GxKxpxLs70SZ6ab6WXqwjLCxhXBSPnPYC6+y+THcm4YKA g==;
X-IronPort-AV: E=Sophos;i="5.53,215,1531742400"; d="scan'208";a="25486539"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing
Received: from uxcn13-ogg-c.uoa.auckland.ac.nz ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 Aug 2018 00:56:44 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.24) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 10 Aug 2018 00:56:43 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Fri, 10 Aug 2018 00:56:43 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Eric Rescorla <ekr@rtfm.com>
CC: Benjamin Kaduk <bkaduk@akamai.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] inappropriate_fallback
Thread-Index: AQHULxh+rHxlHWndvUmdM8wCvcYKyaS1Di2AgAABSgCAAAVYAIAAAeqAgAACqoCAAAEgAIAB9yYd//9/M4CAANGP3A==
Date: Thu, 09 Aug 2018 12:56:43 +0000
Message-ID: <1533819390717.16753@cs.auckland.ac.nz>
References: <2fd24f64-bee5-18ed-cf0d-0fc999add395@openssl.org> <20180808132151.GQ28516@akamai.com> <4fe1cef1-2dd2-3838-9019-a97dd4dbe776@openssl.org> <CABcZeBM2Fmo03S=acb=ouZcyV=5-H5dV3is6TJjAJj-SDeRmBw@mail.gmail.com> <b18313b5-ca58-cf66-be72-46ad9ffb4ae0@openssl.org> <20180808140159.GR28516@akamai.com> <CABcZeBOgg0=1G4ENBF+wqZNFLfD6Q60674_G8cJqPZr7oQ9FMw@mail.gmail.com> <1533802033644.1196@cs.auckland.ac.nz>, <CABcZeBPSYsCTn0pOuBPreT4oBrH+ha-PoMP94CnAvOiOr_e_sA@mail.gmail.com>
In-Reply-To: <CABcZeBPSYsCTn0pOuBPreT4oBrH+ha-PoMP94CnAvOiOr_e_sA@mail.gmail.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/cZVJ3Zs-hV61UkrYZZldrszPXbA>
Subject: Re: [TLS] inappropriate_fallback
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
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, 09 Aug 2018 12:56:51 -0000

​Eric Rescorla <ekr@rtfm.com> writes:

>So if the server wants TLS 1.1, then it doesn't set the bytes.

If that's the case then the text that says:

   If negotiating TLS 1.1 or below, TLS 1.3 servers MUST and TLS 1.2
   servers SHOULD set the last eight bytes of their Random value ...

needs to be fixed, beause as far as I can tell that's saying that if the
server wants TLS 1.1 then it has to set the bytes, not that it doesn't set the
bytes.

Here's an example of where this causes problems.  A TLS 1.2 client connects to
the server.  The server, a TLS 1.2 server, is configured to use TLS 1.1, so it
responds with the signalling bytes in its random value.  The client is now
required to abort the handshake even though everything is running as it
should.

Peter.

v2.23.0 | Report a Bug | By Email