From Jeff.Hodges@KingsMountain.com Mon Dec 3 10:55:46 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B95F21F885A for ; Mon, 3 Dec 2012 10:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 t0-twZUu6-NN for ; Mon, 3 Dec 2012 10:55:46 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id EEDBC21F884B for ; Mon, 3 Dec 2012 10:55:45 -0800 (PST) Received: (qmail 8440 invoked by uid 0); 3 Dec 2012 18:51:57 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 3 Dec 2012 18:51:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=Roe2bq6Ze8LOh0AueaAn+kaWaz9rxBGgdZzwdLEApg0=; b=cf1hMrx50lHqI3VvGFnx9d3QeGKHLfG+J9UztqbkRRGEVBTvIMA+2XJ7/hA70pYuB3Fl3MkTmqgFMC7qI+0z8/cQ1g1psaT5Z0V00vG0wHcq2+PN2cHRwqckGF9uU5QZ; Received: from [216.113.168.128] (port=37923 helo=[10.244.137.210]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Tfb7V-0007tL-AQ for wpkops@ietf.org; Mon, 03 Dec 2012 11:51:57 -0700 Message-ID: <50BCF4CB.5070800@KingsMountain.com> Date: Mon, 03 Dec 2012 10:51:55 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: wpkops@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [wpkops] Draft charter last call X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:55:46 -0000 I agree with Sean's comments. regarding PaulH's comments.. > references are normally not used in IETF WG charters agreed overall with the point above in that there /are/ a few charters that have included such. > The references here could easily be removed I don't think the given references hinder the charter and it's useful to have them at least clearly noted. > Capturing state changes that are visible to the user doesn't seem to be part > of "trust model", "certificate, CRL, and OCSP field and extension > processing", "certificate revocation", or "TLS stack operation". > > Possibly the last document could be expanded to "TLS stack operation and > interaction with the browser". Alternately, a document about visible state > changes in web browsers could be added to the list of documents. A third > option is to drop the paragraph if the group believes that adding this would > be to difficult to do cleanly. I don't think we should drop it, we discussed this at fair length during the BoF.. > The discussion went to whether or not aspects of UI should be considered > in-scope. It was decided that functional aspects of user interaction should > be in-scope. But aspects of style (such as colours and symbols) should not. My supposition is that the "functional aspects of user interaction" will most likely be captured in the "TLS stack operation" document. Altering the purported document topic as suggested above is fine by me. HTH, =JeffH From paul.hoffman@vpnc.org Mon Dec 3 10:58:19 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7826B21F8862 for ; Mon, 3 Dec 2012 10:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 f+kmHFjNivpV for ; Mon, 3 Dec 2012 10:58:19 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0049721F885B for ; Mon, 3 Dec 2012 10:58:18 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qB3IwGcG099165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 11:58:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <50BCF4CB.5070800@KingsMountain.com> Date: Mon, 3 Dec 2012 10:58:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <45545F01-5FEA-4C8D-9096-55397AF55891@vpnc.org> References: <50BCF4CB.5070800@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1499) Cc: wpkops@ietf.org Subject: Re: [wpkops] Draft charter last call X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:58:19 -0000 On Dec 3, 2012, at 10:51 AM, =3DJeffH = wrote: > I agree with Sean's comments. >=20 > regarding PaulH's comments.. >=20 > > references are normally not used in IETF WG charters >=20 > agreed overall with the point above in that there /are/ a few charters = that have > included such. Indeed, there are now. So, ignore my request to remove them; they're = fine. --Paul Hoffman From tim.moses@entrust.com Mon Dec 3 13:11:52 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA7421F86A2 for ; Mon, 3 Dec 2012 13:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 wUcc1bHJVUkU for ; Mon, 3 Dec 2012 13:11:51 -0800 (PST) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFB821F85D7 for ; Mon, 3 Dec 2012 13:11:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,209,1355115600"; d="scan'208";a="2580558" Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge2.entrust.com with ESMTP; 03 Dec 2012 16:11:50 -0500 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.004; Mon, 3 Dec 2012 16:11:50 -0500 From: Tim Moses To: '=JeffH' , "wpkops@ietf.org" Thread-Topic: [wpkops] Draft charter last call Thread-Index: AQHN0YfRMYtL2dRTB0ytqlElpdIXLJgHhHIQ Date: Mon, 3 Dec 2012 21:11:49 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A66E3D7@SOTTEXCH10.corp.ad.entrust.com> References: <50BCF4CB.5070800@KingsMountain.com> In-Reply-To: <50BCF4CB.5070800@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [wpkops] Draft charter last call X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 21:11:52 -0000 Guys - I was also thinking that "field and extension processing" causes sta= te changes that are communicated to the user. So, rather than introduce an= additional document to cover this requirement, I prefer to make sure it is= adequately covered in the proposed existing set of documents. I'll update the charter for final assent. All the best. Tim. -----Original Message----- From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of= =3DJeffH Sent: Monday, December 03, 2012 1:52 PM To: wpkops@ietf.org Subject: Re: [wpkops] Draft charter last call I agree with Sean's comments. regarding PaulH's comments.. > references are normally not used in IETF WG charters agreed overall with the point above in that there /are/ a few charters that= have included such. > The references here could easily be removed I don't think the given references hinder the charter and it's useful to ha= ve them at least clearly noted. > Capturing state changes that are visible to the user doesn't seem to be = part > of "trust model", "certificate, CRL, and OCSP field and extension = > processing", "certificate revocation", or "TLS stack operation". > > Possibly the last document could be expanded to "TLS stack operation and= > interaction with the browser". Alternately, a document about visible st= ate > changes in web browsers could be added to the list of documents. A t= hird > option is to drop the paragraph if the group believes that adding t= his would > be to difficult to do cleanly. I don't think we should drop it, we discussed this at fair length during th= e BoF.. > The discussion went to whether or not aspects of UI should be considered= > in-scope. It was decided that functional aspects of user interaction s= hould > be in-scope. But aspects of style (such as colours and symbols) s= hould not. My supposition is that the "functional aspects of user interaction" will mo= st likely be captured in the "TLS stack operation" document. Altering the = purported document topic as suggested above is fine by me. HTH, =3DJeffH _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops From paul.hoffman@vpnc.org Mon Dec 3 13:56:40 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1E821F8715 for ; Mon, 3 Dec 2012 13:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 UJ2LNK9RY15Y for ; Mon, 3 Dec 2012 13:56:40 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC4A21F8574 for ; Mon, 3 Dec 2012 13:56:39 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qB3LuaPY005897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 14:56:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A66E3D7@SOTTEXCH10.corp.ad.entrust.com> Date: Mon, 3 Dec 2012 13:56:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8ACDDEF4-0929-4D96-9DDB-544F62F0279C@vpnc.org> References: <50BCF4CB.5070800@KingsMountain.com> <5B68A271B9C97046963CB6A5B8D6F62C3A66E3D7@SOTTEXCH10.corp.ad.entrust.com> To: Tim Moses X-Mailer: Apple Mail (2.1499) Cc: "wpkops@ietf.org" , '=JeffH' Subject: Re: [wpkops] Draft charter last call X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 21:56:41 -0000 On Dec 3, 2012, at 1:11 PM, Tim Moses wrote: > Guys - I was also thinking that "field and extension processing" = causes state changes that are communicated to the user. So, rather than = introduce an additional document to cover this requirement, I prefer to = make sure it is adequately covered in the proposed existing set of = documents. Please note that the document that you thought covered "Capturing state = changes that are visible to the user" is different than the one Jeff = did. For example, I don't see how the state change of "starting TLS" to = "TLS failed due to an expired certificate" has anything to do with = "certificate, CRL, and OCSP field and extension processing". Jeff = suggested that these visible state changes be in "TLS stack operation", = which seems a heck of a lot more appropriate. --Paul Hoffman= From tim.moses@entrust.com Fri Dec 14 13:11:33 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6229521F8AD8 for ; Fri, 14 Dec 2012 13:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 F0tYhTIEUW-o for ; Fri, 14 Dec 2012 13:11:32 -0800 (PST) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id 75DB821F8AC6 for ; Fri, 14 Dec 2012 13:11:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,284,1355115600"; d="scan'208";a="7196722" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge1.entrust.com with ESMTP; 14 Dec 2012 16:11:31 -0500 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.004; Fri, 14 Dec 2012 16:11:30 -0500 From: Tim Moses To: "wpkops@ietf.org" Thread-Topic: TLS stack anomalies in scope? Thread-Index: Ac3aP5X0msMENtjGT/u0WILONrEZaw== Date: Fri, 14 Dec 2012 21:11:29 +0000 Message-ID: <6D990251-C71A-477E-B696-DF811B17506F@bwdldb.pp.bnr.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <8085EA7BAACD964092CFFF6321CFD047@entrust.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [wpkops] TLS stack anomalies in scope? X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 21:11:33 -0000 Colleagues. There is a question over whether the results of Adam Langley's= work on anomalous bahaviour in common TLS stack implementations is in or o= ut of scope for the WPKOPS activity, and whether the draft charter properly= reflects the answer to that question. There have been no objections that = I am aware of to including the work. It merely remains to ensure that the = charter makes it clear. I propose adding the following statement to the list of example problems: "Finally, varying interpretations of the protocol specifications and implem= entation errors result in interoperability failures and introduce security = vulnerabilities in the TLS stack." Do people think this is sufficient, or is a more radical rewrite called for= in which the emphasis is on TLS and its supporting infrastructure? All the best. Tim.= From hallam@gmail.com Fri Dec 14 13:21:41 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9A021F8A7D for ; Fri, 14 Dec 2012 13:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.668 X-Spam-Level: X-Spam-Status: No, score=-3.668 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 mgfhG+SbpB2o for ; Fri, 14 Dec 2012 13:21:37 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EAD6A21F8A21 for ; Fri, 14 Dec 2012 13:21:36 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so3836185obc.31 for ; Fri, 14 Dec 2012 13:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qZpkU6efsTHj16ix5N6oZoxc9eUWZC2B1l13CAZ0iJM=; b=KP5nGfrRkiWxHqWNhLo2vMibK4zoW7CPOdadIVUWPinz4P96AhTgLt3GTMJNlqURfy BdkXPjiIVQG8WIDQBAh3P1SOhz/L9DYSjPTsxV/niuxdtZ8X0rQHdXgNzcPvYz8uTNGQ wJEoOrfwbKgytzyKTWC8l9t0xoEZlZqDPA9//7yco5NfR8JLhMibS+met6mvt3rAgHrG A8RlkpCODhV13jtlRxsl01vohH2Gyz1vmXGHN6hJ1KHiMw8UIIFHwEzuIdo2sj4YL7t3 +GgwqF8UURwsQxaEa/BQxBYXdnpdMnMKI8eQXKoJBK9HBuU+qYZPIGZg7UW7NyNs4DBt qsfg== MIME-Version: 1.0 Received: by 10.60.8.199 with SMTP id t7mr5637651oea.26.1355520095680; Fri, 14 Dec 2012 13:21:35 -0800 (PST) Received: by 10.76.19.43 with HTTP; Fri, 14 Dec 2012 13:21:35 -0800 (PST) In-Reply-To: <6D990251-C71A-477E-B696-DF811B17506F@bwdldb.pp.bnr.ca> References: <6D990251-C71A-477E-B696-DF811B17506F@bwdldb.pp.bnr.ca> Date: Fri, 14 Dec 2012 16:21:35 -0500 Message-ID: From: Phillip Hallam-Baker To: Tim Moses Content-Type: multipart/alternative; boundary=e89a8ff1ce46c9f91b04d0d69de9 Cc: "wpkops@ietf.org" Subject: Re: [wpkops] TLS stack anomalies in scope? X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 21:21:41 -0000 --e89a8ff1ce46c9f91b04d0d69de9 Content-Type: text/plain; charset=ISO-8859-1 I don't see a problem with it. Understanding the muck at the bottom of that swamp is one of the principal concerns. On Fri, Dec 14, 2012 at 4:11 PM, Tim Moses wrote: > Colleagues. There is a question over whether the results of Adam > Langley's work on anomalous bahaviour in common TLS stack implementations > is in or out of scope for the WPKOPS activity, and whether the draft > charter properly reflects the answer to that question. There have been no > objections that I am aware of to including the work. It merely remains to > ensure that the charter makes it clear. > > I propose adding the following statement to the list of example problems: > > "Finally, varying interpretations of the protocol specifications and > implementation errors result in interoperability failures and introduce > security vulnerabilities in the TLS stack." > > Do people think this is sufficient, or is a more radical rewrite called > for in which the emphasis is on TLS and its supporting infrastructure? > > All the best. Tim. > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > -- Website: http://hallambaker.com/ --e89a8ff1ce46c9f91b04d0d69de9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't see a problem with it. Understanding the muck at the bottom of = that swamp is one of the principal concerns.

On Fri, Dec 14, 2012 at 4:11 PM, Tim Moses <tim.moses@entrust.com<= /a>> wrote:
Colleagues. =A0There is a question over whet= her the results of Adam Langley's work on anomalous bahaviour in common= TLS stack implementations is in or out of scope for the WPKOPS activity, a= nd whether the draft charter properly reflects the answer to that question.= =A0There have been no objections that I am aware of to including the work.= =A0It merely remains to ensure that the charter makes it clear.

I propose adding the following statement to the list of example problems:
"Finally, varying interpretations of the protocol specifications and i= mplementation errors result in interoperability failures and introduce secu= rity vulnerabilities in the TLS stack."

Do people think this is sufficient, or is a more radical rewrite called for= in which the emphasis is on TLS and its supporting infrastructure?

All the best. =A0Tim.
_______________________________________________
wpkops mailing list
wpkops@ietf.org
= https://www.ietf.org/mailman/listinfo/wpkops



--
Website: http://hallambaker.com/

--e89a8ff1ce46c9f91b04d0d69de9-- From paul.hoffman@vpnc.org Fri Dec 14 16:34:06 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF99F21F8B59 for ; Fri, 14 Dec 2012 16:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 cM6l-8coWx3y for ; Fri, 14 Dec 2012 16:34:06 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5B921F8B2B for ; Fri, 14 Dec 2012 16:34:06 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qBF0Y1AF003021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Dec 2012 17:34:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <6D990251-C71A-477E-B696-DF811B17506F@bwdldb.pp.bnr.ca> Date: Fri, 14 Dec 2012 16:34:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <71B6AF70-B2CD-4D61-93D1-CF975712BC77@vpnc.org> References: <6D990251-C71A-477E-B696-DF811B17506F@bwdldb.pp.bnr.ca> To: Tim Moses X-Mailer: Apple Mail (2.1499) Cc: "wpkops@ietf.org" Subject: Re: [wpkops] TLS stack anomalies in scope? X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 00:34:07 -0000 On Dec 14, 2012, at 1:11 PM, Tim Moses wrote: > Colleagues. There is a question over whether the results of Adam = Langley's work on anomalous bahaviour in common TLS stack = implementations is in or out of scope for the WPKOPS activity, and = whether the draft charter properly reflects the answer to that question. = There have been no objections that I am aware of to including the work. = It merely remains to ensure that the charter makes it clear. >=20 > I propose adding the following statement to the list of example = problems: >=20 > "Finally, varying interpretations of the protocol specifications and = implementation errors result in interoperability failures and introduce = security vulnerabilities in the TLS stack." >=20 > Do people think this is sufficient, or is a more radical rewrite = called for in which the emphasis is on TLS and its supporting = infrastructure? Neither. The rest of the WPKOPS charter is, in fact, about the "PK" part = of the acronym. That's good. If you want to have a document on how the = TLS stack today deals with PKI, then just say "This document will cover = how the TLS stack today deals with PKI, including varying = interpretations and implementation errors". This is also a good way to deal with the "visible state changes" that = the WG wanted to deal with. That would then change the sentence to "This = document will cover how the TLS stack today deals with PKI, including = varying interpretations and implementation errors, as well as state = changes visible to the user". --Paul Hoffman= From tim.moses@entrust.com Tue Dec 18 09:38:09 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3538521F86F5 for ; Tue, 18 Dec 2012 09:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 BeOjaDgj0fiN for ; Tue, 18 Dec 2012 09:38:04 -0800 (PST) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8D121F86C1 for ; Tue, 18 Dec 2012 09:38:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,309,1355115600"; d="scan'208,217";a="7235497" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge1.entrust.com with ESMTP; 18 Dec 2012 12:38:03 -0500 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.004; Tue, 18 Dec 2012 12:38:03 -0500 From: Tim Moses To: "wpkops@ietf.org" Thread-Topic: WPKOPS draft charter v07 Thread-Index: Ac3dRm5qCTLOk+kDRIOgiQp79PvFIQ== Date: Tue, 18 Dec 2012 17:38:02 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A67F917@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.88] Content-Type: multipart/alternative; boundary="_000_5B68A271B9C97046963CB6A5B8D6F62C3A67F917SOTTEXCH10corpa_" MIME-Version: 1.0 Subject: [wpkops] WPKOPS draft charter v07 X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 17:38:09 -0000 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A67F917SOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have incorporated Paul's proposal ... The Web PKI is the set of systems, policies and procedures most commonly us= ed, in conjunction with security protocols (e.g. TLS/SSL and OCSP), to prot= ect the confidentiality, integrity and authenticity of communications betwe= en Web browsers and Web content servers. More specifically, the Web PKI (as= considered here) consists of the fields included in the certificates issue= d to Web content and application providers by Certification Authorities (CA= s), the certificate status services provided by the Authorities to Web brow= sers and their users, and the TLS/SSL protocol stacks embedded in web serve= rs and browsers. The Web PKI first appeared in 1993 or thereabouts and has developed continu= ously in a somewhat organic fashion since then. Taking into account all th= e versions of Web servers and browsers that have been released in the inter= vening years, there are now hundreds of variations on the Web PKI in regula= r use. And this is a source of problems for end-users, certificate holders= , and certificate issuers (CAs). For end-users (i.e. relying parties), there is no clear view whether certif= icate "problems" remain when they see indication of a "good" connection. F= or instance, in some browsers, a "good" indication is displayed when a "rev= oked" response has been received and "accepted" by the user, whereas other = browsers refuse to display the contents under these circumstances. Many certificate holders are unsure which browser versions will reject thei= r certificate if certain certificate profiles are not met, such as a subjec= t public key that does not satisfy a minimum key size, or a certificate pol= icies extension that does not contain a particular standard policy identifi= er. And for certificate issuers, it is difficult to predict whether a certifica= te chain with certain characteristics will be accepted. For instance, some= browsers include a nonce in their OCSP requests and expect one in the corr= esponding responses, not all servers include a nonce in their replies, and = this means some certificate chains will validate while others won't. Starting from the premise that more consistency in Web security behavior is= desirable, a natural first step is to document current and historic browse= r and server behavior, including: the trust model on which they are based; = the contents and processing of fields and extensions; the processing of the= various revocation schemes; and how the TLS stack deals with PKI, includin= g varying interpretations and implementation errors, as well as state chang= es visible to the user. Where appropriate, specific products and specific = versions of those products will be identified. The effectiveness of the Web PKI depends critically upon decisions made by = its users in response to information provided in the user interfaces of its= various components. Therefore, such information should be accurate and co= mplete, yet comprehensible. While recording the design details of the user= interfaces of specific products is not necessary, state changes that are v= isible to, and/or controlled by, the user should be captured. Such a project has to be bounded. Therefore, only server-authentication be= havior encountered in more than 0.1 percent of connections made by desktop = and mobile browsers is to be considered. While it is not intended to apply= the threshold with any precision, it will be used to justify the inclusion= or exclusion of a technique. Future activities may attempt to prescribe how the Web PKI "should" work, a= nd the prescription may turn out to be a proper subset of the PKIX PKI. Ho= wever, that task is explicitly not a goal of the proposed working group. I= nstead, the group's goal is merely to describe how the Web PKI "actually" w= orks in the set of browsers and servers that are in common use today. Additionally, a number of applications (such as client authentication, docu= ment signing, code signing, and email) often use the same trust anchors and= certificate processing mechanisms as those used for Web server authenticat= ion. This reuse creates problems in some situations [1]. While these appl= ications are outside the scope of this working group, deliverables should (= wherever practical within the available expertise and time) identify mechan= isms that are reused by other applications and identify the implications of= that reuse. Also, the reliability of the Web PKI depends critically on the "practices" = of its certificate issuers. These practices comprise how certificate issue= rs perform their functions and implement controls, and are described in doc= uments known as "Certification Practice Statements" [2][3] and operational = requirements documents [4][5]. However, the topic of certification practic= es is outside the scope of the working group. That there are technical shortcomings with Web PKI, as it is practiced toda= y, is well recognized. And, that there is also some urgency in addressing = these shortcomings is also well recognized. But, it is felt that too much = haste can be counter-productive. The expectation is that the work of this = group will bring to light, in a systematic way, aspects of the Web PKI that= should be progressed in future working groups of the IETF's Security Area,= and that Web servers, browsers and CAs will be willing to participate in t= hose working groups and modify their products to comply with their standard= s. Given the urgency of the required developments and the scale of the task, i= t is agreed that adherence to the published schedule should take precedence= over completeness of the results, without sacrificing technical correctnes= s. Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. First WG draft of "trust model" document (4 months). 2. First WG draft of "field and extension processing for certificates, C= RLs, and OCSP responses" document (12 months). 3. First WG draft of "certificate revocation" document (8 months). 4. First WG draft of "TLS stack operation" document (8 months). 5. IESG submission of "trust model" document (16 months). 6. IESG submission of "field and extension processing for certificates, = CRLs, and OCSP responses" document (24 months). 7. IESG submission of "certificate revocation" document (20 months). 8. IESG submission of "TLS stack operation" document (16 months). References: [1] https://www.ietf.org/mail-archive/web/wpkops/current/msg00104.html [2] Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. S. Chokhani et al, IETF RFC3647 https://tools.ietf.org/html/rfc3647 [3] Electronic Signatures and Infrastructures (ESI); Policy requirements fo= r certification authorities issuing public key certificates. ETSI TS 102 042 V2.2.1 (2011-12) http://www.etsi.org/deliver/etsi_ts/102000_102099/102042 /02.02.01_60/ts_102042v020201p.pdf [4] Network and certificate system security requirements, CA/Browser Forum, Aug 2012, https://www.cabforum.org/Network_Security_Controls_V1.pdf [5] Baseline Requirements for the Issuance and Management of Publicly-Trust= ed Certificates Version 1.0, CA/Browser Forum, Nov 2011, https://www.cabforum.org/Baseline_Requirements_V1.pdf T: +1 613 270 3183 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A67F917SOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have incorporated Paul’s proposal …

 

The Web PKI is the set of systems, policies and proc= edures most commonly used, in conjunction with security protocols (e.g. TLS= /SSL and OCSP), to protect the confidentiality, integrity and authenticity = of communications between Web browsers and Web content servers. More specifically, the Web PKI (as considered her= e) consists of the fields included in the certificates issued to Web conten= t and application providers by Certification Authorities (CAs), the certifi= cate status services provided by the Authorities to Web browsers and their users, and the TLS/SSL protocol = stacks embedded in web servers and browsers.

 

The Web PKI first appeared in 1993 or thereabouts an= d has developed continuously in a somewhat organic fashion since then. = ; Taking into account all the versions of Web servers and browsers that hav= e been released in the intervening years, there are now hundreds of variations on the Web PKI in regular use.  = And this is a source of problems for end-users, certificate holders, and ce= rtificate issuers (CAs).

 

For end-users (i.e. relying parties), there is no cl= ear view whether certificate "problems" remain when they see indi= cation of a "good" connection.  For instance, in some browse= rs, a "good" indication is displayed when a "revoked" r= esponse has been received and "accepted" by the user, whereas other brow= sers refuse to display the contents under these circumstances.

 

Many certificate holders are unsure which browser ve= rsions will reject their certificate if certain certificate profiles are no= t met, such as a subject public key that does not satisfy a minimum key siz= e, or a certificate policies extension that does not contain a particular standard policy identifier.<= /p>

 

