Re: [TLS] Proposed text for removing renegotiation

Watson Ladd <watsonbladd@gmail.com> Mon, 09 June 2014 21:21 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 BC7BA1A020E for <tls@ietfa.amsl.com>; Mon, 9 Jun 2014 14:21:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 jl7jRL29s5et for <tls@ietfa.amsl.com>; Mon, 9 Jun 2014 14:21:26 -0700 (PDT)
Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804961A01CF for <tls@ietf.org>; Mon, 9 Jun 2014 14:21:26 -0700 (PDT)
Received: by mail-yh0-f48.google.com with SMTP id b6so1651344yha.7 for <tls@ietf.org>; Mon, 09 Jun 2014 14:21:25 -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=PrZQAoVKPIbGoNHbGcv+aeQAu824H466iHINKqzf5is=; b=r9HPSDvA7lzix/8j58PD+mTCc3J08IruPoq2eLF0eCyUXRhbuYcUxAcJ4Q47EtZu4q f/hbWVCtIGf7d6Mgj7vU89OY+REFKWUJdoENN5oZKNEM4hwZToXsmZBAZbcxFcu+ASjG SX0l5CrAf1wDVxnsPX4ud3JSIdFJo3Q3N/4yU/pop0OYMREwhAvEzs+HTPfQ3KBVs4eq 3rYPPmGL9/j+WWZveaYE3+RBpcCtGEs6XEmcBV4h1/Q8hy4oOKTWBUXrR+NgnCNWwTRB R4zssFkyXyqvGdjZxv8gyarvbW4c6/SP5hwviAJEBMmebVOLzl9CqXRz1yH4LY5sb6+L D2wQ==
MIME-Version: 1.0
X-Received: by 10.236.89.69 with SMTP id b45mr18936512yhf.16.1402348885817; Mon, 09 Jun 2014 14:21:25 -0700 (PDT)
Received: by 10.170.39.136 with HTTP; Mon, 9 Jun 2014 14:21:25 -0700 (PDT)
In-Reply-To: <fab4976db86243c5a02039866e3be457@BL2PR03MB419.namprd03.prod.outlook.com>
References: <CAFewVt65X1V6=A_HP_pcg=6nXNVFLxQmSsPB2rq1KvmGPRz+og@mail.gmail.com> <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <CACsn0cmcc6kXvOuqkZaDj7+QPdpY9qqQ58bs3s-JBGXdNJSZyw@mail.gmail.com> <CABcZeBPe45BM-uXd7DEBD_BBn=jhk8KkYB=facp+NMb2e4nBiw@mail.gmail.com> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <CABkgnnX5+fXNDy1o7Pu60rp8vSx7XfKbt337e_q=+3fb8fXHJw@mail.gmail.com> <fab4976db86243c5a02039866e3be457@BL2PR03MB419.namprd03.prod.outlook.com>
Date: Mon, 9 Jun 2014 18:21:25 -0300
Message-ID: <CACsn0cmJUXFS0+Rj0r9rYvXdn=b_Ynr1tfdnwx23Mv2uoxTRdw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Content-Type: multipart/alternative; boundary=20cf300e524130bf7304fb6dcb3f
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oXc7bpi2GB97cez_h3DdmRRfL30
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Proposed text for removing 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: Mon, 09 Jun 2014 21:21:28 -0000

On Mon, Jun 9, 2014 at 3:49 PM, Andrei Popov <Andrei.Popov@microsoft.com>
wrote:

> Hi Martin,
>
> > The former we have decided to solve in HTTP.
>
> Are you referring to these I-Ds:
> http://tools.ietf.org/html/draft-thomson-httpbis-cant-00
> http://tools.ietf.org/html/draft-thomson-tls-care-00
>
> Httpbis-cant talks (rather vaguely) about using "realm" or "other
> challenge parameters" to select an appropriate client cert. I think client
> cert selection should be clearly specified before we can say that the
> mid-session client auth problem has been solved, and remove renegotiation
> from TLS 1.3.
>
> It would be even better to solve this problem at the TLS layer, so that
> each application protocol does not need to come up with a separate
> solution. And avoiding the round-trips involved in establishing a TCP
> connection would be awesome, too. The current solution using renegotiation
> has both of these desirable properties.
>

TLS still includes the Certificate Request message to indicate which client
certificates are being used. If we have an extension to allow clients to
say "I want to offer a cert, what cert do you want?", this can be used.

>
> Cheers,
>
> Andrei
>
> -----Original Message-----
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson
> Sent: Monday, June 9, 2014 11:17 AM
> To: Nikos Mavrogiannopoulos
> Cc: tls@ietf.org
> Subject: Re: [TLS] Proposed text for removing renegotiation
>
> On 9 June 2014 00:34, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
> > Could somebody elaborate on what is that issue and why does it need to
> > be solved? (it is not even mentioned in the TLS 1.3 charter) As
> > someone who follows the mailing list that proposal comes out of the
> > blue with no context whatsoever.
>
>
> I think that this has been covered in the thread, but piecemeal:
>
> * Renegotiation is a major source of security issues, both of the "we
> screwed the TLS design up" sort and of the "my application didn't realize
> that these things could change" sort.  There is a clear desire to remove
> features that enable either sort of problem.
>
> * Renegotiation is just more protocol complexity.  Removing it potentially
> makes implementations simpler.
>
> I think that either might be sufficient justification for removing the
> feature.
>
> However, a number of use cases depend on renegotiation to achieve their
> ends.  Of these, we have identified:
>
> * mid-session client authentication, which uses renegotiation seems to
> only be used in HTTP
>
> * very long-lived connections, which require renegotiation to re-key
> occasionally
>
> The former we have decided to solve in HTTP.  As a side note, we just
> decided to forbid renegotiation in HTTP/2.
>
> The latter can be addressed by my proposal, or any of a number of
> mechanisms.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
"Those who would give up Essential Liberty to purchase a little Temporary
Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin