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