IETF Logo Mail Archive

Re: [TLS] Call for Consensus on removal of renegotiation

Martin Thomson <martin.thomson@gmail.com> Fri, 27 June 2014 16:25 UTC

Return-Path: <martin.thomson@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 2E8721B2992 for <tls@ietfa.amsl.com>; Fri, 27 Jun 2014 09:25:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 09ajSPR7WHkq for <tls@ietfa.amsl.com>; Fri, 27 Jun 2014 09:25:55 -0700 (PDT)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9D41B27EC for <tls@ietf.org>; Fri, 27 Jun 2014 09:25:54 -0700 (PDT)
Received: by mail-we0-f178.google.com with SMTP id x48so5482930wes.23 for <tls@ietf.org>; Fri, 27 Jun 2014 09:25:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5n3epwE9vju/exJAzIqPj6WcDaMAiL0q2c+eoYRtI2o=; b=RZcB34+OCS8YbywzwCx1OY+2uqov3JXu7T6mzCG4DrFa2fuJPyTdZh8q8gntqznkjL ewx7islhwZAx/SsoHKxBfBN0KhFIlfoVhqcyEaf8oPlqOgibKjzOrom0+0l6j0pWDEmN UqUO2FTFElcOzcrNYd2K5Z0ooW6/cc72BIvJBaSWOfB9iaEz2A3So28XZwhJp4xhhyjw TDceHCUnUvaBs41jz6XxhejWkHK21QPO849xFqXN/NisaPXuFRSDU4qi/HtEvQLWzwh8 VW9orlSuYDJyEWzJ3LnhrpjoRZmg1TXjWZHbUPsASA7QGeg4v+ptJgGmfsTEXId9Jt3/ wmuA==
MIME-Version: 1.0
X-Received: by 10.180.14.162 with SMTP id q2mr13048331wic.54.1403886353372; Fri, 27 Jun 2014 09:25:53 -0700 (PDT)
Received: by 10.194.51.134 with HTTP; Fri, 27 Jun 2014 09:25:53 -0700 (PDT)
In-Reply-To: <CE5218A410D7774BA10C7A54F8BB4D305EBE3E@SEAEMBX02.olympus.F5Net.com>
References: <B7430912-46B8-49DD-85EC-00FC5BC3B8D3@cisco.com> <20140626143044.F3B0C1AD68@ld9781.wdf.sap.corp> <CE5218A410D7774BA10C7A54F8BB4D305EBAC9@SEAEMBX02.olympus.F5Net.com> <CABkgnnVBsAJ3+KaR87WgUO0oQ=mYrnA7r4+qSOdcrmkM3ne7iw@mail.gmail.com> <CE5218A410D7774BA10C7A54F8BB4D305EBAEB@SEAEMBX02.olympus.F5Net.com> <CE5218A410D7774BA10C7A54F8BB4D305EBE3E@SEAEMBX02.olympus.F5Net.com>
Date: Fri, 27 Jun 2014 09:25:53 -0700
Message-ID: <CABkgnnU_NnrCErf6Hn3HOWD-h1jL7i2QGpsAC7w-4r33LSacyQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Brian Hamon <B.Hamon@f5.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0RRhU_mb3pwcGjZkeJI43p_zbFU
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Call for Consensus on removal of renegotiation
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: Fri, 27 Jun 2014 16:25:56 -0000

On 27 June 2014 09:10, Brian Hamon <B.Hamon@f5.com> wrote:
> Unless someone makes a case otherwise, I think that the answer to my question is that client authentication (assuming Martin's proposal is accepted) is either required from initial ServerHello or unavailable?


There are other options:

1. TLS 1.3 could allow clients to authenticate unilaterally (i.e., not
require the CertificateRequest message to be sent before sending a
client cert, or mandating that servers provide a CertificateRequest
always).

2. Authentication might be provided with a separate type of control
message.  This has been discussed.

And any combination of the above, depending on what we think best fits
the complexity/functionality trade-off.

Personally, I like the idea of doing option 1 here.  With
confidentiality protection for handshake messages, it could make
client authentication considerably more accessible than it was in
previous TLS versions.

> [...] perhaps this committee should eliminate client authentication completely from TLS.

I haven't seen much interest in doing that.  My proposal still relies
on TLS providing a binding to client credentials.

v2.23.0 | Report a Bug | By Email