[TLS] draft-rescorla-tls-renegotiate.txt

Martin Rex <mrex@sap.com> Fri, 06 November 2009 19:27 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F65328C0D8 for <tls@core3.amsl.com>; Fri, 6 Nov 2009 11:27:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.072
X-Spam-Level:
X-Spam-Status: No, score=-6.072 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0VWlOd0Vnal for <tls@core3.amsl.com>; Fri, 6 Nov 2009 11:27:46 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 6831928C1C0 for <tls@ietf.org>; Fri, 6 Nov 2009 11:27:45 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA6JS7Pr029523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 20:28:07 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911061928.nA6JS7vq000076@fs4113.wdf.sap.corp>
To: ekr@rtfm.com (Eric Rescorla)
Date: Fri, 6 Nov 2009 20:28:07 +0100 (MET)
In-Reply-To: <d3aa5d00911051052r1f9c2fa5kc907bb1ea10b6d2d@mail.gmail.com> from "Eric Rescorla" at Nov 5, 9 10:52:59 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org
Subject: [TLS] draft-rescorla-tls-renegotiate.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Fri, 06 Nov 2009 19:27:47 -0000

Eric Rescorla wrote:
> 
> >  4.1  Client Considerations
> >
> > Essentially we are going to hold TLS clients and the installed
> > base of good Servers responsible for the broken Servers out there.
> > That feels very wrong.
> 
> I'm not recommending that clients do that. What I'm trying to say is that
> *if* a client wants to be totally sure then all it can do is require
> the extension.
> I agree it's impractical (and probably unwise) to suggest that they actually
> behave that way.
> 
> Do you agree that the characterization above is correct? If so, how can I
> update the draft to make that clearer?

Yes, unfortunately, the description is the honest and cold truth.

It's challenging to come up with something better.

Maybe the consequences of the suggestion to no longer talk to
SSL/TLS servers without that extension should be made more
explicit.


As correctly described in Marshs publication, the problem affects
all existing releases of the SSL and TLS protocol family.

I assume that this WG, the IETF, the vendors and the consumers would
appreciate if the fix could be applied to the entire installed base,
no matter what protocol level each component implements.

It's not always an option to move to a newer implementation that
also supports a more recent version of TLS, so I would appreciate
that we describe two additional things in this draft:

   - to describe how to add/implement this fix to each and
     every affected protocol version of the SSL/TLS Family.

     I just noticed that SSLv3 does _NOT_ have a "no_renegotiate" alert!
     To me, it looks like the SSLv3 spec does not specify how to
     deny performing a renegotiate.  Which is slightly odd, since
     there are SSLv3 implementations that do not implement renegotiation...

   - to describe/suggest the behaviour for implementations of SSL/TLS
     that do not support (or do not want to perform) renegotiation,
     in particular for SSLv3.

   - since we currently overload the empty extension with signaling
     to different things: 
       - I am a patched server
       - I support secure renegotiation

     we should probably explicitly describe what a TLS v1.x Server
     should do if it does not implement TLS renego in the server or
     reliably know that it will not perform renegotiation.
     Since it is against common sense that such a server responds
     with a TLS Extension "I support secure renegotiation" in
     the ServerHello, we should explicity write what we want them
     to implement.


-Martin