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

Dean Anderson <> Sat, 30 January 2010 22:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E91C13A67B6 for <>; Sat, 30 Jan 2010 14:13:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6FamcfKsUso2 for <>; Sat, 30 Jan 2010 14:13:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 517243A6873 for <>; Sat, 30 Jan 2010 14:13:20 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.12.11/8.12.11) with ESMTP id o0UMDfIf007869 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 30 Jan 2010 17:13:45 -0500
Date: Sat, 30 Jan 2010 17:13:41 -0500 (EST)
From: Dean Anderson <>
To: Paul Hoffman <>
In-Reply-To: <p0624089bc78922bdaddd@[]>
Message-ID: <>
MIME-Version: 1.0
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: Sat, 30 Jan 2010 22:13:23 -0000

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

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.  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.

Changing the master secret calculation in a nonstandard way is a
proprietary change.  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.


Av8 Internet   Prepared to pay a premium for better service?         faster, more reliable, better service
617 256 5494