And for certificate issuers, it is difficult to pred= ict whether a certificate chain with certain characteristics will be accept= ed.  For instance, some browsers include a nonce in their OCSP request= s and expect one in the corresponding responses, not all servers include a nonce in their replies, and this means some cert= ificate chains will validate while others won't.

 

Starting from the premise that more consistency in W= eb security behavior is desirable, a natural first step is to document curr= ent and historic browser and server behavior, including: the trust model on= which they are based; the contents and processing of fields and extensions; the processing of the various rev= ocation schemes; and how the TLS stack deals with PKI, including varying in= terpretations and implementation errors, as well as state changes visible t= o the user.  Where appropriate, specific products and specific versions of those products will be identifi= ed.

 

The effectiveness of the Web PKI depends critically = upon decisions made by its users in response to information provided in the= user interfaces of its various components.  Therefore, such informati= on should be accurate and complete, yet comprehensible.  While recording the design details of the user inter= faces of specific products is not necessary, state changes that are visible= to, and/or controlled by, the user should be captured.

 

Such a project has to be bounded.  Therefore, o= nly server-authentication behavior encountered in more than 0.1 percent of = connections made by desktop and mobile browsers is to be considered.  = While it is not intended to apply the threshold with any precision, it will be used to justify the inclusion or exclusion = of a technique.

 

