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

Brian Hamon <B.Hamon@F5.com> Fri, 27 June 2014 16:10 UTC

Return-Path: <B.Hamon@f5.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 92E631B3010 for <tls@ietfa.amsl.com>; Fri, 27 Jun 2014 09:10:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.652
X-Spam-Level:
X-Spam-Status: No, score=-7.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 KEFml8pdPOzT for <tls@ietfa.amsl.com>; Fri, 27 Jun 2014 09:10:53 -0700 (PDT)
Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797CD1B2C07 for <tls@ietf.org>; Fri, 27 Jun 2014 09:10:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1403885454; x=1435421454; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Gz69VMKFKv4N8BPSRcXmV+fhMvJvfSAmk1x/3/gnUvU=; b=dDdWUUHqmWqdzeg6J8hr0SMppgfLOcObswx8RbxsReArLcHy3xOCz18o 1urGLPhErK9Z5R3kBKJnOAO5aA84ghZ+Fm3lVWd+lENh68xmNpixKF4hm +JCimMmkE5BqSKYFEO9cQufzKXWesAs4dvsqMEEFrXyK4pW6JYL043VU2 s=;
X-IronPort-AV: E=Sophos;i="5.01,561,1400025600"; d="scan'208";a="119975063"
X-IPAS-Result: AvsEAKeWrVPAqArr/2dsb2JhbABahDmqPQEBAQEBAQaZcAGBIXWEAwEBAQECAR0dPwULAgEIIhQQMiUCBA4NE4gfxBcXhWSIcDEHgy2BFgWWRptUgjA
Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 27 Jun 2014 16:10:52 +0000
Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Fri, 27 Jun 2014 09:10:50 -0700
From: Brian Hamon <B.Hamon@F5.com>
To: Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: [TLS] Call for Consensus on removal of renegotiation
Thread-Index: AQHPkKQi2ibdHwQZAU+UoLazXGbTxJuCn8+AgAAVNgCAATV4AP//97oQgAB9MwD//4sSAIABNxcg
Date: Fri, 27 Jun 2014 16:10:49 +0000
Message-ID: <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>
In-Reply-To: <CE5218A410D7774BA10C7A54F8BB4D305EBAEB@SEAEMBX02.olympus.F5Net.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.15.167]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9R3XENg_w6WGEmfbo3C0nAUnfzA
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:10:55 -0000

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?

This may be where the WG wants to take TLSv1.3, and from an OSI layering perspective might be the best result. After all, if the application is making the decision on whether to require client authentication, then client authentication is best addressed at the application layer. If so, then perhaps this committee should eliminate client authentication completely from TLS.

> My main concern is that if your proposal is accepted, what is the solution for a server that must examine 
> some ApplicationData in order to determine if client authentication is required?