Re: [TLS] Proposed text for removing renegotiation

Andy Lutomirski <luto@amacapital.net> Wed, 28 May 2014 00:13 UTC

Return-Path: <luto@amacapital.net>
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 8BF771A081F for <tls@ietfa.amsl.com>; Tue, 27 May 2014 17:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 o9sXb35Fgys7 for <tls@ietfa.amsl.com>; Tue, 27 May 2014 17:13:20 -0700 (PDT)
Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 426161A07D4 for <tls@ietf.org>; Tue, 27 May 2014 17:13:20 -0700 (PDT)
Received: by mail-pa0-f47.google.com with SMTP id lf10so9996916pab.34 for <tls@ietf.org>; Tue, 27 May 2014 17:13:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=g8E8GY3arnZrRaXsAfumKN1vGvByS6KeAwKVKU1//14=; b=eD9HjgmrwWFHSu6n0OSs07MH9xJ7EL4/tc8ikQLXqekxRkcMekMEFe/OQzI9juNobi ez/W6bEcisoOKnDkRsHNQzrzDwfggoNm3nhKgdDwC9c5vv1izS+u4BIcUZuLH2tpKz1M PDDtDEDOMBkpC3b9sgcm43zkqcAoGHtF2q54A4meKg8aAJ8tAcrdA8pqRO2j4OMXIncD UCtMskTOmvFMEWL6jA6rgkg3s3T60huKofh4D3bJs+PamuZ1kD3oId+O+EDaeX69StqP HX086AeRTHSBfYwSMtTvsDDbown8VLsXafyy5ewTVwvLyYz+2bPq4orOb86ucbcxmsPN 34Kw==
X-Gm-Message-State: ALoCoQmhp8dpfyagg7ldjB0hvf+ZnCa1r+/YJB48U1hdC6rNss8oX4jZ13Ei2tmOZlkDIsYbSKGb
X-Received: by 10.68.106.130 with SMTP id gu2mr40482713pbb.59.1401235997040; Tue, 27 May 2014 17:13:17 -0700 (PDT)
Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id xg4sm25234060pbb.47.2014.05.27.17.13.15 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 17:13:16 -0700 (PDT)
Message-ID: <53852A1B.6000808@amacapital.net>
Date: Tue, 27 May 2014 17:13:15 -0700
From: Andy Lutomirski <luto@amacapital.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Salz, Rich" <rsalz@akamai.com>, Martin Thomson <martin.thomson@gmail.com>, "tls@ietf.org" <tls@ietf.org>
References: <CABkgnnXaLKmxXL01hQEdxHSNGt3nZQQNBLDD5H2LqBzTo3vK4g@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130CE35E03@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130CE35E03@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AxIgxbjdaqxc9J9ArOe1XIcOStg
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: Wed, 28 May 2014 00:13:21 -0000

On 05/27/2014 03:18 PM, Salz, Rich wrote:
>> This overloads ChangeCipherSpec, which some might find distasteful, but I think that it is consistent with it's current use and purpose.
> 
> Yeah, I'm not thrilled but it, although I admit it is consistent.
> 
> I would rather see something like Yoav (?) proposed via Jabber at the interim meeting:  a "reset but don't close" message.  Either side sends it, the other side replies, and at this point all state is thrown away and it's just as if the client first connected.  It avoids TCP reconnect, perhaps requires more work (but the EDH key should be cached), but it seems much clearner.

I suspect that, without a lot of API care, this will reintroduce the
original renegotiation attack: client sends a prefix, says "reset but
don't close", and starts forwarding ciphertext from a different client.

--Andy