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

Eric Rescorla <ekr@rtfm.com> Fri, 27 June 2014 16:29 UTC

Return-Path: <ekr@rtfm.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 F28641B29B3 for <tls@ietfa.amsl.com>; Fri, 27 Jun 2014 09:29:28 -0700 (PDT)
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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 QGaCK1IFGAyB for <tls@ietfa.amsl.com>; Fri, 27 Jun 2014 09:29:27 -0700 (PDT)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19EFF1B2960 for <tls@ietf.org>; Fri, 27 Jun 2014 09:29:26 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id bs8so3126177wib.7 for <tls@ietf.org>; Fri, 27 Jun 2014 09:29:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QwRADSwgB38GtCm8rIDXIPsTBqTTwNVasKnfUV0kl9s=; b=mKx7W7p9/I9u1M9m+bpMLroUSnn3eKcgQXaLkuQWv67l+syhSgaVCOaNk+Bvj+Ynts 1GfhfQvTafblSkmesCOoivRd08R7FFOOKljMpiCyTpwy1AdlyX2tXMls9uH8fQJ/ARnW ex7Zd8yBf75itvLpwiuE1rC+cxJr8n813cSwI7+IZpDH9zMpFC5RG3GUcLDuCGkv88UP PFGcBd2quoGu0fPLYVHx/7Y6iOdvktoafAm/R93qtCgd3tyvjnw8luwPCCYHGpFLVigr R31qO5dgxEFWl6Vpl3kVt0bgI8SyAyTr/ZIJ/L5R/1RyoWqysmvkBSd4UVzTposlrR3c a3gw==
X-Gm-Message-State: ALoCoQm9wEDkrFy8Zp5myJdnswjqLlg6Bhz6raD+QrB5tBD50MXbDNZJdeLIMZjUO+kJacJIFhjs
X-Received: by 10.180.76.20 with SMTP id g20mr12933446wiw.7.1403886565623; Fri, 27 Jun 2014 09:29:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Fri, 27 Jun 2014 09:28:45 -0700 (PDT)
X-Originating-IP: [2620:101:80fc:232:41f3:8311:4908:49b1]
In-Reply-To: <CABkgnnU_NnrCErf6Hn3HOWD-h1jL7i2QGpsAC7w-4r33LSacyQ@mail.gmail.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> <CABkgnnU_NnrCErf6Hn3HOWD-h1jL7i2QGpsAC7w-4r33LSacyQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 27 Jun 2014 09:28:45 -0700
Message-ID: <CABcZeBNdTp10TLF6Z6YxqdNvE0vFCNQ9xZHZJf2cMkEdo1cLug@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="f46d043439460ca35804fcd3d00f"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2mzwxUdyH_Brra32zOX12rRYQY0
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:29:29 -0000

On Fri, Jun 27, 2014 at 9:25 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> 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.


I would oppose that. There are plenty of situations where mutual
authentication
is needed in TLS.

-Ekr


> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>