From nobody Thu Feb 5 06:09:53 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788871A8848 for ; Thu, 5 Feb 2015 06:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNTMyQ1uQBeO for ; Thu, 5 Feb 2015 06:09:50 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id BCE201A8822 for ; Thu, 5 Feb 2015 06:09:49 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::ce] (unknown [IPv6:2001:67c:10ec:2a49:8000::ce]) by trammell.ch (Postfix) with ESMTPSA id C02681A0051; Thu, 5 Feb 2015 15:09:48 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Brian Trammell In-Reply-To: Date: Thu, 5 Feb 2015 15:09:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <873D58BD-CE84-4AE7-8750-D9BDD2B43FAA@trammell.ch> References: To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1993) Archived-At: Cc: Ted Hardie , "" Subject: Re: [perpass] Review request: draft-iab-privsec-confidentiality-threat-01.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 14:09:52 -0000 hi Bj=F6rn, Thanks for the review! Comments/questions on points inline, points = removed will be edited into the working document without comment. > On 10 Jan 2015, at 02:08, Bjoern Hoehrmann wrote: >=20 > * Ted Hardie wrote: >> The program and authors would appreciate review of >> draft-iab-privsec-confidentiality-threat-01.txt ( >> = http://www.ietf.org/id/draft-iab-privsec-confidentiality-threat-01.txt). >> Note that the text on mitigations to these threats has been split = into a >> second document which is forthcoming. Reviews can be sent to this = list or >> the authors. >=20 > Mostly editorial things on sections 1-3: > In Section 2 I think the example for "Infererence" should be replaced = by > a much simpler one. Do you have a suggestion here? > I am not happy with using "Observation" with the specified meaning in > this context. The word usually refers to the act, not the data, and = here > it may be easy to confuse it with, say, targeted surveillance as part = of > a justice system, perhaps especially for non-native readers. I = encourage > trying to find an alternative term. This terminology is borrowed from the passive network measurement = community, and specifically from the terminology for IPFIX/PSAMP (see = RFC 7011). Unfortunately, in this space we've pretty much used all the = words we could (many multiple times), so I think any change would be = arbitrary. However, I'm open to suggestions for better terms. > The definition for "Unwitting Collaborator" as though an "Unwitting > Collaborator" is a "Collaborator". That seems incorrect to me. How about "An entity that is a legitimate participant in a = communication, and who is the source of information obtained by the = attacker without the entity's consent or intention, because the attacker = has exploited some technology used by the entity"? > I do not think "Key Exfiltration" depends on the presence of a > "collaborator". Same for "Content Exfiltration". Without a collaborator (deliberate or unwitting), how would this be = exfiltration? > I think Section 3 would benefit from a short preface that explains, as > the section title suggest, this is an "idealised" description, and > explains how this is useful. Right now the section jumps right into > describing something that is extremely implausible without qualifiers, > and many readers might be unfamiliar with such descriptions. The idealized attacker model was based on more or less the maximum set = of capabilities you could publicly (i.e. outside the security community) = ascribe to an entity performing pervasive surveillance without being = accused of paranoia, before the spring of 2013. It only seems = implausible *now* because of what we know and can confirm.=20 I think we can make this clearer with a little text and some = reorganization. Thanks again! A new version will follow shortly. Cheers, Biran > --=20 > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 = http://bjoern.hoehrmann.de > D-10243 Berlin =B7 PGP Pub. KeyID: 0xA4357E78 =B7 = http://www.bjoernsworld.de > Available for hire in Berlin (early 2015) =B7 = http://www.websitedev.de/=20 >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From nobody Fri Feb 6 03:28:00 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7701B1A0271 for ; Fri, 6 Feb 2015 03:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wocLzFJrsrAP for ; Fri, 6 Feb 2015 03:27:55 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 85A221A0118 for ; Fri, 6 Feb 2015 03:27:55 -0800 (PST) Received: from [IPv6:2001:470:26:9c2:b8e7:d717:7045:d5c0] (unknown [IPv6:2001:470:26:9c2:b8e7:d717:7045:d5c0]) by trammell.ch (Postfix) with ESMTPSA id 7F6291A0953; Fri, 6 Feb 2015 12:27:54 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0651ADDA-B0D9-4BDE-92F9-E48510249561"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b4 From: Brian Trammell In-Reply-To: Date: Fri, 6 Feb 2015 12:27:54 +0100 Message-Id: <85EBA3F4-3ED2-4817-ADF6-D2379E85844B@trammell.ch> References: To: Aziz Mohaisen X-Mailer: Apple Mail (2.1993) Archived-At: Cc: Ted Hardie , perpass@ietf.org Subject: Re: [perpass] Review request: draft-iab-privsec-confidentiality-threat-01.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 11:27:58 -0000 --Apple-Mail=_0651ADDA-B0D9-4BDE-92F9-E48510249561 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Aziz, Many thanks for your review! Anything I don't reply to from your message = I'll pull directly into the -02 draft. Otherwise, comments on comments = inline below: > On 13 Jan 2015, at 21:47, Aziz Mohaisen wrote: >=20 >=20 > The document provides an interesting view of the threat posed by = pervasive monitoring and tries to formalize a threat model around the = problem. However, the model still lacks rigor, and examples mentioned to = highlight the idealized pervasive passive adversary (as defined in the = document) seem to share some elements of an active attack, suggesting = that this perhaps should be called a =E2=80=9Chybrid adversary=E2=80=9D. = Most of my comments in the feedback below are on this point, and cite = parts of the document where this issue is clear. This feedback also = provides some typos that need be fixed (towards the end of the = feedback). I agree that the main issue raised by this review goes back to a = disagreement about the meaning of "passive" and "active" as used in the = document. "Passive" here is with respect to the network. Passive attacks = do not change the traffic stream or the handling of the traffic stream = in the network, active attacks do. Compromise of an intermediate system = (whatever the layer or method) is, from the point of view of the traffic = stream, passive. In this terminology, an attack only becomes active once = the attacker modifies the traffic stream: MITM attacks, session = hijacking and resetting, route injection, cache poisoning, etc. are all = active. I think an additional definition of "active" and "passive" in the = terminology section as used in the document would clear this up. > I hope these comments/suggestions help. >=20 > Aziz > page 2: > Inference should be specified to be indirect, and not just any = information obtained through analysis (e.g., summary) I'm not sure what you mean here... Inference is indirect, and is = necessarily the output of analysis. Do you have a specific suggestion = here? >=20 > - (Page 2-3) The word passive is somewhat misleading. Capabilities = listed under the passive pervasive attack include elements where a = system is compromised; surely compromising a system is an active act and = not passive. The reason to make this distinction is that it "set[s] a lower bound on = the capabilities of an attacker interested in indiscriminate passive = surveillance while interested in remaining undetectable." Yes, the = activity of compromising the intermediate was probably "active", but = from the point of view of the endpoints, it is unobservable. > The description of the =E2=80=9CIdealized Pervasive Passive = Attacker=E2=80=9D is a bit confusing; on the one hand, it is understood = that the attacker does not actively seek to gain access to users data = =E2=80=94 by the virtue of being passive. No, it actively seeks to gain access to users' data, and doesn't modify = the user's traffic to do so. > On the other hand, at the same time the attacker can observe data in = intermediaries by compromising those intermediaries =E2=80=94 e.g., = stated in the last paragraph on page 3. Even when a vulnerability exists = in such intermediaries, the adversary would have to actively use the = vulnerability =E2=80=94 by compromise, as stated towards the end of page = 3 =E2=80=94 in order to be able to observe contents in the intermediary. = To this end, the definition seems to mix both active and passive = attackers. >=20 > Page 6: > - The last point in section 3.3.2. does not seem to follow the = aforementioned attacker model. [In many jurisdictions, Internet Service = Providers (ISPs) are required to provide identification on a case by = case basis of the "owner" of a specific IP address for law enforcement = purposes] -> this does not seem (to me) to imply a passive monitoring = attack. If you get the cooperation of an ISP, that is no longer a = passive attack. Again, this is passive in the sense that it does not require = modification of the traffic stream, and as such can be done without any = information about the surveillance being observable an the endpoints. > Page 12: > - [These attacks all rely on a collaborator providing the attacker = with some information, either keys or data. These attacks have not = traditionally been considered in security analyses of protocols, since = they happen outside of the protocol.] -> I am not sure if you mean those = attacks aren=E2=80=99t traditionally considered in the IETF community or = the community at large. Yep... I'm aware of this. Here we mean "in the IETF community", or more = specifically "in the Security Considerations sections for most = protocols". We should say so explicitly. Here the threat model commonly = addresses a non-participant entities either on or off the path, as = opposed to with respect to untrusted endpoints. Case in point: there is = no technical protocol mechanism in TLS to keep a TLS endpoint from = sharing session keys with whatever entity it wants. > A secondary point: while the attacks mentioned on page 12 concern a = mechanism, what matters from a security/privacy analysis point of view = is the state of the matter upon the exposure of the keys/data/etc. (or = parts of them), and how that can be used to launch an attack on the = security of a system/protocol or the privacy of a user. This is kind of the point of this section, and to some extent, this = whole document. Pre-Snowden "common knowledge" outside the security area = about how to analyze a protocol didn't consider these things, and now = they must. Again, many thanks, and best regards, Brian --Apple-Mail=_0651ADDA-B0D9-4BDE-92F9-E48510249561 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU1KU6AAoJENt3nsOmbNJc8O0IAIuQFe++xiNR+DRfxzXJYZL/ xercZfmsSAt2XoHdZfBziZR4vYoG2te1mZKvQZmDiOBLuoA8hEloonU7tqkuzAZr 6Za7bdazlBcp3rZYAWXUuCGPH1sGc/cH5/4b+yq/YKfO+CQModT0RpQYAWQRfTg4 F5j5+Rejx6oXU6FQ1M8ILmImSYM0a/Po+b2f88LhxG48nm8AhQpJU3uMqyz9ydoQ P1zsQMubiG93d/BCjzBG5tXRSzwLjc0fZt3W9TvUKWGiR08IadqI1EXBfBhzO7TZ q5HNh2e4YGjU9TOplmL+etpynpOqsOK7p0mb9/AaMBzbPI5QhMMp6knqmCB1n9U= =7ChN -----END PGP SIGNATURE----- --Apple-Mail=_0651ADDA-B0D9-4BDE-92F9-E48510249561-- From nobody Wed Feb 25 00:24:06 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB231A6EE0 for ; Wed, 25 Feb 2015 00:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tc8m5dhDRg5y for ; Wed, 25 Feb 2015 00:24:03 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AFF81A1A80 for ; Wed, 25 Feb 2015 00:24:03 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 1E1412802E0 for ; Wed, 25 Feb 2015 09:24:01 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 1901A28012C for ; Wed, 25 Feb 2015 09:24:01 +0100 (CET) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id 176A7B38038 for ; Wed, 25 Feb 2015 09:23:31 +0100 (CET) Date: Wed, 25 Feb 2015 09:23:31 +0100 From: Stephane Bortzmeyer To: perpass@ietf.org Message-ID: <20150225082331.GA22142@nic.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline X-Operating-System: Debian GNU/Linux 8.0 X-Kernel: Linux 3.16.0-4-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [perpass] [warren@kumari.net: [dns-privacy] Start of WGLC for draft-ietf-dprive-problem-statement - please review.] X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 08:24:05 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This work on DNS privacy started on the perpass mailing list. Now that it is in WGLC, some people here may be interested to review it? Once done, DNS will be one of the very few IETF protocols to have a documented comprehensive (?) privacy analysis. --BXVAT5kNtrzKuDFl Content-Type: message/rfc822 Content-Disposition: inline Return-Path: dns-privacy-bounces@ietf.org Received: from hebe.prod-int.prive.th3.nic.fr [10.1.81.80] by batilda.nic.fr with IMAP (fetchmail-6.3.26) for (single-drop); Mon, 23 Feb 2015 23:37:21 +0100 (CET) Received: from hebe.prod-int.prive.th3.nic.fr (LHLO zimbra.afnic.fr) (10.1.81.80) by zimbra.afnic.fr with LMTP; Mon, 23 Feb 2015 23:36:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.afnic.fr (Postfix) with ESMTP id EFF792D7C06D for ; Mon, 23 Feb 2015 23:36:37 +0100 (CET) X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-0.668] autolearn=unavailable autolearn_force=no Authentication-Results: zimbra.afnic.fr (amavisd-new); dkim=pass (1024-bit key) header.d=ietf.org Received: from zimbra.afnic.fr ([127.0.0.1]) by localhost (zimbra.afnic.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id zp1BdABgo3GL for ; Mon, 23 Feb 2015 23:36:37 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.afnic.fr (Postfix) with ESMTP id 9561B2D7C06F for ; Mon, 23 Feb 2015 23:36:37 +0100 (CET) X-Virus-Scanned: amavisd-new at zimbra.afnic.fr Received: from zimbra.afnic.fr ([127.0.0.1]) by localhost (zimbra.afnic.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 91FWprHdGYjI for ; Mon, 23 Feb 2015 23:36:37 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by zimbra.afnic.fr (Postfix) with ESMTP id 78F002D7C06D for ; Mon, 23 Feb 2015 23:36:37 +0100 (CET) Received: by relay1.nic.fr (Postfix) id 755204C007A; Mon, 23 Feb 2015 23:36:37 +0100 (CET) Delivered-To: bortzmeyer@nic.fr Received: from mx5.nic.fr (mx5.nic.fr [IPv6:2001:67c:2218:2::4:13]) by relay1.nic.fr (Postfix) with ESMTP id 74B534C0053 for ; Mon, 23 Feb 2015 23:36:37 +0100 (CET) Received: from mx5.nic.fr (localhost [127.0.0.1]) by mx5.nic.fr (Postfix) with SMTP id 73641300168 for ; Mon, 23 Feb 2015 23:36:37 +0100 (CET) Received: by mx5.nic.fr (Postfix, from userid 1137) id 58BB93002DE; Mon, 23 Feb 2015 23:36:37 +0100 (CET) Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx5.nic.fr (Postfix) with ESMTPS id 07A2A300168 for ; Mon, 23 Feb 2015 23:36:37 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 575211A0399; Mon, 23 Feb 2015 14:36:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1424730993; bh=bXkgcm9QeoTlmF8j71Ed1qIXdb5KYog5kqxi+svKCf0=; h=MIME-Version:Date:Message-ID:From:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=OrPhcTmSi+dsja9o6xFyOF4DKN6zddjAD2bFt7QZAHWnPIaZ22nK0Q2t6yF+AfiY6 Lj2MVecWyhvO6pUSwvTHuX+UMC8IsfBT0KVW077zEA6Oz4bBJlm5Gh1wLn+npQIDSu FJi4srGMnc3Zid8fUCYbiWoPLE5OfHUwLiAManUQ= X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F335A1A0372 for ; Mon, 23 Feb 2015 14:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7YQ2_0_Eu2q for ; Mon, 23 Feb 2015 14:36:30 -0800 (PST) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AADA1A0018 for ; Mon, 23 Feb 2015 14:36:30 -0800 (PST) Received: by wevm14 with SMTP id m14so21699179wev.8 for ; Mon, 23 Feb 2015 14:36:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=cGaSCHDFAX56qTisG8NKqiVxSKsKlBhkKG9B4CiAdKs=; b=Yg64jqtBd+UTtCaEkQkmkJzgSGetI3ybEl1+wtEpu7KIStldHIyy2duzPI8AaMUwvb supMTcOPQo1FzTEWS7xNqtK/a/yD1vCeNSBEx9SscTwwSB5aT2PKUjG/Y/evcMa/c2xh iuyPTvtLAgcU1w5Nu6kxPCp9VN+O06N7g2amHzo+MbsIAulAGuGWouPoLclSJgmJf+if oMbaZu90LdVuLqO7ivD/CeemZ7phH883hJl/h5Axa1fvkUPkw//YWkKspVcTlAt5dyKv SRkg7RJqkLREP7pJEZge4rXKvLTYW0ODGddPNAmn6i0iUn9w9lhWDThQJKUOHk+Y9Ap+ 3HYw== X-Gm-Message-State: ALoCoQnCAXmHGh0D6VdnWH+/5OSuM4gjExn36WCzBtEHLdjw2OevRNXCUippmrA6JgHsDlR/OIyJ MIME-Version: 1.0 X-Received: by 10.194.63.16 with SMTP id c16mr26983973wjs.117.1424730988743; Mon, 23 Feb 2015 14:36:28 -0800 (PST) Received: by 10.194.158.229 with HTTP; Mon, 23 Feb 2015 14:36:28 -0800 (PST) Date: Mon, 23 Feb 2015 17:36:28 -0500 Message-ID: Old-From: Warren Kumari To: draft-ietf-dprive-problem-statement@tools.ietf.org, DPRIVE-chairs@tools.ietf.org, "dns-privacy@ietf.org" Archived-At: Old-Subject: [dns-privacy] Start of WGLC for draft-ietf-dprive-problem-statement - please review. X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dns-privacy-bounces@ietf.org Sender: "dns-privacy" X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.23.222720 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1600_1699 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, DKIM_SIGNATURE 0, WEBMAIL_SOURCE 0, __ANY_URI 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_LIST_HEADER 0, __HAS_LIST_HELP 0, __HAS_LIST_SUBSCRIBE 0, __HAS_LIST_UNSUBSCRIBE 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_HTTP_RECEIVED 0, __PHISH_SPEAR_STRUCTURE_1 0, __PHISH_SPEAR_STRUCTURE_2 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NS , __YOUTUBE_RCVD 0' X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Subject: [dns-privacy] Start of WGLC for draft-ietf-dprive-problem-statement - please review. From: Warren Kumari Dear DPRIVE WG, The authors of draft-ietf-dprive-problem-statement have indicated that they believe that the document is ready, and have asked for Working Group Last Call. The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dprive-problem-statement/ This document was discussed at the DPRIVE meeting at IETF91 - some notes here: http://tools.ietf.org/wg/dprive/minutes?item=minutes-91-dprive.html The document has also been worked on in GitHub, here: https://github.com/bortzmeyer/my-IETF-work It has also received a fair bit of on-list discussion. Please review this draft to see if you think it is ready for publication and send comments to the list, clearly stating your view. Even if you previously expressed support for the document (e.g during adoption), please respond to the WGLC showing that you still support it. This WGLC ends Mon 09-Mar-2015. In addition, to satisfy RFC 6702 ("Promoting Compliance with Intellectual Property Rights (IPR)"): Are you personally aware of any IPR that applies to draft-ietf-dprive-problem-statement? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) Thanks, Warren Kumari (as DPRIVE WG co-chair) -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy --BXVAT5kNtrzKuDFl--