Re: [TLS] New drafts: adding input to the TLS master secret

Paul Hoffman <> Sun, 31 January 2010 01:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C8E43A67A8 for <>; Sat, 30 Jan 2010 17:33:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.081
X-Spam-Status: No, score=-6.081 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y9j+jjzZcGJ1 for <>; Sat, 30 Jan 2010 17:33:44 -0800 (PST)
Received: from (Balder-227.Proper.COM []) by (Postfix) with ESMTP id 52D733A6829 for <>; Sat, 30 Jan 2010 17:33:44 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.2/8.14.2) with ESMTP id o0V1YBZh010461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Sat, 30 Jan 2010 18:34:12 -0700 (MST) (envelope-from
Mime-Version: 1.0
Message-Id: <p062408bbc78a8c9e5ede@[]>
In-Reply-To: <>
References: <>
Date: Sat, 30 Jan 2010 17:34:08 -0800
From: Paul Hoffman <>
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [TLS] New drafts: adding input to the TLS master secret
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 31 Jan 2010 01:33:45 -0000

At 5:13 PM -0500 1/30/10, Dean Anderson wrote:
>On Fri, 29 Jan 2010, Paul Hoffman wrote:
>> The first document changes the TLS/DTLS master secret calculation when
>> there are particular kinds of extensions present. Of course, it does
>> not change the calculation when those extensions are not present, and
>> there are no extensions yet that would kick in the change.
>Unless I misunderstand what you plan to change, te master secret
>calculation is a core subject of TLS and thus the TLS Working Group

You do not misunderstand what I plan to change. What I am far from clear on is whether this WG can add such a work item without rechartering, given that the charter disagrees with your view that this is inherently a WG activity. If the WG can adopt the work without rechartering, that would be fine with me. If, however, it takes a bunch of silly work, there is no need to do that: individual submission would give folks just as much review opportunity and will give the AD just as much input from the community.

>I am concerned that this is an out-of-WG framework change that
>effectively alters WG standards on the master secret calculation and
>impacts subsequent extensions; and that as it is outside of the WG
>standards process. 

As you can see from the draft itself, it only affects "subsequent extensions" if those extensions want to be affected. That is, they have to explicitly declare themselves as affected; otherwise, they aren't.

>Independent submissions are not allowed on WG
>subject matter. It would seem to me that the RFC editor ought to reject
>this independent submission because it is related to WG activity, and
>amounts to an end-run around WG decision-making on master secret
>calculation and how TLS extensions affect core facilities. Merely
>bringing such work to the attention of the WG before independent
>submission seems to be insufficient to comply with the requirement that
>Working Groups decide on standards in their chartered area.

All quite true. That's why I said I intended them to be by "individual submission", not "independent submission".

>Changing the master secret calculation in a nonstandard way is a
>proprietary change. 

True, but completely irrelevant. As one can see from the drafts themselves, they are meant to be on standards track.

>The WG gives approval by accepting the document,
>reviewing it, and deciding on it. Saying "Hey WG, look at this" isn't
>sufficient.  Putting an "RFC"  imprimatur on your change via independent
>submission doesn't alter the fact of WG non-standardization, but merely
>confuses both implementers and the public, and constrains WG decisions
>in the future. But of course, that's why the RFC editor is supposed to
>reject independent submissions that overlap WG work.

Again, true but irrelevant. Independent submissions are fully vetted in the IETF, and the AD would certainly want to be sure that there was "enough" technical discussion in the TLS WG before even considering the documents for IETF Last Call.

--Paul Hoffman, Director
--VPN Consortium