Re: [TLS] Issue 49: Finished.verify length

Russ Housley <housley@vigilsec.com> Mon, 17 September 2007 13:56 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXH52-0001Wq-7r; Mon, 17 Sep 2007 09:56:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXH51-0001Wl-1T for tls@ietf.org; Mon, 17 Sep 2007 09:56:03 -0400
Received: from [8.8.40.152] (helo=woodstock.binhost.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IXH4z-0004Vv-SD for tls@ietf.org; Mon, 17 Sep 2007 09:56:03 -0400
Received: (qmail 21278 invoked by uid 0); 17 Sep 2007 13:48:38 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203) by 8.8.40.152 with SMTP; 17 Sep 2007 13:48:38 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 17 Sep 2007 09:36:45 -0400
To: Eric Rescorla <ekr@networkresonance.com>
From: Russ Housley <housley@vigilsec.com>
Subject: Re: [TLS] Issue 49: Finished.verify length
In-Reply-To: <20070916171835.57FF033C21@delta.rtfm.com>
References: <20070914090853.GA20702@tau.invalid> <B356D8F434D20B40A8CEDAEC305A1F2404937712@esebe105.NOE.Nokia.com> <20070914120310.GA29073@tau.invalid> <B356D8F434D20B40A8CEDAEC305A1F2404937802@esebe105.NOE.Nokia.com> <20070914141809.2439533C21@delta.rtfm.com> <B356D8F434D20B40A8CEDAEC305A1F2404966D3F@esebe105.NOE.Nokia.com> <20070914183633.6B09F33C21@delta.rtfm.com> <B356D8F434D20B40A8CEDAEC305A1F2404966DF0@esebe105.NOE.Nokia.com> <20070916171835.57FF033C21@delta.rtfm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org
Message-Id: <E1IXH52-0001Wq-7r@megatron.ietf.org>

Eric:

>Well, I don't think changing the encoding is needed. The
>verify_data is the only thing in the Finished message so it's
>already implicitly encoded. If we want to allow this to change
>length without doing an Update, then why not change it to:
>
>    struct {
>        opaque verify_data[SecurityParameters.finished_length];
>    } Finished;
>
>This leaves a hole but doesn't require changing the wire encoding.
>
>That said, I'd sort of like to discourage changing the length without
>good reason, so I'd actually like the first cipher suite to do
>this to have to Update: TLS 1.2. However, using the technique above,
>we could make this cahnge later without having to impact
>implemenations that didn't support the new cipher suite.

I like this way forward, but I do not see any reason to wait.  A 
ciphersuite should not need to update the base protocol specification.

Russ 


_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls