Re: [TLS] Revised TLS Charter

Joe Salowey <jsalowey@cisco.com> Fri, 13 May 2011 15:21 UTC

Return-Path: <jsalowey@cisco.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100A6E0735 for <tls@ietfa.amsl.com>; Fri, 13 May 2011 08:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7TKVXxr1Roa for <tls@ietfa.amsl.com>; Fri, 13 May 2011 08:21:41 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 93E8CE0734 for <tls@ietf.org>; Fri, 13 May 2011 08:21:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=2167; q=dns/txt; s=iport; t=1305300101; x=1306509701; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8PSbz6J6EX7u8Ig4PX+7whIREpsP/hgDVFU+WcOLNK8=; b=ftcWUidb5PmiOSA0i8Mst+9Wk5el3nOFFAC0gl6Wfu0scstiTh/ShGmy 4vJ5BcUJ4dJSqVeEcxSHCJVRc+xNdwU4Wzy39E7B8Rd7rtsrwd/gELZ0z qMJl0IduLsUmeD1oP6hvYfVoYX5e327gqjqYQl4NoUc88OuM7RmNI0dj6 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAL1LzU2rRDoI/2dsb2JhbACmCHeIcJ5lnhOGFQSGTYk5hC+KYw
X-IronPort-AV: E=Sophos;i="4.64,364,1301875200"; d="scan'208";a="697016647"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 13 May 2011 15:21:41 +0000
Received: from [10.33.249.93] ([10.33.249.93]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4DFLcIR006641; Fri, 13 May 2011 15:21:39 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Joe Salowey <jsalowey@cisco.com>
In-Reply-To: <1886376336.97108.1305232878619.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
Date: Fri, 13 May 2011 08:21:48 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <C36057C9-4213-4839-8A5F-C50CD813A2D6@cisco.com>
References: <1886376336.97108.1305232878619.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
To: Brian Smith <bsmith@mozilla.com>
X-Mailer: Apple Mail (2.1084)
Cc: tls@ietf.org
Subject: Re: [TLS] Revised TLS Charter
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 13 May 2011 15:21:42 -0000

On May 12, 2011, at 1:41 PM, Brian Smith wrote:

> Joe Salowey wrote:
>> [Joe] The intent is to tighten up the charter so minor work items
>> such, as cipher suites and extensions, are still in scope and major
>> changes to the operation of the protocol are out of scope and require
>> a charter revision. This does not mean that we cannot discuss such
>> changes in the working group, but before we add add work items to
>> create documents for these changes we would need to update the
>> charter. While I can envision cases where updating the charter would
>> be irritating I think in most cases where we have working group
>> consensus to make the change it would be relatively easy.
> 
> There are a changes that we (Mozilla) are interested in implementing, documenting, and standardizing to improve handshake performance, and to improve the privacy and usability of client cert authentication (especially in Asia), so that more websites will adopt HTTPS. It seems counterproductive to change the charter now in such a way that would require us to debate whether we need to change the charter each time. I would like the charter to clearly indicate that significant changes at least in these areas (handshake performance and client cert authentication) are in scope.
> 
[Joe] Our security AD has requested that we tighten up the charter such that significant changes to the protocol require a charter update.  We can certainly discuss the topics you raise without a charter update.  It may be possible to publish documents for some of the things you want without a charter update.  For other things, in particular things that require significant change to the TLS state machine or other aspects of the protocol we are going to have to go through the process of updating the charter.   This does not have to be a heavyweight process, but it does require more review than just adding a working group milestone.   Since TLS is in widespread use in all areas of the IETF this ensures there is some cross area review before we initiate the work for a major change


> Cheers,
> Brian