Future activities may attempt to prescribe how the W= eb PKI "should" work, and the prescription may turn out to be a p= roper subset of the PKIX PKI.  However, that task is explicitly not a = goal of the proposed working group.  Instead, the group's goal is merely to describe how the Web PKI "actually" wo= rks in the set of browsers and servers that are in common use today.

 

Additionally, a number of applications (such as clie= nt authentication, document signing, code signing, and email) often use the= same trust anchors and certificate processing mechanisms as those used for= Web server authentication.  This reuse creates problems in some situations [1].  While these applicati= ons are outside the scope of this working group, deliverables should (where= ver practical within the available expertise and time) identify mechanisms = that are reused by other applications and identify the implications of that reuse.

 

Also, the reliability of the Web PKI depends critica= lly on the "practices" of its certificate issuers.  These pr= actices comprise how certificate issuers perform their functions and implem= ent controls, and are described in documents known as "Certification Practice Statements" [2][3] and operational re= quirements documents [4][5].  However, the topic of certification prac= tices is outside the scope of the working group.

 

That there are technical shortcomings with Web PKI, = as it is practiced today, is well recognized.  And, that there is also= some urgency in addressing these shortcomings is also well recognized.&nbs= p; But, it is felt that too much haste can be counter-productive.  The expectation is that the work of this group w= ill bring to light, in a systematic way, aspects of the Web PKI that should= be progressed in future working groups of the IETF's Security Area, and th= at Web servers, browsers and CAs will be willing to participate in those working groups and modify their product= s to comply with their standards.

 

