IETF Logo Mail Archive

[TLS] Renegotation redux

Watson Ladd <watsonbladd@gmail.com> Mon, 14 April 2014 14:48 UTC

Return-Path: <watsonbladd@gmail.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 C33FD1A044B for <tls@ietfa.amsl.com>; Mon, 14 Apr 2014 07:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 L9fGVJTE1n5J for <tls@ietfa.amsl.com>; Mon, 14 Apr 2014 07:48:25 -0700 (PDT)
Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA131A0468 for <tls@ietf.org>; Mon, 14 Apr 2014 07:48:25 -0700 (PDT)
Received: by mail-yh0-f41.google.com with SMTP id i57so6706991yha.28 for <tls@ietf.org>; Mon, 14 Apr 2014 07:48:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=J5lgFII3oEHkvN/aa/b6KtOXyxV+E03w8PZOP2q2ejw=; b=JXB7P+06IqjXn/jMecyUh79NX8GEYk8UR0+iVGrDifF/9WZOnOPjysuWP6Ra60z0s6 rZrkPm5/0xxkf1qc/+S88WB960Kxh875OG6uSD6paEqa3xajumzXY7/XuT8d/lBEv8OG YpchVXUpwuA1D1WdJmJ0eNLmvZMB8Ch17Mi8qH7aERZ+Jd9x4kQO/3ErDwu94gVx/8RB FnhSt+mcd+tJDoO2te3ZEYJR0Q6ZAU2eOQVSgqmboejFoWZF2PuBIDOo/0WdFZlC8LAY TqB4z9on1kXT2JG8A+8SB7QjNjwKEfCWx61fOzVc81RgOJsvRLn9Q3Y12fg5xyJ1eM8S NmRQ==
MIME-Version: 1.0
X-Received: by 10.236.66.135 with SMTP id h7mr3102100yhd.60.1397486902921; Mon, 14 Apr 2014 07:48:22 -0700 (PDT)
Received: by 10.170.63.197 with HTTP; Mon, 14 Apr 2014 07:48:22 -0700 (PDT)
Date: Mon, 14 Apr 2014 07:48:22 -0700
Message-ID: <CACsn0c=mLgKor7PLPG0PNMYqJP9bDD1yfVeCzM0yUFwnkgMQXg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OypOoKn4LvxmdEFtyTtOCWa8InM
Subject: [TLS] Renegotation redux
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <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: Mon, 14 Apr 2014 14:48:26 -0000

Dear all,

Are there any users of renegotiation beyond authentication with client
side certificates? In particular has anyone come up with a use for
changing the claimed identity of the server?

I think we can do client authentication upgrades via a channel
extraction+signing solution while preserving the privacy currently
given by renegotiation. I haven't yet run Proverif on this solution,
so it might not work, but my intuition is that this will work better
than trying to expose the semantics of renegotiation correctly.

Renegotation has been responsible for two major security issues, and
significantly complicates the TLS handshake state machine and
semantics.

Sincerely,
Watson Ladd

v2.23.0 | Report a Bug | By Email