Re: [TLS] Triple Handshake Fix.
mrex@sap.com (Martin Rex) Tue, 29 April 2014 22:06 UTC
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA361A09CA for <tls@ietfa.amsl.com>; Tue, 29 Apr 2014 15:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 5VsowCKAO03f for <tls@ietfa.amsl.com>; Tue, 29 Apr 2014 15:06:20 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4D94E1A09A9 for <tls@ietf.org>; Tue, 29 Apr 2014 15:06:20 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s3TM6B6e021033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Apr 2014 00:06:11 +0200 (MEST)
In-Reply-To: <op.xe3krion3dfyax@killashandra.invalid.invalid>
To: "Yngve N. Pettersen" <yngve@spec-work.net>
Date: Wed, 30 Apr 2014 00:06:10 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140429220611.041D31ACE8@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/M28S_wyCFWRRrCkXMlRB-TWP6d8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Triple Handshake Fix.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: <http://www.ietf.org/mail-archive/web/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, 29 Apr 2014 22:06:22 -0000
Yngve N. Pettersen wrote: > > On Tue, 29 Apr 2014 23:05:50 +0200, Adam Langley <agl@google.com> wrote: > > > > [1] https://secure-resumption.com > > [2] https://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt > > A comment about the draft: > > Section 5.3 states: > > In its ClientHello message, a client MUST either send the > "extended_master_secret" extension, or the > "TLS_EXTENDED_MASTER_SECRET" SCSV. Clients SHOULD NOT include both. > > In my opinion, the "SHOULD NOT" ought to be a "MUST NOT", *unless* the > document also states something like "Servers MUST accept ClientHello > messages that contain both the "extended_master_secret" extension and the > "TLS_EXTENDED_MASTER_SECRET" SCSV, and treat them as if only one had been > received" The only problem is having two seperate indicators with the exact same meaning in the first place. Kill the ClientHelloExtension, have everyone use the SCSV in ClientHello all the time. > > When I originally implemented the Renego Information extension in Opera, I > decided to send both, since deciding when to send either complicates the > code, at least a little. However, I had to eventually change the code to > send only one of them (SCSV in extension less handshakes, extension > otherwise), as 4.7% of Renego patched servers does not tolerate the > combination, some of them major sites like Linkedin and Paypal. The by far simplest approach is to send SCSV on all initial handshakes plus on old-style renegotiation handshakes, and the TLS extension on all renegotiation handshakes. KISS -- smaller and simpler code. So far I have not received any reports about interop problems with my implementation. > > A SHOULD NOT means that the server may encounter handshakes with both, and > since server vendors apparently are apt to think that "either" and "SHOULD > NOT include both" in combination means "MUST NOT include both", then the > document should either specify how the server should handle reception of > both indicators, or say that both are forbidden. Imperatives should only be used when they're absolutely necessary, so here we have the situation where we need a MAY if we can not get rid of the ClientHelloExtension. Unfortunately, the poor choice of defining both for rfc5746 made it likely that a few superficial implementors get the combination wrong. Remember Mike's description? https://www.ietf.org/mail-archive/web/tls/current/msg05456.html -Martin
- [TLS] Triple Handshake Fix. Adam Langley
- Re: [TLS] Triple Handshake Fix. Alfredo Pironti
- Re: [TLS] Triple Handshake Fix. Yngve N. Pettersen
- Re: [TLS] Triple Handshake Fix. Nico Williams
- Re: [TLS] Triple Handshake Fix. Martin Rex
- Re: [TLS] Triple Handshake Fix. Martin Thomson
- Re: [TLS] Triple Handshake Fix. Geoffrey Keating
- Re: [TLS] Triple Handshake Fix. Nico Williams
- Re: [TLS] Triple Handshake Fix. Watson Ladd
- Re: [TLS] Triple Handshake Fix. Bodo Moeller
- Re: [TLS] Triple Handshake Fix. Bodo Moeller
- Re: [TLS] Triple Handshake Fix. Karthik Bhargavan
- Re: [TLS] Triple Handshake Fix. Karthik Bhargavan
- Re: [TLS] Triple Handshake Fix. Geoffrey Keating
- Re: [TLS] Triple Handshake Fix. Nico Williams
- Re: [TLS] Triple Handshake Fix. Bodo Moeller
- Re: [TLS] Triple Handshake Fix. Nico Williams
- Re: [TLS] Triple Handshake Fix. Martin Thomson
- Re: [TLS] Triple Handshake Fix. Bodo Moeller
- Re: [TLS] Triple Handshake Fix. Bodo Moeller
- Re: [TLS] Triple Handshake Fix. Nico Williams
- Re: [TLS] Triple Handshake Fix. Bodo Moeller
- Re: [TLS] Triple Handshake Fix. Watson Ladd
- Re: [TLS] Triple Handshake Fix. Nico Williams
- Re: [TLS] Triple Handshake Fix. Bodo Moeller