Re: [TLS] TLS renegotiation issue

Eric Rescorla <ekr@rtfm.com> Thu, 05 November 2009 18:52 UTC

Return-Path: <ekr@rtfm.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 6C2DD3A68C3 for <tls@core3.amsl.com>; Thu, 5 Nov 2009 10:52:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 6vk1AbIc7B9A for <tls@core3.amsl.com>; Thu, 5 Nov 2009 10:52:42 -0800 (PST)
Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 92E3F3A62C1 for <tls@ietf.org>; Thu, 5 Nov 2009 10:52:42 -0800 (PST)
Received: by yxe30 with SMTP id 30so296769yxe.29 for <tls@ietf.org>; Thu, 05 Nov 2009 10:53:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.91.54.8 with SMTP id g8mr6990532agk.83.1257447179976; Thu, 05 Nov 2009 10:52:59 -0800 (PST)
In-Reply-To: <200911051848.nA5ImQaY004909@fs4113.wdf.sap.corp>
References: <d3aa5d00911051016p7a0cc508q2090b86de30a50d5@mail.gmail.com> <200911051848.nA5ImQaY004909@fs4113.wdf.sap.corp>
Date: Thu, 5 Nov 2009 10:52:59 -0800
Message-ID: <d3aa5d00911051052r1f9c2fa5kc907bb1ea10b6d2d@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: mrex@sap.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: tls@ietf.org
Subject: Re: [TLS] TLS renegotiation issue
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/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: Thu, 05 Nov 2009 18:52:43 -0000

On Thu, Nov 5, 2009 at 10:48 AM, Martin Rex <mrex@sap.com> wrote:
> Eric Rescorla wrote:
>>
>> I now have a draft extension up
>
> Thanks Eric.
>
>  Page 5:
>
>  The contents of this extension are specified as follows.
>   [...]
>  The above rules apply even when TLS resumption is used.
>
>
> I read this as meaning that the client and server should add
> two elements client.verify_data and server.verify_data
> to their SecurityParameters for the connection state suggested
> by RFC5246 6.1. and update this data on EVERY TLS handshake,
> even TLS session resume.

Yes. That's what it means.


>  4.1  Client Considerations
>
> I can understand what it says, but I _really_ dislike it.
>
> The root of the problem is servers that perform (or at least allow)
> TLS renegotiations and make flawed assumptions about what a
> successful TLS renegotiation means for the data previously received.
>
> What you're essentially asking for, is that a client should no longer
> talk TLS to _any_ Server that doesn't support the new extension.
> Not even to the good ones that neither offer nor support renegotiation.
>
> This is discriminating against servers that have been playing safe!
>
> 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?

-Ekr