[TLS] Draft 18 review: Downgrade protection
Olivier Levillain <olivier.levillain@ssi.gouv.fr> Tue, 22 November 2016 18:58 UTC
Return-Path: <olivier.levillain@ssi.gouv.fr>
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 42CA2129B18 for <tls@ietfa.amsl.com>; Tue, 22 Nov 2016 10:58:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no 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 0izcGWDEjHIO for <tls@ietfa.amsl.com>; Tue, 22 Nov 2016 10:58:56 -0800 (PST)
Received: from garfield.picty.org (garfield.picty.org [82.231.235.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F5212956B for <tls@ietf.org>; Tue, 22 Nov 2016 10:58:56 -0800 (PST)
Received: from neoplankton.picty.org (unknown [80.12.39.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by garfield.picty.org (Postfix) with ESMTPSA id E574E54248 for <tls@ietf.org>; Tue, 22 Nov 2016 18:58:43 +0000 (UTC)
Date: Tue, 22 Nov 2016 20:01:06 +0100
From: Olivier Levillain <olivier.levillain@ssi.gouv.fr>
To: tls@ietf.org
Message-ID: <20161122190101.GA19978@neoplankton.picty.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VusrwTgYIr1m_LsRBq7H1xZc2vs>
Subject: [TLS] Draft 18 review: Downgrade protection
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, 22 Nov 2016 18:58:58 -0000
Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification. We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. = Donwgrade protection = On P.32 (section 4.1.3), the part about downgrade protection mechanism is not clear enough. As I understand it, the modified server_random only occurs with a ServerHello indicating TLS 1.2 or below. Moreover, a TLS 1.2 client should only abort the handshake with the TLS 1.1 value, which is not clear in the explanation. Finally, the ServerKeyExchange is only defined in TLS 1.2 or below, so it would be better to add some precision. Here is a proposal to make these points more explicit: TLS 1.3 has a downgrade protection mechanism embedded in the server's random value. TLS 1.3 server implementations MAY respond to a ClientHello indicating only support for TLS 1.2 or below with a ServerHello containing the appropriate version field. TLS 1.3 server implementations which respond with a TLS 1.2 ServerHello, MUST set the last eight bytes of their Random value to the bytes: 44 4F 57 4E 47 52 44 01 TLS 1.3 server implementations which respond with a ServerHello indicating support for TLS 1.1 or below SHOULD set the last eight bytes of their Random value to the bytes: 44 4F 57 4E 47 52 44 00 TLS 1.3 clients receiving a TLS 1.2 or below ServerHello MUST check that the last eight octets are not equal to either of these values. TLS 1.2 clients SHOULD also check that the last eight bytes are not equal to the second value if the ServerHello indicates TLS 1.1 or below. If a match is found, the client MUST abort the handshake with an "illegal_parameter" alert. This mechanism provides limited protection against downgrade attacks over and above that provided by the Finished exchange: because the ServerKeyExchange, a message present in TLS 1.2 and below, includes a signature over both random values, it is not possible for an active attacker to modify the randoms without detection as long as ephemeral ciphers are used. It does not provide downgrade protection when static RSA is used. I can propose a PR if this makes sense to the WG. Olivier Levillain
- [TLS] Draft 18 review: Downgrade protection Olivier Levillain
- Re: [TLS] Draft 18 review: Downgrade protection Eric Rescorla
- Re: [TLS] Draft 18 review: Downgrade protection Olivier Levillain