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

Watson Ladd <watsonbladd@gmail.com> Fri, 27 June 2014 01:23 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 6E4C21B3094 for <tls@ietfa.amsl.com>; Thu, 26 Jun 2014 18:23:37 -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 bRMvSpGgNlca for <tls@ietfa.amsl.com>; Thu, 26 Jun 2014 18:23:35 -0700 (PDT)
Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDBE51B298B for <tls@ietf.org>; Thu, 26 Jun 2014 18:23:35 -0700 (PDT)
Received: by mail-yh0-f53.google.com with SMTP id b6so2637667yha.12 for <tls@ietf.org>; Thu, 26 Jun 2014 18:23:35 -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=6Cyxfn0PGLtahZQM/Ww1K95xlxFSTJQa3VUNzBXWdnA=; b=udfJidnp+yFiVCIQgHWER5YXQDRYm6bEfu3iw5xod2hRvlSbIxqFaDCq5H2k2hkBSJ jMFJG2nUl6Ip0LEIwOqg1LztASbxGr+9KCr5vTBU5TylgFc2xOv6ClJkBlVbXGsx59LW LcmwcSGWEXiahbXrkc/E/FIAte/7zi86NqdPptJSXgkXeVUh6a5qpnx3/4c9T35prs8d uCJgvOAzW5cylgqIedNK2rIz7d4QF5y44OottwCOdHekMWV9QIVz75PogA0P+Phc/ExN eOC0xlv/Ft15vfXJk/dai8s8ed+jLanNNHR+m8M5Dfqirqc+WxBufHQBCbyExm8nn91U HCwQ==
MIME-Version: 1.0
X-Received: by 10.236.129.115 with SMTP id g79mr26638627yhi.86.1403832215063; Thu, 26 Jun 2014 18:23:35 -0700 (PDT)
Received: by 10.170.39.136 with HTTP; Thu, 26 Jun 2014 18:23:34 -0700 (PDT)
In-Reply-To: <20140626143044.F3B0C1AD68@ld9781.wdf.sap.corp>
References: <B7430912-46B8-49DD-85EC-00FC5BC3B8D3@cisco.com> <20140626143044.F3B0C1AD68@ld9781.wdf.sap.corp>
Date: Thu, 26 Jun 2014 18:23:34 -0700
Message-ID: <CACsn0c=3-SdQUADeUaN_eh6wZ4MMTPViizC5gmpmonrJ-wN4wg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "mrex@sap.com" <mrex@sap.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/melHiFK8oVi4J3u9GQ74HQyqA1E
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 01:23:37 -0000

On Thu, Jun 26, 2014 at 7:30 AM, Martin Rex <mrex@sap.com> wrote:
> Joseph Salowey (jsalowey) wrote:
>>
>> 1.  In favor of removing renegotiation
>> 2.  In favor of removing renegotiation with the addition of rekey facility
>> 3.  Not in favor of removing renegotiation
>
>
> (3) Leave it in the spec,  Make it a true option for implementors.
>     with a guidance that clients might need it for interop, but should
>     play safe (and nail down identities once they're established) by default
>
>
> I never offered/exposed renegotiation at the API to application callers,
> and since January 2010, I have the server-side reject renegotiation attempts
> from clients.  But the installed base of _other_ servers that use
> (or require) it is to large to be ignored, and I don't see it go away
> that easily...
>
> Everything that you change from TLSv1.0/1/2 toward v1.3 will add complexity
> and require more code.  This applies not just to adding new features, but
> also to axing existing features that may be in current use.
>
> A TLSv1.3 spec that requires implementors to carefully avoid TLSv1.3 for
> a number of commonly used TLSv1.0/1/2 features may be even harder to
> sell than TLSv1.2 and IPv6.

I think this is an excellent point: unless we are making TLS 1.3 web
only, and committing to supporting TLS 1.2 (including renegotation!)
for
a long time, we cannot ax this feature. As much as I dislike
renegotiation, it may be that we need to include it as an optional
feature if we want to replace TLS 1.2.

Conversely, if we're committed to stabilizing the security flaws in
TLS 1.2 and phasing it out, while not having everything upgrade to TLS
1.3, we can get away with eliminating  renegotation.

Sincerely,
Watson Ladd
>
>
> -Martin
>
> _______________________________________________
> 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