Given the urgency of the required developments and t= he scale of the task, it is agreed that adherence to the published schedule= should take precedence over completeness of the results, without sacrifici= ng technical correctness.

 

Milestones

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

1.    First WG draft of "trust m= odel" document (4 months).

2.    First WG draft of "field a= nd extension processing for certificates, CRLs, and OCSP responses" do= cument (12 months).

3.    First WG draft of "certifi= cate revocation" document (8 months).

4.    First WG draft of "TLS sta= ck operation" document (8 months).

5.    IESG submission of "trust = model" document (16 months).

6.    IESG submission of "field = and extension processing for certificates, CRLs, and OCSP responses" d= ocument (24 months).

7.    IESG submission of "certif= icate revocation" document (20 months).

8.    IESG submission of "TLS st= ack operation" document (16 months).

 

 

References:

 

[1] https://www.ietf.org/mail-archive/web/wpkops/cur= rent/msg00104.html

 

[2] Internet X.509 Public Key Infrastructure Certifi= cate Policy and

      Certification Practic= es Framework. S. Chokhani et al, IETF RFC3647

      https://tools.ietf.or= g/html/rfc3647

 

[3] Electronic Signatures and Infrastructures (ESI);= Policy requirements for

      certification authori= ties issuing public key certificates.

      ETSI TS 102 042 V2.2.= 1 (2011-12)

      http://www.etsi.org/d= eliver/etsi_ts/102000_102099/102042

      /02.02.01_60/ts_10204= 2v020201p.pdf

 

[4] Network and certificate system security requirem= ents, CA/Browser Forum,

      Aug 2012, https://www= .cabforum.org/Network_Security_Controls_V1.pdf

 

[5] Baseline Requirements for the Issuance and Manag= ement of Publicly-Trusted

      Certificates Version = 1.0, CA/Browser Forum, Nov 2011,

      https://www.cabforum.= org/Baseline_Requirements_V1.pdf

 

 

T: +1 613 270 3183

 

--_000_5B68A271B9C97046963CB6A5B8D6F62C3A67F917SOTTEXCH10corpa_--