From nobody Wed Mar 8 12:18:13 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A66129490 for ; Wed, 8 Mar 2017 12:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 i6Fd63ZL40jn for ; Wed, 8 Mar 2017 12:18:11 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 D922712940F for ; Wed, 8 Mar 2017 12:18:10 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id b129so17037659pgc.2 for ; Wed, 08 Mar 2017 12:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=IW616r/MatpSqFb4Z352BSriYwDYCrDDv8Jdvq5B2WY=; b=U1G3hClt+6Q93uSNGs6pAA/6p4ykyigfNJHUiA96dDWBfDBi4uQJe5dfNTCIWYDqEw cXt7GSpCOg5EKhPt0kv3fNuSb9LUPX+MpcFOV6xtyjGDqnVRlvHe48axdlc9/2/FExJJ BAJcoP4uf6Vy0cX1j5UJfsm8XWGIxFl3Lsl1fIE4B2sDi6018/aVlfLGBVxJ8CTgmxUn tUP28aaOo550ygXCGdcBpl5PyYgcGq2WdobVe8jLgSXPHcLlkBPO08Zq3wH4Z6DYgWI9 I4666TWSmaqRU2ywtwjZZpKDdXosQqsruRknYhs4qnIiNQ9+m0UadgipFD/YuCCIGTHN HQ3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=IW616r/MatpSqFb4Z352BSriYwDYCrDDv8Jdvq5B2WY=; b=gWLAr4JqSvsua8+SWcCWKZAVFnGONskVJZW1YvwFnvVOJh5kOoDKydt3I7r3Xx/R+x FbZ0M8gBOP/ysI0WJw1LkZV8MCd7XdcAtMQGgcoBPoNWrqCNIdC7BElnx6bzfqZdgwYc qmo4jVIgZaIZVOP2/kcS+3tgMQjqhTfF0DWp6OfzLsDbW4q1FbLzKbOatJ8Z3YXW3PH5 ekAuiP18vSWQv8HKiPuw6hO7BKK9RfQQHEe1G4Uy6nJn+WHU8XlLMRyxhzhR8tNukVEk v22S1txjIJv4+BjijbrTI9mLWyQ/mDmKVc2Up1EiO9dFKdT8lQ7OkCBH9hlL7JOURCtG 7tBQ== X-Gm-Message-State: AMke39lvZAs7x+fAq8T0Amcp/vaiD9xENc39WuIJAt8QB2MJCZA/v64MwJkMpE2NevIgt+onVprLuH+2M9MpBg== X-Received: by 10.98.54.196 with SMTP id d187mr9420183pfa.33.1489004290299; Wed, 08 Mar 2017 12:18:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.177.199 with HTTP; Wed, 8 Mar 2017 12:18:09 -0800 (PST) From: Kathleen Moriarty Date: Wed, 8 Mar 2017 15:18:09 -0500 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Badri.Subramanyan@ril.com" , "ALFRED C MORTON \(AL\)" Subject: [saag] Last call feedback: draft-mm-wg-effect-encrypt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 20:18:12 -0000 Hello Badri, Thank you very much for your review and feedback on the draft. This is very helpful to add in your perspective. I do have a few questions in line and am hoping you have some good references for us to cite as well. We need to get a draft revision out by Friday, so hopefully we can iterate quickly. > > On Feb 23, 2017, at 9:54 AM, "Badri.Subramanyan@ril.com" > wrote: > > Hello, > > > > I work for a Mobile Service Provider and wanted to start = by > thanking you for putting this document together (Effects of Pervasive > Encryption). Encryption of content has been impacting the service provide= rs > for sometime, and this document outlines it very well. I had a few > comments/suggestions on the document. This documents is comprehensive, bu= t > there are a few impacts more specific to Mobile Carriers which I thought > were not included. I would greatly appreciate it, if you could look into > these and modify the document as suited. > > > > 1. ALG =E2=80=93 Application Layer Gateway, is a feature used by Fi= rewalls, > NAT boxes and Load Balancers to identify streams which are related and tr= eat > them alike. Many of the protocols work in conjunction to deliver a servic= e. > Eg. RTSP/RTCP/RTP protocols are used to provide video service. RTSP uses = TCP > and negotiates the UDP ports used for RTP and RTCP communication. RTSP an= d > RTCP form the control plane, when RTP forms the data plane. > > a. The ALG feature makes the Firewall application-aware and allow o= r > block a video content as desired. > > b. This feature is also used as of today on the Firewall or NAT box. > The scenario here is, the FW/NAT box acts as a demarcation point between = the > DMZ and untrusted network, which allows out bound traffic and any flow > initiated from within the DMZ. When we have service with multiple flows, > some of these could be initiated from within the DMZ, which should enable > other flows in both directions. Eg. RTSP Request from within the DMZ woul= d > need to allow RTP packets from the untrusted zone into the DMZ. The FW/NA= T > box can only allow this if they are aware of the co-relation between the > different flows using feature like ALG. > > c. The ALG feature on a LB similarly would allow the identification= of > the different co-related flows and treat them alike =E2=80=93 allow, bloc= k, LB them > to the same server or re-route to another set of servers. > > If the streams are encrypted, then the ALG feature would be rendered > useless. This would limit the capability of any network element to make > smart policing and routing decisions based on application layer attribute= s. Do you know if these can work with a 2-tuple or 5-tuple? Is there an impact from encryption via TLS for instance? If so, what is that impact? What is used by ALG to correlate streams? This would be helpful to understand if this particular method for ALGs does become 'useless' and also to figure out if other options may exist to perform the functions needed. Do you have references on this that are stable (ones we can cite in an RFC)= ? > > 2. Over-The-Top Caching web content =E2=80=93 You did touch upon th= is topic in > section 2.1.4, but I think this is a big enough topic that it warrants it= s > own subsection. As the Internet traffic increases across the world, Mobil= e > Carriers and other Service Providers are using caching solution to keep u= p > with the bandwidth needs. Caching at a high level would allow for web/vid= eo > and other caches to be located closer to the customers. The first time a > content is requested, it is stored in the cache and every request going > forward would be served from the cache thus cutting down on the backhaul > tonnage between the source of the content and the cache. This not only he= lps > in cutting down on the bandwidth requirements, but also cuts down on the > latency with quicker time to first byte and improves customer experience. > Mobile Carriers are deploying caches closer to the customers, thus cuttin= g > down latency drastically. These caches play an even more significant role > when the latency to the destination is very high, eg: Mobile carrier is > located in the Asia, but the source content is located in US or vice vers= a. > This also helps mobile carriers located outside of US, to cut down on the= ir > Internet traffic to the US, which directly translates to savings. The cac= he > server uses information in the HTTP headers, payload and other attribute = to > make the effective caching decisions. As we move to encryption the cache > server does not have this information, rendering them useless. Do you have references on this trend? It would be good if we can cite a resource as we also heard at the MARNEW workshop that some content carriers prefer end-to-end solutions. In that case, caching wouldn't work anyway. If there are trends in both directions, it would be good to cite resources. > > 3. HTTP header enrichment =E2=80=93 HTTP header enrichment has been= a > mechanism for the mobile carrier to provide =E2=80=9Callowed=E2=80=9D (No= n-CPNI) subscriber > information to third parties or other internal systems. The third parties > can in turn provide customized service, or use it to bill the customer or > allow/block selective content=E2=80=A6. This header-enrichment method is = also used > within the Mobile Carrier to pass information internally between > sub-systems, thus keeping the internal systems loosely-coupled. With > encryption, the mobile carrier loses the capability to include any > information in the content itself as it is encrypted, making it impossibl= e > for the mobile carrier to pass on the information in any HTTP headers. A reference would be helpful, thanks! > > 4. HTTP Redirection =E2=80=93 As of today the Mobile Carrier would = need to > block or redirect a customer for multiple reasons > > a. The customer may not be allowed to view the content due to paren= tal > controls. OK, so you have the information to block, but no ability to redirect in this case. > > b. The customer may not be allowed to view the content as they have > not purchased the content. Wouldn't this be a server-side decision anyway? In that case, TLS makes no difference. > > c. The customer may not be allowed as they have reached their usage > limit and need to buy additional data. > > Currently, the Mobile carrier redirects the customer using HTTP redirect = to > a page which educates the customer on the reason for the blockage and > provide steps to proceed. Once the content is encrypted, the Mobile carri= er > loses the option to redirect the traffic and the only option being to blo= ck > the customer, for all scenarios. This would not only cause bad customer > experience, but would also need another way to pass on the additional > information to the customer =E2=80=93 text message. If for any reason, th= e customer > is not able to find the information, he/she would have to call customer c= are > to find out the reason. This is not only an inconvenience to the customer= , > but also an overhead to the service provider. > > This is reasonable to add. Do you have a reference we can cite on the practices? Thank you! Kathleen > > Please feel free to get back to me if you have any > questions. > > > > Thanks, > > Badri > > Reliance Jio > > > "Confidentiality Warning: This message and any attachments are intended o= nly > for the use of the intended recipient(s), are confidential and may be > privileged. If you are not the intended recipient, you are hereby notifie= d > that any review, re-transmission, conversion to hard copy, copying, > circulation or other use of this message and any attachments is strictly > prohibited. If you are not the intended recipient, please notify the send= er > immediately by return email and delete this message and any attachments f= rom > your system. > > Virus Warning: Although the company has taken reasonable precautions to > ensure no viruses are present in this email. The company cannot accept > responsibility for any loss or damage arising from the use of this email = or > attachment." --=20 Best regards, Kathleen From nobody Thu Mar 9 06:19:43 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACA8129658; Thu, 9 Mar 2017 06:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 dcGHxnTIWoTF; Thu, 9 Mar 2017 06:19:33 -0800 (PST) Received: from gwsmtp011.ril.com (gwsmtp011.ril.com [116.50.78.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18358129649; Thu, 9 Mar 2017 06:19:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.36,268,1486405800"; d="scan'208";a="363759333" From: To: , , Thread-Topic: Last call feedback: draft-mm-wg-effect-encrypt Thread-Index: AQHSmEkdymufh+be8EG0ggEJbV3WwqGMUL1A Date: Thu, 9 Mar 2017 14:19:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Cc: acmorton@att.com Subject: Re: [saag] Last call feedback: draft-mm-wg-effect-encrypt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 14:19:36 -0000 S2F0aGxlZW4vQWwsDQoNCglUaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLiBJIGhhdmUgaW5j bHVkZWQgbXkgY29tbWVudHMgaW5saW5lLiANCglJIGFtIHN0aWxsIGxvb2tpbmcgZm9yIHJlZmVy ZW5jZXMgYW5kIHdpbGwgc2VuZCBpdCBvdXQgYXMgSSBmaW5kIHRoZW0uDQoNClRoYW5rcywNCkJh ZHJpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBLYXRobGVlbiBNb3JpYXJ0 eSBbbWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tXSANClNlbnQ6IFdlZG5l c2RheSwgTWFyY2ggMDgsIDIwMTcgMjoxOCBQTQ0KVG86IHNhYWdAaWV0Zi5vcmcNCkNjOiBCYWRy aSBTdWJyYW1hbnlhbiA8QmFkcmkuU3VicmFtYW55YW5AcmlsLmNvbT47IEFMRlJFRCBDIE1PUlRP TiAoQUwpIDxhY21vcnRvbkBhdHQuY29tPjsgc3RlcGhlbi4gZmFycmVsbCA8c3RlcGhlbi5mYXJy ZWxsQGNzLnRjZC5pZT4NClN1YmplY3Q6IExhc3QgY2FsbCBmZWVkYmFjazogZHJhZnQtbW0td2ct ZWZmZWN0LWVuY3J5cHQNCg0KSGVsbG8gQmFkcmksDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9y IHlvdXIgcmV2aWV3IGFuZCBmZWVkYmFjayBvbiB0aGUgZHJhZnQuICBUaGlzIGlzIHZlcnkgaGVs cGZ1bCB0byBhZGQgaW4geW91ciBwZXJzcGVjdGl2ZS4gIEkgZG8gaGF2ZSBhIGZldyBxdWVzdGlv bnMgaW4gbGluZSBhbmQgYW0gaG9waW5nIHlvdSBoYXZlIHNvbWUgZ29vZCByZWZlcmVuY2VzIGZv ciB1cyB0byBjaXRlIGFzIHdlbGwuICBXZSBuZWVkIHRvIGdldCBhIGRyYWZ0IHJldmlzaW9uIG91 dCBieSBGcmlkYXksIHNvIGhvcGVmdWxseSB3ZSBjYW4gaXRlcmF0ZSBxdWlja2x5Lg0KDQoNCj4N Cj4gT24gRmViIDIzLCAyMDE3LCBhdCA5OjU0IEFNLCAiQmFkcmkuU3VicmFtYW55YW5AcmlsLmNv bSINCj4gPEJhZHJpLlN1YnJhbWFueWFuQHJpbC5jb20+IHdyb3RlOg0KPg0KPiBIZWxsbywNCj4N Cj4NCj4NCj4gICAgICAgICAgICAgICAgIEkgd29yayBmb3IgYSBNb2JpbGUgU2VydmljZSBQcm92 aWRlciBhbmQgd2FudGVkIHRvIA0KPiBzdGFydCBieSB0aGFua2luZyB5b3UgZm9yIHB1dHRpbmcg dGhpcyBkb2N1bWVudCB0b2dldGhlciAoRWZmZWN0cyBvZiANCj4gUGVydmFzaXZlIEVuY3J5cHRp b24pLiBFbmNyeXB0aW9uIG9mIGNvbnRlbnQgaGFzIGJlZW4gaW1wYWN0aW5nIHRoZSANCj4gc2Vy dmljZSBwcm92aWRlcnMgZm9yIHNvbWV0aW1lLCBhbmQgdGhpcyBkb2N1bWVudCBvdXRsaW5lcyBp dCB2ZXJ5IA0KPiB3ZWxsLiBJIGhhZCBhIGZldyBjb21tZW50cy9zdWdnZXN0aW9ucyBvbiB0aGUg ZG9jdW1lbnQuIFRoaXMgZG9jdW1lbnRzIA0KPiBpcyBjb21wcmVoZW5zaXZlLCBidXQgdGhlcmUg YXJlIGEgZmV3IGltcGFjdHMgbW9yZSBzcGVjaWZpYyB0byBNb2JpbGUgDQo+IENhcnJpZXJzIHdo aWNoIEkgdGhvdWdodCB3ZXJlIG5vdCBpbmNsdWRlZC4gSSB3b3VsZCBncmVhdGx5IGFwcHJlY2lh dGUgDQo+IGl0LCBpZiB5b3UgY291bGQgbG9vayBpbnRvIHRoZXNlIGFuZCBtb2RpZnkgdGhlIGRv Y3VtZW50IGFzIHN1aXRlZC4NCj4NCj4NCj4NCj4gMS4gICAgICAgQUxHIOKAkyBBcHBsaWNhdGlv biBMYXllciBHYXRld2F5LCBpcyBhIGZlYXR1cmUgdXNlZCBieSBGaXJld2FsbHMsDQo+IE5BVCBi b3hlcyBhbmQgTG9hZCBCYWxhbmNlcnMgdG8gaWRlbnRpZnkgc3RyZWFtcyB3aGljaCBhcmUgcmVs YXRlZCBhbmQgDQo+IHRyZWF0IHRoZW0gYWxpa2UuIE1hbnkgb2YgdGhlIHByb3RvY29scyB3b3Jr IGluIGNvbmp1bmN0aW9uIHRvIGRlbGl2ZXIgYSBzZXJ2aWNlLg0KPiBFZy4gUlRTUC9SVENQL1JU UCBwcm90b2NvbHMgYXJlIHVzZWQgdG8gcHJvdmlkZSB2aWRlbyBzZXJ2aWNlLiBSVFNQIA0KPiB1 c2VzIFRDUCBhbmQgbmVnb3RpYXRlcyB0aGUgVURQIHBvcnRzIHVzZWQgZm9yIFJUUCBhbmQgUlRD UCANCj4gY29tbXVuaWNhdGlvbi4gUlRTUCBhbmQgUlRDUCBmb3JtIHRoZSBjb250cm9sIHBsYW5l LCB3aGVuIFJUUCBmb3JtcyB0aGUgZGF0YSBwbGFuZS4NCj4NCj4gYS4gICAgICAgVGhlIEFMRyBm ZWF0dXJlIG1ha2VzIHRoZSBGaXJld2FsbCBhcHBsaWNhdGlvbi1hd2FyZSBhbmQgYWxsb3cgb3IN Cj4gYmxvY2sgYSB2aWRlbyBjb250ZW50IGFzIGRlc2lyZWQuDQo+DQo+IGIuICAgICAgVGhpcyBm ZWF0dXJlIGlzIGFsc28gdXNlZCBhcyBvZiB0b2RheSBvbiB0aGUgRmlyZXdhbGwgb3IgTkFUIGJv eC4NCj4gVGhlIHNjZW5hcmlvIGhlcmUgaXMsIHRoZSBGVy9OQVQgYm94IGFjdHMgYXMgYSBkZW1h cmNhdGlvbiBwb2ludCANCj4gYmV0d2VlbiB0aGUgRE1aIGFuZCB1bnRydXN0ZWQgbmV0d29yaywg d2hpY2ggYWxsb3dzIG91dCBib3VuZCB0cmFmZmljIA0KPiBhbmQgYW55IGZsb3cgaW5pdGlhdGVk IGZyb20gd2l0aGluIHRoZSBETVouIFdoZW4gd2UgaGF2ZSBzZXJ2aWNlIHdpdGggDQo+IG11bHRp cGxlIGZsb3dzLCBzb21lIG9mIHRoZXNlIGNvdWxkIGJlIGluaXRpYXRlZCBmcm9tIHdpdGhpbiB0 aGUgRE1aLCANCj4gd2hpY2ggc2hvdWxkIGVuYWJsZSBvdGhlciBmbG93cyBpbiBib3RoIGRpcmVj dGlvbnMuIEVnLiBSVFNQIFJlcXVlc3QgDQo+IGZyb20gd2l0aGluIHRoZSBETVogd291bGQgbmVl ZCB0byBhbGxvdyBSVFAgcGFja2V0cyBmcm9tIHRoZSB1bnRydXN0ZWQgDQo+IHpvbmUgaW50byB0 aGUgRE1aLiBUaGUgRlcvTkFUIGJveCBjYW4gb25seSBhbGxvdyB0aGlzIGlmIHRoZXkgYXJlIA0K PiBhd2FyZSBvZiB0aGUgY28tcmVsYXRpb24gYmV0d2VlbiB0aGUgZGlmZmVyZW50IGZsb3dzIHVz aW5nIGZlYXR1cmUgbGlrZSBBTEcuDQo+DQo+IGMuICAgICAgIFRoZSBBTEcgZmVhdHVyZSBvbiBh IExCIHNpbWlsYXJseSB3b3VsZCBhbGxvdyB0aGUgaWRlbnRpZmljYXRpb24gb2YNCj4gdGhlIGRp ZmZlcmVudCBjby1yZWxhdGVkIGZsb3dzIGFuZCB0cmVhdCB0aGVtIGFsaWtlIOKAkyBhbGxvdywg YmxvY2ssIExCIA0KPiB0aGVtIHRvIHRoZSBzYW1lIHNlcnZlciBvciByZS1yb3V0ZSB0byBhbm90 aGVyIHNldCBvZiBzZXJ2ZXJzLg0KPg0KPiBJZiB0aGUgc3RyZWFtcyBhcmUgZW5jcnlwdGVkLCB0 aGVuIHRoZSBBTEcgZmVhdHVyZSB3b3VsZCBiZSByZW5kZXJlZCANCj4gdXNlbGVzcy4gVGhpcyB3 b3VsZCBsaW1pdCB0aGUgY2FwYWJpbGl0eSBvZiBhbnkgbmV0d29yayBlbGVtZW50IHRvIA0KPiBt YWtlIHNtYXJ0IHBvbGljaW5nIGFuZCByb3V0aW5nIGRlY2lzaW9ucyBiYXNlZCBvbiBhcHBsaWNh dGlvbiBsYXllciBhdHRyaWJ1dGVzLg0KDQpEbyB5b3Uga25vdyBpZiB0aGVzZSBjYW4gd29yayB3 aXRoIGEgMi10dXBsZSBvciA1LXR1cGxlPyAgSXMgdGhlcmUgYW4gaW1wYWN0IGZyb20gZW5jcnlw dGlvbiB2aWEgVExTIGZvciBpbnN0YW5jZT8gIElmIHNvLCB3aGF0IGlzIHRoYXQgaW1wYWN0Pw0K W0JhZHJpXSBUaGUgcnVsZXMgaW4gbW9zdCBvZiB0aGUgY2FzZXMgaXMgNS10dXBsZSB0byBhY2N1 cmF0ZWx5IGRlcGljdCBhIGZsb3cuIFllcywgdGhlcmUgaXMgYW4gaW1wYWN0IGZyb20gZW5jcnlw dGlvbiB2aWEgVExTIGFzIG1vc3Qgb2YgdGhlIGltcGxlbWVudGF0aW9ucyBvZiBBTEcgZ2V0IGlu Zm9ybWF0aW9uIHJlZ2FyZGluZyBzdXBwb3J0aW5nIHByb3RvY29scyBieSBwYXJzaW5nIGRhdGEu IFdpdGggVExTIGVuY3J5cHRpb24sIHRoZSBBTEcgbG9zZXMgdGhlIGFiaWxpdHkgdG8gcGFyc2Us IGhlbmNlIGdldCBpbmZvcm1hdGlvbiBvbiB0aGUgc3VwcG9ydGluZyBwcm90b2NvbHMuDQoNCldo YXQgaXMgdXNlZCBieSBBTEcgdG8gY29ycmVsYXRlIHN0cmVhbXM/ICBUaGlzIHdvdWxkIGJlIGhl bHBmdWwgdG8gdW5kZXJzdGFuZCBpZiB0aGlzIHBhcnRpY3VsYXIgbWV0aG9kIGZvciBBTEdzIGRv ZXMgYmVjb21lICd1c2VsZXNzJw0KYW5kIGFsc28gdG8gZmlndXJlIG91dCBpZiBvdGhlciBvcHRp b25zIG1heSBleGlzdCB0byBwZXJmb3JtIHRoZSBmdW5jdGlvbnMgbmVlZGVkLg0KW0JhZHJpXSBS RkMgMjY2MywgU2VjdGlvbiAyLjkgZ2l2ZXMgaW5mb3JtYXRpb24gYWJvdXQgQUxHLiBUaGVyZSBp c27igJl0IG9uZSBkZWZpbmVkIG1ldGhvZCB0byBpbXBsZW1lbnQgaXQgYW5kIHNvbWUgb2YgdGhl IG1ldGhvZHMgdXNlZCBieSB2ZW5kb3JzIGFyZSBpbmNsdWRlZCBiZWxvdy4NCjEuICBQYXJzZSB0 aGUgY29udGVudCBvZiB0aGUgcHJpbWFyeSBzdHJlYW0gYW5kIGlkZW50aWZ5IHRoZSA1LXR1cGxl IG9mIHRoZSBzdXBwb3J0aW5nIHN0cmVhbXMgYXMgaXQgaXMgYmVpbmcgbmVnb3RpYXRlZC4NCjIu IEludGVyY2VwdCBhbmQgbW9kaWZ5IHRoZSA1LXR1cGxlIGluZm9ybWF0aW9uIG9mIHRoZSBzdXBw b3J0aW5nIHN0cmVhbSBhcyB0aGUgaXQgaXMgYmVpbmcgbmVnb3RpYXRlZCBvbiB0aGUgcHJpbWFy eSBzdHJlYW0uIFRoaXMgaXMgYSBsaXR0bGUgbW9yZSBpbnRydXNpdmUgaW4gbmF0dXJlLg0KDQpE byB5b3UgaGF2ZSByZWZlcmVuY2VzIG9uIHRoaXMgdGhhdCBhcmUgc3RhYmxlIChvbmVzIHdlIGNh biBjaXRlIGluIGFuIFJGQyk/DQpSRkMgMjY2MywgU2VjdGlvbiAyLjkNCg0KSSBoYXZlIGFsc28g c3BlbGxlZCBvdXQgc29tZSBvZiB0aGUgYWNyb255bXMgYmVsb3cNClJUU1AgLSBSZWFsIFRpbWUg U3RyZWFtaW5nIFByb3RvY29sDQpSVENQIC0gUmVhbCBUaW1lIENvbnRyb2wgUHJvdG9jb2wNClJU UCAtIFJlYWwgVGltZSBQcm90b2NvbA0KQUxHIC0gQXBwbGljYXRpb24gTGV2ZWwgR2F0ZXdheS9B cHBsaWNhdGlvbiBMYXllciBHYXRld2F5DQpMQiAtIExvYWQgQmFsYW5jZXJzDQpETVogLSBEZW1p bGl0YXJpemVkIFpvbmUNCkZXIC0gRmlyZXdhbGwNCg0KPg0KPiAyLiAgICAgICBPdmVyLVRoZS1U b3AgQ2FjaGluZyB3ZWIgY29udGVudCDigJMgWW91IGRpZCB0b3VjaCB1cG9uIHRoaXMgdG9waWMg aW4NCj4gc2VjdGlvbiAyLjEuNCwgYnV0IEkgdGhpbmsgdGhpcyBpcyBhIGJpZyBlbm91Z2ggdG9w aWMgdGhhdCBpdCB3YXJyYW50cyANCj4gaXRzIG93biBzdWJzZWN0aW9uLiBBcyB0aGUgSW50ZXJu ZXQgdHJhZmZpYyBpbmNyZWFzZXMgYWNyb3NzIHRoZSANCj4gd29ybGQsIE1vYmlsZSBDYXJyaWVy cyBhbmQgb3RoZXIgU2VydmljZSBQcm92aWRlcnMgYXJlIHVzaW5nIGNhY2hpbmcgDQo+IHNvbHV0 aW9uIHRvIGtlZXAgdXAgd2l0aCB0aGUgYmFuZHdpZHRoIG5lZWRzLiBDYWNoaW5nIGF0IGEgaGln aCBsZXZlbCANCj4gd291bGQgYWxsb3cgZm9yIHdlYi92aWRlbyBhbmQgb3RoZXIgY2FjaGVzIHRv IGJlIGxvY2F0ZWQgY2xvc2VyIHRvIHRoZSANCj4gY3VzdG9tZXJzLiBUaGUgZmlyc3QgdGltZSBh IGNvbnRlbnQgaXMgcmVxdWVzdGVkLCBpdCBpcyBzdG9yZWQgaW4gdGhlIA0KPiBjYWNoZSBhbmQg ZXZlcnkgcmVxdWVzdCBnb2luZyBmb3J3YXJkIHdvdWxkIGJlIHNlcnZlZCBmcm9tIHRoZSBjYWNo ZSANCj4gdGh1cyBjdXR0aW5nIGRvd24gb24gdGhlIGJhY2toYXVsIHRvbm5hZ2UgYmV0d2VlbiB0 aGUgc291cmNlIG9mIHRoZSANCj4gY29udGVudCBhbmQgdGhlIGNhY2hlLiBUaGlzIG5vdCBvbmx5 IGhlbHBzIGluIGN1dHRpbmcgZG93biBvbiB0aGUgDQo+IGJhbmR3aWR0aCByZXF1aXJlbWVudHMs IGJ1dCBhbHNvIGN1dHMgZG93biBvbiB0aGUgbGF0ZW5jeSB3aXRoIHF1aWNrZXIgdGltZSB0byBm aXJzdCBieXRlIGFuZCBpbXByb3ZlcyBjdXN0b21lciBleHBlcmllbmNlLg0KPiBNb2JpbGUgQ2Fy cmllcnMgYXJlIGRlcGxveWluZyBjYWNoZXMgY2xvc2VyIHRvIHRoZSBjdXN0b21lcnMsIHRodXMg DQo+IGN1dHRpbmcgZG93biBsYXRlbmN5IGRyYXN0aWNhbGx5LiBUaGVzZSBjYWNoZXMgcGxheSBh biBldmVuIG1vcmUgDQo+IHNpZ25pZmljYW50IHJvbGUgd2hlbiB0aGUgbGF0ZW5jeSB0byB0aGUg ZGVzdGluYXRpb24gaXMgdmVyeSBoaWdoLCBlZzogDQo+IE1vYmlsZSBjYXJyaWVyIGlzIGxvY2F0 ZWQgaW4gdGhlIEFzaWEsIGJ1dCB0aGUgc291cmNlIGNvbnRlbnQgaXMgbG9jYXRlZCBpbiBVUyBv ciB2aWNlIHZlcnNhLg0KPiBUaGlzIGFsc28gaGVscHMgbW9iaWxlIGNhcnJpZXJzIGxvY2F0ZWQg b3V0c2lkZSBvZiBVUywgdG8gY3V0IGRvd24gb24gDQo+IHRoZWlyIEludGVybmV0IHRyYWZmaWMg dG8gdGhlIFVTLCB3aGljaCBkaXJlY3RseSB0cmFuc2xhdGVzIHRvIA0KPiBzYXZpbmdzLiBUaGUg Y2FjaGUgc2VydmVyIHVzZXMgaW5mb3JtYXRpb24gaW4gdGhlIEhUVFAgaGVhZGVycywgDQo+IHBh eWxvYWQgYW5kIG90aGVyIGF0dHJpYnV0ZSB0byBtYWtlIHRoZSBlZmZlY3RpdmUgY2FjaGluZyBk ZWNpc2lvbnMuIA0KPiBBcyB3ZSBtb3ZlIHRvIGVuY3J5cHRpb24gdGhlIGNhY2hlIHNlcnZlciBk b2VzIG5vdCBoYXZlIHRoaXMgaW5mb3JtYXRpb24sIHJlbmRlcmluZyB0aGVtIHVzZWxlc3MuDQoN CkRvIHlvdSBoYXZlIHJlZmVyZW5jZXMgb24gdGhpcyB0cmVuZD8gIEl0IHdvdWxkIGJlIGdvb2Qg aWYgd2UgY2FuIGNpdGUgYSByZXNvdXJjZSBhcyB3ZSBhbHNvIGhlYXJkIGF0IHRoZSBNQVJORVcg d29ya3Nob3AgdGhhdCBzb21lIGNvbnRlbnQgY2FycmllcnMgcHJlZmVyIGVuZC10by1lbmQgc29s dXRpb25zLiAgSW4gdGhhdCBjYXNlLCBjYWNoaW5nIHdvdWxkbid0IHdvcmsgYW55d2F5LiAgSWYg dGhlcmUgYXJlIHRyZW5kcyBpbiBib3RoIGRpcmVjdGlvbnMsIGl0IHdvdWxkIGJlIGdvb2QgdG8g Y2l0ZSByZXNvdXJjZXMuDQpDYWNoaW5nIGhlbHBzIGluIHJlZHVjaW5nIExhdGVuY3kgYW5kIElu dGVybmV0IGJhbmR3aWR0aCBmb3IgdGhlIGEgTW9iaWxlIENhcnJpZXIsIHdoaWNoIGlzIHRoZSBi YXNpcyBvZiBIVFRQIENhY2hpbmcgYXMgZGVzY3JpYmVkIGluIFJGQyA3MjM0LiBMZXQgbWUgY2hl Y2sgdG8gc2VlIGlmIHRoZXJlIGFyZSBhbnkgd2hpdGUgcGFwZXJzIHdoaWNoIHRhbGsgYWJvdXQg dGhpcyB0cmVuZCBvZiB1c2luZyBPVFQgQ2FjaGVzLi4uDQpSRkMgNzIzNCBnaXZlcyBpbmZvcm1h dGlvbiBvbiBIVFRQIENhY2hpbmcgYW5kIHRoZSBleHBlY3RlZCBiZW5lZml0cy4gDQo+DQo+IDMu ICAgICAgIEhUVFAgaGVhZGVyIGVucmljaG1lbnQg4oCTIEhUVFAgaGVhZGVyIGVucmljaG1lbnQg aGFzIGJlZW4gYQ0KPiBtZWNoYW5pc20gZm9yIHRoZSBtb2JpbGUgY2FycmllciB0byBwcm92aWRl IOKAnGFsbG93ZWTigJ0gKE5vbi1DUE5JKSANCj4gc3Vic2NyaWJlciBpbmZvcm1hdGlvbiB0byB0 aGlyZCBwYXJ0aWVzIG9yIG90aGVyIGludGVybmFsIHN5c3RlbXMuIFRoZSANCj4gdGhpcmQgcGFy dGllcyBjYW4gaW4gdHVybiBwcm92aWRlIGN1c3RvbWl6ZWQgc2VydmljZSwgb3IgdXNlIGl0IHRv IA0KPiBiaWxsIHRoZSBjdXN0b21lciBvciBhbGxvdy9ibG9jayBzZWxlY3RpdmUgY29udGVudOKA pi4gVGhpcyANCj4gaGVhZGVyLWVucmljaG1lbnQgbWV0aG9kIGlzIGFsc28gdXNlZCB3aXRoaW4g dGhlIE1vYmlsZSBDYXJyaWVyIHRvIA0KPiBwYXNzIGluZm9ybWF0aW9uIGludGVybmFsbHkgYmV0 d2VlbiBzdWItc3lzdGVtcywgdGh1cyBrZWVwaW5nIHRoZSANCj4gaW50ZXJuYWwgc3lzdGVtcyBs b29zZWx5LWNvdXBsZWQuIFdpdGggZW5jcnlwdGlvbiwgdGhlIG1vYmlsZSBjYXJyaWVyIA0KPiBs b3NlcyB0aGUgY2FwYWJpbGl0eSB0byBpbmNsdWRlIGFueSBpbmZvcm1hdGlvbiBpbiB0aGUgY29u dGVudCBpdHNlbGYgDQo+IGFzIGl0IGlzIGVuY3J5cHRlZCwgbWFraW5nIGl0IGltcG9zc2libGUg Zm9yIHRoZSBtb2JpbGUgY2FycmllciB0byBwYXNzIG9uIHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkg SFRUUCBoZWFkZXJzLg0KDQpBIHJlZmVyZW5jZSB3b3VsZCBiZSBoZWxwZnVsLCB0aGFua3MhDQoN Cj4NCj4gNC4gICAgICAgSFRUUCBSZWRpcmVjdGlvbiDigJMgQXMgb2YgdG9kYXkgdGhlIE1vYmls ZSBDYXJyaWVyIHdvdWxkIG5lZWQgdG8NCj4gYmxvY2sgb3IgcmVkaXJlY3QgYSBjdXN0b21lciBm b3IgbXVsdGlwbGUgcmVhc29ucw0KDQo+DQo+IGEuICAgICAgIFRoZSBjdXN0b21lciBtYXkgbm90 IGJlIGFsbG93ZWQgdG8gdmlldyB0aGUgY29udGVudCBkdWUgdG8gcGFyZW50YWwNCj4gY29udHJv bHMuDQoNCk9LLCBzbyB5b3UgaGF2ZSB0aGUgaW5mb3JtYXRpb24gdG8gYmxvY2ssIGJ1dCBubyBh YmlsaXR5IHRvIHJlZGlyZWN0IGluIHRoaXMgY2FzZS4NCg0KW0JhZHJpXSBZZXMsIHRoYXQgdGhl IGV4YWN0bHkgdGhlIHNjZW5hcmlvLiBUaGUgbW9iaWxlIHByb3ZpZGVyIGhhcyB0aGUgZGVzdGlu YXRpb24gZG9tYWluL0lQIEFkZHJlc3MgZnJvbSB0aGUgQ3VzdG9tZXIgcmVxdWVzdCBhbmQgaWRl bnRpZmllcyB0aGlzIGRvbWFpbiBhcyBhIGJsb2NrZWQgZG9tYWluIHVuZGVyIFBhcmVudGFsIGNv bnRyb2wuDQoNCj4NCj4gYi4gICAgICBUaGUgY3VzdG9tZXIgIG1heSBub3QgYmUgYWxsb3dlZCB0 byB2aWV3IHRoZSBjb250ZW50IGFzIHRoZXkgaGF2ZQ0KPiBub3QgcHVyY2hhc2VkIHRoZSBjb250 ZW50Lg0KDQpXb3VsZG4ndCB0aGlzIGJlIGEgc2VydmVyLXNpZGUgZGVjaXNpb24gYW55d2F5PyAg SW4gdGhhdCBjYXNlLCBUTFMgbWFrZXMgbm8gZGlmZmVyZW5jZS4NCg0KPg0KPiBjLiAgICAgICBU aGUgY3VzdG9tZXIgbWF5IG5vdCBiZSBhbGxvd2VkIGFzIHRoZXkgaGF2ZSByZWFjaGVkIHRoZWly IHVzYWdlDQo+IGxpbWl0IGFuZCBuZWVkIHRvIGJ1eSBhZGRpdGlvbmFsIGRhdGEuDQo+DQo+IEN1 cnJlbnRseSwgdGhlIE1vYmlsZSBjYXJyaWVyIHJlZGlyZWN0cyB0aGUgY3VzdG9tZXIgdXNpbmcg SFRUUCANCj4gcmVkaXJlY3QgdG8gYSBwYWdlIHdoaWNoIGVkdWNhdGVzIHRoZSBjdXN0b21lciBv biB0aGUgcmVhc29uIGZvciB0aGUgDQo+IGJsb2NrYWdlIGFuZCBwcm92aWRlIHN0ZXBzIHRvIHBy b2NlZWQuIE9uY2UgdGhlIGNvbnRlbnQgaXMgZW5jcnlwdGVkLCANCj4gdGhlIE1vYmlsZSBjYXJy aWVyIGxvc2VzIHRoZSBvcHRpb24gdG8gcmVkaXJlY3QgdGhlIHRyYWZmaWMgYW5kIHRoZSANCj4g b25seSBvcHRpb24gYmVpbmcgdG8gYmxvY2sgdGhlIGN1c3RvbWVyLCBmb3IgYWxsIHNjZW5hcmlv cy4gVGhpcyB3b3VsZCANCj4gbm90IG9ubHkgY2F1c2UgYmFkIGN1c3RvbWVyIGV4cGVyaWVuY2Us IGJ1dCB3b3VsZCBhbHNvIG5lZWQgYW5vdGhlciANCj4gd2F5IHRvIHBhc3Mgb24gdGhlIGFkZGl0 aW9uYWwgaW5mb3JtYXRpb24gdG8gdGhlIGN1c3RvbWVyIOKAkyB0ZXh0IA0KPiBtZXNzYWdlLiBJ ZiBmb3IgYW55IHJlYXNvbiwgdGhlIGN1c3RvbWVyIGlzIG5vdCBhYmxlIHRvIGZpbmQgdGhlIA0K PiBpbmZvcm1hdGlvbiwgaGUvc2hlIHdvdWxkIGhhdmUgdG8gY2FsbCBjdXN0b21lciBjYXJlIHRv IGZpbmQgb3V0IHRoZSANCj4gcmVhc29uLiBUaGlzIGlzIG5vdCBvbmx5IGFuIGluY29udmVuaWVu Y2UgdG8gdGhlIGN1c3RvbWVyLCBidXQgYWxzbyBhbiBvdmVyaGVhZCB0byB0aGUgc2VydmljZSBw cm92aWRlci4NCj4NCj4NCg0KVGhpcyBpcyByZWFzb25hYmxlIHRvIGFkZC4gIERvIHlvdSBoYXZl IGEgcmVmZXJlbmNlIHdlIGNhbiBjaXRlIG9uIHRoZSBwcmFjdGljZXM/DQpbQmFkcmldIFRoZXNl IGFyZSBwcmFjdGljZXMgdGhhdCBoYXZlIGJlZW4gZm9sbG93ZWQgaW4gdGhlIGluZHVzdHJ5LCBi dXQgZG9u4oCZdCBrbm93IGlmIHRoZXkgaGF2ZSBiZWVuIHB1Ymxpc2hlZCBhbnl3aGVyZS4gSSB3 aWxsIGNoZWNrIGFuZCBnZXQgYmFjayB0byB5b3UuDQoNClRoYW5rIHlvdSENCkthdGhsZWVuDQo+ DQo+ICAgICAgICAgICAgICAgICBQbGVhc2UgZmVlbCBmcmVlIHRvIGdldCBiYWNrIHRvIG1lIGlm IHlvdSBoYXZlIGFueSANCj4gcXVlc3Rpb25zLg0KPg0KPg0KPg0KPiBUaGFua3MsDQo+DQo+IEJh ZHJpDQo+DQo+IFJlbGlhbmNlIEppbw0KPg0KPg0KPiAiQ29uZmlkZW50aWFsaXR5IFdhcm5pbmc6 IFRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSANCj4gaW50ZW5kZWQgb25seSBm b3IgdGhlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLCBhcmUgDQo+IGNvbmZpZGVu dGlhbCBhbmQgbWF5IGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCAN Cj4gcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSByZXZpZXcsIHJl LXRyYW5zbWlzc2lvbiwgDQo+IGNvbnZlcnNpb24gdG8gaGFyZCBjb3B5LCBjb3B5aW5nLCBjaXJj dWxhdGlvbiBvciBvdGhlciB1c2Ugb2YgdGhpcyANCj4gbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1l bnRzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSANCj4gaW50ZW5k ZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgcmV0 dXJuIA0KPiBlbWFpbCBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRz IGZyb20geW91ciBzeXN0ZW0uDQo+DQo+IFZpcnVzIFdhcm5pbmc6IEFsdGhvdWdoIHRoZSBjb21w YW55IGhhcyB0YWtlbiByZWFzb25hYmxlIHByZWNhdXRpb25zIA0KPiB0byBlbnN1cmUgbm8gdmly dXNlcyBhcmUgcHJlc2VudCBpbiB0aGlzIGVtYWlsLiBUaGUgY29tcGFueSBjYW5ub3QgDQo+IGFj Y2VwdCByZXNwb25zaWJpbGl0eSBmb3IgYW55IGxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0 aGUgdXNlIG9mIA0KPiB0aGlzIGVtYWlsIG9yIGF0dGFjaG1lbnQuIg0KDQoNCg0KLS0gDQoNCkJl c3QgcmVnYXJkcywNCkthdGhsZWVuDQoNCiJDb25maWRlbnRpYWxpdHkgV2FybmluZzogVGhpcyBt ZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gDQphcmUgY29uZmlkZW50aWFsIGFuZCBtYXkg YmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudC4geW91 IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgDQpyZXZpZXcuIHJlLXRyYW5zbWlzc2lvbi4g Y29udmVyc2lvbiB0byBoYXJkIGNvcHkuIGNvcHlpbmcuIGNpcmN1bGF0aW9uIG9yIG90aGVyIHVz ZSBvZiB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBpcyANCnN0cmljdGx5IHByb2hp Yml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSByZXR1cm4gZW1haWwuIA0KYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBmcm9tIHlvdXIgc3lzdGVtLg0KDQpWaXJ1 cyBXYXJuaW5nOiBBbHRob3VnaCB0aGUgY29tcGFueSBoYXMgdGFrZW4gcmVhc29uYWJsZSBwcmVj YXV0aW9ucyB0byBlbnN1cmUgbm8gdmlydXNlcyBhcmUgcHJlc2VudCBpbiB0aGlzIGVtYWlsLiAN ClRoZSBjb21wYW55IGNhbm5vdCBhY2NlcHQgcmVzcG9uc2liaWxpdHkgZm9yIGFueSBsb3NzIG9y IGRhbWFnZSBhcmlzaW5nIGZyb20gdGhlIHVzZSBvZiB0aGlzIGVtYWlsIG9yIGF0dGFjaG1lbnQu Igo= From nobody Thu Mar 9 14:07:11 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7559129588; Thu, 9 Mar 2017 14:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2eheyJgeQA7P; Thu, 9 Mar 2017 14:07:04 -0800 (PST) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (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 18131129490; Thu, 9 Mar 2017 14:07:04 -0800 (PST) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v29M73Tv063696; Thu, 9 Mar 2017 14:07:03 -0800 (PST) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v29M73oT056087; Thu, 9 Mar 2017 14:07:03 -0800 (PST) From: David Mazieres To: saag@ietf.org, ilc@ietf.org, trans@ietf.org Date: Thu, 09 Mar 2017 14:07:03 -0800 Message-ID: <87a88uksu0.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [saag] Talk announcement: Internet-Level Consensus is Practical X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David Mazieres expires 2017-06-07 PDT List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 22:07:05 -0000 I'll be giving the following 30-minute talk during the saag session at the upcoming IETF meeting in Chicago, likely followed by a "bar bof" on Internet-level consensus that evening. Internet-Level Consensus is Practical David Mazi=C3=A8res Security Area Open Meeting Thursday March 30, 2017 15:20-17:20 Zurich D room =09=09=09=09=20=20=20 Consensus is the problem of agreeing on a valid input value among members of a distributed system. Internet-level consensus extends the concept to global agreement, despite the fact that the Internet has no meaningful notion of membership. This talk will report on the Stellar consensus protocol (SCP), an existence proof that secure consensus does not require well-defined membership. SCP's key idea is for individual participants to decide for themselves which other participants they cannot afford to diverge from. SCP guarantees agreement so long as there is transitive overlap in these dependencies. SCP is in production use by the Stellar payment network, but has broader potential applications ranging from secure package distribution to key management in end-to-end email encryption. From nobody Thu Mar 9 23:36:07 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2CD12945D; Thu, 9 Mar 2017 23:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=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 OrQulRtdyeVl; Thu, 9 Mar 2017 23:35:54 -0800 (PST) Received: from gwsmtp010.ril.com (unknown [203.199.41.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F43D129456; Thu, 9 Mar 2017 23:35:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.36,139,1486405800"; d="scan'208";a="377191291" From: To: , , Thread-Topic: Last call feedback: draft-mm-wg-effect-encrypt Thread-Index: AQHSmEkdymufh+be8EG0ggEJbV3WwqGMUL1AgAD0g4A= Date: Fri, 10 Mar 2017 07:35:18 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Cc: acmorton@att.com Subject: Re: [saag] Last call feedback: draft-mm-wg-effect-encrypt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 07:35:58 -0000 S2F0aGxlZW4vQWwsDQoNCglJIGhhdmUgaW5jbHVkZWQgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBp bmxpbmUuIFBsZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgbmVlZCBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uLg0KDQpUaGFua3MsDQpCYWRyaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogQmFkcmkgU3VicmFtYW55YW4gDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMDksIDIwMTcgODox OSBBTQ0KVG86ICdLYXRobGVlbiBNb3JpYXJ0eScgPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21h aWwuY29tPjsgJ3NhYWdAaWV0Zi5vcmcnIDxzYWFnQGlldGYub3JnPjsgJ2lldGZAaWV0Zi5vcmcn IDxpZXRmQGlldGYub3JnPg0KQ2M6ICdBTEZSRUQgQyBNT1JUT04gKEFMKScgPGFjbW9ydG9uQGF0 dC5jb20+OyAnc3RlcGhlbi4gZmFycmVsbCcgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+DQpT dWJqZWN0OiBSRTogTGFzdCBjYWxsIGZlZWRiYWNrOiBkcmFmdC1tbS13Zy1lZmZlY3QtZW5jcnlw dA0KDQpLYXRobGVlbi9BbCwNCg0KCVRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24uIEkgaGF2 ZSBpbmNsdWRlZCBteSBjb21tZW50cyBpbmxpbmUuIA0KCUkgYW0gc3RpbGwgbG9va2luZyBmb3Ig cmVmZXJlbmNlcyBhbmQgd2lsbCBzZW5kIGl0IG91dCBhcyBJIGZpbmQgdGhlbS4NCg0KVGhhbmtz LA0KQmFkcmkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEthdGhsZWVuIE1v cmlhcnR5IFttYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb21dDQpTZW50OiBX ZWRuZXNkYXksIE1hcmNoIDA4LCAyMDE3IDI6MTggUE0NClRvOiBzYWFnQGlldGYub3JnDQpDYzog QmFkcmkgU3VicmFtYW55YW4gPEJhZHJpLlN1YnJhbWFueWFuQHJpbC5jb20+OyBBTEZSRUQgQyBN T1JUT04gKEFMKSA8YWNtb3J0b25AYXR0LmNvbT47IHN0ZXBoZW4uIGZhcnJlbGwgPHN0ZXBoZW4u ZmFycmVsbEBjcy50Y2QuaWU+DQpTdWJqZWN0OiBMYXN0IGNhbGwgZmVlZGJhY2s6IGRyYWZ0LW1t LXdnLWVmZmVjdC1lbmNyeXB0DQoNCkhlbGxvIEJhZHJpLA0KDQpUaGFuayB5b3UgdmVyeSBtdWNo IGZvciB5b3VyIHJldmlldyBhbmQgZmVlZGJhY2sgb24gdGhlIGRyYWZ0LiAgVGhpcyBpcyB2ZXJ5 IGhlbHBmdWwgdG8gYWRkIGluIHlvdXIgcGVyc3BlY3RpdmUuICBJIGRvIGhhdmUgYSBmZXcgcXVl c3Rpb25zIGluIGxpbmUgYW5kIGFtIGhvcGluZyB5b3UgaGF2ZSBzb21lIGdvb2QgcmVmZXJlbmNl cyBmb3IgdXMgdG8gY2l0ZSBhcyB3ZWxsLiAgV2UgbmVlZCB0byBnZXQgYSBkcmFmdCByZXZpc2lv biBvdXQgYnkgRnJpZGF5LCBzbyBob3BlZnVsbHkgd2UgY2FuIGl0ZXJhdGUgcXVpY2tseS4NCg0K DQo+DQo+IE9uIEZlYiAyMywgMjAxNywgYXQgOTo1NCBBTSwgIkJhZHJpLlN1YnJhbWFueWFuQHJp bC5jb20iDQo+IDxCYWRyaS5TdWJyYW1hbnlhbkByaWwuY29tPiB3cm90ZToNCj4NCj4gSGVsbG8s DQo+DQo+DQo+DQo+ICAgICAgICAgICAgICAgICBJIHdvcmsgZm9yIGEgTW9iaWxlIFNlcnZpY2Ug UHJvdmlkZXIgYW5kIHdhbnRlZCB0byANCj4gc3RhcnQgYnkgdGhhbmtpbmcgeW91IGZvciBwdXR0 aW5nIHRoaXMgZG9jdW1lbnQgdG9nZXRoZXIgKEVmZmVjdHMgb2YgDQo+IFBlcnZhc2l2ZSBFbmNy eXB0aW9uKS4gRW5jcnlwdGlvbiBvZiBjb250ZW50IGhhcyBiZWVuIGltcGFjdGluZyB0aGUgDQo+ IHNlcnZpY2UgcHJvdmlkZXJzIGZvciBzb21ldGltZSwgYW5kIHRoaXMgZG9jdW1lbnQgb3V0bGlu ZXMgaXQgdmVyeSANCj4gd2VsbC4gSSBoYWQgYSBmZXcgY29tbWVudHMvc3VnZ2VzdGlvbnMgb24g dGhlIGRvY3VtZW50LiBUaGlzIGRvY3VtZW50cyANCj4gaXMgY29tcHJlaGVuc2l2ZSwgYnV0IHRo ZXJlIGFyZSBhIGZldyBpbXBhY3RzIG1vcmUgc3BlY2lmaWMgdG8gTW9iaWxlIA0KPiBDYXJyaWVy cyB3aGljaCBJIHRob3VnaHQgd2VyZSBub3QgaW5jbHVkZWQuIEkgd291bGQgZ3JlYXRseSBhcHBy ZWNpYXRlIA0KPiBpdCwgaWYgeW91IGNvdWxkIGxvb2sgaW50byB0aGVzZSBhbmQgbW9kaWZ5IHRo ZSBkb2N1bWVudCBhcyBzdWl0ZWQuDQo+DQo+DQo+DQo+IDEuICAgICAgIEFMRyDigJMgQXBwbGlj YXRpb24gTGF5ZXIgR2F0ZXdheSwgaXMgYSBmZWF0dXJlIHVzZWQgYnkgRmlyZXdhbGxzLA0KPiBO QVQgYm94ZXMgYW5kIExvYWQgQmFsYW5jZXJzIHRvIGlkZW50aWZ5IHN0cmVhbXMgd2hpY2ggYXJl IHJlbGF0ZWQgYW5kIA0KPiB0cmVhdCB0aGVtIGFsaWtlLiBNYW55IG9mIHRoZSBwcm90b2NvbHMg d29yayBpbiBjb25qdW5jdGlvbiB0byBkZWxpdmVyIGEgc2VydmljZS4NCj4gRWcuIFJUU1AvUlRD UC9SVFAgcHJvdG9jb2xzIGFyZSB1c2VkIHRvIHByb3ZpZGUgdmlkZW8gc2VydmljZS4gUlRTUCAN Cj4gdXNlcyBUQ1AgYW5kIG5lZ290aWF0ZXMgdGhlIFVEUCBwb3J0cyB1c2VkIGZvciBSVFAgYW5k IFJUQ1AgDQo+IGNvbW11bmljYXRpb24uIFJUU1AgYW5kIFJUQ1AgZm9ybSB0aGUgY29udHJvbCBw bGFuZSwgd2hlbiBSVFAgZm9ybXMgdGhlIGRhdGEgcGxhbmUuDQo+DQo+IGEuICAgICAgIFRoZSBB TEcgZmVhdHVyZSBtYWtlcyB0aGUgRmlyZXdhbGwgYXBwbGljYXRpb24tYXdhcmUgYW5kIGFsbG93 IG9yDQo+IGJsb2NrIGEgdmlkZW8gY29udGVudCBhcyBkZXNpcmVkLg0KPg0KPiBiLiAgICAgIFRo aXMgZmVhdHVyZSBpcyBhbHNvIHVzZWQgYXMgb2YgdG9kYXkgb24gdGhlIEZpcmV3YWxsIG9yIE5B VCBib3guDQo+IFRoZSBzY2VuYXJpbyBoZXJlIGlzLCB0aGUgRlcvTkFUIGJveCBhY3RzIGFzIGEg ZGVtYXJjYXRpb24gcG9pbnQgDQo+IGJldHdlZW4gdGhlIERNWiBhbmQgdW50cnVzdGVkIG5ldHdv cmssIHdoaWNoIGFsbG93cyBvdXQgYm91bmQgdHJhZmZpYyANCj4gYW5kIGFueSBmbG93IGluaXRp YXRlZCBmcm9tIHdpdGhpbiB0aGUgRE1aLiBXaGVuIHdlIGhhdmUgc2VydmljZSB3aXRoIA0KPiBt dWx0aXBsZSBmbG93cywgc29tZSBvZiB0aGVzZSBjb3VsZCBiZSBpbml0aWF0ZWQgZnJvbSB3aXRo aW4gdGhlIERNWiwgDQo+IHdoaWNoIHNob3VsZCBlbmFibGUgb3RoZXIgZmxvd3MgaW4gYm90aCBk aXJlY3Rpb25zLiBFZy4gUlRTUCBSZXF1ZXN0IA0KPiBmcm9tIHdpdGhpbiB0aGUgRE1aIHdvdWxk IG5lZWQgdG8gYWxsb3cgUlRQIHBhY2tldHMgZnJvbSB0aGUgdW50cnVzdGVkIA0KPiB6b25lIGlu dG8gdGhlIERNWi4gVGhlIEZXL05BVCBib3ggY2FuIG9ubHkgYWxsb3cgdGhpcyBpZiB0aGV5IGFy ZSANCj4gYXdhcmUgb2YgdGhlIGNvLXJlbGF0aW9uIGJldHdlZW4gdGhlIGRpZmZlcmVudCBmbG93 cyB1c2luZyBmZWF0dXJlIGxpa2UgQUxHLg0KPg0KPiBjLiAgICAgICBUaGUgQUxHIGZlYXR1cmUg b24gYSBMQiBzaW1pbGFybHkgd291bGQgYWxsb3cgdGhlIGlkZW50aWZpY2F0aW9uIG9mDQo+IHRo ZSBkaWZmZXJlbnQgY28tcmVsYXRlZCBmbG93cyBhbmQgdHJlYXQgdGhlbSBhbGlrZSDigJMgYWxs b3csIGJsb2NrLCBMQiANCj4gdGhlbSB0byB0aGUgc2FtZSBzZXJ2ZXIgb3IgcmUtcm91dGUgdG8g YW5vdGhlciBzZXQgb2Ygc2VydmVycy4NCj4NCj4gSWYgdGhlIHN0cmVhbXMgYXJlIGVuY3J5cHRl ZCwgdGhlbiB0aGUgQUxHIGZlYXR1cmUgd291bGQgYmUgcmVuZGVyZWQgDQo+IHVzZWxlc3MuIFRo aXMgd291bGQgbGltaXQgdGhlIGNhcGFiaWxpdHkgb2YgYW55IG5ldHdvcmsgZWxlbWVudCB0byAN Cj4gbWFrZSBzbWFydCBwb2xpY2luZyBhbmQgcm91dGluZyBkZWNpc2lvbnMgYmFzZWQgb24gYXBw bGljYXRpb24gbGF5ZXIgYXR0cmlidXRlcy4NCg0KRG8geW91IGtub3cgaWYgdGhlc2UgY2FuIHdv cmsgd2l0aCBhIDItdHVwbGUgb3IgNS10dXBsZT8gIElzIHRoZXJlIGFuIGltcGFjdCBmcm9tIGVu Y3J5cHRpb24gdmlhIFRMUyBmb3IgaW5zdGFuY2U/ICBJZiBzbywgd2hhdCBpcyB0aGF0IGltcGFj dD8NCltCYWRyaV0gVGhlIHJ1bGVzIGluIG1vc3Qgb2YgdGhlIGNhc2VzIGlzIDUtdHVwbGUgdG8g YWNjdXJhdGVseSBkZXBpY3QgYSBmbG93LiBZZXMsIHRoZXJlIGlzIGFuIGltcGFjdCBmcm9tIGVu Y3J5cHRpb24gdmlhIFRMUyBhcyBtb3N0IG9mIHRoZSBpbXBsZW1lbnRhdGlvbnMgb2YgQUxHIGdl dCBpbmZvcm1hdGlvbiByZWdhcmRpbmcgc3VwcG9ydGluZyBwcm90b2NvbHMgYnkgcGFyc2luZyBk YXRhLiBXaXRoIFRMUyBlbmNyeXB0aW9uLCB0aGUgQUxHIGxvc2VzIHRoZSBhYmlsaXR5IHRvIHBh cnNlLCBoZW5jZSBnZXQgaW5mb3JtYXRpb24gb24gdGhlIHN1cHBvcnRpbmcgcHJvdG9jb2xzLg0K DQpXaGF0IGlzIHVzZWQgYnkgQUxHIHRvIGNvcnJlbGF0ZSBzdHJlYW1zPyAgVGhpcyB3b3VsZCBi ZSBoZWxwZnVsIHRvIHVuZGVyc3RhbmQgaWYgdGhpcyBwYXJ0aWN1bGFyIG1ldGhvZCBmb3IgQUxH cyBkb2VzIGJlY29tZSAndXNlbGVzcycNCmFuZCBhbHNvIHRvIGZpZ3VyZSBvdXQgaWYgb3RoZXIg b3B0aW9ucyBtYXkgZXhpc3QgdG8gcGVyZm9ybSB0aGUgZnVuY3Rpb25zIG5lZWRlZC4NCltCYWRy aV0gUkZDIDI2NjMsIFNlY3Rpb24gMi45IGdpdmVzIGluZm9ybWF0aW9uIGFib3V0IEFMRy4gVGhl cmUgaXNu4oCZdCBvbmUgZGVmaW5lZCBtZXRob2QgdG8gaW1wbGVtZW50IGl0IGFuZCBzb21lIG9m IHRoZSBtZXRob2RzIHVzZWQgYnkgdmVuZG9ycyBhcmUgaW5jbHVkZWQgYmVsb3cuDQoxLiAgUGFy c2UgdGhlIGNvbnRlbnQgb2YgdGhlIHByaW1hcnkgc3RyZWFtIGFuZCBpZGVudGlmeSB0aGUgNS10 dXBsZSBvZiB0aGUgc3VwcG9ydGluZyBzdHJlYW1zIGFzIGl0IGlzIGJlaW5nIG5lZ290aWF0ZWQu DQoyLiBJbnRlcmNlcHQgYW5kIG1vZGlmeSB0aGUgNS10dXBsZSBpbmZvcm1hdGlvbiBvZiB0aGUg c3VwcG9ydGluZyBzdHJlYW0gYXMgdGhlIGl0IGlzIGJlaW5nIG5lZ290aWF0ZWQgb24gdGhlIHBy aW1hcnkgc3RyZWFtLiBUaGlzIGlzIGEgbGl0dGxlIG1vcmUgaW50cnVzaXZlIGluIG5hdHVyZS4N Cg0KRG8geW91IGhhdmUgcmVmZXJlbmNlcyBvbiB0aGlzIHRoYXQgYXJlIHN0YWJsZSAob25lcyB3 ZSBjYW4gY2l0ZSBpbiBhbiBSRkMpPw0KUkZDIDI2NjMsIFNlY3Rpb24gMi45DQoNCkkgaGF2ZSBh bHNvIHNwZWxsZWQgb3V0IHNvbWUgb2YgdGhlIGFjcm9ueW1zIGJlbG93IFJUU1AgLSBSZWFsIFRp bWUgU3RyZWFtaW5nIFByb3RvY29sIFJUQ1AgLSBSZWFsIFRpbWUgQ29udHJvbCBQcm90b2NvbCBS VFAgLSBSZWFsIFRpbWUgUHJvdG9jb2wgQUxHIC0gQXBwbGljYXRpb24gTGV2ZWwgR2F0ZXdheS9B cHBsaWNhdGlvbiBMYXllciBHYXRld2F5IExCIC0gTG9hZCBCYWxhbmNlcnMgRE1aIC0gRGVtaWxp dGFyaXplZCBab25lIEZXIC0gRmlyZXdhbGwNCg0KPg0KPiAyLiAgICAgICBPdmVyLVRoZS1Ub3Ag Q2FjaGluZyB3ZWIgY29udGVudCDigJMgWW91IGRpZCB0b3VjaCB1cG9uIHRoaXMgdG9waWMgaW4N Cj4gc2VjdGlvbiAyLjEuNCwgYnV0IEkgdGhpbmsgdGhpcyBpcyBhIGJpZyBlbm91Z2ggdG9waWMg dGhhdCBpdCB3YXJyYW50cyANCj4gaXRzIG93biBzdWJzZWN0aW9uLiBBcyB0aGUgSW50ZXJuZXQg dHJhZmZpYyBpbmNyZWFzZXMgYWNyb3NzIHRoZSANCj4gd29ybGQsIE1vYmlsZSBDYXJyaWVycyBh bmQgb3RoZXIgU2VydmljZSBQcm92aWRlcnMgYXJlIHVzaW5nIGNhY2hpbmcgDQo+IHNvbHV0aW9u IHRvIGtlZXAgdXAgd2l0aCB0aGUgYmFuZHdpZHRoIG5lZWRzLiBDYWNoaW5nIGF0IGEgaGlnaCBs ZXZlbCANCj4gd291bGQgYWxsb3cgZm9yIHdlYi92aWRlbyBhbmQgb3RoZXIgY2FjaGVzIHRvIGJl IGxvY2F0ZWQgY2xvc2VyIHRvIHRoZSANCj4gY3VzdG9tZXJzLiBUaGUgZmlyc3QgdGltZSBhIGNv bnRlbnQgaXMgcmVxdWVzdGVkLCBpdCBpcyBzdG9yZWQgaW4gdGhlIA0KPiBjYWNoZSBhbmQgZXZl cnkgcmVxdWVzdCBnb2luZyBmb3J3YXJkIHdvdWxkIGJlIHNlcnZlZCBmcm9tIHRoZSBjYWNoZSAN Cj4gdGh1cyBjdXR0aW5nIGRvd24gb24gdGhlIGJhY2toYXVsIHRvbm5hZ2UgYmV0d2VlbiB0aGUg c291cmNlIG9mIHRoZSANCj4gY29udGVudCBhbmQgdGhlIGNhY2hlLiBUaGlzIG5vdCBvbmx5IGhl bHBzIGluIGN1dHRpbmcgZG93biBvbiB0aGUgDQo+IGJhbmR3aWR0aCByZXF1aXJlbWVudHMsIGJ1 dCBhbHNvIGN1dHMgZG93biBvbiB0aGUgbGF0ZW5jeSB3aXRoIHF1aWNrZXIgdGltZSB0byBmaXJz dCBieXRlIGFuZCBpbXByb3ZlcyBjdXN0b21lciBleHBlcmllbmNlLg0KPiBNb2JpbGUgQ2Fycmll cnMgYXJlIGRlcGxveWluZyBjYWNoZXMgY2xvc2VyIHRvIHRoZSBjdXN0b21lcnMsIHRodXMgDQo+ IGN1dHRpbmcgZG93biBsYXRlbmN5IGRyYXN0aWNhbGx5LiBUaGVzZSBjYWNoZXMgcGxheSBhbiBl dmVuIG1vcmUgDQo+IHNpZ25pZmljYW50IHJvbGUgd2hlbiB0aGUgbGF0ZW5jeSB0byB0aGUgZGVz dGluYXRpb24gaXMgdmVyeSBoaWdoLCBlZzoNCj4gTW9iaWxlIGNhcnJpZXIgaXMgbG9jYXRlZCBp biB0aGUgQXNpYSwgYnV0IHRoZSBzb3VyY2UgY29udGVudCBpcyBsb2NhdGVkIGluIFVTIG9yIHZp Y2UgdmVyc2EuDQo+IFRoaXMgYWxzbyBoZWxwcyBtb2JpbGUgY2FycmllcnMgbG9jYXRlZCBvdXRz aWRlIG9mIFVTLCB0byBjdXQgZG93biBvbiANCj4gdGhlaXIgSW50ZXJuZXQgdHJhZmZpYyB0byB0 aGUgVVMsIHdoaWNoIGRpcmVjdGx5IHRyYW5zbGF0ZXMgdG8gDQo+IHNhdmluZ3MuIFRoZSBjYWNo ZSBzZXJ2ZXIgdXNlcyBpbmZvcm1hdGlvbiBpbiB0aGUgSFRUUCBoZWFkZXJzLCANCj4gcGF5bG9h ZCBhbmQgb3RoZXIgYXR0cmlidXRlIHRvIG1ha2UgdGhlIGVmZmVjdGl2ZSBjYWNoaW5nIGRlY2lz aW9ucy4NCj4gQXMgd2UgbW92ZSB0byBlbmNyeXB0aW9uIHRoZSBjYWNoZSBzZXJ2ZXIgZG9lcyBu b3QgaGF2ZSB0aGlzIGluZm9ybWF0aW9uLCByZW5kZXJpbmcgdGhlbSB1c2VsZXNzLg0KDQpEbyB5 b3UgaGF2ZSByZWZlcmVuY2VzIG9uIHRoaXMgdHJlbmQ/ICBJdCB3b3VsZCBiZSBnb29kIGlmIHdl IGNhbiBjaXRlIGEgcmVzb3VyY2UgYXMgd2UgYWxzbyBoZWFyZCBhdCB0aGUgTUFSTkVXIHdvcmtz aG9wIHRoYXQgc29tZSBjb250ZW50IGNhcnJpZXJzIHByZWZlciBlbmQtdG8tZW5kIHNvbHV0aW9u cy4gIEluIHRoYXQgY2FzZSwgY2FjaGluZyB3b3VsZG4ndCB3b3JrIGFueXdheS4gIElmIHRoZXJl IGFyZSB0cmVuZHMgaW4gYm90aCBkaXJlY3Rpb25zLCBpdCB3b3VsZCBiZSBnb29kIHRvIGNpdGUg cmVzb3VyY2VzLg0KQ2FjaGluZyBoZWxwcyBpbiByZWR1Y2luZyBMYXRlbmN5IGFuZCBJbnRlcm5l dCBiYW5kd2lkdGggZm9yIHRoZSBhIE1vYmlsZSBDYXJyaWVyLCB3aGljaCBpcyB0aGUgYmFzaXMg b2YgSFRUUCBDYWNoaW5nIGFzIGRlc2NyaWJlZCBpbiBSRkMgNzIzNC4gTGV0IG1lIGNoZWNrIHRv IHNlZSBpZiB0aGVyZSBhcmUgYW55IHdoaXRlIHBhcGVycyB3aGljaCB0YWxrIGFib3V0IHRoaXMg dHJlbmQgb2YgdXNpbmcgT1RUIENhY2hlcy4uLg0KUkZDIDcyMzQgZ2l2ZXMgaW5mb3JtYXRpb24g b24gSFRUUCBDYWNoaW5nIGFuZCB0aGUgZXhwZWN0ZWQgYmVuZWZpdHMuIFRoZSBJbnRlcm5ldCBQ cm90b2NvbCBKb3VybmFsIHB1Ymxpc2hlZCBieSBDaXNjbyBhbHNvIGNvbnRhaW5zIGluZm9ybWF0 aW9uIG9uIHdlYiBjYWNoaW5nIGFuZCBpdHMgYmVuZWZpdCAoaHR0cDovL3d3dy5jaXNjby5jb20v Yy9kYW0vZW5fdXMvYWJvdXQvYWMxMjMvYWMxNDcvYXJjaGl2ZWRfaXNzdWVzL2lwal8yLTMvaXBq XzItMy5wZGYpIC4gVGhlIGZvbGxvd2luZyBhcnRpY2xlIGFsc28gdGFsa3MgYWJvdXQgcHJveHkg YW5kIGNhY2hpbmcgb24gdGhlIG1vYmlsZSBjYXJyaWVyIG5ldHdvcmtzIC0gaHR0cHM6Ly9uc2wu Y3MudXNjLmVkdS9+anlyL3BhcGVycy85MDgxOC5wZGYNCj4NCj4gMy4gICAgICAgSFRUUCBoZWFk ZXIgZW5yaWNobWVudCDigJMgSFRUUCBoZWFkZXIgZW5yaWNobWVudCBoYXMgYmVlbiBhDQo+IG1l Y2hhbmlzbSBmb3IgdGhlIG1vYmlsZSBjYXJyaWVyIHRvIHByb3ZpZGUg4oCcYWxsb3dlZOKAnSAo Tm9uLUNQTkkpIA0KPiBzdWJzY3JpYmVyIGluZm9ybWF0aW9uIHRvIHRoaXJkIHBhcnRpZXMgb3Ig b3RoZXIgaW50ZXJuYWwgc3lzdGVtcy4gVGhlIA0KPiB0aGlyZCBwYXJ0aWVzIGNhbiBpbiB0dXJu IHByb3ZpZGUgY3VzdG9taXplZCBzZXJ2aWNlLCBvciB1c2UgaXQgdG8gDQo+IGJpbGwgdGhlIGN1 c3RvbWVyIG9yIGFsbG93L2Jsb2NrIHNlbGVjdGl2ZSBjb250ZW504oCmLiBUaGlzIA0KPiBoZWFk ZXItZW5yaWNobWVudCBtZXRob2QgaXMgYWxzbyB1c2VkIHdpdGhpbiB0aGUgTW9iaWxlIENhcnJp ZXIgdG8gDQo+IHBhc3MgaW5mb3JtYXRpb24gaW50ZXJuYWxseSBiZXR3ZWVuIHN1Yi1zeXN0ZW1z LCB0aHVzIGtlZXBpbmcgdGhlIA0KPiBpbnRlcm5hbCBzeXN0ZW1zIGxvb3NlbHktY291cGxlZC4g V2l0aCBlbmNyeXB0aW9uLCB0aGUgbW9iaWxlIGNhcnJpZXIgDQo+IGxvc2VzIHRoZSBjYXBhYmls aXR5IHRvIGluY2x1ZGUgYW55IGluZm9ybWF0aW9uIGluIHRoZSBjb250ZW50IGl0c2VsZiANCj4g YXMgaXQgaXMgZW5jcnlwdGVkLCBtYWtpbmcgaXQgaW1wb3NzaWJsZSBmb3IgdGhlIG1vYmlsZSBj YXJyaWVyIHRvIHBhc3Mgb24gdGhlIGluZm9ybWF0aW9uIGluIGFueSBIVFRQIGhlYWRlcnMuDQoN CkEgcmVmZXJlbmNlIHdvdWxkIGJlIGhlbHBmdWwsIHRoYW5rcyENCltCYWRyaV0gUkZDIDcyMzAg YWxsb3dzIG9mIGFkZGl0aW9uIGFuZCB1c2Ugb2YgbmV3IGhlYWRlcnMgaW4gc2VjdGlvbiAzLjIg KDMuMi4xIHNwZWNpZmljYWxseSkuIEluaXRpYWxseSBjdXN0b20gaGVhZGVycyBwcmVwZW5kZWQg dGhlIHZhbHVlICJ4LSIgdG8gdGhlIGhlYWRlciBuYW1lLiBFdmVuIHRob3VnaCB0aGlzIHByYWN0 aWNlIHdhcyBkZXByZWNhdGVkIGluIFJGQyA2NjQ4LCB0aGVzZSBoZWFkZXIgYXJlIHN0aWxsIHdp ZGVseSB1c2VkIHRvIG1haW50YWluIHN1cHBvcnQgZm9yIGxlZ2FjeSBzeXN0ZW1zLiBUaGUgcGFw ZXIgIkhlYWRlciBFbnJpY2htZW50IG9yIElTUCBFbnJpY2htZW50PyIgKGh0dHBzOi8vd3d3Lmlj aXIub3JnL3Zlcm4vcGFwZXJzL2hlYWRlci1lbnJpY2htZW50LWhvdG1pZGRsZTE1LnBkZikgdGFs a3MgYWJvdXQgdGhlIHVzZSBvZiB0aGlzIGZlYXR1cmUgYWNyb3NzIGRpZmZlcmVudCBNb2JpbGUg Q2FycmllcnMuIFRoaXMgcGFwZXIgYWxzbyBnZXRzIGludG8gdGhlIHZ1bG5lcmFiaWxpdHkgb2Yg dXNpbmcgdGhpcyBtZWNoYW5pc20sIGlmIGN1c3RvbWVyIHByaXZhY3kgaW5mb3JtYXRpb24gaXMg c2VudCBvdmVyIHRoZSBpbnRlcm5ldC4gDQoNCj4NCj4gNC4gICAgICAgSFRUUCBSZWRpcmVjdGlv biDigJMgQXMgb2YgdG9kYXkgdGhlIE1vYmlsZSBDYXJyaWVyIHdvdWxkIG5lZWQgdG8NCj4gYmxv Y2sgb3IgcmVkaXJlY3QgYSBjdXN0b21lciBmb3IgbXVsdGlwbGUgcmVhc29ucw0KDQo+DQo+IGEu ICAgICAgIFRoZSBjdXN0b21lciBtYXkgbm90IGJlIGFsbG93ZWQgdG8gdmlldyB0aGUgY29udGVu dCBkdWUgdG8gcGFyZW50YWwNCj4gY29udHJvbHMuDQoNCk9LLCBzbyB5b3UgaGF2ZSB0aGUgaW5m b3JtYXRpb24gdG8gYmxvY2ssIGJ1dCBubyBhYmlsaXR5IHRvIHJlZGlyZWN0IGluIHRoaXMgY2Fz ZS4NCg0KW0JhZHJpXSBZZXMsIHRoYXQgdGhlIGV4YWN0bHkgdGhlIHNjZW5hcmlvLiBUaGUgbW9i aWxlIHByb3ZpZGVyIGhhcyB0aGUgZGVzdGluYXRpb24gZG9tYWluL0lQIEFkZHJlc3MgZnJvbSB0 aGUgQ3VzdG9tZXIgcmVxdWVzdCBhbmQgaWRlbnRpZmllcyB0aGlzIGRvbWFpbiBhcyBhIGJsb2Nr ZWQgZG9tYWluIHVuZGVyIFBhcmVudGFsIGNvbnRyb2wuDQoNCj4NCj4gYi4gICAgICBUaGUgY3Vz dG9tZXIgIG1heSBub3QgYmUgYWxsb3dlZCB0byB2aWV3IHRoZSBjb250ZW50IGFzIHRoZXkgaGF2 ZQ0KPiBub3QgcHVyY2hhc2VkIHRoZSBjb250ZW50Lg0KDQpXb3VsZG4ndCB0aGlzIGJlIGEgc2Vy dmVyLXNpZGUgZGVjaXNpb24gYW55d2F5PyAgSW4gdGhhdCBjYXNlLCBUTFMgbWFrZXMgbm8gZGlm ZmVyZW5jZS4NCltCYWRyaV0gVGhlIHBhcnRpY3VsYXIgc2NlbmFyaW8gSSB3YXMgcmVmZXJyaW5n IHRvIGlzIHdoZXJlIHRoZSBjdXN0b21lciBpcyBjaGFyZ2VkIGJ5IHRoZSBNb2JpbGUgQ2Fycmll ciBvbiBiZWhhbGYgb2YgdGhlIGNvbnRlbnQgcHJvdmlkZXIuIEFzIGFuIGV4YW1wbGUgYSBjdXN0 b21lciBidXlzIGEgc3RyZWFtaW5nIHNlcnZpY2UgZnJvbSB0aGUgbW9iaWxlIHByb3ZpZGVyLCB3 aGljaCBhbGxvd3MgdGhlIGN1c3RvbWVyIHRvIHN0cmVhbSB2aWRlbyBjb250ZW50IGZyb20gdGhl IHZpZGVvIHByb3ZpZGVyLiBUaGUgY3VzdG9tZXIgZ2V0cyBhIHNpbmdsZSBiaWxsIGZyb20gdGhl IE1vYmlsZSBwcm92aWRlciwgYW5kIHRoZSBNb2JpbGUgcHJvdmlkZXIgaGFzIGEgcmV2LXNoYXJl IG1vZGVsIHdpdGggdGhlIHZpZGVvIHByb3ZpZGVyLiBUaGlzIGlzIG1ldGhvZCBpcyB1c2VkIGJ5 IE1vYmlsZSBwcm92aWRlcnMgYW5kIGNvbnRlbnQgcGFydG5lcnMgdG8gcHJvbW90ZSBlYWNoIG90 aGVyIGFuZCBpbiByZXR1cm4gdGhlIGN1c3RvbWVyIGdldCB0aGUgY29udmVuaWVuY2Ugb2Ygb25l IGJpbGwgYXMgY29tcGFyZWQgdG8gZGlmZmVyZW50IGJpbGwgZnJvbSBlYWNoIGNvbnRlbnQgcGFy dG5lci4NCj4NCj4gYy4gICAgICAgVGhlIGN1c3RvbWVyIG1heSBub3QgYmUgYWxsb3dlZCBhcyB0 aGV5IGhhdmUgcmVhY2hlZCB0aGVpciB1c2FnZQ0KPiBsaW1pdCBhbmQgbmVlZCB0byBidXkgYWRk aXRpb25hbCBkYXRhLg0KPg0KPiBDdXJyZW50bHksIHRoZSBNb2JpbGUgY2FycmllciByZWRpcmVj dHMgdGhlIGN1c3RvbWVyIHVzaW5nIEhUVFAgDQo+IHJlZGlyZWN0IHRvIGEgcGFnZSB3aGljaCBl ZHVjYXRlcyB0aGUgY3VzdG9tZXIgb24gdGhlIHJlYXNvbiBmb3IgdGhlIA0KPiBibG9ja2FnZSBh bmQgcHJvdmlkZSBzdGVwcyB0byBwcm9jZWVkLiBPbmNlIHRoZSBjb250ZW50IGlzIGVuY3J5cHRl ZCwgDQo+IHRoZSBNb2JpbGUgY2FycmllciBsb3NlcyB0aGUgb3B0aW9uIHRvIHJlZGlyZWN0IHRo ZSB0cmFmZmljIGFuZCB0aGUgDQo+IG9ubHkgb3B0aW9uIGJlaW5nIHRvIGJsb2NrIHRoZSBjdXN0 b21lciwgZm9yIGFsbCBzY2VuYXJpb3MuIFRoaXMgd291bGQgDQo+IG5vdCBvbmx5IGNhdXNlIGJh ZCBjdXN0b21lciBleHBlcmllbmNlLCBidXQgd291bGQgYWxzbyBuZWVkIGFub3RoZXIgDQo+IHdh eSB0byBwYXNzIG9uIHRoZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHRvIHRoZSBjdXN0b21lciDi gJMgdGV4dCANCj4gbWVzc2FnZS4gSWYgZm9yIGFueSByZWFzb24sIHRoZSBjdXN0b21lciBpcyBu b3QgYWJsZSB0byBmaW5kIHRoZSANCj4gaW5mb3JtYXRpb24sIGhlL3NoZSB3b3VsZCBoYXZlIHRv IGNhbGwgY3VzdG9tZXIgY2FyZSB0byBmaW5kIG91dCB0aGUgDQo+IHJlYXNvbi4gVGhpcyBpcyBu b3Qgb25seSBhbiBpbmNvbnZlbmllbmNlIHRvIHRoZSBjdXN0b21lciwgYnV0IGFsc28gYW4gb3Zl cmhlYWQgdG8gdGhlIHNlcnZpY2UgcHJvdmlkZXIuDQo+DQo+DQoNClRoaXMgaXMgcmVhc29uYWJs ZSB0byBhZGQuICBEbyB5b3UgaGF2ZSBhIHJlZmVyZW5jZSB3ZSBjYW4gY2l0ZSBvbiB0aGUgcHJh Y3RpY2VzPw0KW0JhZHJpXSBUaGVzZSBhcmUgcHJhY3RpY2VzIHRoYXQgaGF2ZSBiZWVuIGZvbGxv d2VkIGluIHRoZSBpbmR1c3RyeSwgYnV0IGRvbuKAmXQga25vdyBpZiB0aGV5IGhhdmUgYmVlbiBw dWJsaXNoZWQgYW55d2hlcmUuIEkgd2lsbCBjaGVjayBhbmQgZ2V0IGJhY2sgdG8geW91Lg0KDQpU aGFuayB5b3UhDQpLYXRobGVlbg0KPg0KPiAgICAgICAgICAgICAgICAgUGxlYXNlIGZlZWwgZnJl ZSB0byBnZXQgYmFjayB0byBtZSBpZiB5b3UgaGF2ZSBhbnkgDQo+IHF1ZXN0aW9ucy4NCj4NCj4N Cj4NCg0KPiBUaGFua3MsDQo+DQo+IEJhZHJpDQo+DQo+IFJlbGlhbmNlIEppbw0KPg0KPg0KPiAi Q29uZmlkZW50aWFsaXR5IFdhcm5pbmc6IFRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSANCj4gaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50KHMpLCBhcmUgDQo+IGNvbmZpZGVudGlhbCBhbmQgbWF5IGJlIHByaXZpbGVnZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCANCj4gcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3Rp ZmllZCB0aGF0IGFueSByZXZpZXcsIHJlLXRyYW5zbWlzc2lvbiwgDQo+IGNvbnZlcnNpb24gdG8g aGFyZCBjb3B5LCBjb3B5aW5nLCBjaXJjdWxhdGlvbiBvciBvdGhlciB1c2Ugb2YgdGhpcyANCj4g bWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlv dSBhcmUgbm90IHRoZSANCj4gaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgaW1tZWRpYXRlbHkgYnkgcmV0dXJuIA0KPiBlbWFpbCBhbmQgZGVsZXRlIHRoaXMgbWVz c2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGZyb20geW91ciBzeXN0ZW0uDQo+DQo+IFZpcnVzIFdh cm5pbmc6IEFsdGhvdWdoIHRoZSBjb21wYW55IGhhcyB0YWtlbiByZWFzb25hYmxlIHByZWNhdXRp b25zIA0KPiB0byBlbnN1cmUgbm8gdmlydXNlcyBhcmUgcHJlc2VudCBpbiB0aGlzIGVtYWlsLiBU aGUgY29tcGFueSBjYW5ub3QgDQo+IGFjY2VwdCByZXNwb25zaWJpbGl0eSBmb3IgYW55IGxvc3Mg b3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIA0KPiB0aGlzIGVtYWlsIG9yIGF0dGFj aG1lbnQuIg0KDQoNCg0KLS0gDQoNCkJlc3QgcmVnYXJkcywNCkthdGhsZWVuDQoNCiJDb25maWRl bnRpYWxpdHkgV2FybmluZzogVGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGlu dGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gDQph cmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudC4geW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgDQpy ZXZpZXcuIHJlLXRyYW5zbWlzc2lvbi4gY29udmVyc2lvbiB0byBoYXJkIGNvcHkuIGNvcHlpbmcu IGNpcmN1bGF0aW9uIG9yIG90aGVyIHVzZSBvZiB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2ht ZW50cyBpcyANCnN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQuIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSByZXR1 cm4gZW1haWwuIA0KYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBm cm9tIHlvdXIgc3lzdGVtLg0KDQpWaXJ1cyBXYXJuaW5nOiBBbHRob3VnaCB0aGUgY29tcGFueSBo YXMgdGFrZW4gcmVhc29uYWJsZSBwcmVjYXV0aW9ucyB0byBlbnN1cmUgbm8gdmlydXNlcyBhcmUg cHJlc2VudCBpbiB0aGlzIGVtYWlsLiANClRoZSBjb21wYW55IGNhbm5vdCBhY2NlcHQgcmVzcG9u c2liaWxpdHkgZm9yIGFueSBsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gdGhlIHVzZSBvZiB0 aGlzIGVtYWlsIG9yIGF0dGFjaG1lbnQuIgo= From nobody Mon Mar 13 07:38:27 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903E012967A for ; Mon, 13 Mar 2017 07:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ENaHrCPUJWgE for ; Mon, 13 Mar 2017 07:38:24 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 F067E129470 for ; Mon, 13 Mar 2017 07:38:23 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id g6so85044901ioj.1 for ; Mon, 13 Mar 2017 07:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=K7SsgYvEqYZfZLTqVWMETcyv4r4m0vAqkiZcF5ZlXn4=; b=TOktlvzkGZMFym0BjHcRSiqtpLaywknI9LGfCi7zE9g2b69B/Bk4ga3RlqoKyQarMe lVKVSsTxLF9t9NJLMv3t3rTYXKFszAwBFtkQ2UWW427yF1HB0ki639x+deBLbsAVpyzl 9/nr5Qb15HftGb1zRRzbY+o1XMMPtG1kIfZSqRkb96pe4Iv86OA72en1D6Lp8g9aWKoC fYE6OuokwbqoHD18STyO/hbhZwKSmkGlTkc9el+9V0vAsVK0Gjk9arEZHu++9yr1XyzJ t4WMponm5s1BRL44fJ9XpN3F5Lzbq2pbCFs8Q6OP5Qd3Uf/fiij6sgPKgswwvDqbP8T/ JXUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=K7SsgYvEqYZfZLTqVWMETcyv4r4m0vAqkiZcF5ZlXn4=; b=Y08pJBxMjt1A0WdUUULoBTg4PduxiAkOZyOB9+TGKDidDErnq877gmqPt5tbgqgGc5 7tb3tUeiDfK4hVNo+9lvuQgoI7kgW02iDzldlnd7JEGotQZ+FjtHzF5jXVherh913YAl iCHSu8U9egrhPfPTEnKYzgD3Q0cQh3zyGeW/SJQfa+kRHCE2BYwnixpJN+VYYPN/t4YT wH1VVOod6UmwjVYzIzAeGLPSv4v9AYZjpGjqL7mlFw9qHolRxQBCTfRk7WAmLQDj6cr0 2cAJyBxxbwDiFCHNkbDRk/QtsVlUPEj3iVDZorgQIB657niByB/QBUmBpjhDGV0CtKfk meTw== X-Gm-Message-State: AMke39mKJ+Zbb+pjOnSPduRc5zE4SKejKH5whdXNVOQLxfHceFlGsn+5ueb3wfvDWr/L+BbkOQh0tD5m/pUVvA== X-Received: by 10.107.135.136 with SMTP id r8mr27137518ioi.36.1489415903045; Mon, 13 Mar 2017 07:38:23 -0700 (PDT) MIME-Version: 1.0 Sender: sharon.goldbe@gmail.com Received: by 10.107.141.197 with HTTP; Mon, 13 Mar 2017 07:37:42 -0700 (PDT) From: Sharon Goldberg Date: Mon, 13 Mar 2017 10:37:42 -0400 X-Google-Sender-Auth: 2gHm9Y70_51e_uAycagC_ADdjTI Message-ID: To: saag@ietf.org Content-Type: multipart/alternative; boundary=001a113ec77cd2ef36054a9da930 Archived-At: Subject: [saag] new draft specifying VRFs (verifiable random functions) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 14:38:25 -0000 --001a113ec77cd2ef36054a9da930 Content-Type: text/plain; charset=UTF-8 Several of us have been working a draft specification for Verifiable Random Functions (VRFs). A VRF is the public-key version of a keyed cryptographic hash function. Only the holder of the private VRF key can compute the hash, but anyone with the corresponding public key can verify the correctness of the hash. This draft has one VRF based on RSA, and another based on elliptic curves. https://datatracker.ietf.org/doc/draft-goldbe-vrf/ Our team is using a VRF to prevent zone enumeration with NSEC5 for DNSSEC [1,2]. The Google Key Transparency project is using a similar VRF to prevent key enumeration [3,4]. Open Whisper systems has also specified a similar VRF [5]. We think VRFs will be useful for other applications as well, so it would be helpful to have a standard way to implement them. We've requested an agenda slot at SAAG to talk about VRFs. The chairs have requested that we send out a note to SAAG and CFRG ahead of time, and direct discussion to CFRG, if possible. Here's the note on CFRG: https://mailarchive.ietf.org/arch/msg/cfrg/J-8YlvX2e4Z0NEb2_g3uIRKoj6I Hope to chat in person at IETF and/or on list. Thanks, Sharon (with Dimitris Papadopoulos, Jan Vcelak, Leonid Reyzin, Shumon Huque, David C Lawrence) [1] https://datatracker.ietf.org/doc/draft-vcelak-nsec5/ [2] https://gitlab.labs.nic.cz/knot/nsec5-crypto [3] https://security.googleblog.com/2017/01/security-through-transparency. html [4] https://github.com/google/keytransparency/blob/master/core/vrf/vrf.go [5] https://whispersystems.org/docs/specifications/xeddsa/ --- Sharon Goldberg Associate Professor, Computer Science, Boston University Sloan Research Fellow http://www.cs.bu.edu/~goldbe --001a113ec77cd2ef36054a9da930 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Several of us have been working a draft specification for Verifiable= Random Functions (VRFs). A VRF is the public-key version of a keyed crypto= graphic hash function.=C2=A0 Only the holder of the private VRF key can com= pute the hash, but anyone with the corresponding public key can verify the = correctness of the hash. =C2=A0 This draft has one VRF based on RSA, and an= other based on elliptic curves.
=C2=A0

Our team is using a VRF t= o prevent zone enumeration with NSEC5 for DNSSEC [1,2]. The Google Key Tran= sparency project is using a similar VRF to prevent key enumeration [3,4]. O= pen Whisper systems has also specified a similar VRF [5]. =C2=A0 We think V= RFs will be useful for other applications as well, so it would be helpful t= o have a standard way to implement them.

We've requested an agenda = slot at SAAG to talk about VRFs.=C2=A0 The chairs have requested that we se= nd out a note to SAAG and CFRG ahead of time, and direct=C2=A0discussion to CFRG, if possible. Here's the=C2=A0= note on CFRG:

https://maila= rchive.ietf.org/arch/msg/cfrg/J-8YlvX2e4Z0NEb2_g3uIRKoj6I

Hope to chat in person at IETF and/or on list.

Thanks,=

Sharon
(with Dimitris Papadopoulo= s, Jan Vcelak,=C2=A0Leonid Reyzin, Shumon Huque, David C Lawrence)


---
Sharon Goldberg
Associate Professor= , Computer Science, Boston University
= Sloan Research Fellow
http://www.cs.bu.edu/~goldbe
--001a113ec77cd2ef36054a9da930-- From nobody Mon Mar 13 09:24:03 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9ED129505 for ; Mon, 13 Mar 2017 09:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 IDKXFW7HXcNo for ; Mon, 13 Mar 2017 09:24:00 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04760129504 for ; Mon, 13 Mar 2017 09:23:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 90A77BE3E for ; Mon, 13 Mar 2017 16:23:57 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96mOpqDQrokC for ; Mon, 13 Mar 2017 16:23:57 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 04D1FBE2E for ; Mon, 13 Mar 2017 16:23:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1489422237; bh=Q3XORgxH7JUNCS7BTIzcoaoR675+ebn92/FISkYDtlI=; h=Subject:References:To:From:Date:In-Reply-To:From; b=K0OQlVB58xU4uls05OV/HD6x88YREpCVEyVLIIGudb/JpC9vjLCjD11ss7qKZnEvh fPR78dC0UwNJBRJFQgx9O6rzIEDAJiNu7gnP2jFOnUCd2AfoHjAgDhxhtpKZDAW58W Z8aPor1M6Pcbel1BY/eeWEIKW8jrXhB0UPisL8sA= References: <974141142.88826.1489421412806.JavaMail.cfmx@127.0.0.1> To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <974141142.88826.1489421412806.JavaMail.cfmx@127.0.0.1> Message-ID: <706cc7e2-a670-a739-c1d4-7a314b9fd7c2@cs.tcd.ie> Date: Mon, 13 Mar 2017 16:23:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <974141142.88826.1489421412806.JavaMail.cfmx@127.0.0.1> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4JQH9Juv6lgAuItuW3rVTraQkddHGnQ19" Archived-At: Subject: [saag] Fwd: Cybersecurity and digital privacy newsletter update - 13/03/2017 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 16:24:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4JQH9Juv6lgAuItuW3rVTraQkddHGnQ19 Content-Type: multipart/mixed; boundary="w7Qdngqq6UDKkhsSdASgB1gLWhVLx3Rmu"; protected-headers="v1" From: Stephen Farrell To: "saag@ietf.org" Message-ID: <706cc7e2-a670-a739-c1d4-7a314b9fd7c2@cs.tcd.ie> Subject: Fwd: Cybersecurity and digital privacy newsletter update - 13/03/2017 References: <974141142.88826.1489421412806.JavaMail.cfmx@127.0.0.1> In-Reply-To: <974141142.88826.1489421412806.JavaMail.cfmx@127.0.0.1> --w7Qdngqq6UDKkhsSdASgB1gLWhVLx3Rmu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI, those of you interested in ENISA might want to check out the review link below and give feedback. Two notes: 1. Apologies for making you view the large number of occurrences of cyberFOO in all this;-) 2. I don't have further information about the review of ENISA, so there's no point asking me, but if anyone does know more about this, it might be good to reply here. Cheers, S. -------- Forwarded Message -------- Subject: Cybersecurity and digital privacy newsletter update - 13/03/201= 7 Date: Mon, 13 Mar 2017 17:10:12 +0100 From: CNECT-CYBERSECURITY@ec.europa.eu Reply-To: CNECT-CYBERSECURITY@ec.europa.eu To: CNECT-CYBERSECURITY@ec.europa.eu If you have trouble reading this e-mail read the online version . ISSN : 2467-4311 European Commission Cybersecurity and digital privacy Newsletter *Follow us on twitter* icon Twitter News Reminder: Public consultation on the evaluation and review of the European Union Agency for Network and Information Security (ENISA) ENISA is the Agency of the European Union tasked with contributing to the enhancement of the overall level of cybersecurity of the EU and its Member States. This consultation kicks off the review of ENISA, whose current mandate will come to an end in 2020. The European Commission welcomes the views of all interested stakeholders on ENISA's past performances, as well as on a possible revision of its mandate in view of new challenges the EU faces in the cybersecurity field. The consultation is open until 12 April 2017. Read more... See also : Online questionnaire Contact : CNECT-FEEDBACK-ENISA@EC.EUROPA.EU visual reminder New cooperation in support of Cyber Security in Aviation The European Aviation Safety Agency and the Computer Emergency Response Team (CERT-EU) of the EU Institutions signed on 10 February 2017 a Memorandum of Cooperation with a view to the establishment of a European Centre for Cyber Security in Aviation (ECCSA). Read more... logo of EASA Studies and reports ENISA Threat Landscape 2016 report: cyber-threats becoming top priority The European Union Agency for Network and Information Security(ENISA) has published the "Threat Landscape 2016". The report summarises the top cyber threats encountered in 2016. This year is characterised by numerous serious cyber-incidents which have dominated the news. Main objectives of malicious activities detected were monetization and political impact. Read more... logo of the report Calendar *16 March 2017 * - Brussels Functional safety and cybersecurity - CEN/CENELEC's Stakeholder Engagement Workshop Cybersecurity is becoming relevant to all industry sectors not just the =E2=80=98natively digital=E2=80=99, but also traditional industries as th= ey digitally transform their processes, systems and supply chains. While this shift opens up opportunities, it also creates threats to operational safety, robustness and resilience. CEN and CENELEC will engage industry to define their standardization needs for functional safety and digital protection of their processes, systems and data. Read more... logo of the workshop *27 March 2017 * - Brussels, Avenue de Beaulieu 25 Workshop on the security and incident notification requirements for Digital Service Providers (DSPs) under the NIS Directive In line with the recently adopted Network and Information Systems (NIS) Directive, important digital businesses ("digital service providers") will be required to take appropriate security measures and to notify incidents to the competent national authority. To specify further the elements and parameters related to security and notification requirements, the Commission is empowered to adopt an implementing act. The workshop will serve as a forum for interested stakeholders from the private sector and the Commission to discuss and exchange views on the possible content of this implementing act. Read more... Projects news & results Small European cybersecurity companies capitalise on an expanding market with EU support The threat from cybercriminals shows no sign of abating, opening up opportunities for European companies to develop new tools to fight against threats =E2=80=93 and win a greater share of one of the fastest g= rowing markets in the IT sector. Read more... See also : Call for proposals: SMEInst-13-2016-2017: Engaging SMEs in security research and development The ReCRED project =E2=80=93 a solution to password overload ReCRED aims at "Killing the password" by combining biometrics, behavioural characteristics and innovative cryptographic techniques. Furthermore, connecting all online accounts under the same physical identity allows citizens to use specific attributes for accountless access while retaining their anonymity. ReCRED is co-funded by the Horizon H2020 Framework Programme. Read more... See also : Article on the project: "You could be tracked by your payment-enabled phone" Logo of the project This is the newsletter of the Cybersecurity & Digital Privacy unit at the European Commission. It is hosted by the Digital Agenda for Europe Newsroom . If this Newsletter was forwarded to you and you are interested to receive it directly you can subscribe here . You may unsubscribe or broaden your subscription from this newsletter by going to Your Profile or by contacting us at this address: CNECT-CYBERSECURITY@ec.europa.eu . --w7Qdngqq6UDKkhsSdASgB1gLWhVLx3Rmu-- --4JQH9Juv6lgAuItuW3rVTraQkddHGnQ19 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYxsecAAoJEC88hzaAX42iz58H/jSDwiafHl6KV2ZNBpEk4rvO mA9WV6GuFtovbl+7ISNvTMDHdNBgHM+UW/f6sLIjRaGV+fyJTUmbEqK4nZICkY0D mCnm9tQ+0YqBlxQm7P4AaKy0Ob5E1RjDltYudZtPZ1NRcDUaGnSDmySZD4JP5dQx AK0XLoz6hQl68TqmESpsaQw7N2e/l5seA8EgmydI3+dFbOueRVIzWmNVL3RHiFDo a8nm9bt64WhhbUbBr4lvgP5pTcaHElnVYnONHRNA/JBktqkXochBO1sIr7SBjEcw lsRc1BJCNqXCLm27htOTCIuvctkH1ceSMxdRcfwzHCN4ZYYa1Tub+9J+uUb7CpU= =M/iU -----END PGP SIGNATURE----- --4JQH9Juv6lgAuItuW3rVTraQkddHGnQ19-- From nobody Tue Mar 14 15:01:54 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589AC129B70; Tue, 14 Mar 2017 15:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.997 X-Spam-Level: X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 kUCsGoTtN7sD; Tue, 14 Mar 2017 15:01:51 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 CDEB5129B1D; Tue, 14 Mar 2017 15:01:50 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v2ELtGCZ012331; Tue, 14 Mar 2017 18:01:41 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 296r1k1f3n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 14 Mar 2017 18:01:41 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v2EM1dPk012995; Tue, 14 Mar 2017 18:01:40 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v2EM1Uhi012750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Mar 2017 18:01:31 -0400 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 14 Mar 2017 22:01:19 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v2EM1JMD016954; Tue, 14 Mar 2017 17:01:19 -0500 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v2EM1FOB016441; Tue, 14 Mar 2017 17:01:16 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-blue.research.att.com (Postfix) with ESMTP id CD7C0F052C; Tue, 14 Mar 2017 18:01:14 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 18:01:14 -0400 From: "MORTON, ALFRED C (AL)" To: "Badri.Subramanyan@ril.com" , "kathleen.moriarty.ietf@gmail.com" , "saag@ietf.org" , "ietf@ietf.org" Thread-Topic: Last call feedback: draft-mm-wg-effect-encrypt Thread-Index: AQHSmEkg/clGABfaOEacwArHo1mOHqGMUL1AgAD0g4CAB6IkUA== Date: Tue, 14 Mar 2017 22:01:14 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25F3252D@njmtexg5.research.att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.246.164] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-14_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703140168 Archived-At: Subject: Re: [saag] Last call feedback: draft-mm-wg-effect-encrypt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:01:52 -0000 SGkgQmFkcmksDQpvbmUgZm9sbG93LXVwIHF1ZXN0aW9uIGJlbG93Og0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJhZHJpLlN1YnJhbWFueWFuQHJpbC5jb20gW21haWx0 bzpCYWRyaS5TdWJyYW1hbnlhbkByaWwuY29tXQ0KPiBTZW50OiBGcmlkYXksIE1hcmNoIDEwLCAy MDE3IDI6MzUgQU0NCg0KPHNuaXA+DQoNCj4gPiBJZiB0aGUgc3RyZWFtcyBhcmUgZW5jcnlwdGVk LCB0aGVuIHRoZSBBTEcgZmVhdHVyZSB3b3VsZCBiZSByZW5kZXJlZA0KPiANCj4gPiB1c2VsZXNz LiBUaGlzIHdvdWxkIGxpbWl0IHRoZSBjYXBhYmlsaXR5IG9mIGFueSBuZXR3b3JrIGVsZW1lbnQg dG8NCj4gDQo+ID4gbWFrZSBzbWFydCBwb2xpY2luZyBhbmQgcm91dGluZyBkZWNpc2lvbnMgYmFz ZWQgb24gYXBwbGljYXRpb24gbGF5ZXINCj4gYXR0cmlidXRlcy4NCj4gDQo+IA0KPiBLYXRobGVl biB3cm90ZToNCj4gRG8geW91IGtub3cgaWYgdGhlc2UgY2FuIHdvcmsgd2l0aCBhIDItdHVwbGUg b3IgNS10dXBsZT8gIElzIHRoZXJlIGFuDQo+IGltcGFjdCBmcm9tIGVuY3J5cHRpb24gdmlhIFRM UyBmb3IgaW5zdGFuY2U/ICBJZiBzbywgd2hhdCBpcyB0aGF0DQo+IGltcGFjdD8NCj4gDQo+IFtC YWRyaV0gVGhlIHJ1bGVzIGluIG1vc3Qgb2YgdGhlIGNhc2VzIGlzIDUtdHVwbGUgdG8gYWNjdXJh dGVseSBkZXBpY3QgYQ0KPiBmbG93LiBZZXMsIHRoZXJlIGlzIGFuIGltcGFjdCBmcm9tIGVuY3J5 cHRpb24gdmlhIFRMUyBhcyBtb3N0IG9mIHRoZQ0KPiBpbXBsZW1lbnRhdGlvbnMgb2YgQUxHIGdl dCBpbmZvcm1hdGlvbiByZWdhcmRpbmcgc3VwcG9ydGluZyBwcm90b2NvbHMgYnkNCj4gcGFyc2lu ZyBkYXRhLiBXaXRoIFRMUyBlbmNyeXB0aW9uLCB0aGUgQUxHIGxvc2VzIHRoZSBhYmlsaXR5IHRv IHBhcnNlLA0KPiBoZW5jZSBnZXQgaW5mb3JtYXRpb24gb24gdGhlIHN1cHBvcnRpbmcgcHJvdG9j b2xzLg0KPiANCj4gDQo+IEthdGhsZWVuIHdyb3RlOg0KPiBXaGF0IGlzIHVzZWQgYnkgQUxHIHRv IGNvcnJlbGF0ZSBzdHJlYW1zPyAgVGhpcyB3b3VsZCBiZSBoZWxwZnVsIHRvDQo+IHVuZGVyc3Rh bmQgaWYgdGhpcyBwYXJ0aWN1bGFyIG1ldGhvZCBmb3IgQUxHcyBkb2VzIGJlY29tZSAndXNlbGVz cycNCj4gYW5kIGFsc28gdG8gZmlndXJlIG91dCBpZiBvdGhlciBvcHRpb25zIG1heSBleGlzdCB0 byBwZXJmb3JtIHRoZQ0KPiBmdW5jdGlvbnMgbmVlZGVkLg0KPiANCj4gW0JhZHJpXSBSRkMgMjY2 MywgU2VjdGlvbiAyLjkgZ2l2ZXMgaW5mb3JtYXRpb24gYWJvdXQgQUxHLiBUaGVyZSBpc27igJl0 DQo+IG9uZSBkZWZpbmVkIG1ldGhvZCB0byBpbXBsZW1lbnQgaXQgYW5kIHNvbWUgb2YgdGhlIG1l dGhvZHMgdXNlZCBieQ0KPiB2ZW5kb3JzIGFyZSBpbmNsdWRlZCBiZWxvdy4NCj4gDQo+IDEuICBQ YXJzZSB0aGUgY29udGVudCBvZiB0aGUgcHJpbWFyeSBzdHJlYW0gYW5kIGlkZW50aWZ5IHRoZSA1 LXR1cGxlIG9mDQo+IHRoZSBzdXBwb3J0aW5nIHN0cmVhbXMgYXMgaXQgaXMgYmVpbmcgbmVnb3Rp YXRlZC4NCj4gDQo+IDIuIEludGVyY2VwdCBhbmQgbW9kaWZ5IHRoZSA1LXR1cGxlIGluZm9ybWF0 aW9uIG9mIHRoZSBzdXBwb3J0aW5nIHN0cmVhbQ0KPiBhcyB0aGUgaXQgaXMgYmVpbmcgbmVnb3Rp YXRlZCBvbiB0aGUgcHJpbWFyeSBzdHJlYW0uIFRoaXMgaXMgYSBsaXR0bGUNCj4gbW9yZSBpbnRy dXNpdmUgaW4gbmF0dXJlLg0KPiANCj4gDQpbQUNNXSANCkFmdGVyIFNyYyZEc3QgQWRkcmVzcyBh bmQgUG9ydCwgd2hhdCBpcyB0aGUgNXRoIEVsZW1lbnQNCm9mIHRoZSA1LXR1cGxlIGluIHlvdXIg ZXhwZXJpZW5jZT8NCg0KUHJvdG9jb2wgbnVtYmVyIGFuZCBQYWNrZXQgUHJpb3JpdHkgTWFya2lu ZyAoRFNDUCkgYXJlIHR3byBjYW5kaWRhdGVzLi4uDQoNCmxldCB1cyBrbm93LCB0aGFua3MhDQpB bA0KDQo= From nobody Tue Mar 14 16:18:23 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4854131627 for ; Tue, 14 Mar 2017 16:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 7OFhXGgClNgO for ; Tue, 14 Mar 2017 16:18:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B10D13162E for ; Tue, 14 Mar 2017 16:18:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CF6E0BE80 for ; Tue, 14 Mar 2017 23:18:16 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbMpuwuF-Qda for ; Tue, 14 Mar 2017 23:18:14 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 62971BE5D for ; Tue, 14 Mar 2017 23:18:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1489533494; bh=9cAGc70mkiCsMwrgP+OG32AChCCu+TTIAlsA2R6aBe4=; h=Subject:References:To:From:Date:In-Reply-To:From; b=SL4Exbo5wwaxogoTrvHt8Sjhs8ejhhMr8uyfsnHjhFnJ+ja9AyEql30iuyiVV6J3w 2dG0kOpc8cnRY8NKBWfGrPOwPgptYYnPpPL5Kk5ljPSdEwr68Ut19OvOA7kAph6mQE 2a7bXq2qJwtHv5qCgrYFdMUhIhCFuTbXXqkFI3aA= References: To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: Message-ID: Date: Tue, 14 Mar 2017 23:18:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wm4lEgWNNIQLgK0855r8wJL8clwIgd0eS" Archived-At: Subject: [saag] Fwd: Good but not-quite-trivial change in auth-48 for draft-harkins-owe X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 23:18:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wm4lEgWNNIQLgK0855r8wJL8clwIgd0eS Content-Type: multipart/mixed; boundary="jgxvqpvaIsqe7opwkKcnjmDQVr0UaFJ3q"; protected-headers="v1" From: Stephen Farrell To: "saag@ietf.org" Message-ID: Subject: Fwd: Good but not-quite-trivial change in auth-48 for draft-harkins-owe References: In-Reply-To: --jgxvqpvaIsqe7opwkKcnjmDQVr0UaFJ3q Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI -------- Forwarded Message -------- Subject: Good but not-quite-trivial change in auth-48 for draft-harkins-o= we Date: Tue, 14 Mar 2017 20:52:17 +0000 From: Stephen Farrell To: IETF-Discussion CC: Jouni Malinen Hiya, This draft [1] is currently paused in auth-48 as one of the authors (Dan) just got some implementer feedback (Many thanks Jouni!) that a clarification is needed. The proposed change is to add a table explicitly calling out how derived keys are to be used in the protocol. The proposed NEW text is below (with an easier to view diff at [2]) and Dan tells me that the content of the table is about the only sensible choice and would almost be obvious, but is much better being explicit. I don't think myself that that change requires us to go back to IETF last call but I've asked the RFC editor folks to pause processing of the draft for a week or so while we check that this change doesn't cause any problems. If you do think that this change or handling the change this way is problematic please let me or the IESG know (or just reply to this;-) and we can see how best to handle things. If there are no problems I'll ask the RFC editor to ok that change in a week (on Tuesday 21st). Cheers, S. [1] https://datatracker.ietf.org/doc/draft-harkins-owe/ [2] https://tools.ietf.org/rfcdiff?url1=3Dhttp://www.lounge.org/rfc-ed-8110-o= rig.txt&url2=3Dhttp://www.lounge.org/rfc-ed-8110.txt NEW TEXT to be added to section 4.4: +---------+--------------+----------+-------+------------+----------+ | Hash | Integrity | KCK_bits | Size | Key-wrap | KEK_bits | | | Algorithm | | of | Algorithm | | | | | | MIC | | | +---------+--------------+----------+-------+------------+----------+ | SHA-256 | HMAC-SHA-256 | 128 | 16 | NIST AES | 128 | | | | | | Key-wrap | | | SHA-384 | HMAC-SHA-384 | 192 | 24 | NIST AES | 256 | | | | | | Key-wrap | | | SHA-512 | HMAC-SHA-512 | 256 | 32 | NIST AES | 256 | | | | | | Key-wrap | | +---------+--------------+----------+-------+------------+----------+ Table 2: Integrity and Key Wrap Algorithms Upon completion of 802.11 association, the AP initiates the 4-way handshake to the client using the PMK generated above. The 4-way handshake generates a key-encrypting key (KEK), a key-confirmation key (KCK), a message integrity code (MIC), to use for protection of the frames that define the 4-way handshake. The algorithms and key lengths used in the 4-way handshake depend on the hash algorithm selected in Section 4.1 and are listed in Table 2. --jgxvqpvaIsqe7opwkKcnjmDQVr0UaFJ3q-- --wm4lEgWNNIQLgK0855r8wJL8clwIgd0eS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYyHo2AAoJEC88hzaAX42iyqEIAKJ+PEp3GUfy8/Xz4RvzUteq 3k63XVf7tPgWDFG631Uu8a9j8iGns+zKDjPZCwjA+wpOcJax6icoVuBrUs5uWbpA q5BUSTDo/Ld/Y/Y2zC8XStoCLtAGYes3kiIIBzm8pHbqyB5UD7j/25yKFqujrTSc EW0XnqBKpqPPfT7ZmDC89DH0y3EsCBQmVFODAyreo84jiTp6tFQpNVjrFql5vVtl UquTVm1F15OnbNeqa+lqkbnZnvlVDt8zkGPgsCKJ0oGTeJtBFoOjj6PykkB2/UzH sh0vHhm7Yp6Ku/o0t/i8KBy0jDb3bkmDpMCw4loenvzTVtxlk4EdYvY4+rlhZsg= =5VLt -----END PGP SIGNATURE----- --wm4lEgWNNIQLgK0855r8wJL8clwIgd0eS-- From nobody Wed Mar 15 04:20:25 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4293A129BBB; Wed, 15 Mar 2017 04:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 k1FTI_iZjwsj; Wed, 15 Mar 2017 04:20:22 -0700 (PDT) Received: from gwsmtp010.ril.com (unknown [203.199.41.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866FB129BAB; Wed, 15 Mar 2017 04:20:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.36,168,1486405800"; d="scan'208";a="378324604" From: To: , , , Thread-Topic: Last call feedback: draft-mm-wg-effect-encrypt Thread-Index: AQHSmEkdymufh+be8EG0ggEJbV3WwqGMUL1AgAD0g4CAB0r5AIABOrxA Date: Wed, 15 Mar 2017 11:20:11 +0000 Message-ID: <0d728d3f894c4d0a9f16bd6a21088818@SIDC1EXMBX24.in.ril.com> References: <4D7F4AD313D3FC43A053B309F97543CF25F3252D@njmtexg5.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25F3252D@njmtexg5.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [saag] Last call feedback: draft-mm-wg-effect-encrypt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 11:20:24 -0000 QWwsDQoNCglJbiBteSBleHBlcmllbmNlLCBwcm90b2NvbCBoYXMgYmVlbiB0aGUgNXRoIHR1cGxl IGFsb25nIHdpdGggU291cmNlIGFuZCBEZXN0aW5hdGlvbiBJUCBhZGRyZXNzIGFuZCBwb3J0cy4N Cg0KVGhhbmtzLA0KQmFkcmkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1P UlRPTiwgQUxGUkVEIEMgKEFMKSBbbWFpbHRvOmFjbW9ydG9uQGF0dC5jb21dIA0KU2VudDogVHVl c2RheSwgTWFyY2ggMTQsIDIwMTcgNTowMSBQTQ0KVG86IEJhZHJpIFN1YnJhbWFueWFuIDxCYWRy aS5TdWJyYW1hbnlhbkByaWwuY29tPjsga2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb207 IHNhYWdAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmcNCkNjOiBzdGVwaGVuLmZhcnJlbGxAY3MudGNk LmllDQpTdWJqZWN0OiBSRTogTGFzdCBjYWxsIGZlZWRiYWNrOiBkcmFmdC1tbS13Zy1lZmZlY3Qt ZW5jcnlwdA0KDQpIaSBCYWRyaSwNCm9uZSBmb2xsb3ctdXAgcXVlc3Rpb24gYmVsb3c6DQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmFkcmkuU3VicmFtYW55YW5Acmls LmNvbSBbbWFpbHRvOkJhZHJpLlN1YnJhbWFueWFuQHJpbC5jb21dDQo+IFNlbnQ6IEZyaWRheSwg TWFyY2ggMTAsIDIwMTcgMjozNSBBTQ0KDQo8c25pcD4NCg0KPiA+IElmIHRoZSBzdHJlYW1zIGFy ZSBlbmNyeXB0ZWQsIHRoZW4gdGhlIEFMRyBmZWF0dXJlIHdvdWxkIGJlIHJlbmRlcmVkDQo+IA0K PiA+IHVzZWxlc3MuIFRoaXMgd291bGQgbGltaXQgdGhlIGNhcGFiaWxpdHkgb2YgYW55IG5ldHdv cmsgZWxlbWVudCB0bw0KPiANCj4gPiBtYWtlIHNtYXJ0IHBvbGljaW5nIGFuZCByb3V0aW5nIGRl Y2lzaW9ucyBiYXNlZCBvbiBhcHBsaWNhdGlvbiBsYXllcg0KPiBhdHRyaWJ1dGVzLg0KPiANCj4g DQo+IEthdGhsZWVuIHdyb3RlOg0KPiBEbyB5b3Uga25vdyBpZiB0aGVzZSBjYW4gd29yayB3aXRo IGEgMi10dXBsZSBvciA1LXR1cGxlPyAgSXMgdGhlcmUgYW4gDQo+IGltcGFjdCBmcm9tIGVuY3J5 cHRpb24gdmlhIFRMUyBmb3IgaW5zdGFuY2U/ICBJZiBzbywgd2hhdCBpcyB0aGF0IA0KPiBpbXBh Y3Q/DQo+IA0KPiBbQmFkcmldIFRoZSBydWxlcyBpbiBtb3N0IG9mIHRoZSBjYXNlcyBpcyA1LXR1 cGxlIHRvIGFjY3VyYXRlbHkgZGVwaWN0IA0KPiBhIGZsb3cuIFllcywgdGhlcmUgaXMgYW4gaW1w YWN0IGZyb20gZW5jcnlwdGlvbiB2aWEgVExTIGFzIG1vc3Qgb2YgdGhlIA0KPiBpbXBsZW1lbnRh dGlvbnMgb2YgQUxHIGdldCBpbmZvcm1hdGlvbiByZWdhcmRpbmcgc3VwcG9ydGluZyBwcm90b2Nv bHMgDQo+IGJ5IHBhcnNpbmcgZGF0YS4gV2l0aCBUTFMgZW5jcnlwdGlvbiwgdGhlIEFMRyBsb3Nl cyB0aGUgYWJpbGl0eSB0byANCj4gcGFyc2UsIGhlbmNlIGdldCBpbmZvcm1hdGlvbiBvbiB0aGUg c3VwcG9ydGluZyBwcm90b2NvbHMuDQo+IA0KPiANCj4gS2F0aGxlZW4gd3JvdGU6DQo+IFdoYXQg aXMgdXNlZCBieSBBTEcgdG8gY29ycmVsYXRlIHN0cmVhbXM/ICBUaGlzIHdvdWxkIGJlIGhlbHBm dWwgdG8gDQo+IHVuZGVyc3RhbmQgaWYgdGhpcyBwYXJ0aWN1bGFyIG1ldGhvZCBmb3IgQUxHcyBk b2VzIGJlY29tZSAndXNlbGVzcycNCj4gYW5kIGFsc28gdG8gZmlndXJlIG91dCBpZiBvdGhlciBv cHRpb25zIG1heSBleGlzdCB0byBwZXJmb3JtIHRoZSANCj4gZnVuY3Rpb25zIG5lZWRlZC4NCj4g DQo+IFtCYWRyaV0gUkZDIDI2NjMsIFNlY3Rpb24gMi45IGdpdmVzIGluZm9ybWF0aW9uIGFib3V0 IEFMRy4gVGhlcmUgaXNu4oCZdCANCj4gb25lIGRlZmluZWQgbWV0aG9kIHRvIGltcGxlbWVudCBp dCBhbmQgc29tZSBvZiB0aGUgbWV0aG9kcyB1c2VkIGJ5IA0KPiB2ZW5kb3JzIGFyZSBpbmNsdWRl ZCBiZWxvdy4NCj4gDQo+IDEuICBQYXJzZSB0aGUgY29udGVudCBvZiB0aGUgcHJpbWFyeSBzdHJl YW0gYW5kIGlkZW50aWZ5IHRoZSA1LXR1cGxlIA0KPiBvZiB0aGUgc3VwcG9ydGluZyBzdHJlYW1z IGFzIGl0IGlzIGJlaW5nIG5lZ290aWF0ZWQuDQo+IA0KPiAyLiBJbnRlcmNlcHQgYW5kIG1vZGlm eSB0aGUgNS10dXBsZSBpbmZvcm1hdGlvbiBvZiB0aGUgc3VwcG9ydGluZyANCj4gc3RyZWFtIGFz IHRoZSBpdCBpcyBiZWluZyBuZWdvdGlhdGVkIG9uIHRoZSBwcmltYXJ5IHN0cmVhbS4gVGhpcyBp cyBhIA0KPiBsaXR0bGUgbW9yZSBpbnRydXNpdmUgaW4gbmF0dXJlLg0KPiANCj4gDQpbQUNNXQ0K QWZ0ZXIgU3JjJkRzdCBBZGRyZXNzIGFuZCBQb3J0LCB3aGF0IGlzIHRoZSA1dGggRWxlbWVudCBv ZiB0aGUgNS10dXBsZSBpbiB5b3VyIGV4cGVyaWVuY2U/DQoNClByb3RvY29sIG51bWJlciBhbmQg UGFja2V0IFByaW9yaXR5IE1hcmtpbmcgKERTQ1ApIGFyZSB0d28gY2FuZGlkYXRlcy4uLg0KDQps ZXQgdXMga25vdywgdGhhbmtzIQ0KQWwNCg0KIkNvbmZpZGVudGlhbGl0eSBXYXJuaW5nOiBUaGlz IG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgaW50ZW5kZWQgb25seSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiANCmFyZSBjb25maWRlbnRpYWwgYW5kIG1h eSBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiB5 b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSANCnJldmlldy4gcmUtdHJhbnNtaXNzaW9u LiBjb252ZXJzaW9uIHRvIGhhcmQgY29weS4gY29weWluZy4gY2lyY3VsYXRpb24gb3Igb3RoZXIg dXNlIG9mIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIA0Kc3RyaWN0bHkgcHJv aGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IHJldHVybiBlbWFpbC4gDQphbmQgZGVsZXRl IHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGZyb20geW91ciBzeXN0ZW0uDQoNClZp cnVzIFdhcm5pbmc6IEFsdGhvdWdoIHRoZSBjb21wYW55IGhhcyB0YWtlbiByZWFzb25hYmxlIHBy ZWNhdXRpb25zIHRvIGVuc3VyZSBubyB2aXJ1c2VzIGFyZSBwcmVzZW50IGluIHRoaXMgZW1haWwu IA0KVGhlIGNvbXBhbnkgY2Fubm90IGFjY2VwdCByZXNwb25zaWJpbGl0eSBmb3IgYW55IGxvc3Mg b3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoaXMgZW1haWwgb3IgYXR0YWNobWVu dC4iCg== From nobody Wed Mar 15 17:51:20 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8CD12E852 for ; Wed, 15 Mar 2017 17:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 czohhFX3jYos for ; Wed, 15 Mar 2017 17:51:16 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 44C1B129C68 for ; Wed, 15 Mar 2017 17:51:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 26CC7B76; Thu, 16 Mar 2017 00:51:15 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZO1UufotLs2v; Thu, 16 Mar 2017 00:51:15 +0000 (UTC) Received: from [192.168.1.174] (c-98-238-4-39.hsd1.fl.comcast.net [98.238.4.39]) by mail.networkradius.com (Postfix) with ESMTPSA id 8A6A86DB; Thu, 16 Mar 2017 00:51:14 +0000 (UTC) From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <84ED66AD-2ED0-4AD0-8AEA-50D566BCFAA2@deployingradius.com> Date: Wed, 15 Mar 2017 20:51:13 -0400 To: Security Area Advisory Group , draft-bchv-rfc6890bis@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [saag] Secdir review of draft-bchv-rfc6890bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 00:51:18 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. The document is Ready. This document updates IANA registries, and has minimal possible = security issues which can be discussed.= From nobody Tue Mar 21 09:30:48 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEFC129B9A for ; Tue, 21 Mar 2017 09:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Tlpcro-Ujc9Q for ; Tue, 21 Mar 2017 09:30:44 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (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 D18B6129BA4 for ; Tue, 21 Mar 2017 09:30:31 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id i1so155005928ota.3 for ; Tue, 21 Mar 2017 09:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to; bh=spg1ppQb1wNXdh8dRznTjyt6RHFLyPDkqOiBYaR/wxM=; b=XSQqZQPAL2yxap5qO8XJsKF455EMnIV1L6UV/djIxbHVCG1tvjwk5cc6707HG3wSth XX9opbc5sXjL8lrM/kEM6kexcCIjPq5cBMAdF36jg0rbKLeJB+6Rt3X3WbLpwnsgr+sH zUcDALE3SSv6sOnGDIGkNYF29Oc5+XKUjlryNBKUM4GJMHLHYzHYI+k2/4wQeZqqgt7K JymaYZG4P2B9u58nwVSJdyYSIckx+vU/TzikFC+2E5rl1RhT7YEGjN1XDt6DK0aS1JEP bQ8b/k3Knap4Tkx5S7kOqUxFbg+TgHG2BDxTxqxu4k8M6nhknix3dcmV/HENOG0ihaFH 86DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=spg1ppQb1wNXdh8dRznTjyt6RHFLyPDkqOiBYaR/wxM=; b=XYEde43q11YPWxo7Fzu0DoiRNgdQLlo8mB0UfwkC/y43uwZGGY+51SfwW+K7NTKeRh wbhVm0M1lyNEaMSl6CzJc9AeQ37lrR/hCRi6bY8go6ixpN4IlcXhwBpM7HDWX4KddYYy rq4bOR3Xa3ix6reWteN1sxvMb4kE8a5vzxRmeGYZK3SR46AyU45/SbPKXgoEOVXtD55u GhSl3l0lABCDI7GQ2mtYStqd/bUoQQhlSYoPZ/ipd1EtASf8Ry9mE4SAPFVc+xjfnR3+ yO/Tx8vLNrN6vLa6Ow+kLuIniZpmuaXme/yYDtZCKAo6WPq4Qnl0fruvwwmkwTLTRJ4N J5Mw== X-Gm-Message-State: AFeK/H0Tu5QBnYqc96WGh7f9JR43WHWtuvvmvaYpDB+xcusSx9LoGqxMTSp7VIVneisTkH8KUd+mj4v+Ramorw== X-Received: by 10.157.20.151 with SMTP id d23mr18728516ote.37.1490113831167; Tue, 21 Mar 2017 09:30:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.31.131 with HTTP; Tue, 21 Mar 2017 09:30:30 -0700 (PDT) Reply-To: noloader@gmail.com From: Jeffrey Walton Date: Tue, 21 Mar 2017 12:30:30 -0400 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] Security Controls for Interception proxies outbound connections? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 16:30:46 -0000 Hi Everyone, US Cert recently released TA17-075A, "HTTPS Interception Weakens TLS Security", https://www.us-cert.gov/ncas/alerts/TA17-075A. It seems to be a restatement of Jarmoc's "SSL Interception Proxies and Transitive Trust", https://media.blackhat.com/bh-eu-12/Jarmoc/bh-eu-12-Jarmoc-SSL_TLS_Interception-Slides.pdf. What security controls are available to contain the threats related to the proxy's outbound connection? Does the IETF offer anything? Jeff From nobody Wed Mar 22 08:15:02 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9FC129492 for ; Wed, 22 Mar 2017 08:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 OLgK3K79J9rI for ; Wed, 22 Mar 2017 08:14:58 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 7BD1E126C22 for ; Wed, 22 Mar 2017 08:14:58 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id d188so127307326vka.0 for ; Wed, 22 Mar 2017 08:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hK530WMAATVpiLvlHWpo88SMDT8afx474dwh2Wn2BTk=; b=QSGm/Xr+HAEggd6tBKEgZSnLBdY9W/P5nsgupgWB6r0ewTHynWOwg9axoj1/mLJCNN Ub+emhthy8phjL0sUtsJ3jq6Zr8xjv41wdpm0HmqyOOnxYzRDC6PtFVomvTqTNlyn/H3 1roK7rSPFvLZFRhRwFy3ulG7gckYTNiumxD/FTyQOi2ajWkHQUD7gY4Etpjsmocr72ks QnFEkQ+XXnCViR1582koAmbHfFxIBXtAoNDg2w6/ilcxcohKSTUaNEkD5lEOVf/tcLjo zZ4WNk+tAvLtY6aK50hx1SeH6C659+7soXzOsFn13wHmAv1oGL8gAtPD588D9BcC57dw Gorg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hK530WMAATVpiLvlHWpo88SMDT8afx474dwh2Wn2BTk=; b=f0I1qyLQvS6pPm79VwMfh7YWVdksEw+6kUbNo1r2+CpoYF4D2lvScJj921GbcuUF4L qtwcS8toskT8+/AZtVCH9qK1SsMXbNch26jzO7N4XGQZjXniaH4nxasq3Rqv/pEPlLJ0 9L0SZrUkQFqU78jcsDMGDLpFmMwHlAryVTiD1uM3c+8FsN+1bD1AOnqp4of0zbiOALPU 6KZWnVnV0WpkZubBwaB1UkR6EAltwebb+jaVHzimARPTLRIPXjSGb0o313cGjXqMAd9B CpFGt0cIfY2BEqqtf/79ig0FoNUSX7nHfonKHZI4YLn+yhZxKl0nbanPbeDaSVa86qYC N8ug== X-Gm-Message-State: AFeK/H0WCMroTngnb7bLd/ZX54PTLX5I7I1lcSYbDTmaZ4BeXM6s0z/2Rfdeg7+zge6vzeNbPJAxKVSjE7UH1Qop X-Received: by 10.31.110.138 with SMTP id j132mr13237788vkc.103.1490195697311; Wed, 22 Mar 2017 08:14:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.174.73 with HTTP; Wed, 22 Mar 2017 08:14:56 -0700 (PDT) In-Reply-To: References: <22519.43588.421250.807948@fireball.acr.fi> From: Ben Laurie Date: Wed, 22 Mar 2017 15:14:56 +0000 Message-ID: To: Yoav Nir Cc: Tero Kivinen , Security Area Advisory Group Content-Type: multipart/alternative; boundary=94eb2c14a23a2f8354054b533901 Archived-At: Subject: Re: [saag] Possible backdoor in RFC 5114 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 15:15:00 -0000 --94eb2c14a23a2f8354054b533901 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7 October 2016 at 16:56, Yoav Nir wrote: > > > On 7 Oct 2016, at 16:59, Tero Kivinen wrote: > > > > Stephen Farrell writes: > >> > >> So I'm not seeing anyone so far argue to not > >> deprecate these somehow. > >> > >> We could just make 5114 historic as Yoav suggests, > >> or, if someone writes an I-D to explain why, we > >> could obsolete 5114. (Such an I-D would presumably > >> also say something about codepoints that point at > >> 5114 from other registries.) > >> > >> Assuming nobody shows up saying these are in > >> fact in widespread use I'd be supportive of us > >> getting rid of cruft. > > > > I think the NIST ECP groups are quite widely supportd, and used. > > RFC5114 includes both Nist ECP Groups (192, 224, 256, 384 and 521) and > > 3 MODP groups. > > > > In IPsec, ECP groups are widely used, those MODP groups with subgroup > > are not. On the other hand I think only those 192, 256 and 521 bit > > groups are really used, and those are defined also in RFC5903 (which > > obsoleted original 4753 which had serious bug in it). > > > First, I think you meant 256, 384 and 521 bit, not the 192. > > Second, 5114 did not fix the bug in 4753. It just referenced 4753 for > formatting. You know this better than I do, but I don=E2=80=99t think the= IANA > registry ever referenced 5114 for these ECP groups. > > So for the three useful groups in 5114 you didn=E2=80=99t need it (as 475= 3) > already existed, and you don=E2=80=99t need it now, as 5903 exists. I don= =E2=80=99t see > anything standing in the way of moving to historic or obsoleting it. > Possibly I missed something here: why should we be any happier about 5903 than we are about 5114? --94eb2c14a23a2f8354054b533901 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 7 October 2016 at 16:56, Yoav Nir <ynir.ietf@gmail.com> wrote:

> On 7 Oct 2016, at 16:59, Tero Kivinen <kivinen@iki.fi> wrote:
>
> Stephen Farrell writes:
>>
>> So I'm not seeing anyone so far argue to not
>> deprecate these somehow.
>>
>> We could just make 5114 historic as Yoav suggests,
>> or, if someone writes an I-D to explain why, we
>> could obsolete 5114. (Such an I-D would presumably
>> also say something about codepoints that point at
>> 5114 from other registries.)
>>
>> Assuming nobody shows up saying these are in
>> fact in widespread use I'd be supportive of us
>> getting rid of cruft.
>
> I think the NIST ECP groups are quite widely supportd, and used= .
> RFC5114 includes both Nist ECP Groups (192, 224, 256,= 384 and 521) and
> 3 MODP groups.
>
> In IPsec, ECP groups are widely used, those MODP groups with subgroup<= br> > are not. On the other hand I think only those 192, 256 and 521 bit
> groups are really used, and those are defined also in RFC5903 (which > obsoleted original 4753 which had serious bug in it).


First, I think you meant 256, 384 and 521 bit, not the 192.

Second, 5114 did not fix the bug in 4753. It just referenced 4753 for forma= tting. You know this better than I do, but I don=E2=80=99t think the IANA r= egistry ever referenced 5114 for these ECP groups.

So for the three useful groups in 5114 you didn=E2=80=99t need it (as 4753)= already existed, and you don=E2=80=99t need it now, as 5903 exists. I don= =E2=80=99t see anything standing in the way of moving to historic or obsole= ting it.

Possibly I missed something he= re: why should we be any happier about 5903 than we are about 5114?

--94eb2c14a23a2f8354054b533901-- From nobody Wed Mar 22 11:20:07 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DF712986E for ; Wed, 22 Mar 2017 11:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Q-s88e6t2rjw for ; Wed, 22 Mar 2017 11:20:03 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 CA187129477 for ; Wed, 22 Mar 2017 11:20:03 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id 21so78225740pgg.1 for ; Wed, 22 Mar 2017 11:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BqrOL+NUUuG4xKPfwvC0JZrXFqSRgfQtWc4B65u89Jo=; b=nCSix0XepgeIB4hISuTJyIbGTUEASjigwz4tRX0hgYcxef/Bl+Nq24RbWjj0Q42dE6 JjaIAQDOaWNSwS/b34xklzHw+ULXoXPMZrReCwk3gSH4wbc47dg4mP64YReo4I8JLPXk uP8574JXeIGMjPHgl4QaaJDnV40Gn1EsB0zlIMzPsE6ZrNoYxilBTcSMTZIKPePclhsY GfW4oAFtIxIZwv16fEdjZs72CI0bhBe3Gk6qqVMpFUV8AtEWPBzT/KRJxD3T+8mwTcKx L8YIP/0nvAeiS+6mSFGT5Lpqwy8YSwd05865R380EXm5LS7WAnR8ZX7tn76stG1yLUve 68NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BqrOL+NUUuG4xKPfwvC0JZrXFqSRgfQtWc4B65u89Jo=; b=Kzu61/G2n68w76qW3VD7fjyjfZgEUD5+ZywB7qeOS1fJ1a3izLl42305N28UtnJQap Y74AMUKE258uXcVtPD7Aq3YUPTlpoYbIEKdWkfbpeAoVfslU3UVwbgK7DV2tYbb1XTmg RulWocRb8DhOsEEcjpxfmKmNXKSGv8EkuGAMAc/gR/EGW5tjeK3jShWjuKIB78AFj/9n GOyIXmX/xYQLdmaic7hPh8PV8wkerxl7B+KAF4q9boKRX4pik2JLXGlONJkVAsOx0vvx YqLGILh81dbMwa0u3Nzv8s9iIboMrQc0QD0oczCWkwAMq20LUeBvNh4YAuNg7BQWje1r dM1g== X-Gm-Message-State: AFeK/H0teDZPwu0nHD+/ApmhqNCXQXkH/7UuCA9XzieFMmaG/3XXroNiUxb1Br0uNvvI7ZdRNvfP1fXTcTeMWw== X-Received: by 10.98.13.16 with SMTP id v16mr47756764pfi.38.1490206803394; Wed, 22 Mar 2017 11:20:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.169.165 with HTTP; Wed, 22 Mar 2017 11:20:02 -0700 (PDT) Received: by 10.100.169.165 with HTTP; Wed, 22 Mar 2017 11:20:02 -0700 (PDT) In-Reply-To: References: <22519.43588.421250.807948@fireball.acr.fi> From: Watson Ladd Date: Wed, 22 Mar 2017 11:20:02 -0700 Message-ID: To: Ben Laurie Cc: Yoav Nir , saag@ietf.org, Tero Kivinen Content-Type: multipart/alternative; boundary=001a11467c72288578054b55cf44 Archived-At: Subject: Re: [saag] Possible backdoor in RFC 5114 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 18:20:06 -0000 --001a11467c72288578054b55cf44 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mar 22, 2017 8:15 AM, "Ben Laurie" wrote: On 7 October 2016 at 16:56, Yoav Nir wrote: > > > On 7 Oct 2016, at 16:59, Tero Kivinen wrote: > > > > Stephen Farrell writes: > >> > >> So I'm not seeing anyone so far argue to not > >> deprecate these somehow. > >> > >> We could just make 5114 historic as Yoav suggests, > >> or, if someone writes an I-D to explain why, we > >> could obsolete 5114. (Such an I-D would presumably > >> also say something about codepoints that point at > >> 5114 from other registries.) > >> > >> Assuming nobody shows up saying these are in > >> fact in widespread use I'd be supportive of us > >> getting rid of cruft. > > > > I think the NIST ECP groups are quite widely supportd, and used. > > RFC5114 includes both Nist ECP Groups (192, 224, 256, 384 and 521) and > > 3 MODP groups. > > > > In IPsec, ECP groups are widely used, those MODP groups with subgroup > > are not. On the other hand I think only those 192, 256 and 521 bit > > groups are really used, and those are defined also in RFC5903 (which > > obsoleted original 4753 which had serious bug in it). > > > First, I think you meant 256, 384 and 521 bit, not the 192. > > Second, 5114 did not fix the bug in 4753. It just referenced 4753 for > formatting. You know this better than I do, but I don=E2=80=99t think the= IANA > registry ever referenced 5114 for these ECP groups. > > So for the three useful groups in 5114 you didn=E2=80=99t need it (as 475= 3) > already existed, and you don=E2=80=99t need it now, as 5903 exists. I don= =E2=80=99t see > anything standing in the way of moving to historic or obsoleting it. > Possibly I missed something here: why should we be any happier about 5903 than we are about 5114? Can you prepare a backdoored elliptic curve that passes all acceptence critera? The reason not to use 5114 is that one can construct moduli with hidden SNFS structure. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --001a11467c72288578054b55cf44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 22, 2017 8:15 AM, "Ben Laurie" <benl@google.com> wrote:

=
On 7 October 2016= at 16:56, Yoav Nir <ynir.ietf@gmail.com> wrote:

> On 7 Oct 2016, at 16:59, Tero Kivinen <kivinen@iki.fi> wrote:
>
> Stephen Farrell writes:
>>
>> So I'm not seeing anyone so far argue to not
>> deprecate these somehow.
>>
>> We could just make 5114 historic as Yoav suggests,
>> or, if someone writes an I-D to explain why, we
>> could obsolete 5114. (Such an I-D would presumably
>> also say something about codepoints that point at
>> 5114 from other registries.)
>>
>> Assuming nobody shows up saying these are in
>> fact in widespread use I'd be supportive of us
>> getting rid of cruft.
>
> I think the NIST ECP groups are quite widely supportd, and used= .
> RFC5114 includes both Nist ECP Groups (192, 224, 256, 384 and 52= 1) and
> 3 MODP groups.
>
> In IPsec, ECP groups are widely used, those MODP groups with subgroup<= br> > are not. On the other hand I think only those 192, 256 and 521 bit
> groups are really used, and those are defined also in RFC5903 (which > obsoleted original 4753 which had serious bug in it).


First, I think you meant 256, 384 and 521 bit, not the 192.

Second, 5114 did not fix the bug in 4753. It just referenced 4753 for forma= tting. You know this better than I do, but I don=E2=80=99t think the IANA r= egistry ever referenced 5114 for these ECP groups.

So for the three useful groups in 5114 you didn=E2=80=99t need it (as 4753)= already existed, and you don=E2=80=99t need it now, as 5903 exists. I don= =E2=80=99t see anything standing in the way of moving to historic or obsole= ting it.

Possibly I missed someth= ing here: why should we be any happier about 5903 than we are about 5114?

=
Can you prepare a backdoored elliptic curve that pa= sses all acceptence critera?

The reason not to use 5114 is that one can construct moduli with hidde= n SNFS structure.

<= br>

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag


--001a11467c72288578054b55cf44-- From nobody Fri Mar 24 01:08:31 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B16E129C62 for ; Fri, 24 Mar 2017 01:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 80PofVqk4SNa for ; Fri, 24 Mar 2017 01:08:27 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 791E0129C5F for ; Fri, 24 Mar 2017 01:08:27 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id p64so5211123qke.1 for ; Fri, 24 Mar 2017 01:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=4UGlUPlQI3ua5nG2spLMjyn0qe4DRF01uaO9pnRXaQo=; b=H9z4ana/19v9yD911IEBrO41aI0PzG1yxhNccZSR1Dx5KNYvgt53SuyA6aPPLd61ax 9pnE6Uo2V2UjSFyxAIjFVIp+s79yogw9qJ8GKaWDhL2PgO2SCGMZJ84093EO11VNDNog SDMtgxdY2rlvJ53zMhyaQSf6naLbsdtuTACwEjoqB/kk2X1lvOowYk859N1fFSsYm+On m88sYT6bngqpUvEkV2ES3MOrh0Gr+DFO/oSxcbpIfqWW4dYNYq8xYqkSzBCvPOinw/Qo 14RpqLN1kbfMoB52UxN9QXS4oJTWkR6mCzzUckcl1B0ccL83TcS+0+pijKDkp3jfALBx iidg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=4UGlUPlQI3ua5nG2spLMjyn0qe4DRF01uaO9pnRXaQo=; b=dQp6tIurstd/vEKWEBQdEY7kDAAPg1JrRnCvu8w6BWl0lQXBCoDq8OHjhAG8F28FtF 9+6oUdlN8L1NZ+JfKfvwXO7vPBbX88Es8inLxYqTTOhRVmQZMR738+aOmiwl/RnZhc7R G6XuiaMKwsp3h6iEj6H2ZVeE488IyXO/fxHKsDoM2n8b86Pf+MuwFoUjAeCloYzrQPYk Ez1Z78JZc/SYtEMxzFcgJESi/rHn5X5XVU/6hbx4xA9NKLtYRNQAdVN1C/svfOOfyhl2 eYEvaWH4TAZL61T6CEVci3Z7Q4R+4kfzhB3CQ03VCme932FtL14Cxx8OkmnLrpPAs+WD vM5w== X-Gm-Message-State: AFeK/H1PWxhr7j6fOZVY2sr80eZEL5Grgftv5mtuw1vyTfgKH3n2pTiSK/PLOYGcdVt6+Bbj1JeyB7fLxuIlJw== X-Received: by 10.55.78.88 with SMTP id c85mr6830941qkb.52.1490342906665; Fri, 24 Mar 2017 01:08:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.175.216 with HTTP; Fri, 24 Mar 2017 01:07:46 -0700 (PDT) From: Nikos Mavrogiannopoulos Date: Fri, 24 Mar 2017 09:07:46 +0100 Message-ID: To: IETF SAAG Cc: Kathleen.Moriarty@emc.com, mnystrom@microsoft.com, bkaliski@verisign.com Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] encrypted files with UTF-8/16 passwords X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 08:08:29 -0000 Hi, PKCS#8 (rfc8018) and PKCS#12 (rfc7292) can be used to encrypt keys and certificates with a password. In the first case, PKCS#8 utilizes PKCS#5 for converting a password to an encryption key, and PKCS#5 requires a password to be in UTF-8. For PKCS#12, a password is input in UTF-16 format (mentioned as BMPString in the document) in some preset schemes, but uses UTF-8 for newer schemes like AES via PKCS#5. However, UTF-8 (and UTF-16) are ambiguous. The same string may have multiple representations, and for that, there are some guidelines in RFC7613 to prepare a unicode string for a password, but they do not update either of these documents. Given that these are informational RFCs, which would be the proper method to propose an update on them based on these lines and requiring RFC7613 processing for passwords entered in UTF-8? regards, Nikos From nobody Fri Mar 24 07:53:58 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95DA124BFA for ; Fri, 24 Mar 2017 07:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.497 X-Spam-Level: X-Spam-Status: No, score=-5.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=Oaa4aNSC; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=WOXW+Wqm 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 Z76hrZ-idLWK for ; Fri, 24 Mar 2017 07:53:55 -0700 (PDT) Received: from esa3.dell-outbound.iphmx.com (esa3.dell-outbound.iphmx.com [68.232.153.94]) (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 DAFF71270A0 for ; Fri, 24 Mar 2017 07:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1490367226; x=1521903226; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=o+xGff8NTfoOusfovlALBVhmFjYcjgteMeOLs6Nh3JU=; b=Oaa4aNSC/3mwaTutTRZmhfodRF0rfLpfqWqoLHDkAnCaF5TG3eyNyYvx ILUt5R2HUkA2E+UiJ+EvisZYqfhjEOd8dyA0v0OjYqrlBKcdHm2V/lXYO B4ezzk/hop0lZHkgk5R+lLVNdV+YfBebGGWCeevujZv2d3oypinnm2Opt 4=; Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa3.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Mar 2017 09:53:46 -0500 From: "Moriarty, Kathleen" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Mar 2017 20:48:49 +0600 Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v2OErnQR020176 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Mar 2017 10:53:53 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v2OErnQR020176 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1490367233; bh=TeR9SBB07QS2+7ufApL106Dmr+8=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=WOXW+WqmTqg6P2vjrXMPgNC6RMY0H2rzd4u1VEQh/u/Lq+PrCkDY5nf7VxJlN4T71 dsfBjOFaOvsCmkfBhxnNW4mvuMz61+og/YtvirS/C2qZAn6arSoAibnqIrsOTDagEY r6TIoNJ8liXlqM1bOqFpaI/CZYh1/DxBsoMzX7Dc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v2OErnQR020176 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd54.lss.emc.com (RSA Interceptor); Fri, 24 Mar 2017 10:52:37 -0400 Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com [10.146.3.27]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v2OErVZl027737 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Fri, 24 Mar 2017 10:53:31 -0400 Received: from MX307CL02.corp.emc.com ([fe80::64dd:bdd6:70f5:692a]) by MXHUB301.corp.emc.com ([10.146.3.27]) with mapi id 14.03.0266.001; Fri, 24 Mar 2017 10:53:31 -0400 To: Nikos Mavrogiannopoulos CC: IETF SAAG , "mnystrom@microsoft.com" , "bkaliski@verisign.com" Thread-Topic: encrypted files with UTF-8/16 passwords Thread-Index: AQHSpHXT5LDMXREpjUyMtqFbls3Q/6GkE9+l Date: Fri, 24 Mar 2017 14:53:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [saag] encrypted files with UTF-8/16 passwords X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 14:53:57 -0000 Hi Nikos, They are just informational because they were contributed as existing stand= ards. Change control has been handed over to the IETF, so an update could = happen to make them standards track. Or you could start an updated draft t= o add what you need and we'll figure out if it has to stay informational or= not. Thanks, Kathleen=20 Sent from my iPhone > On Mar 24, 2017, at 4:08 AM, Nikos Mavrogiannopoulos wrote: >=20 > Hi, > PKCS#8 (rfc8018) and PKCS#12 (rfc7292) can be used to encrypt keys > and certificates with a password. In the first case, PKCS#8 utilizes > PKCS#5 for converting a password to an encryption key, and PKCS#5 > requires a password to be in UTF-8. For PKCS#12, a password is input > in UTF-16 format (mentioned as BMPString in the document) in some > preset schemes, but uses UTF-8 for newer schemes like AES via PKCS#5. >=20 > However, UTF-8 (and UTF-16) are ambiguous. The same string may have > multiple representations, and for that, there are some guidelines in > RFC7613 to prepare a unicode string for a password, but they do not > update either of these documents. >=20 > Given that these are informational RFCs, which would be the proper > method to propose an update on them based on these lines and requiring > RFC7613 processing for passwords entered in UTF-8? >=20 > regards, > Nikos From nobody Sat Mar 25 08:28:48 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9E712714F; Sat, 25 Mar 2017 08:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 g-Uzz2O2obCC; Sat, 25 Mar 2017 08:28:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8B51270AC; Sat, 25 Mar 2017 08:28:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DDM04523; Sat, 25 Mar 2017 15:28:39 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 25 Mar 2017 15:28:39 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.223]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Sat, 25 Mar 2017 23:28:36 +0800 From: Tianran Zhou To: "saag@ietf.org" , "draft-ietf-opsawg-mud.authors@ietf.org" Thread-Topic: WG LC for draft-ietf-opsawg-mud-05 Thread-Index: AdKe9vAgYqk7rVgYSsewZPAvl6ONiAGhHf4g Date: Sat, 25 Mar 2017 15:28:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.108.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58D68CA7.0262, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.223, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0c4f4cee1a21f268d03cd98894f9ba31 Archived-At: Subject: [saag] FW: WG LC for draft-ietf-opsawg-mud-05 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 15:28:46 -0000 Dear SAAG, This I-D is in OPSAWG LC. I feel it relates to security. I really appreciat= e if there is input from here. Thanks, Tianran -----Original Message----- From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Tianran Zhou Sent: Friday, March 17, 2017 4:18 PM To: opsawg@ietf.org Cc: opsawg-chairs@ietf.org Subject: [OPSAWG] WG LC for draft-ietf-opsawg-mud-05 Dear OPSAWG, This is a notice to start a two-week OPSAWG WG last call for the document: Manufacturer Usage Description Specification https://datatracker.ietf.org/d= oc/draft-ietf-opsawg-mud/ Please read the above draft and send any issues, comments, or corrections t= o this mailing list. Please indicate your support or concerns by Friday March 31, 2017. Thanks, Chairs _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Sat Mar 25 08:39:12 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4586126C26 for ; Sat, 25 Mar 2017 08:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 eWYtld3Wri-6 for ; Sat, 25 Mar 2017 08:39:08 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (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 C5176124BFA for ; Sat, 25 Mar 2017 08:39:07 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 087DC780377 for ; Sat, 25 Mar 2017 16:39:05 +0100 (CET) To: saag@ietf.org References: From: Denis Message-ID: <2069106e-5e72-cf36-63fa-4b50275c1036@free.fr> Date: Sat, 25 Mar 2017 16:39:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FE71B6EE778A5361EFEBE6D7" Archived-At: Subject: [saag] About Token Binding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 15:39:11 -0000 This is a multi-part message in MIME format. --------------FE71B6EE778A5361EFEBE6D7 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I would like to draw your attention, on the fact that the work performed both by the OAuth WG and the Token Binding WG is currently unable to counter a major threat scenario that has been described in an earlier e-mail sent to the OAuth WG as the "ABC attack" or the "Alice and Bob Collusion attack". See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html This threat is not mentioned in RFC 6819 : OAuth 2.0 Threat Model and Security Considerations (2013). Hence, nobody attempted to find a solution ... for a threat that had not been identified. A basic property of the current Token Binding mechanisms being developed by the Token Binding WG is that a specific piece of software voluntarily installed by a client can export any token and perform all the needed computations so that any token can successfully be used by another client. It is _NOT the replay of a token_, since the token is not used at any time by the legitimate owner, but is used by an illegitimate user. As the above link mentions: Whatever kind of cryptographic is being used, when two users collaborate, a software-only solution will be unable to prevent the transfer of an attribute of a user that possess it to another user that does not possess it . The use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key will be ineffective to counter the Alice and Bob collusion attack. Additional properties will be required for the secure element. Hence, any method able to counter the ABC attack requires the *use of secure elements* by the users. The objectives of the Token Binding WG are as follows: The main design objectives for the Token Binding protocol, in no particular order: 1. Allow applications and services to prevent unauthorized replay of security tokens. (...) At the present this objective has not been met and will never be met until some secure element will be used by clients. The HTTP binding mechanism being developed by the Token Binding WG gets more and more complex ... but will be insecure (i. e 'broken') as soon as someone will develop a piece of software able to by-pass it. Many people believe that it is "impossible" to counter this threat/attack and thus, since it is "impossible", a mechanism unable to address this issue is equal in terms of security to another mechanism unable to solve this issue (!). Another key point is that none of the techniques mentioned hereafter is able to counter the ABC attack, i.e. the transmission and then the use of an access token legitimately obtained by a user to another user, as soon as they agree to cooperate : · U-Prove from Microsoft, · Identity Mixer (Idemix) from IBM, · the IRMA Project (which is a combination of the *use of a smart card *and of Idemix), and · OpenID Connect. This means in particular that these methods are unable to support an ABAC (Attribute Based Access Control) model. Denis DP Security Consulting SAS. France. --------------FE71B6EE778A5361EFEBE6D7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I would like to draw your attention, on the fact that the work performed both by the OAuth WG and the Token Binding WG is currently
unable to counter a major threat scenario that has been described in an earlier e-mail sent to the OAuth WG as the "ABC attack" or
the "Alice and Bob Collusion attack".

See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html

This threat is not mentioned in RFC 6819 : OAuth 2.0 Threat Model and Security Considerations (2013).
Hence, nobody attempted to find a solution ... for a threat that had not been identified.

A basic property of the current Token Binding mechanisms being developed by the Token Binding WG is that a specific piece of software
voluntarily installed by a client can export any token and perform all the needed computations so that any token can successfully be used
by another client. It is NOT the replay of a token, since the token is not used at any time by the legitimate owner, but is used by an illegitimate
user. As the above link mentions:

Whatever kind of cryptographic is being used, when two users collaborate, a software-only solution
will be unable to prevent the transfer of an attribute of a user that possess it to another user that does not possess it .

The use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key
will be ineffective to counter the Alice and Bob collusion attack. Additional properties will be required for the secure element.

Hence, any method able to counter the ABC attack requires the use of secure elements by the users.

The objectives of the Token Binding WG are as follows:

  The main design objectives for the Token Binding protocol, in no particular order: 
  1. Allow applications and services to prevent unauthorized replay of security tokens. (...)

At the present this objective has not been met and will never be met until some secure element will be used by clients.

The HTTP binding mechanism being developed by the Token Binding WG gets more and more complex ...
but will be insecure (i. e 'broken') as soon as someone will develop a piece of software able to by-pass it.

Many people believe that it is "impossible" to counter this threat/attack and thus, since it is "impossible", a mechanism unable
to address this issue is equal in terms of security to another mechanism unable to solve this issue (!).

Another key point is that none of the techniques mentioned hereafter is able to counter the ABC attack, i.e. the transmission
and then the use of an access token legitimately obtained by a user to another user, as soon as they agree to cooperate :

·    U-Prove from Microsoft,
·    Identity Mixer (Idemix) from IBM,
·    the IRMA Project (which is a combination of the use of a smart card and of Idemix), and
·    OpenID Connect.

This means in particular that these methods are unable to support an ABAC (Attribute Based Access Control) model.
 
Denis

DP Security Consulting SAS. France.

--------------FE71B6EE778A5361EFEBE6D7-- From nobody Sat Mar 25 20:58:10 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CE71294F0 for ; Sat, 25 Mar 2017 20:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 aAGGj0fzZQDa for ; Sat, 25 Mar 2017 20:58:06 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 180C01294EF for ; Sat, 25 Mar 2017 20:58:05 -0700 (PDT) X-AuditID: 12074423-68fff70000002b70-32-58d73c4b9725 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 81.8B.11120.B4C37D85; Sat, 25 Mar 2017 23:58:04 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v2Q3w23I002196; Sat, 25 Mar 2017 23:58:03 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v2Q3vxQP000584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 25 Mar 2017 23:58:01 -0400 Date: Sat, 25 Mar 2017 22:57:59 -0500 From: Benjamin Kaduk To: Denis Cc: saag@ietf.org Message-ID: <20170326035758.GU30306@kduck.kaduk.org> References: <2069106e-5e72-cf36-63fa-4b50275c1036@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2069106e-5e72-cf36-63fa-4b50275c1036@free.fr> User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsUixCmqrOtjcz3C4PoMdov1XXYWU/o7mRyY PPrXfWb1WLLkJ1MAUxSXTUpqTmZZapG+XQJXxrpFH5gL7nJXXGq8y9TAuJOzi5GTQ0LARGLV ycXsXYxcHEICbUwSu04tYAVJCAlsZJQ4ujMFInGVSeJu8wdGkASLgKrE5om3wIrYBFQkGrov M4PYIgJyEqvuXQOzmQUEJXpnvWMCsYUF1CV6d5xlB7F5gbYtv/oLakEjo8Tk7hyIuKDEyZlP WCB6tSRu/HsJ1MsBZEtLLP/HARLmFLCWePBxJdgJogLKEg0zHjBPYBSYhaR7FpLuWQjdCxiZ VzHKpuRW6eYmZuYUpybrFicn5uWlFuma6eVmluilppRuYgSFKLuL8g7Gl33ehxgFOBiVeHgb dl6LEGJNLCuuzD3EKMnBpCTKG3EWKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE95fB9Qgh3pTE yqrUonyYlDQHi5I4r7hGY4SQQHpiSWp2ampBahFMVoaDQ0mCt9EaqFGwKDU9tSItM6cEIc3E wQkynAdoeBlIDW9xQWJucWY6RP4Uo6KUOO97K6CEAEgiozQPrheUQiSy99e8YhQHekWY1xKk nQeYfuC6XwENZgIaPHvDFZDBJYkIKakGxtlxK/dw3nadF5kT836nRI6t48UdLBcvXbWL2BP+ vM2wwW2rUvr2qen5k1JyQy5Espzi2zr3fcKnd2aO98odzi94M/tEbOeP5U9+2nmHJcxQj4tO e/9ZoNRCsCtgFue0zUv+GC1rSKpJ49Q6HV57zVnIVVHzc5PAJMdpx5gdll+dvMw9nl04R4ml OCPRUIu5qDgRAGA9M7j8AgAA Archived-At: Subject: Re: [saag] About Token Binding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 03:58:08 -0000 Hi Denis, On Sat, Mar 25, 2017 at 04:39:06PM +0100, Denis wrote: > > I would like to draw your attention, on the fact that the work performed > both by the OAuth WG and the Token Binding WG is currently > unable to counter a major threat scenario that has been described in an With all due respect, I do not believe that there is consensus to apply the modifier "major" to this threat scenario. > earlier e-mail sent to the OAuth WG as the "ABC attack" or > the "Alice and Bob Collusion attack". > > See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html While it may be the case that the authors and participants of these working groups are interested in desiging protocols that allow non-malicious clients to gain protection for themselves from malicious third parties even though the actual text of the charter permits designing protections against malicious clients, it seems that the proper response may be to reevaluate the charter text and the desired goals from the work and the working group, rather than to insist that this attack be considered and addressed. That is to say, though there are threat models in which the ABC attack is a "real" attack, those are not necessarily the threat models in which people are interested in working, and I do not think there is much support for attempting to force one threat model on other WG participants absent explicit consensus to adopt such a threat model for the scope of some work. -Ben From nobody Mon Mar 27 01:16:56 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A0C129484 for ; Mon, 27 Mar 2017 01:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 JH5EaAPc0vd6 for ; Mon, 27 Mar 2017 01:16:50 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 E64631294A3 for ; Mon, 27 Mar 2017 01:16:49 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id E5D99780333; Mon, 27 Mar 2017 10:16:47 +0200 (CEST) To: Benjamin Kaduk References: <2069106e-5e72-cf36-63fa-4b50275c1036@free.fr> <20170326035758.GU30306@kduck.kaduk.org> Cc: saag@ietf.org From: Denis Message-ID: <1d6be71f-f746-1fa7-d6e6-21d8201cc637@free.fr> Date: Mon, 27 Mar 2017 10:16:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170326035758.GU30306@kduck.kaduk.org> Content-Type: multipart/alternative; boundary="------------90A3B88F7490261E28E961AC" Archived-At: Subject: Re: [saag] About Token Binding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 08:16:55 -0000 This is a multi-part message in MIME format. --------------90A3B88F7490261E28E961AC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Ben, > Hi Denis, > > On Sat, Mar 25, 2017 at 04:39:06PM +0100, Denis wrote: >> I would like to draw your attention, on the fact that the work performed >> both by the OAuth WG and the Token Binding WG is currently >> unable to counter a major threat scenario that has been described in an > With all due respect, I do not believe that there is consensus to > apply the modifier "major" to this threat scenario. This depends of the content of the access token. If the access token contains a sufficient number of attributes able to fully identify one individual in a given context, Bob will disagree to collaborate with Alice because Alice would then be able to impersonate as Bob. On the contrary, if the access token *does not contain *a sufficient number of attributes able to fully identify one individual in a given context, Bob cannot be identified as being the one who got the access token that has been transmitted to Alice and thus Bob is very likely to accept to collaborate with Alice based on the property: "*not seen, not taken*". This is why I said : "This means in particular that these methods [U-Prove, Idemix, the IRMA Project, OpenID Connect and OAuth 2.0] are unable to support an ABAC (*Attribute Based Access Control*) model". Atttribute-based authentication aims to provide a mechanism for precisely doing this: allowing transactions on the basis of those attributes which are required for the transaction. (...) The attribute that is most needed now is probably the minimal-age attribute, like ‘over 18’. Extract from "Credential Design in Attribute-Based Identity Management" available at: https://www.cs.ru.nl/~gergely/objects/TILTing_Alpar-Jacobs_CredentialDesign.pdf If a person over 18 can transmit an access token to anybody under 18 and if this person is then able to use that token, without the server being able to detect that this is a collusion attack, then I consider that this is a *major *problem. This is not only a *major *problem for *OAuth 2.0*, but also a *major *problem for both *U-Prove* and *Idemix*, and as a consequence for the now-closed *ABC4Trust* project. > >> earlier e-mail sent to the OAuth WG as the "ABC attack" or >> the "Alice and Bob Collusion attack". >> >> See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html > While it may be the case that the authors and participants of these > working groups are interested in desiging protocols that allow > non-malicious clients to gain protection for themselves from > malicious third parties even though the actual text of the charter > permits designing protections against malicious clients, it seems > that the proper response may be to reevaluate the charter text and > the desired goals from the work and the working group, rather than > to insist that this attack be considered and addressed. If you have a technique able to counter the ABC attack, then it will also protect users from malicious third parties, while the reverse is not true. > That is to say, though there are threat models in which the ABC attack is a > "real" attack, those are not necessarily the threat models in which > people are interested in working, and I do not think there is much > support for attempting to force one threat model on other WG > participants absent explicit consensus to adopt such a threat model > for the scope of some work. > > -Ben OAuth 2.0 is currently not restricting access tokens to only contain a sufficient set of attributes that allows to fully identify an individual in a given context. Since OAuth 2.0 allows access tokens to contain non-directly identifiable attributes, this is indeed a *major *problem. Denis ====================================================================================================================== Original message: I would like to draw your attention, on the fact that the work performed both by the OAuth WG and the Token Binding WG is currently unable to counter a major threat scenario that has been described in an earlier e-mail sent to the OAuth WG as the "ABC attack" or the "Alice and Bob Collusion attack". See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html This threat is not mentioned in RFC 6819 : OAuth 2.0 Threat Model and Security Considerations (2013). Hence, nobody attempted to find a solution ... for a threat that had not been identified. A basic property of the current Token Binding mechanisms being developed by the Token Binding WG is that a specific piece of software voluntarily installed by a client can export any token and perform all the needed computations so that any token can successfully be used by another client. It is _NOT the replay of a token_, since the token is not used at any time by the legitimate owner, but is used by an illegitimate user. As the above link mentions: Whatever kind of cryptographic is being used, when two users collaborate, a software-only solution will be unable to prevent the transfer of an attribute of a user that possess it to another user that does not possess it . The use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key will be ineffective to counter the Alice and Bob collusion attack. Additional properties will be required for the secure element. Hence, any method able to counter the ABC attack requires the *use of secure elements* by the users. The objectives of the Token Binding WG are as follows: The main design objectives for the Token Binding protocol, in no particular order: 1. Allow applications and services to prevent unauthorized replay of security tokens. (...) At the present this objective has not been met and will never be met until some secure element will be used by clients. The HTTP binding mechanism being developed by the Token Binding WG gets more and more complex ... but will be insecure (i. e 'broken') as soon as someone will develop a piece of software able to by-pass it. Many people believe that it is "impossible" to counter this threat/attack and thus, since it is "impossible", a mechanism unable to address this issue is equal in terms of security to another mechanism unable to solve this issue (!). Another key point is that none of the techniques mentioned hereafter is able to counter the ABC attack, i.e. the transmission and then the use of an access token legitimately obtained by a user to another user, as soon as they agree to cooperate : · U-Prove from Microsoft, · Identity Mixer (Idemix) from IBM, · the IRMA Project (which is a combination of the *use of a smart card *and of Idemix), and · OpenID Connect. This means in particular that these methods are unable to support an ABAC (Attribute Based Access Control) model. Denis DP Security Consulting SAS. France. --------------90A3B88F7490261E28E961AC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Ben,

Hi Denis,

On Sat, Mar 25, 2017 at 04:39:06PM +0100, Denis wrote:

I would like to draw your attention, on the fact that the work performed 
both by the OAuth WG and the Token Binding WG is currently
unable to counter a major threat scenario that has been described in an 

With all due respect, I do not believe that there is consensus to
apply the modifier "major" to this threat scenario.

This depends of the content of the access token.

If the access token contains a sufficient number of attributes able to fully identify one individual in a given context,
Bob will disagree to collaborate with Alice because Alice would then be able to impersonate as Bob.

On the contrary, if the access token does not contain a sufficient number of attributes able to fully identify one individual
in a given context, Bob cannot be identified as being the one who got the access token that has been transmitted to Alice
and thus Bob is very likely to accept to collaborate with Alice based on the property: "not seen, not taken".

This is why I said : "This means in particular that these methods [U-Prove, Idemix, the IRMA Project, OpenID Connect and OAuth 2.0]
are unable to support an ABAC (Attribute Based Access Control) model".
Atttribute-based authentication aims to provide a mechanism for precisely doing this: allowing transactions on the basis of those attributes
which are required for the transaction. (...) The attribute that is most needed now is probably the minimal-age attribute, like ‘over 18’.

Extract from "Credential Design in Attribute-Based Identity Management" available at:
https://www.cs.ru.nl/~gergely/objects/TILTing_Alpar-Jacobs_CredentialDesign.pdf
If a person over 18 can transmit an access token to anybody under 18 and if this person is then able to use that token,
without the server being able to detect that this is a collusion attack, then I consider that this is a major problem.

This is not only a major problem for OAuth 2.0, but also a major problem for both U-Prove and Idemix, and as a consequence
for the now-closed ABC4Trust project.


earlier e-mail sent to the OAuth WG as the "ABC attack" or
the "Alice and Bob Collusion attack".

See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html

While it may be the case that the authors and participants of these
working groups are interested in desiging protocols that allow
non-malicious clients to gain protection for themselves from
malicious third parties even though the actual text of the charter
permits designing protections against malicious clients, it seems
that the proper response may be to reevaluate the charter text and
the desired goals from the work and the working group, rather than
to insist that this attack be considered and addressed.

If you have a technique able to counter the ABC attack, then it will also protect users from malicious third parties,
while the reverse is not true.
 
That is to say, though there are threat models in which the ABC attack is a
"real" attack, those are not necessarily the threat models in which
people are interested in working, and I do not think there is much
support for attempting to force one threat model on other WG
participants absent explicit consensus to adopt such a threat model
for the scope of some work.

-Ben


OAuth 2.0 is currently not restricting access tokens to only contain a sufficient set of attributes that allows to fully identify
an individual in a given context.

Since OAuth 2.0 allows access tokens to contain non-directly identifiable attributes, this is indeed a major problem.

Denis 

======================================================================================================================
Original message:

I would like to draw your attention, on the fact that the work performed both by the OAuth WG and the Token Binding WG is currently
unable to counter a major threat scenario that has been described in an earlier e-mail sent to the OAuth WG as the "ABC attack" or
the "Alice and Bob Collusion attack".

See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html

This threat is not mentioned in RFC 6819 : OAuth 2.0 Threat Model and Security Considerations (2013).
Hence, nobody attempted to find a solution ... for a threat that had not been identified.

A basic property of the current Token Binding mechanisms being developed by the Token Binding WG is that a specific piece of software
voluntarily installed by a client can export any token and perform all the needed computations so that any token can successfully be used
by another client. It is NOT the replay of a token, since the token is not used at any time by the legitimate owner, but is used by an illegitimate
user. As the above link mentions:

Whatever kind of cryptographic is being used, when two users collaborate, a software-only solution
will be unable to prevent the transfer of an attribute of a user that possess it to another user that does not possess it .

The use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key
will be ineffective to counter the Alice and Bob collusion attack. Additional properties will be required for the secure element.

Hence, any method able to counter the ABC attack requires the use of secure elements by the users.

The objectives of the Token Binding WG are as follows:

  The main design objectives for the Token Binding protocol, in no particular order: 
  1. Allow applications and services to prevent unauthorized replay of security tokens. (...)

At the present this objective has not been met and will never be met until some secure element will be used by clients.

The HTTP binding mechanism being developed by the Token Binding WG gets more and more complex ...
but will be insecure (i. e 'broken') as soon as someone will develop a piece of software able to by-pass it.

Many people believe that it is "impossible" to counter this threat/attack and thus, since it is "impossible", a mechanism unable
to address this issue is equal in terms of security to another mechanism unable to solve this issue (!).

Another key point is that none of the techniques mentioned hereafter is able to counter the ABC attack, i.e. the transmission
and then the use of an access token legitimately obtained by a user to another user, as soon as they agree to cooperate :

·    U-Prove from Microsoft,
·    Identity Mixer (Idemix) from IBM,
·    the IRMA Project (which is a combination of the use of a smart card and of Idemix), and
·    OpenID Connect.

This means in particular that these methods are unable to support an ABAC (Attribute Based Access Control) model.
 
Denis

DP Security Consulting SAS. France.

--------------90A3B88F7490261E28E961AC-- From nobody Mon Mar 27 06:56:48 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E97912783A; Mon, 27 Mar 2017 06:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 VI0J-VDdRHjC; Mon, 27 Mar 2017 06:56:39 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0129.outbound.protection.outlook.com [23.103.201.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B9A128C83; Mon, 27 Mar 2017 06:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HXBR63eaiRVBHRnRkqQnAKMWl90fiPY7jMYXrlouy+4=; b=KmHjYFcqSDypWgZGjwrlTtLFwxOI74GEwgR6dWafp/wV41+rkDM2wu7R2bZBodyPjN+n3qQKzQ0vNOo1ZSKLG8EkxDbydFoVQ5PCfYx3OG5R5xBAzyO856qYsuhWsHo1hgushzhGRfwrG162JRRXhjC5B/P0cvQYvHfJWgYRKec= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1439.namprd09.prod.outlook.com (10.173.50.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Mon, 27 Mar 2017 13:56:37 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0991.020; Mon, 27 Mar 2017 13:56:37 +0000 From: "Waltermire, David A. (Fed)" To: "saag@ietf.org" , "opsawg@ietf.org" Thread-Topic: PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKnAbKJdBq3STHUQoS3UW3fFlo+sQ== Date: Mon, 27 Mar 2017 13:56:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.223.1] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1439; 7:uyHrKgDVOiHHcSWns2Uz5ix9kmgy465Scp/Y8KcApdmAeZLkjlNspYSOYEWMYGHezrffJjzibjBpkBTyhqL7saC2vXGht9mkhhfRxdTYlfzbYWJeeGN/JF+bmmn9OdpYZpXtKK5I8mdCVjPzwtz7lQSVov/mlylz0/0FKJbbCicWXAzSDIXoqwWJbIPWWfytTUU0HgiiQZqY4pZghC7j9BOhzjTjwecxocLrNfqukrdX6yFjeq7SZvP4yf7zf9wC2jV2t7bx7tFSv97TvQvqP/KmpSqATZZWqUAoodIcBpweLSBPBb5Y+tLvn95QX2LlgaURtFnXxS2GKzc2Ckk2ZA== x-ms-office365-filtering-correlation-id: f991cccb-54c2-4c5f-b06d-08d475191625 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:MWHPR09MB1439; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(211171220733660)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:MWHPR09MB1439; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1439; x-forefront-prvs: 02596AB7DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39450400003)(39840400002)(39860400002)(55016002)(9686003)(6506006)(6436002)(99286003)(2900100001)(77096006)(33656002)(50986999)(3280700002)(54356999)(66066001)(2906002)(3660700001)(7736002)(122556002)(189998001)(5660300001)(2501003)(8936002)(102836003)(3846002)(74316002)(6116002)(7696004)(81166006)(8676002)(305945005)(38730400002)(86362001)(450100002)(53936002)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1439; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2017 13:56:37.1472 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1439 Archived-At: Subject: [saag] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 13:56:41 -0000 The IETF SACM work group has been working to standardize the collection of = endpoint configuration and other posture information from enterprise endpoi= nts. Collecting this information is critical to support automation of commo= n network security tasks, including asset, software, vulnerability, and con= figuration management. Thus far, our efforts have focused primarily on stan= dards to collect information in support of asset, software and vulnerabilit= y management use cases, and has worked with other IETF members to determine= what data would need to be to be collected, and how that data would be sec= urely communicated across the network. Through such exchanges an organizati= on can know what client endpoints are connected to their network, and if th= ey are vulnerable to attack. Given the proliferation of attacks against network infrastructure devices, = it is clear that the next step in our enterprise security automation effort= must be to enable standardized reporting of similar information from netwo= rk infrastructure devices. With the growing number of Yang models and incre= ased adoption of NETCONF, RESTCONF, and related protocol work, the time is = right to work out how these standards can be used to measure the health of = network devices. This information will, as in our efforts in SACM for clien= t devices, support asset, software, vulnerability, and configuration manage= ment use cases. Standards-based reporting of this information from network = infrastructure devices will help network defenders protect against known at= tacks, and provide the necessary knowledge to detect and mitigate future at= tacks.=20 We would like to start a discussion about how to leverage the existing IETF= network management protocols to best address security automation for netwo= rk infrastructure devices. We would like your ideas on how to best pursue t= his work, and your insights into network infrastructure security problems t= hat will impact our networks in the future. We are holding a side meeting a= t IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion abou= t how to move forward. We will be meeting in Vevey 4 at the IETF meeting ve= nue. Here is a summary of the meeting details: PANIC (Posture Assessment through Network Information Collection) Bar BoF W= ednesday, March 29th, 2017 @ 6:30pm CDT Swissotel Conference Center - Vevey= 4 We look forward to working with you, and hope to see you in Chicago at the = PANIC Bar BoF. Regards, Dave Waltermire David Waltermire Information Technology Laboratory Computer Security Division National Institute of Standards and Technology David Waltermire Information Technology Laboratory | Computer Security Division National Institute of Standards and Technology From nobody Mon Mar 27 07:49:34 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845901296FA for ; Mon, 27 Mar 2017 07:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YIo4AGDxJE3s for ; Mon, 27 Mar 2017 07:49:32 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 2E84C12943A for ; Mon, 27 Mar 2017 07:49:32 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id g2so42047680pge.3 for ; Mon, 27 Mar 2017 07:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=pvxgTWSyCi5xIMiO07EI8sqnZRvE4+u0Lh4Wka363P4=; b=P3RgHRWlTIML/YGcbM9IDTn8CsNcqrbobTlTU/cRqqhmy2w21d2id/IEVTyFuE2tSJ hk9bVOPqjx6lPzUFcvIOumAu4Ec6MViKOHI0PXR5wq1zafZnr9gCycWxw3qjSpI9IHPj RA9viTral9sbup5skXhch2y3OaLhW+xMLKnaz2tRtQjt7yFnJaEB0lllSPcP1txx3jfV lix4KnSwwbDSKOnaGJmwhB2/dKlOUTcO534TkgYMNlv+9jo8khBDs+AoOX9H5r9DcE7Y c5nke8vJ/W103V6AJ8T6fItTqGskBFMoDlVnC75AwZRZVXI4NnKEXtqiF8vCkStJ6VKC UQBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pvxgTWSyCi5xIMiO07EI8sqnZRvE4+u0Lh4Wka363P4=; b=M71vuo7loYDEW9fT3cbWvKbdhQo87A8X+swDGh/HMBLHDzRQRb9NfFM9tOGbhcIZQV c4J74ZNkzr3O+s0r55RdcIqm6FlYpkR66ClJBPukmu2+AQNam4tkaG0+qOyNz/s79mSt crNSiWMOG0TKxmNnOVv8ucDvZXNDxrCDeuv/1z+64UCXNWjn9Q3jfCh/uKPVwa1U0ZcE Qv7ykypfJ1JtAjV6mmRXuaLOv05s7aD1J20DNlCdA6B4bTSmaz/6rGJ1buMQPVvpF5iq OOylvIxCMDezAjCQYPvRQ9SnnAkLkMb2jqWvX+MiiskznXFP/SkSWC64SybiverSuKXk nRvQ== X-Gm-Message-State: AFeK/H0JG36RHHzX2UGVBqGy+H5kk9xTYZAiXmX2C95FBPWpjFDDt4zOBDgY1R37rJoBVuMyzHKFJfI5TP/EMA== X-Received: by 10.99.139.196 with SMTP id j187mr24440404pge.176.1490626171716; Mon, 27 Mar 2017 07:49:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.183.98 with HTTP; Mon, 27 Mar 2017 07:49:31 -0700 (PDT) From: Kathleen Moriarty Date: Mon, 27 Mar 2017 10:49:31 -0400 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] minutes and jabber X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 14:49:33 -0000 Hello, Can we have a couple of volunteers to take minutes and one to help as a jabber scribe? Thank you in advance! -- Best regards, Kathleen From nobody Mon Mar 27 09:06:44 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A847129465 for ; Mon, 27 Mar 2017 09:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=virgil.gr 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 1MwS2mcusMKu for ; Mon, 27 Mar 2017 09:06:40 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 74E7B129454 for ; Mon, 27 Mar 2017 09:06:40 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id p77so34823957ywg.1 for ; Mon, 27 Mar 2017 09:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virgil.gr; s=dkim; h=mime-version:from:date:message-id:subject:to; bh=fG37KPLbTFelh4npkV34wekwzeCkKH0rMNLcZoPbo28=; b=YXsZDTK0FBvybs0D5UuHVZqJqA6OuPMUCldkK2LENXgLpe/zLcudow2r1T0+1rPP4P 0m3VorPbiGN9Pv7IVdA9oC5pPjr9h4l0cTkXR5AKJFnhJ9kJW7R53f8vxtiHFOzMgRgw WuLOoRPECzhlwYWHZME3rsTaiyj1ZEfg6Ab5A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fG37KPLbTFelh4npkV34wekwzeCkKH0rMNLcZoPbo28=; b=cPEsNIiFqQynYAxShhW74Nz2fiuiZh47NJaXbZMACd9k2kEdtAg4BC0+jJ2B+a3ULW aL2PzCczldtntRxIYzn5GAVSKLIbYhY214UzbbcV8lMQrd4G9XeTYs7UZf/yx3sMTwGb M2d6HCalymNLvllcezW9TkSpHFW/Joq3soiCneO/UczWNbxMNHyRZr6ozXrQ3Sbc3x+o mE/v/3zG5EmGjpuMl4OKNsa2+qm1/fwwWJULFU31OCc5OZxAxLMiJeAXJMsy1+9ecIu6 dv3XbQOiR2jV/Ts1tBCEx8JWDe6DCEGj18hrqJ1HMnNQm7D23zzXNyMAP9LYc5XlE5Th 5FEw== X-Gm-Message-State: AFeK/H0Q8uhgIUv8AVeZqsE/5BfzOq6+Ti7Rc6+Q6ss7aPgrGaUcGqAJk2QF4mf9koiS1gD46ahLhtucESrAfg== X-Received: by 10.13.225.80 with SMTP id k77mr18639082ywe.83.1490630799334; Mon, 27 Mar 2017 09:06:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.252.26 with HTTP; Mon, 27 Mar 2017 09:06:18 -0700 (PDT) From: Virgil Griffith Date: Tue, 28 Mar 2017 00:06:18 +0800 Message-ID: To: saag@ietf.org Content-Type: multipart/alternative; boundary=94eb2c071944493f7c054bb8875a Archived-At: Subject: [saag] Hello from the Ethereum Foundation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 16:06:42 -0000 --94eb2c071944493f7c054bb8875a Content-Type: text/plain; charset=UTF-8 Hello everyone. I was invited to this list by Walid Al-Saqaf. I represent the Ethereum Foundation and am joining this list because the Foundation is starting to build-out our public platform. For an example of this build-out, we recently launched the new Ethereum Name Service: https://hackernoon.com/hosting-a-dns-domain-on-the-blockchain-58a41dc50028#.b5tetdpiw https://github.com/ethereum/ens As-is, the Ethereum Name Service allows any "smart-contract" or "dapp" on Ethereum to be accessed via a human-readable name. Normally this requires access to the Ethereum system, but we've opened this up to the world-wide-web by with the DNS proxy "ens.domains". But we wish to do better. Particularly, we are interested in getting the TLD .eth as a reserved name for the Ethereum platform and get .eth added to the list of reserved names akin to these: * https://tools.ietf.org/html/rfc6761 * https://tools.ietf.org/html/rfc7686 Our (very long term) aspiration is to demonstrate by example how a blockchain can be used as a fully transparent, decentralized domain-registry. We hope that if other TLDs see that this can be done securely, that they might be inspired to emulate us resulting in more secure, transparent DNS for all internet users. The Ethereum Foundation has two benefits to the IETF: (1) There's been plenty of talk on the interface between the web and blockchain systems, e.g., https://www.w3.org/2016/04/blockchain-workshop/report As Ethereum is the most flexible blockchain platform in the world, we're a good candidate for experiments in this direction. (2) There's been talk of wanting to doing IoT with URIs, again particularly referencing blockchain, https://www.technologyreview.com/s/603298/a-secure-model-of-iot-with-blockchain/ , and Ethereum is a good fit for this as well. I am writing here to get feedback just for how things work around here and any suggestions for achieving our goals. Outside of our interest in the .eth TLD, if you have ideas for other ways Ethereum might help the IETF, we're obviously interested in doing that, and we can discuss the possibility of devoting some man-hours to doing that. Thanks much, -Virgil --94eb2c071944493f7c054bb8875a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello everyone.

I was invite= d to this list by Walid Al-Saqaf.=C2=A0 I represent the Ethereum Foundation= and am joining this list because the Foundation is starting to build-out o= ur public platform. For an example of this build-out, we recently launched = the new Ethereum Name Service:



A= s-is, the Ethereum Name Service allows any "smart-contract" or &q= uot;dapp" on Ethereum to be accessed via a human-readable name.=C2=A0 = Normally this requires access to the Ethereum system, but we've opened = this up to the world-wide-web by with the DNS proxy "ens.domains"= .=C2=A0 But we wish to do better.=C2=A0 Particularly, we are interested in = getting the TLD .eth as a reserved name for the Ethereum platform and get .= eth added to the list of reserved names akin to these:

=

Our (= very long term) aspiration is to demonstrate by example how a blockchain ca= n be used as a fully transparent, decentralized domain-registry.=C2=A0 We h= ope that if other TLDs see that this can be done securely, that they might = be inspired to emulate us resulting in more secure, transparent DNS for all= internet users.

The Ethereum Foundation has two b= enefits to the IETF:

(1) There's been plenty o= f talk on the interface between the web and blockchain systems, e.g.,
=

<= div>As Ethereum is the most flexible blockchain platform in the world, we&#= 39;re a good candidate for experiments in this direction.

(2) There's been talk of wanting to doing IoT with URIs, again = particularly referencing blockchain,


and Ethereum is a good fit for th= is as well.


I am writing here to ge= t feedback just for how things work around here and any suggestions for ach= ieving our goals.=C2=A0 Outside of our interest in the .eth TLD, if you hav= e ideas for other ways Ethereum might help the IETF, we're obviously in= terested in doing that, and we can discuss the possibility of devoting some= man-hours to doing that.

Thanks much,
-= Virgil
--94eb2c071944493f7c054bb8875a-- From nobody Mon Mar 27 10:04:53 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29822127077 for ; Mon, 27 Mar 2017 10:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 VnraKxWrQUbp for ; Mon, 27 Mar 2017 10:04:50 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 CAFF412702E for ; Mon, 27 Mar 2017 10:04:49 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id l43so65989059wre.1 for ; Mon, 27 Mar 2017 10:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dgp0Y3x0K0HyLj7BttnhZtVa1EjzquyYMgi672pWlYE=; b=fItihogc6fisDDVM2aRehMk15SFDhFd6XGWjmlQC17m95MgKs/38zM788TQpZ58Sj4 yfbXu1UYAbjjKXcBkz/+HCXe6k3zKx5furrzq2HoAadisBDFJTXF4HFz0o1Ax9PXLmRO oaKLiReO6M04lbFeNiL1Sl6cA5XwPvjR9FEwJGzf2xMQFfPJG9bXM1JhxVzJuciuLNGQ 1/T+RthbgQffWY9OEsGDQRf7H2xOy1Fs7dVh9/QSV5fbdftrN1v8d8tzvCizhVOXluDN KVZo0SW3Vl52VTMZqH0OXz+Uv4HFDZxUhtg/ju9PTg+LU5Oo3lABglb7bkpxU8XkCCiL uzJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dgp0Y3x0K0HyLj7BttnhZtVa1EjzquyYMgi672pWlYE=; b=h7sBsT9L862NpbKrQHr19UqC4s3sEwHlKyoE4Jjn+lG82lvOU4D0r62DMImrgmryBx fh0Y5CiyDqI2EynFStbQptQ7Md9cHFjHxsx5/U/SnGcqZPrvFuB29G2lewHD4Fqj94zD AhK/ytffvORMU5KJ0is7XygStheI28C7IfJDMJXTFBlg+zNcQGr3//0chWeggclEftIO dP9fAujy8JDmKsmeHynSiHoFpZaeHredbHvTbXGh1V20t9wuRBosTsXoC4BqCy9gnFd8 Q0kytBw7z2sXfaRkKjRRkNl5MixzwEo+Y15Uw9oxsx8wzUpbnsWNhPhtyPqy1tdrcOER yS3Q== X-Gm-Message-State: AFeK/H3VGnjPPuzvQUPBhwsv2vWzzbA//1duRo9v7PhfIOW1tLhF7NqOLHF9wqeGfDs7oZAy3U1niRB9LJJzSg== X-Received: by 10.223.149.35 with SMTP id 32mr17960786wrs.107.1490634288212; Mon, 27 Mar 2017 10:04:48 -0700 (PDT) MIME-Version: 1.0 Sender: benlaurie@gmail.com Received: by 10.28.166.208 with HTTP; Mon, 27 Mar 2017 10:04:47 -0700 (PDT) In-Reply-To: References: From: Ben Laurie Date: Mon, 27 Mar 2017 18:04:47 +0100 X-Google-Sender-Auth: _N6EErrjL-b5miU8UVejneio42k Message-ID: To: Virgil Griffith Cc: IETF Security Area Advisory Group Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [saag] Hello from the Ethereum Foundation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 17:04:52 -0000 On 27 March 2017 at 17:06, Virgil Griffith wrote: > Hello everyone. > > I was invited to this list by Walid Al-Saqaf. I represent the Ethereum > Foundation and am joining this list because the Foundation is starting to > build-out our public platform. For an example of this build-out, we recently > launched the new Ethereum Name Service: > > https://hackernoon.com/hosting-a-dns-domain-on-the-blockchain-58a41dc50028#.b5tetdpiw > https://github.com/ethereum/ens > > > As-is, the Ethereum Name Service allows any "smart-contract" or "dapp" on > Ethereum to be accessed via a human-readable name. Normally this requires > access to the Ethereum system, but we've opened this up to the > world-wide-web by with the DNS proxy "ens.domains". DNS is used for a lot more than just the WWW. > But we wish to do > better. Particularly, we are interested in getting the TLD .eth as a > reserved name for the Ethereum platform and get .eth added to the list of > reserved names akin to these: > > * https://tools.ietf.org/html/rfc6761 > * https://tools.ietf.org/html/rfc7686 Are you intending .eth to not be resolvable using standard tools? > Our (very long term) aspiration is to demonstrate by example how a > blockchain can be used as a fully transparent, decentralized > domain-registry. We hope that if other TLDs see that this can be done > securely, that they might be inspired to emulate us resulting in more > secure, transparent DNS for all internet users. > > The Ethereum Foundation has two benefits to the IETF: > > (1) There's been plenty of talk on the interface between the web and > blockchain systems, e.g., > https://www.w3.org/2016/04/blockchain-workshop/report > > As Ethereum is the most flexible blockchain platform in the world, we're a > good candidate for experiments in this direction. > > (2) There's been talk of wanting to doing IoT with URIs, again particularly > referencing blockchain, > > https://www.technologyreview.com/s/603298/a-secure-model-of-iot-with-blockchain/ > , > > and Ethereum is a good fit for this as well. > > > I am writing here to get feedback just for how things work around here and > any suggestions for achieving our goals. Outside of our interest in the > .eth TLD, if you have ideas for other ways Ethereum might help the IETF, > we're obviously interested in doing that, and we can discuss the possibility > of devoting some man-hours to doing that. > > Thanks much, > -Virgil > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Mon Mar 27 10:21:22 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9D612714F for ; Mon, 27 Mar 2017 10:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=virgil.gr 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 0XhHlHQQbuKx for ; Mon, 27 Mar 2017 10:21:18 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 DB7C2127077 for ; Mon, 27 Mar 2017 10:21:17 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id i203so36437266ywc.3 for ; Mon, 27 Mar 2017 10:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virgil.gr; s=dkim; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aKZFnokGNpQFVvgxDVwlCBLDXLn57NNrpqC1iwz7xuA=; b=UglpRUJp3LOFAeWlnUVocWvQ0JXkX/Okc8Oow5SUD1n86M0MZFUprxPLBUAIL955HU fuVIBf3M2cWmRUjazC0vXfCMoTF2ZH3WbErOjXyUkkEZ2cvgQhxtEExcpDeDC3lDrFpu RtnjWaHdvqyYJxb/V4A6V7AsZqk3cjAiz7OKA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aKZFnokGNpQFVvgxDVwlCBLDXLn57NNrpqC1iwz7xuA=; b=nsjXTv+QFgbu9ymBk5Qeh3ySlUOi+c/gV9fz8g21lXObM5vWNAH8CMW1yHn+PRyvvP sdsQbKI2+pEnE/ViiY648C03Df4YJxOEAXwyPHpBulVEttl0rC07gUUghczcvBxHvXLa tmiHHdWpeAADwRndWZxxQ4PQjYk7eb0vfaJAZaRnmPIyXTdpZp/fuiXSd3eviUPhjrPI Ubd50oAtvpHJR3RAngSodK/6iv0cSjihVsoQl9cYLLINbpwWS3GpiQk4/0zO9ZeZzZGN JpqK4wtIXzs9VQJCb3E95Br06FPmsLfluVpep43Qk1Nbf/GKaUmyhcOIHobleNh4vT/p T7Yw== X-Gm-Message-State: AFeK/H1F4uR/qFiyMu0ZEojirF5/f4Sv+ADSGsrJzCS8gddJlwCFGUwwbWIZ7ApWiTwWJ2YJDVbBKKog4KyvmA== X-Received: by 10.37.177.24 with SMTP id g24mr5791933ybj.94.1490635277069; Mon, 27 Mar 2017 10:21:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.252.26 with HTTP; Mon, 27 Mar 2017 10:20:56 -0700 (PDT) In-Reply-To: References: From: Virgil Griffith Date: Tue, 28 Mar 2017 01:20:56 +0800 Message-ID: To: Ben Laurie Cc: IETF Security Area Advisory Group Content-Type: multipart/alternative; boundary=f403045e4fa02e0e86054bb992d6 Archived-At: Subject: Re: [saag] Hello from the Ethereum Foundation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 17:21:21 -0000 --f403045e4fa02e0e86054bb992d6 Content-Type: text/plain; charset=UTF-8 Hi Ben, pleasure to see you again. > DNS is used for a lot more than just the WWW. Indeed. The WWW use-case is merely what ens.domains service supports at the moment. > Are you intending .eth to not be resolvable using standard tools? We wish .eth to be resolvable using the standard tools. For this we will presumably apply for a .eth gTLD from ICANN when they open up for new gTLD applications around 2020. However, between now and 2020, we have been counseled to pursue the .eth name reservation through IETF. If this is the wrong approach please say so. -Virgil On Tue, Mar 28, 2017 at 1:04 AM, Ben Laurie wrote: > On 27 March 2017 at 17:06, Virgil Griffith wrote: > > Hello everyone. > > > > I was invited to this list by Walid Al-Saqaf. I represent the Ethereum > > Foundation and am joining this list because the Foundation is starting to > > build-out our public platform. For an example of this build-out, we > recently > > launched the new Ethereum Name Service: > > > > https://hackernoon.com/hosting-a-dns-domain-on-the-blockchai > n-58a41dc50028#.b5tetdpiw > > https://github.com/ethereum/ens > > > > > > As-is, the Ethereum Name Service allows any "smart-contract" or "dapp" on > > Ethereum to be accessed via a human-readable name. Normally this > requires > > access to the Ethereum system, but we've opened this up to the > > world-wide-web by with the DNS proxy "ens.domains". > > DNS is used for a lot more than just the WWW. > > > But we wish to do > > better. Particularly, we are interested in getting the TLD .eth as a > > reserved name for the Ethereum platform and get .eth added to the list of > > reserved names akin to these: > > > > * https://tools.ietf.org/html/rfc6761 > > * https://tools.ietf.org/html/rfc7686 > > Are you intending .eth to not be resolvable using standard tools? > > > Our (very long term) aspiration is to demonstrate by example how a > > blockchain can be used as a fully transparent, decentralized > > domain-registry. We hope that if other TLDs see that this can be done > > securely, that they might be inspired to emulate us resulting in more > > secure, transparent DNS for all internet users. > > > > The Ethereum Foundation has two benefits to the IETF: > > > > (1) There's been plenty of talk on the interface between the web and > > blockchain systems, e.g., > > https://www.w3.org/2016/04/blockchain-workshop/report > > > > As Ethereum is the most flexible blockchain platform in the world, we're > a > > good candidate for experiments in this direction. > > > > (2) There's been talk of wanting to doing IoT with URIs, again > particularly > > referencing blockchain, > > > > https://www.technologyreview.com/s/603298/a-secure-model-of- > iot-with-blockchain/ > > , > > > > and Ethereum is a good fit for this as well. > > > > > > I am writing here to get feedback just for how things work around here > and > > any suggestions for achieving our goals. Outside of our interest in the > > .eth TLD, if you have ideas for other ways Ethereum might help the IETF, > > we're obviously interested in doing that, and we can discuss the > possibility > > of devoting some man-hours to doing that. > > > > Thanks much, > > -Virgil > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > > --f403045e4fa02e0e86054bb992d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ben, pleasure to see you aga= in.

&g= t; DNS is used for a lot more than just the WWW.

Indeed.=C2=A0 The WWW use-case i= s merely what=C2=A0ens.domains service supports at the moment.

> Are you inten= ding .eth to not be resolvable using standard tools?

We wish .eth to be resolvabl= e using the standard tools.=C2=A0 For this we will presumably apply for a .= eth gTLD from ICANN when they open up for new gTLD applications around 2020= .=C2=A0 However, between now and 2020, we have been counseled to pursue the= .eth name reservation through IETF.=C2=A0 If this is the wrong approach pl= ease say so.

-Virgil

On Tue, Mar 28, 2017 at 1:04 AM, Ben Laurie <ben@links.org> w= rote:
On 27 March 2017 at 17:06, Virgil Griffi= th <i@virgil.gr>= wrote:
> Hello everyone.
>
> I was invited to this list by Walid Al-Saqaf.=C2=A0 I represent the Et= hereum
> Foundation and am joining this list because the Foundation is starting= to
> build-out our public platform. For an example of this build-out, we re= cently
> launched the new Ethereum Name Service:
>
> https://ha= ckernoon.com/hosting-a-dns-domain-on-the-blockchain-58a41dc50028#= .b5tetdpiw
> https://github.com/ethereum/ens
>
>
> As-is, the Ethereum Name Service allows any "smart-contract"= or "dapp" on
> Ethereum to be accessed via a human-readable name.=C2=A0 Normally this= requires
> access to the Ethereum system, but we've opened this up to the
> world-wide-web by with the DNS proxy "ens.domains".

DNS is used for a lot more than just the WWW.

>=C2=A0 But we wish to do
> better.=C2=A0 Particularly, we are interested in getting the TLD .eth = as a
> reserved name for the Ethereum platform and get .eth added to the list= of
> reserved names akin to these:
>
> * https://tools.ietf.org/html/rfc6761
> * https://tools.ietf.org/html/rfc7686

Are you intending .eth to not be resolvable using standard tools?
> Our (very long term) aspiration is to demonstrate by example how a
> blockchain can be used as a fully transparent, decentralized
> domain-registry.=C2=A0 We hope that if other TLDs see that this can be= done
> securely, that they might be inspired to emulate us resulting in more<= br> > secure, transparent DNS for all internet users.
>
> The Ethereum Foundation has two benefits to the IETF:
>
> (1) There's been plenty of talk on the interface between the web a= nd
> blockchain systems, e.g.,
> https://www.w3.org/2016/04/blockchai= n-workshop/report
>
> As Ethereum is the most flexible blockchain platform in the world, we&= #39;re a
> good candidate for experiments in this direction.
>
> (2) There's been talk of wanting to doing IoT with URIs, again par= ticularly
> referencing blockchain,
>
> https://www.tec= hnologyreview.com/s/603298/a-secure-model-of-iot-with-blockchain/=
> ,
>
> and Ethereum is a good fit for this as well.
>
>
> I am writing here to get feedback just for how things work around here= and
> any suggestions for achieving our goals.=C2=A0 Outside of our interest= in the
> .eth TLD, if you have ideas for other ways Ethereum might help the IET= F,
> we're obviously interested in doing that, and we can discuss the p= ossibility
> of devoting some man-hours to doing that.
>
> Thanks much,
> -Virgil
>
> ____________________________= ___________________
> saag mailing list
> saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >

--f403045e4fa02e0e86054bb992d6-- From nobody Mon Mar 27 11:30:00 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF602129483 for ; Mon, 27 Mar 2017 11:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 k8-kbqZbDGJB for ; Mon, 27 Mar 2017 11:29:50 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 989F6129490 for ; Mon, 27 Mar 2017 11:29:50 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id y18so85454837itc.0 for ; Mon, 27 Mar 2017 11:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Z5cSTYLXUJj0v0RD5xJud6O7O0zsEG7kubOhpYwYc5E=; b=mXgVMKuUar60iFfJZOII16krxAWL0OFRQOxi4ZAADjYljQMFVMOPuDoBzWlInZPknI cPzR+nbue44cTxe9s6jQSkWZh1KeKAC95w/1wkMhVdADshzW5fjrG2aiWxSgaapU42jH opRWrJt2HxSaG3G132KWle10HF4FMmj9HclxIjZEsmxl3fUTLxmVcKnUbaaX7W4UTVs7 HLiDIN+qw51UUIv+uF4EaBeetDAsMmvIqDEOLLVPdh8L/vrZWkCyrDBLf9kpAk7Vl+Mt pzKbXSGRXa+xNdZ+wQD0uiSkSdA/O3QRKum7jIkMUNkkj7bql3VBfpj/rVFh1Ux3uekI yR+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Z5cSTYLXUJj0v0RD5xJud6O7O0zsEG7kubOhpYwYc5E=; b=RH7AjRev7eXnqSns7qqW6Q4SidYmaQGENpteHSpFvNcXWG2QbIbGwSdBRixMLXZwcD M9jjhpEQJKaARVombsNqZB15rLX1QPuAWLfnHOlJuVkIPXjbP9Ip07TCuSIZgiXYa+2r eWjvTxLc3oEhDRaGwbrU+6hQgooI0kDmvNYQ6SHmTDVzd/FSb1wHN9tPNROww47C0+a3 obxnxASBC2QS7hrUGYxHcv13LNFTPlezyXcRfILeIFMju+elJN76o8hsuU86a6bRQrNV yK4aScaNs1lj9Dpz/6BskGapqL1CWZz12sBWkwrAcDJzzAbga6RBYgmsnFOAQm09c2ko 7Bww== X-Gm-Message-State: AFeK/H0+T8Qq41e3cNWE+zmKLxjG47JYfMJaIwV7xSKyiSBbPkKA02F+PemqVNUwiz8uuQ== X-Received: by 10.107.44.23 with SMTP id s23mr25135340ios.229.1490639389955; Mon, 27 Mar 2017 11:29:49 -0700 (PDT) Received: from t2001067c0370012824bc91e97d0043f5.v6.meeting.ietf.org (t2001067c0370012824bc91e97d0043f5.v6.meeting.ietf.org. [2001:67c:370:128:24bc:91e9:7d00:43f5]) by smtp.gmail.com with ESMTPSA id 65sm612023iop.21.2017.03.27.11.29.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 11:29:49 -0700 (PDT) From: Yoav Nir Message-Id: <98069B11-A786-4DD6-84D0-EA805A527BB2@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_876D62F2-0413-4BE9-9376-F4BD71A13E93"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 27 Mar 2017 13:29:47 -0500 In-Reply-To: <1d6be71f-f746-1fa7-d6e6-21d8201cc637@free.fr> Cc: Benjamin Kaduk , Security Area Advisory Group To: Denis References: <2069106e-5e72-cf36-63fa-4b50275c1036@free.fr> <20170326035758.GU30306@kduck.kaduk.org> <1d6be71f-f746-1fa7-d6e6-21d8201cc637@free.fr> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [saag] About Token Binding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 18:29:54 -0000 --Apple-Mail=_876D62F2-0413-4BE9-9376-F4BD71A13E93 Content-Type: multipart/alternative; boundary="Apple-Mail=_076B496B-FAB5-475F-B7FF-2BF845CB6075" --Apple-Mail=_076B496B-FAB5-475F-B7FF-2BF845CB6075 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Denis > On 27 Mar 2017, at 3:16, Denis wrote: >=20 > Hi Ben, >=20 >> Hi Denis, >>=20 >> On Sat, Mar 25, 2017 at 04:39:06PM +0100, Denis wrote: >>> I would like to draw your attention, on the fact that the work = performed >>> both by the OAuth WG and the Token Binding WG is currently >>> unable to counter a major threat scenario that has been described in = an >> With all due respect, I do not believe that there is consensus to >> apply the modifier "major" to this threat scenario. >=20 > This depends of the content of the access token. I don=E2=80=99t think the question is whether this is major or minor. = The question is whether this is without our threat model or not. > If the access token contains a sufficient number of attributes able to = fully identify one individual in a given context, > Bob will disagree to collaborate with Alice because Alice would then = be able to impersonate as Bob. This implies that Bob has a very complex trust policy for Alice. I = don=E2=80=99t think this reflects the real world. =E2=80=9CHere, Alice, = take my driver=E2=80=99s license. Please don=E2=80=99t drink too much=E2=80= =9D is far more realistic. > On the contrary, if the access token does not contain a sufficient = number of attributes able to fully identify one individual > in a given context, Bob cannot be identified as being the one who got = the access token that has been transmitted to Alice > and thus Bob is very likely to accept to collaborate with Alice based = on the property: "not seen, not taken=E2=80=9D. Regardless of the psychology of Bob, this goes against the data = minimization recommendation from RFC 6973. One of the attractive = properties of OAuth is that Bob does not need to send name, address, = fingerprint and SSN to the resource server in order to buy (for example) = vodka. All he needs to do is send a token proving he=E2=80=99s over 18. = There is a balance to be struck between the need to prevent Bob from = misusing his ability to get a token and the need to limit information = shared with the resource server. If anything, the part of the process that needs to be fixed is not that = the access token is used by (not Bob), but that Bob was able to obtain a = token for (not Bob). Not that I have a good solution for that. But = absent technical solutions that are also workable, it is enough to say = that the Authorization Server has a trust relationship with Bob, and = trusts Bob to not obtain tokens on behalf of others. Same as the DMV = trusts him not to give his driver=E2=80=99s license to his niece. > This is why I said : "This means in particular that these methods = [U-Prove, Idemix, the IRMA Project, OpenID Connect and OAuth 2.0] > are unable to support an ABAC (Attribute Based Access Control) model". > Atttribute-based authentication aims to provide a mechanism for = precisely doing this: allowing transactions on the basis of those = attributes > which are required for the transaction. (...) The attribute that is = most needed now is probably the minimal-age attribute, like =E2=80=98over = 18=E2=80=99. >=20 > Extract from "Credential Design in Attribute-Based Identity = Management" available at: > = https://www.cs.ru.nl/~gergely/objects/TILTing_Alpar-Jacobs_CredentialDesig= n.pdf = > If a person over 18 can transmit an access token to anybody under 18 = and if this person is then able to use that token, > without the server being able to detect that this is a collusion = attack, then I consider that this is a major problem. You know, Bob can just buy the vodka himself and give it to her. > This is not only a major problem for OAuth 2.0, but also a major = problem for both U-Prove and Idemix, and as a consequence > for the now-closed ABC4Trust project. >=20 >>=20 >>> earlier e-mail sent to the OAuth WG as the "ABC attack" or >>> the "Alice and Bob Collusion attack". >>>=20 >>> See: = https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html = >> While it may be the case that the authors and participants of these >> working groups are interested in desiging protocols that allow >> non-malicious clients to gain protection for themselves from >> malicious third parties even though the actual text of the charter >> permits designing protections against malicious clients, it seems >> that the proper response may be to reevaluate the charter text and >> the desired goals from the work and the working group, rather than >> to insist that this attack be considered and addressed. >=20 > If you have a technique able to counter the ABC attack, then it will = also protect users from malicious third parties, > while the reverse is not true. >=20 >> That is to say, though there are threat models in which the ABC = attack is a >> "real" attack, those are not necessarily the threat models in which >> people are interested in working, and I do not think there is much >> support for attempting to force one threat model on other WG >> participants absent explicit consensus to adopt such a threat model >> for the scope of some work. >>=20 >> -Ben >=20 > OAuth 2.0 is currently not restricting access tokens to only contain a = sufficient set of attributes that allows to fully identify > an individual in a given context. >=20 To me, this is a feature. > Since OAuth 2.0 allows access tokens to contain non-directly = identifiable attributes, this is indeed a major problem. >=20 > Denis --Apple-Mail=_076B496B-FAB5-475F-B7FF-2BF845CB6075 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Denis

On 27 Mar 2017, at 3:16, Denis = <denis.ietf@free.fr> wrote:

Hi Ben,

Hi Denis,

On Sat, Mar 25, 2017 at 04:39:06PM +0100, Denis wrote:

I =
would like to draw your attention, on the fact that the work performed=20=

both by the OAuth WG and the Token Binding WG is currently
unable to counter a major threat scenario that has been described in an=20=


With all due respect, I do =
not believe that there is consensus to
apply the modifier "major" to this threat scenario.

This depends of the = content of the access token.

I don=E2=80= =99t think the question is whether this is major or minor. The question = is whether this is without our threat model or not.

If the access token contains a sufficient number of = attributes able to fully identify one individual in a given = context, 
Bob will disagree to collaborate with Alice because Alice = would then be able to impersonate as Bob.

This = implies that Bob has a very complex trust policy for Alice. I don=E2=80=99= t think this reflects the real world. =E2=80=9CHere, Alice, take my = driver=E2=80=99s license. Please don=E2=80=99t drink too much=E2=80=9D = is far more realistic. 

On the contrary, if = the access token does not contain a sufficient number of = attributes able to fully identify one individual 
in a given = context, Bob cannot be identified as being the one who got the access = token that has been transmitted to Alice
and thus Bob is = very likely to accept to collaborate with Alice based on the property: = "not seen, not = taken=E2=80=9D.

Regardless = of the psychology of Bob, this goes against the data minimization = recommendation from RFC 6973. One of the attractive properties of OAuth = is that Bob does not need to send name, address, fingerprint and SSN to = the resource server in order to buy (for example) vodka.  All he = needs to do is send a token proving he=E2=80=99s over 18. There is a = balance to be struck between the need to prevent Bob from misusing his = ability to get a token and the need to limit information shared with the = resource server.

If anything, the = part of the process that needs to be fixed is not that the access token = is used by (not Bob), but that Bob was able to obtain a token for (not = Bob). Not that I have a good solution for that. But absent technical = solutions that are also workable, it is enough to say that the = Authorization Server has a trust relationship with Bob, and trusts Bob = to not obtain tokens on behalf of others. Same as the DMV trusts him not = to give his driver=E2=80=99s license to his niece.

This is why I said : "This means in particular that these = methods [U-Prove, Idemix, the IRMA Project, OpenID Connect and OAuth = 2.0]
are unable to support an ABAC (Attribute = Based Access Control) model".
Atttribute-based = authentication aims to provide a mechanism for precisely doing this: = allowing transactions on the basis of those attributes 
which are = required for the transaction. (...) The attribute that is most needed = now is probably the minimal-age attribute, like =E2=80=98over 18=E2=80=99.=

Extract from "Credential Design in = Attribute-Based Identity Management" available at:
https://www.cs.ru.nl/~gergely/objects/TILTing_Alpar-Jacobs_= CredentialDesign.pdf
If a person over 18 can transmit an access token to anybody = under 18 and if this person is then able to use that token, 
without the = server being able to detect that this is a collusion attack, then I = consider that this is a major problem. 

You = know, Bob can just buy the vodka himself and give it to her.

This is not only a major problem for OAuth = 2.0, but also a major problem for both U-Prove and Idemix, = and as a consequence for the now-closed ABC4Trust project.


earlier e-mail sent to the OAuth WG as the "ABC attack" or
the "Alice and Bob Collusion attack".

See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html

While it may be the case =
that the authors and participants of these
working groups are interested in desiging protocols that allow
non-malicious clients to gain protection for themselves from
malicious third parties even though the actual text of the charter
permits designing protections against malicious clients, it seems
that the proper response may be to reevaluate the charter text and
the desired goals from the work and the working group, rather than
to insist that this attack be considered and addressed.  =

If you have a technique = able to counter the ABC attack, then it will also protect users from = malicious third parties, 
while the = reverse is not true.
 
That is to say, though there are =
threat models in which the ABC attack is a
"real" attack, those are not necessarily the threat models in which
people are interested in working, and I do not think there is much
support for attempting to force one threat model on other WG
participants absent explicit consensus to adopt such a threat model
for the scope of some work.

-Ben


OAuth 2.0 is currently not restricting access tokens to only = contain a sufficient set of attributes that allows to fully = identify 
an individual in a given = context.

To me, this is a feature.

Since OAuth 2.0 allows access = tokens to contain non-directly identifiable = attributes, this is indeed a major problem.

Denis  

= --Apple-Mail=_076B496B-FAB5-475F-B7FF-2BF845CB6075-- --Apple-Mail=_876D62F2-0413-4BE9-9376-F4BD71A13E93 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY2VocAAoJELhJCxUKWMyZKb0H/0Ar6MpYvYWAreSd2Ymsf5in Wsd0liR3vB/xpyn2keXnfc8+PR8wY0+5qqVd2kDZdKd+Mmr4tuR2qBk8PeQF7A2i zSMoLbUF/nZswwak49xQPpiGGiJeNP0DQko+z+dDJwe+/kG3O4vKNLlBwSdEcQC9 /iLwalQMy7WT8h3gYWuYwPS0tmuNc5ZmtvISoyJi0u3NTBPF7hPjgkdDSjkezjec OlS/X4g9a8VAaMHERZSTb1bcLSaKSUhaLtlBSLt383GgAu0TP/MTo8y7Ab+IDMax 9J7yJOpdonqAn/soKb3SBhB/aOLxgijzccNrjNCMzSRyXWfHKnruAP/ox3mvGaw= =h5qx -----END PGP SIGNATURE----- --Apple-Mail=_876D62F2-0413-4BE9-9376-F4BD71A13E93-- From nobody Mon Mar 27 12:04:04 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E100E1295E7 for ; Mon, 27 Mar 2017 12:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ZtzmBcJmJImT for ; Mon, 27 Mar 2017 12:03:55 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (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 4E6C012959B for ; Mon, 27 Mar 2017 12:03:34 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 08BDF7801D2; Mon, 27 Mar 2017 21:03:30 +0200 (CEST) To: Yoav Nir References: <2069106e-5e72-cf36-63fa-4b50275c1036@free.fr> <20170326035758.GU30306@kduck.kaduk.org> <1d6be71f-f746-1fa7-d6e6-21d8201cc637@free.fr> <98069B11-A786-4DD6-84D0-EA805A527BB2@gmail.com> Cc: Benjamin Kaduk , Security Area Advisory Group From: Denis Message-ID: Date: Mon, 27 Mar 2017 21:03:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <98069B11-A786-4DD6-84D0-EA805A527BB2@gmail.com> Content-Type: multipart/alternative; boundary="------------66088ADC83638E4CCDB59248" Archived-At: Subject: Re: [saag] About Token Binding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 19:04:00 -0000 This is a multi-part message in MIME format. --------------66088ADC83638E4CCDB59248 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Yoav, My responses are embedded in the text, with "Denis:" in front of my responses. > Hi, Denis > >> On 27 Mar 2017, at 3:16, Denis > > wrote: >> >> Hi Ben, >> >>> Hi Denis, >>> >>> On Sat, Mar 25, 2017 at 04:39:06PM +0100, Denis wrote: >>>> I would like to draw your attention, on the fact that the work performed >>>> both by the OAuth WG and the Token Binding WG is currently >>>> unable to counter a major threat scenario that has been described in an >>> With all due respect, I do not believe that there is consensus to >>> apply the modifier "major" to this threat scenario. >> >> This depends of the content of the access token. > > I don’t think the question is whether this is major or minor. The > question is whether this is without our threat model or not. Denis : The threat was *not placed **voluntarily **outside of the threat model*. It is currently outside the threat model because no one thought about it. Now the threat has been identified. We can't ignore it anymore. > >> If the access token contains a sufficient number of attributes able >> to fully identify one individual in a given context, >> Bob will disagree to collaborate with Alice because Alice would then >> be able to impersonate as Bob. > > This implies that Bob has a very complex trust policy for Alice. I > don’t think this reflects the real world. “Here, Alice, take my > driver’s license. Please don’t drink too much†is far more realistic. Denis: One the contrary, this is a very simple psychology. If Bob "can be seen and taken", he won't accept, but if Bob "cannot be seen and cannot be taken", there is no danger anymore and he may accept. > >> On the contrary, if the access token*does not contain*a sufficient >> number of attributes able to fully identify one individual >> in a given context, Bob cannot be identified as being the one who got >> the access token that has been transmitted to Alice >> and thus Bob is very likely to accept to collaborate with Alice based >> on the property: "*not seen, not taken*â€. > > Regardless of the psychology of Bob, this goes against the data > minimization recommendation from RFC 6973. Denis: No it doesn't. > One of the attractive properties of OAuth is that Bob does not need to > send name, address, fingerprint and SSN to the resource server in > order to buy (for example) vodka. > All he needs to do is send a token proving he’s over 18. There is a > balance to be struck between the need to prevent Bob from misusing his > ability to get a token and > the need to limit information shared with the resource server. Denis: We agree that "All he needs to do is send a token proving he’s over 18". > If anything, the part of the process that needs to be fixed is not > that the access token is used by (not Bob), > but that Bob was able to obtain a token for (not Bob). Not that I have > a good solution for that. Denis : It seems that we agree that needs to be fixed 'one way or the other'. > But absent technical solutions that are also workable, it is enough to > say that the Authorization Server has a trust relationship with Bob, > and trusts Bob to not obtain tokens on behalf of others. Same as the > DMV trusts him not to give his driver’s license to his niece. Denis: Not exactly: Bob obtains the token for himself, but the current Token Binding mechanisms are insufficient to prevent him to forward the token to Alice so that she can successfully use it. The Authorization Server will not know that Alice indeed used the token - instead of Bob. > >> This is why I said : "This means in particular that these methods >> [U-Prove, Idemix, the IRMA Project, OpenID Connect and OAuth 2.0] >> are unable to support an ABAC (*Attribute Based Access Control*) model". >> >> Atttribute-based authentication aims to provide a mechanism for >> precisely doing this: allowing transactions on the basis of those >> attributes >> which are required for the transaction. (...) The attribute that >> is most needed now is probably the minimal-age attribute, like >> ‘over 18’. >> >> Extract from "Credential Design in Attribute-Based Identity >> Management" available at: >> https://www.cs.ru.nl/~gergely/objects/TILTing_Alpar-Jacobs_CredentialDesign.pdf >> >> If a person over 18 can transmit an access token to anybody under 18 >> and if this person is then able to use that token, >> without the server being able to detect that this is a collusion >> attack, then I consider that this is a*major*problem. > > You know, Bob can just buy the vodka himself and give it to her. Denis: Yes indeed, but the situation is worse. Since Alice has been able to get once an access token proving that she is over 18, she is then able to get any number of bottles every week without any need to bother Bob again and again: the server will remember that she is over 18 and hence it will not ask her to prove it again at every access. If she is over 18 today, obviously she will still be over 18 tomorrow. Denis > >> This is not only a*major*problem for*OAuth 2.0*, but also >> a*major*problem for both*U-Prove*and*Idemix*, and as a consequence >> for the now-closed*ABC4Trust*project. >> >>> >>>> earlier e-mail sent to the OAuth WG as the "ABC attack" or >>>> the "Alice and Bob Collusion attack". >>>> >>>> See:https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html >>> While it may be the case that the authors and participants of these >>> working groups are interested in desiging protocols that allow >>> non-malicious clients to gain protection for themselves from >>> malicious third parties even though the actual text of the charter >>> permits designing protections against malicious clients, it seems >>> that the proper response may be to reevaluate the charter text and >>> the desired goals from the work and the working group, rather than >>> to insist that this attack be considered and addressed. >> >> If you have a technique able to counter the ABC attack, then it will >> also protect users from malicious third parties, >> while the reverse is not true. >> >>> That is to say, though there are threat models in which the ABC attack is a >>> "real" attack, those are not necessarily the threat models in which >>> people are interested in working, and I do not think there is much >>> support for attempting to force one threat model on other WG >>> participants absent explicit consensus to adopt such a threat model >>> for the scope of some work. >>> >>> -Ben >> >> >> OAuth 2.0 is currently not restricting access tokens to only contain >> a sufficient set of attributes that allows to fully identify >> an individual in a given context. >> > To me, this is a feature. >> >> Since OAuth 2.0 allows access tokens to containnon-directly >> identifiable attributes, this is indeed a*major*problem. >> >> Denis > --------------66088ADC83638E4CCDB59248 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Yoav,

My responses are embedded in the text, with "Denis:" in front of my responses.

Hi, Denis

On 27 Mar 2017, at 3:16, Denis <denis.ietf@free.fr> wrote:

Hi Ben,

Hi Denis,

On Sat, Mar 25, 2017 at 04:39:06PM +0100, Denis wrote:

I would like to draw your attention, on the fact that the work performed 
both by the OAuth WG and the Token Binding WG is currently
unable to counter a major threat scenario that has been described in an 

With all due respect, I do not believe that there is consensus to
apply the modifier "major" to this threat scenario.

This depends of the content of the access token.

I don’t think the question is whether this is major or minor. The question is whether this is without our threat model or not.

Denis : The threat was not placed voluntarily outside of the threat model. It is currently outside the threat model because
no one thought about it. Now the threat has been identified. We can't ignore it anymore.



If the access token contains a sufficient number of attributes able to fully identify one individual in a given context, 
Bob will disagree to collaborate with Alice because Alice would then be able to impersonate as Bob.

This implies that Bob has a very complex trust policy for Alice. I don’t think this reflects the real world. “Here, Alice, take my driver’s license. Please don’t drink too much†is far more realistic.

Denis: One the contrary, this is a very simple psychology. If Bob "can be seen and taken", he won't accept,
but if Bob "cannot be seen and cannot be taken", there is no danger anymore and he may accept.


On the contrary, if the access token does not contain a sufficient number of attributes able to fully identify one individual 
in a given context, Bob cannot be identified as being the one who got the access token that has been transmitted to Alice
and thus Bob is very likely to accept to collaborate with Alice based on the property: "not seen, not takenâ€.

Regardless of the psychology of Bob, this goes against the data minimization recommendation from RFC 6973.

Denis: No it doesn't.

One of the attractive properties of OAuth is that Bob does not need to send name, address, fingerprint and SSN to the resource server in order to buy (for example) vodka. 
All he needs to do is send a token proving he’s over 18. There is a balance to be struck between the need to prevent Bob from misusing his ability to get a token and
the need to limit information shared with the resource server.
 
Denis: We agree that "All he needs to do is send a token proving he’s over 18".


If anything, the part of the process that needs to be fixed is not that the access token is used by (not Bob),
but that Bob was able to obtain a token for (not Bob). Not that I have a good solution for that.

Denis :  It seems that we agree that needs to be fixed 'one way or the other'.

But absent technical solutions that are also workable, it is enough to say that the Authorization Server has a trust relationship with Bob,
and trusts Bob to not obtain tokens on behalf of others. Same as the DMV trusts him not to give his driver’s license to his niece.

Denis: Not exactly: Bob obtains the token for himself, but the current Token Binding mechanisms are insufficient to prevent him to forward the token
to Alice so that she can successfully use it. The Authorization Server will not know that Alice indeed used the token - instead of Bob.


This is why I said : "This means in particular that these methods [U-Prove, Idemix, the IRMA Project, OpenID Connect and OAuth 2.0]
are unable to support an ABAC (Attribute Based Access Control) model".
Atttribute-based authentication aims to provide a mechanism for precisely doing this: allowing transactions on the basis of those attributes 
which are required for the transaction. (...) The attribute that is most needed now is probably the minimal-age attribute, like ‘over 18’.

Extract from "Credential Design in Attribute-Based Identity Management" available at:
https://www.cs.ru.nl/~gergely/objects/TILTing_Alpar-Jacobs_CredentialDesign.pdf
If a person over 18 can transmit an access token to anybody under 18 and if this person is then able to use that token, 
without the server being able to detect that this is a collusion attack, then I consider that this is a major problem. 

You know, Bob can just buy the vodka himself and give it to her.

Denis: Yes indeed, but the situation is worse. Since Alice has been able to get once an access token proving that she is over 18, she is then able
to get any number of bottles every week without any need to bother Bob again and again: the server will remember that she is over 18
and hence it will not ask her to prove it again at every access. If she is over 18 today, obviously she will still be over 18 tomorrow.

Denis


This is not only a major problem for OAuth 2.0, but also a major problem for both U-Prove and Idemix, and as a consequence 
for the now-closed ABC4Trust project.


earlier e-mail sent to the OAuth WG as the "ABC attack" or
the "Alice and Bob Collusion attack".

See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html

While it may be the case that the authors and participants of these
working groups are interested in desiging protocols that allow
non-malicious clients to gain protection for themselves from
malicious third parties even though the actual text of the charter
permits designing protections against malicious clients, it seems
that the proper response may be to reevaluate the charter text and
the desired goals from the work and the working group, rather than
to insist that this attack be considered and addressed.

If you have a technique able to counter the ABC attack, then it will also protect users from malicious third parties, 
while the reverse is not true.
 
That is to say, though there are threat models in which the ABC attack is a
"real" attack, those are not necessarily the threat models in which
people are interested in working, and I do not think there is much
support for attempting to force one threat model on other WG
participants absent explicit consensus to adopt such a threat model
for the scope of some work.

-Ben


OAuth 2.0 is currently not restricting access tokens to only contain a sufficient set of attributes that allows to fully identify 
an individual in a given context.

To me, this is a feature.

Since OAuth 2.0 allows access tokens to contain non-directly identifiable attributes, this is indeed a major problem.

Denis  


--------------66088ADC83638E4CCDB59248-- From nobody Mon Mar 27 12:06:30 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB89126579 for ; Mon, 27 Mar 2017 12:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 vQCflXZ3bHsW for ; Mon, 27 Mar 2017 12:06:27 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFCC6129408 for ; Mon, 27 Mar 2017 12:06:26 -0700 (PDT) Received: (qmail 67360 invoked from network); 27 Mar 2017 19:06:25 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 27 Mar 2017 19:06:25 -0000 Date: 27 Mar 2017 19:06:03 -0000 Message-ID: <20170327190603.95464.qmail@ary.lan> From: "John Levine" To: saag@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [saag] Hello from the Ethereum Foundation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 19:06:29 -0000 In article you write: >We wish .eth to be resolvable using the standard tools. For this we will >presumably apply for a .eth gTLD from ICANN when they open up for new gTLD >applications around 2020. However, between now and 2020, we have been >counseled to pursue the .eth name reservation through IETF. If this is the >wrong approach please say so. Barring unlikely process changes, ICANN does not allow anyone to apply for IETF reserved domain names, so you need to pick one or the other. The recent ICANN process had a 300 page application guidebook full of rules about everything from business continuity to DNSSEC signing rules and how your registry deals with the registrars that sell the names. The application fee was $180,000. The rules for the next round will be different, but I doubt they'll be very different. The IETF process is, to put it mildly, in great flux. It's addressed in the dnsop working group which happens to be meeting in person right now at the IETF Chicago meeting where I'm typing this. My main suggestion would be to learn a lot more about both the IETF name reservation process and the ICANN application process before you ask for either. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From nobody Mon Mar 27 12:10:28 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157B21270B4 for ; Mon, 27 Mar 2017 12:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=lShg6eQQ; dkim=pass (1024-bit key) header.d=yitter.info header.b=Z3J5bEo+ 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 i79lI4C-3-h3 for ; Mon, 27 Mar 2017 12:10:24 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE8712704B for ; Mon, 27 Mar 2017 12:10:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 3A2F3BB82E for ; Mon, 27 Mar 2017 19:09:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1490641794; bh=vACuKvVX37/TqWIIpZLKJQoE01vFb3PNu/MnNgkiMzQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=lShg6eQQRIUNWMujH7PLjgsYzTxAo751remNspWV1FmJz3GZRkH7lAxo+VTtjNXj6 pDFuCSwF7hjK5Hcbtfwvufg4rDvqsc3TyJG+qAFhv47+w8MwraJUFq8uCJPRBEgHEC jVyebwMQTmLCXvBCuGSCy1P5w7fH4BwGs+eNcpPE= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOTKlNrEkgQv for ; Mon, 27 Mar 2017 19:09:52 +0000 (UTC) Date: Mon, 27 Mar 2017 15:09:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1490641792; bh=vACuKvVX37/TqWIIpZLKJQoE01vFb3PNu/MnNgkiMzQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Z3J5bEo+z/9kltSgHQYpre+sKm+FIon6Td3xXsPBx7LBTCJaj7RrCZgXENIqLGyPP UcPDXCGahBgAH8jt5CnBFHCavimVqGbuf8fDdShe5e2X/XAG/fA5K22nB3t7Ulerpg 2y7E9uEm65b+BwmzVyl6QkAwKRvmRkwragdYUI+g= From: Andrew Sullivan To: saag@ietf.org Message-ID: <20170327190948.GC35484@mx4.yitter.info> References: <20170327190603.95464.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170327190603.95464.qmail@ary.lan> Archived-At: Subject: Re: [saag] Hello from the Ethereum Foundation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 19:10:26 -0000 On Mon, Mar 27, 2017 at 07:06:03PM -0000, John Levine wrote: > Barring unlikely process changes, ICANN does not allow anyone to apply > for IETF reserved domain names, so you need to pick one or the other. I don't know where that is found in the ICANN process documents. I think that _happened_ to be true in the last gTLD round, but only by enumeration for several versions of the AGB (then it was updated with a reference). > The rules for the next > round will be different, but I doubt they'll be very different. "The next round" is a problematic pointer, since ICANN is in fact trying to figure out _whether_ before it figures out _when_. But in any case, I don't believe any of this is a good idea. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Mar 27 12:22:01 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD0B1295EA for ; Mon, 27 Mar 2017 12:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xQqY1IWvjZYE for ; Mon, 27 Mar 2017 12:21:51 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 06A901295E3 for ; Mon, 27 Mar 2017 12:21:46 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id n5so41570994pgh.0 for ; Mon, 27 Mar 2017 12:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=71esb5E4EL97v/up8vNetWWd+JtskCamFQzrv0weLyI=; b=mdvvalbH81qDMKMp3+ZZ06lgiwB4daH/lTUheCId7Z85FedcpTEfdr/CsbJ6dYdzot bWZSQyiPxGNHyw8Gm9nzB8hkjVc5XjThoE2vukkhOJxV+iM8sc+hCueqJVt0G+29Z1Py w4TeBVZCSCSkoua93tRbe2nBjqP2WX9UQLnY869Lvc1f1kC+Mx/gLl6jYxt//JWWDiaE uR1PWgUpgPC6oFVFbEwLaW6hWQiqdt7BmQOW0wNUG+1oKUpim4oP6TmAcXfqLM7eWqH2 f0raOa19UGwNDrZrKM2mXzZxcNbuEJBKUT04OixJBWlLLiOWoqr5Znn9GXfyXGc1Nly8 J8MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=71esb5E4EL97v/up8vNetWWd+JtskCamFQzrv0weLyI=; b=fl0iKIxcylMIzWrhPgslXauwKlgXFe70/RikSbjmIsqlvNbIPKamBObY/E17+QTlmC USpZQqJ4Am5hwQkUnNTmweurjCMdiaSU52D64Q+6DvlXRBKsppm4mxUii2AE1YQ3BaCA GKoVNkhCj4AvSO/Lhz3K9UBtm97tJiY5davfAFvudyN+cqQjdD52ECxC3lIyr8/wHcfn hZhcjzNWEDb38Re3FxIrpQnUmoikSSjlIbWOIrSDNTipw6TrwXfruKKktZsiVnS3qkD7 6i/lmlI7FIp90bZ4pqnEjeS9mmmz/ZBytWdcGpN57JyxWHhQCzjxNDBeINquGXU6QR91 k64A== X-Gm-Message-State: AFeK/H1jZecyr2g51sI10bqc5zHXB5cZDSpCBpwJP5cE2XEKBh3voZa28n1UdK73ZqF1rNSxfUrepWDxpwDDJw== X-Received: by 10.84.143.1 with SMTP id 1mr31252512ply.70.1490642505513; Mon, 27 Mar 2017 12:21:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.183.98 with HTTP; Mon, 27 Mar 2017 12:21:45 -0700 (PDT) In-Reply-To: References: <2069106e-5e72-cf36-63fa-4b50275c1036@free.fr> <20170326035758.GU30306@kduck.kaduk.org> <1d6be71f-f746-1fa7-d6e6-21d8201cc637@free.fr> <98069B11-A786-4DD6-84D0-EA805A527BB2@gmail.com> From: Kathleen Moriarty Date: Mon, 27 Mar 2017 15:21:45 -0400 Message-ID: To: Denis Cc: Yoav Nir , Security Area Advisory Group Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] About Token Binding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 19:21:57 -0000 Hi Denis, One comment inline. On Mon, Mar 27, 2017 at 3:03 PM, Denis wrote: > Hi Yoav, > > My responses are embedded in the text, with "Denis:" in front of my > responses. > > Hi, Denis > > On 27 Mar 2017, at 3:16, Denis wrote: > > Hi Ben, > > Hi Denis, > > On Sat, Mar 25, 2017 at 04:39:06PM +0100, Denis wrote: > > I would like to draw your attention, on the fact that the work performed > both by the OAuth WG and the Token Binding WG is currently > unable to counter a major threat scenario that has been described in an > > With all due respect, I do not believe that there is consensus to > apply the modifier "major" to this threat scenario. > > > This depends of the content of the access token. > > > I don=E2=80=99t think the question is whether this is major or minor. The= question > is whether this is without our threat model or not. > > > Denis : The threat was not placed voluntarily outside of the threat model= . > It is currently outside the threat model because > no one thought about it. Now the threat has been identified. We can't ign= ore > it anymore. > > > > If the access token contains a sufficient number of attributes able to fu= lly > identify one individual in a given context, > Bob will disagree to collaborate with Alice because Alice would then be a= ble > to impersonate as Bob. > > > This implies that Bob has a very complex trust policy for Alice. I don=E2= =80=99t > think this reflects the real world. =E2=80=9CHere, Alice, take my driver= =E2=80=99s license. > Please don=E2=80=99t drink too much=E2=80=9D is far more realistic. > > > Denis: One the contrary, this is a very simple psychology. If Bob "can be > seen and taken", he won't accept, > but if Bob "cannot be seen and cannot be taken", there is no danger anymo= re > and he may accept. > > > On the contrary, if the access token does not contain a sufficient number= of > attributes able to fully identify one individual > in a given context, Bob cannot be identified as being the one who got the > access token that has been transmitted to Alice > and thus Bob is very likely to accept to collaborate with Alice based on = the > property: "not seen, not taken=E2=80=9D. > > > Regardless of the psychology of Bob, this goes against the data minimizat= ion > recommendation from RFC 6973. > > > Denis: No it doesn't. How do you come to this conclusion? Am I missing something from your explanation? I had the same reaction as Yoav when reading this thread. In line with RFC6973, we try to minimize identifying information to reduce the chance of tracking and assist in increasing user privacy. Thanks, Kathleen > > One of the attractive properties of OAuth is that Bob does not need to se= nd > name, address, fingerprint and SSN to the resource server in order to buy > (for example) vodka. > All he needs to do is send a token proving he=E2=80=99s over 18. There is= a balance > to be struck between the need to prevent Bob from misusing his ability to > get a token and > the need to limit information shared with the resource server. > > > Denis: We agree that "All he needs to do is send a token proving he=E2=80= =99s over > 18". > > > If anything, the part of the process that needs to be fixed is not that t= he > access token is used by (not Bob), > but that Bob was able to obtain a token for (not Bob). Not that I have a > good solution for that. > > > Denis : It seems that we agree that needs to be fixed 'one way or the > other'. > > But absent technical solutions that are also workable, it is enough to sa= y > that the Authorization Server has a trust relationship with Bob, > and trusts Bob to not obtain tokens on behalf of others. Same as the DMV > trusts him not to give his driver=E2=80=99s license to his niece. > > > Denis: Not exactly: Bob obtains the token for himself, but the current To= ken > Binding mechanisms are insufficient to prevent him to forward the token > to Alice so that she can successfully use it. The Authorization Server wi= ll > not know that Alice indeed used the token - instead of Bob. > > > This is why I said : "This means in particular that these methods [U-Prov= e, > Idemix, the IRMA Project, OpenID Connect and OAuth 2.0] > are unable to support an ABAC (Attribute Based Access Control) model". > > Atttribute-based authentication aims to provide a mechanism for precisely > doing this: allowing transactions on the basis of those attributes > which are required for the transaction. (...) The attribute that is most > needed now is probably the minimal-age attribute, like =E2=80=98over 18= =E2=80=99. > > Extract from "Credential Design in Attribute-Based Identity Management" > available at: > https://www.cs.ru.nl/~gergely/objects/TILTing_Alpar-Jacobs_CredentialDesi= gn.pdf > > If a person over 18 can transmit an access token to anybody under 18 and = if > this person is then able to use that token, > without the server being able to detect that this is a collusion attack, > then I consider that this is a major problem. > > > You know, Bob can just buy the vodka himself and give it to her. > > > Denis: Yes indeed, but the situation is worse. Since Alice has been able = to > get once an access token proving that she is over 18, she is then able > to get any number of bottles every week without any need to bother Bob ag= ain > and again: the server will remember that she is over 18 > and hence it will not ask her to prove it again at every access. If she i= s > over 18 today, obviously she will still be over 18 tomorrow. > > Denis > > > > This is not only a major problem for OAuth 2.0, but also a major problem = for > both U-Prove and Idemix, and as a consequence > for the now-closed ABC4Trust project. > > > earlier e-mail sent to the OAuth WG as the "ABC attack" or > the "Alice and Bob Collusion attack". > > See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html > > While it may be the case that the authors and participants of these > working groups are interested in desiging protocols that allow > non-malicious clients to gain protection for themselves from > malicious third parties even though the actual text of the charter > permits designing protections against malicious clients, it seems > that the proper response may be to reevaluate the charter text and > the desired goals from the work and the working group, rather than > to insist that this attack be considered and addressed. > > > If you have a technique able to counter the ABC attack, then it will also > protect users from malicious third parties, > while the reverse is not true. > > > That is to say, though there are threat models in which the ABC attack is= a > "real" attack, those are not necessarily the threat models in which > people are interested in working, and I do not think there is much > support for attempting to force one threat model on other WG > participants absent explicit consensus to adopt such a threat model > for the scope of some work. > > -Ben > > > OAuth 2.0 is currently not restricting access tokens to only contain a > sufficient set of attributes that allows to fully identify > an individual in a given context. > > To me, this is a feature. > > Since OAuth 2.0 allows access tokens to contain non-directly identifiable > attributes, this is indeed a major problem. > > Denis > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --=20 Best regards, Kathleen From nobody Mon Mar 27 12:23:53 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D263012704B for ; Mon, 27 Mar 2017 12:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PonSIvTXJQ_O for ; Mon, 27 Mar 2017 12:23:48 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 74C471294E7 for ; Mon, 27 Mar 2017 12:23:48 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id y18so87418813itc.0 for ; Mon, 27 Mar 2017 12:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=X3OBrRJ1wU9jVVU96hWzkJQaLzjfCr1z0owEOtwWZ6g=; b=uLUSwG0EnSdZ8UcohA0pqy8yp6aOxKCPMsqJLNiFahSfrGUtk3PRAi0oqa9+BgPu1v 978Vw6WxIP5g/39oWaCXFrtKqXiblISztIqDuaU3kzBZ8SJNFcvAPBTi9hR+m2Y3LnTM hlzn0ZfS2NtQsyHDppl+2B9YWpncscHDErAO2Kho7F8T1arMWKWaqcJGaXMWCsFiQQ1u xhglWAEoK0L0KvPs1igfvGa71sjevUc+XgV30fN770JNPdvno3w9q6lwlYOscAT3MR/z jzba1SJPd1h+loTvYLJWbX7h8PQvqSKxVq7kGyBawVRzNAlx7r5reAZhlAPfUyCGq6Dm A2Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=X3OBrRJ1wU9jVVU96hWzkJQaLzjfCr1z0owEOtwWZ6g=; b=XNNYkZmDtFL3QHc8Sa5POHr9UA7BgEO06+F6JID8cLOXpOYei96z7LcdBHcF63n0U2 u/I9U2mS5ugQkkvHl9XG2wkOCh+/TQHE9yREOCt6pJ5xZ8PPHtZfQ5RZFe1W6+/86FnT LEcT+05YJ/8L1lzEhBg5bxYwPUGXjyBITp+7BC+bKQ7+XZGaIYgi0iOl8wMf1DuYWhXd E7GJsbP+ZsI5v5MPe8g3L3qRcZRLCGp4iMljcGk656K+xKJoYNQVg5/I/U8NsaJ5rzlE givXq12/tr9gjrLYUhIgUN7QbCzPLwDgcGT9ULT5cNtQkn4LSzRBbva5+BE3QXEDlvVZ p4Xg== X-Gm-Message-State: AFeK/H1Jsx5hBpxxocRhuJEWu8aCegd4RHbHb3uR7UcDAAii4qEMkBL6vQ1lNSJmCchrjw== X-Received: by 10.36.4.88 with SMTP id 85mr11195613itb.92.1490642627758; Mon, 27 Mar 2017 12:23:47 -0700 (PDT) Received: from t2001067c0370012824bc91e97d0043f5.v6.meeting.ietf.org (t2001067c0370012824bc91e97d0043f5.v6.meeting.ietf.org. [2001:67c:370:128:24bc:91e9:7d00:43f5]) by smtp.gmail.com with ESMTPSA id n73sm686870ioe.10.2017.03.27.12.23.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 12:23:47 -0700 (PDT) From: Yoav Nir Message-Id: <0BFE41C8-FD73-4ADA-8A30-A7C7FD1F57DF@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_9449F3F6-73BC-49CA-81D1-A94E9E19B8C4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 27 Mar 2017 14:23:45 -0500 In-Reply-To: Cc: Benjamin Kaduk , Security Area Advisory Group To: Denis References: <2069106e-5e72-cf36-63fa-4b50275c1036@free.fr> <20170326035758.GU30306@kduck.kaduk.org> <1d6be71f-f746-1fa7-d6e6-21d8201cc637@free.fr> <98069B11-A786-4DD6-84D0-EA805A527BB2@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [saag] About Token Binding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 19:23:51 -0000 --Apple-Mail=_9449F3F6-73BC-49CA-81D1-A94E9E19B8C4 Content-Type: multipart/alternative; boundary="Apple-Mail=_2E93CC18-6173-4E48-9F50-DDFA846A0471" --Apple-Mail=_2E93CC18-6173-4E48-9F50-DDFA846A0471 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 27 Mar 2017, at 14:03, Denis wrote: >=20 > Hi Yoav, >=20 > My responses are embedded in the text, with "Denis:" in front of my = responses. >=20 >> Hi, Denis >>=20 >>> On 27 Mar 2017, at 3:16, Denis > wrote: >>>=20 >>> Hi Ben, >>>=20 >>>> Hi Denis, >>>>=20 >>>> On Sat, Mar 25, 2017 at 04:39:06PM +0100, Denis wrote: >>>>> I would like to draw your attention, on the fact that the work = performed >>>>> both by the OAuth WG and the Token Binding WG is currently >>>>> unable to counter a major threat scenario that has been described = in an >>>> With all due respect, I do not believe that there is consensus to >>>> apply the modifier "major" to this threat scenario. >>>=20 >>> This depends of the content of the access token. >>=20 >> I don=E2=80=99t think the question is whether this is major or minor. = The question is whether this is without our threat model or not. >=20 > Denis : The threat was not placed voluntarily outside of the threat = model. It is currently outside the threat model because > no one thought about it. Now the threat has been identified. We can't = ignore it anymore. !ignore !=3D MUST solve >>=20 >>> If the access token contains a sufficient number of attributes able = to fully identify one individual in a given context, >>> Bob will disagree to collaborate with Alice because Alice would then = be able to impersonate as Bob. >>=20 >> This implies that Bob has a very complex trust policy for Alice. I = don=E2=80=99t think this reflects the real world. =E2=80=9CHere, Alice, = take my driver=E2=80=99s license. Please don=E2=80=99t drink too much=E2=80= =9D is far more realistic. >=20 > Denis: One the contrary, this is a very simple psychology. If Bob "can = be seen and taken", he won't accept, > but if Bob "cannot be seen and cannot be taken", there is no danger = anymore and he may accept. And yet people give their driver=E2=80=99s licenses and credit cards to = others all the time. >>> On the contrary, if the access token does not contain a sufficient = number of attributes able to fully identify one individual >>> in a given context, Bob cannot be identified as being the one who = got the access token that has been transmitted to Alice >>> and thus Bob is very likely to accept to collaborate with Alice = based on the property: "not seen, not taken=E2=80=9D. >>=20 >> Regardless of the psychology of Bob, this goes against the data = minimization recommendation from RFC 6973. >=20 > Denis: No it doesn't. >=20 >> One of the attractive properties of OAuth is that Bob does not need = to send name, address, fingerprint and SSN to the resource server in = order to buy (for example) vodka. >> All he needs to do is send a token proving he=E2=80=99s over 18. = There is a balance to be struck between the need to prevent Bob from = misusing his ability to get a token and >> the need to limit information shared with the resource server. >=20 > Denis: We agree that "All he needs to do is send a token proving = he=E2=80=99s over 18=E2=80=9D. Except that you are advocating =E2=80=9Ca sufficient number of = attributes able to fully identify one individual=E2=80=9D in the access = token. >> If anything, the part of the process that needs to be fixed is not = that the access token is used by (not Bob), >> but that Bob was able to obtain a token for (not Bob). Not that I = have a good solution for that. >=20 > Denis : It seems that we agree that needs to be fixed 'one way or the = other'. >=20 >> But absent technical solutions that are also workable, it is enough = to say that the Authorization Server has a trust relationship with Bob, >> and trusts Bob to not obtain tokens on behalf of others. Same as the = DMV trusts him not to give his driver=E2=80=99s license to his niece. >=20 > Denis: Not exactly: Bob obtains the token for himself, but the current = Token Binding mechanisms are insufficient to prevent him to forward the = token > to Alice so that she can successfully use it. The Authorization Server = will not know that Alice indeed used the token - instead of Bob. Somebody=E2=80=99s going to accuse me of semantic hair-splitting, but = here goes. Alice opened account =E2=80=9Cbieberfan2001=E2=80=9D at = vodkaRus.com . vodkaRus requests an authorization = token proving that the person behind bieberfan2001 is over 18, so = vodkaRus creates a token request, which Alice forwards to Bob, who = forwards it to the authorization server, dmv.org . Bob = didn=E2=80=99t get a token for himself - he got a token for an account = he has no access to. He got the token for bieberfan2001 by falsely = representing to dmv.org that he was the real person = behind bieberfan2001. >>> This is why I said : "This means in particular that these methods = [U-Prove, Idemix, the IRMA Project, OpenID Connect and OAuth 2.0] >>> are unable to support an ABAC (Attribute Based Access Control) = model". >>> Atttribute-based authentication aims to provide a mechanism for = precisely doing this: allowing transactions on the basis of those = attributes >>> which are required for the transaction. (...) The attribute that is = most needed now is probably the minimal-age attribute, like =E2=80=98over = 18=E2=80=99. >>>=20 >>> Extract from "Credential Design in Attribute-Based Identity = Management" available at: >>> = https://www.cs.ru.nl/~gergely/objects/TILTing_Alpar-Jacobs_CredentialDesig= n.pdf = >>> If a person over 18 can transmit an access token to anybody under 18 = and if this person is then able to use that token, >>> without the server being able to detect that this is a collusion = attack, then I consider that this is a major problem. >>=20 >> You know, Bob can just buy the vodka himself and give it to her. >=20 > Denis: Yes indeed, but the situation is worse. Since Alice has been = able to get once an access token proving that she is over 18, she is = then able > to get any number of bottles every week without any need to bother Bob = again and again: the server will remember that she is over 18 > and hence it will not ask her to prove it again at every access. If = she is over 18 today, obviously she will still be over 18 tomorrow. And the big question is: do we care? Does dmv.org = care? Yoav --Apple-Mail=_2E93CC18-6173-4E48-9F50-DDFA846A0471 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 27 Mar 2017, at 14:03, Denis <denis.ietf@free.fr> = wrote:

Hi Yoav,

My responses are embedded in the text, with "Denis:" in front = of my responses.

Hi, Denis

On 27 Mar 2017, at 3:16, Denis <denis.ietf@free.fr> wrote:

Hi Ben,

Hi Denis,

On Sat, Mar 25, 2017 at 04:39:06PM +0100, Denis wrote:

I =
would like to draw your attention, on the fact that the work performed=20=

both by the OAuth WG and the Token Binding WG is currently
unable to counter a major threat scenario that has been described in an=20=


With all due respect, I do =
not believe that there is consensus to
apply the modifier "major" to this threat scenario.

This depends of = the content of the access token.

I don=E2=80=99t think the question is whether this is = major or minor. The question is whether this is without our threat model = or not.

Denis : The threat = was not = placed voluntarily outside of the threat model. It is currently outside the = threat model because no one thought about it. Now the threat has been identified. = We can't ignore it anymore.

!ignore !=3D = MUST solve 


If the access token contains a sufficient number of = attributes able to fully identify one individual in a given = context, 
Bob will disagree to collaborate with Alice because Alice = would then be able to impersonate as Bob.

This implies that Bob has a very complex trust policy = for Alice. I don=E2=80=99t think this reflects the real world. =E2=80=9CHe= re, Alice, take my driver=E2=80=99s license. Please don=E2=80=99t drink = too much=E2=80=9D is far more realistic. 

Denis: One the = contrary, this is a very simple psychology. If Bob "can be seen and taken", he won't = accept, 
but if Bob "cannot be seen and cannot be taken", there is no = danger anymore and he may accept.

And yet people give their driver=E2=80=99s = licenses and credit cards to others all the time.

On the contrary, if the access token does not = contain a = sufficient number of attributes able to fully identify one = individual 
in a given context, Bob cannot be identified as being the one = who got the access token that has been transmitted to Alice
and thus Bob is very likely to accept to collaborate with = Alice based on the property: "not seen, not taken=E2=80=9D.

Regardless of the psychology of Bob, this goes against = the data minimization recommendation from RFC 6973. 

Denis: No it = doesn't.

One of the attractive properties of OAuth is that Bob does = not need to send name, address, fingerprint and SSN to the resource = server in order to buy (for example) vodka.  
All he needs to do is send a token proving = he=E2=80=99s over 18. There is a balance to be struck between the = need to prevent Bob from misusing his ability to get a token and 
the need to = limit information shared with the resource = server.
 
Denis: We agree that = "All he needs to do is send a token proving he=E2=80=99s over = 18=E2=80=9D.

Except that you are advocating =E2=80=9Ca sufficient number of = attributes able to fully identify one individual=E2=80=9D in the = access token.

If anything, the part of the process that needs to be fixed = is not that the access token is used by (not Bob), 
but that Bob = was able to obtain a token for (not Bob). Not that I have a good = solution for that. 

Denis :  It seems that we agree that needs to be = fixed 'one way or the other'.

But absent technical solutions that are also workable, it is = enough to say that the Authorization Server has a trust relationship = with Bob, 
and trusts Bob to not obtain tokens on behalf of others. Same = as the DMV trusts him not to give his driver=E2=80=99s license to his = niece.

Denis: Not exactly: = Bob obtains the token for himself, but the current Token Binding = mechanisms are insufficient to prevent him to forward the token 
to Alice so = that she can successfully use it. The Authorization Server will not know = that Alice indeed used the token - instead of Bob.

Somebody=E2=80= =99s going to accuse me of semantic hair-splitting, but here goes. =  Alice opened account =E2=80=9Cbieberfan2001=E2=80=9D at vodkaRus.com.  vodkaRus = requests an authorization token proving that the person behind = bieberfan2001 is over 18, so vodkaRus creates a token request, which = Alice forwards to Bob, who forwards it to the authorization server, dmv.org . Bob didn=E2=80=99t = get a token for himself - he got a token for an account he has no access = to. He got the token for bieberfan2001 by falsely representing to dmv.org that he was the real = person behind bieberfan2001.

This is why I said : "This means in particular that these methods = [U-Prove, Idemix, the IRMA Project, OpenID Connect and OAuth 2.0]
are unable to support an ABAC (Attribute Based = Access Control) model".
Atttribute-based authentication = aims to provide a mechanism for precisely doing this: allowing = transactions on the basis of those attributes 
which are = required for the transaction. (...) The attribute that is most needed = now is probably the minimal-age attribute, like =E2=80=98over 18=E2=80=99.=

Extract from "Credential Design in = Attribute-Based Identity Management" available at:
https://www.cs.ru.nl/~gergely/objects/TILTing_Alpar-Jacob= s_CredentialDesign.pdf
If a person over 18 can transmit an access token to anybody under = 18 and if this person is then able to use that token, 
without the = server being able to detect that this is a collusion attack, then I = consider that this is a major problem. 

You know, Bob can just buy the vodka = himself and give it to her.

Denis: Yes indeed, but the situation is worse. Since = Alice has been able to get once an access token proving that she is over = 18, she is then able to get any number of bottles every week without any need to = bother Bob again and again: the server will remember that she is over = 18 
and = hence it will not ask her to prove it again at every access. If she is = over 18 today, obviously she will still be over 18 tomorrow.

And the = big question is: do we care?  Does dmv.org care?

Yoav

= --Apple-Mail=_2E93CC18-6173-4E48-9F50-DDFA846A0471-- --Apple-Mail=_9449F3F6-73BC-49CA-81D1-A94E9E19B8C4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY2WbCAAoJELhJCxUKWMyZW54H+wX3ySlnM4Ril3qx6+ugL1Ye gHykF68mDE5Zdbm5/RS3lTjmsO6PJShzkCgqOygm+e+gmzIZgbtIv0mPDjgLMLSs pzRL8lxXxedoY7/XUO+xHbfdWmusgo7z+vCHu1etS641dkg3CH3rr1L8Ov5iXOUa 1BgL6CniiBgyU1OZzEdeV5D9q96oPHS2Jhe7oeEg/HIesOW4KcNlqxTz7UWUqKKe qn2C2CyoW+ACdYJ8lpGPlNc+jGxZ5/QPqKwGy0FGXkYWEgR6EQEOLonH7n3gQmbg QndTkL30wgEbirEyP4ukWcfcYvYfEexYSdLgEHxpTcuDUYKY7CqvC54aYxXD114= =tOZq -----END PGP SIGNATURE----- --Apple-Mail=_9449F3F6-73BC-49CA-81D1-A94E9E19B8C4-- From nobody Mon Mar 27 12:58:37 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFE61288B8 for ; Mon, 27 Mar 2017 12:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 dxvIBbT1LzfE for ; Mon, 27 Mar 2017 12:58:28 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (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 CBEA81294B3 for ; Mon, 27 Mar 2017 12:58:27 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 4B58D78035D; Mon, 27 Mar 2017 21:58:25 +0200 (CEST) To: Kathleen Moriarty References: <2069106e-5e72-cf36-63fa-4b50275c1036@free.fr> <20170326035758.GU30306@kduck.kaduk.org> <1d6be71f-f746-1fa7-d6e6-21d8201cc637@free.fr> <98069B11-A786-4DD6-84D0-EA805A527BB2@gmail.com> Cc: Yoav Nir , Security Area Advisory Group From: Denis Message-ID: <0fb702f0-196a-e916-897e-41692aa23050@free.fr> Date: Mon, 27 Mar 2017 21:58:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5768A060C3C136D519F36E5F" Archived-At: Subject: Re: [saag] About Token Binding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 19:58:32 -0000 This is a multi-part message in MIME format. --------------5768A060C3C136D519F36E5F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Kathleen, I am advocating that the token contains an attribute 'over 18' but no other attribute(s) that would allow to uniquely identify Bob. For example, it might also contain (if needed) another attribute like "my home address is in North Carolina". This is along data minimization which is one of the principles of privacy by design. So I meant that if the access token does NOT contain a sufficient number of attributes able to uniquely identify Bob then Bob is very likely to accept to collaborate with Alice based on the property: "not seen, not takenâ€. Denis > Hi Denis, > > One comment inline. > > On Mon, Mar 27, 2017 at 3:03 PM, Denis wrote: >> Hi Yoav, >> >> My responses are embedded in the text, with "Denis:" in front of my >> responses. >> >> Hi, Denis >> >> On 27 Mar 2017, at 3:16, Denis wrote: >> >> Hi Ben, >> >> Hi Denis, >> >> On Sat, Mar 25, 2017 at 04:39:06PM +0100, Denis wrote: >> >> I would like to draw your attention, on the fact that the work performed >> both by the OAuth WG and the Token Binding WG is currently >> unable to counter a major threat scenario that has been described in an >> >> With all due respect, I do not believe that there is consensus to >> apply the modifier "major" to this threat scenario. >> >> >> This depends of the content of the access token. >> >> >> I don’t think the question is whether this is major or minor. The question >> is whether this is without our threat model or not. >> >> >> Denis : The threat was not placed voluntarily outside of the threat model. >> It is currently outside the threat model because >> no one thought about it. Now the threat has been identified. We can't ignore >> it anymore. >> >> >> >> If the access token contains a sufficient number of attributes able to fully >> identify one individual in a given context, >> Bob will disagree to collaborate with Alice because Alice would then be able >> to impersonate as Bob. >> >> >> This implies that Bob has a very complex trust policy for Alice. I don’t >> think this reflects the real world. “Here, Alice, take my driver’s license. >> Please don’t drink too much†is far more realistic. >> >> >> Denis: One the contrary, this is a very simple psychology. If Bob "can be >> seen and taken", he won't accept, >> but if Bob "cannot be seen and cannot be taken", there is no danger anymore >> and he may accept. >> >> >> On the contrary, if the access token does not contain a sufficient number of >> attributes able to fully identify one individual >> in a given context, Bob cannot be identified as being the one who got the >> access token that has been transmitted to Alice >> and thus Bob is very likely to accept to collaborate with Alice based on the >> property: "not seen, not takenâ€. >> >> >> Regardless of the psychology of Bob, this goes against the data minimization >> recommendation from RFC 6973. >> >> >> Denis: No it doesn't. > How do you come to this conclusion? Am I missing something from your > explanation? I had the same reaction as Yoav when reading this > thread. In line with RFC6973, we try to minimize identifying > information to reduce the chance of tracking and assist in increasing > user privacy. > > > Thanks, > Kathleen >> One of the attractive properties of OAuth is that Bob does not need to send >> name, address, fingerprint and SSN to the resource server in order to buy >> (for example) vodka. >> All he needs to do is send a token proving he’s over 18. There is a balance >> to be struck between the need to prevent Bob from misusing his ability to >> get a token and >> the need to limit information shared with the resource server. >> >> >> Denis: We agree that "All he needs to do is send a token proving he’s over >> 18". >> >> >> If anything, the part of the process that needs to be fixed is not that the >> access token is used by (not Bob), >> but that Bob was able to obtain a token for (not Bob). Not that I have a >> good solution for that. >> >> >> Denis : It seems that we agree that needs to be fixed 'one way or the >> other'. >> >> But absent technical solutions that are also workable, it is enough to say >> that the Authorization Server has a trust relationship with Bob, >> and trusts Bob to not obtain tokens on behalf of others. Same as the DMV >> trusts him not to give his driver’s license to his niece. >> >> >> Denis: Not exactly: Bob obtains the token for himself, but the current Token >> Binding mechanisms are insufficient to prevent him to forward the token >> to Alice so that she can successfully use it. The Authorization Server will >> not know that Alice indeed used the token - instead of Bob. >> >> >> This is why I said : "This means in particular that these methods [U-Prove, >> Idemix, the IRMA Project, OpenID Connect and OAuth 2.0] >> are unable to support an ABAC (Attribute Based Access Control) model". >> >> Atttribute-based authentication aims to provide a mechanism for precisely >> doing this: allowing transactions on the basis of those attributes >> which are required for the transaction. (...) The attribute that is most >> needed now is probably the minimal-age attribute, like ‘over 18’. >> >> Extract from "Credential Design in Attribute-Based Identity Management" >> available at: >> https://www.cs.ru.nl/~gergely/objects/TILTing_Alpar-Jacobs_CredentialDesign.pdf >> >> If a person over 18 can transmit an access token to anybody under 18 and if >> this person is then able to use that token, >> without the server being able to detect that this is a collusion attack, >> then I consider that this is a major problem. >> >> >> You know, Bob can just buy the vodka himself and give it to her. >> >> >> Denis: Yes indeed, but the situation is worse. Since Alice has been able to >> get once an access token proving that she is over 18, she is then able >> to get any number of bottles every week without any need to bother Bob again >> and again: the server will remember that she is over 18 >> and hence it will not ask her to prove it again at every access. If she is >> over 18 today, obviously she will still be over 18 tomorrow. >> >> Denis >> >> >> >> This is not only a major problem for OAuth 2.0, but also a major problem for >> both U-Prove and Idemix, and as a consequence >> for the now-closed ABC4Trust project. >> >> >> earlier e-mail sent to the OAuth WG as the "ABC attack" or >> the "Alice and Bob Collusion attack". >> >> See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html >> >> While it may be the case that the authors and participants of these >> working groups are interested in desiging protocols that allow >> non-malicious clients to gain protection for themselves from >> malicious third parties even though the actual text of the charter >> permits designing protections against malicious clients, it seems >> that the proper response may be to reevaluate the charter text and >> the desired goals from the work and the working group, rather than >> to insist that this attack be considered and addressed. >> >> >> If you have a technique able to counter the ABC attack, then it will also >> protect users from malicious third parties, >> while the reverse is not true. >> >> >> That is to say, though there are threat models in which the ABC attack is a >> "real" attack, those are not necessarily the threat models in which >> people are interested in working, and I do not think there is much >> support for attempting to force one threat model on other WG >> participants absent explicit consensus to adopt such a threat model >> for the scope of some work. >> >> -Ben >> >> >> OAuth 2.0 is currently not restricting access tokens to only contain a >> sufficient set of attributes that allows to fully identify >> an individual in a given context. >> >> To me, this is a feature. >> >> Since OAuth 2.0 allows access tokens to contain non-directly identifiable >> attributes, this is indeed a major problem. >> >> Denis >> >> >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > --------------5768A060C3C136D519F36E5F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Kathleen,

I am advocating that the token contains an attribute 'over 18' but no other attribute(s) that would allow to uniquely identify Bob.

For example, it might also contain (if needed) another attribute like "my home address is in North Carolina".
This is along data minimization which is one of the principles of privacy by design.

So I meant that if the access token does NOT contain a sufficient number of attributes able to uniquely identify Bob
then Bob is very likely to accept to collaborate with Alice based on the property: "not seen, not takenâ€.

Denis


Hi Denis,

One comment inline.

On Mon, Mar 27, 2017 at 3:03 PM, Denis <denis.ietf@free.fr> wrote:

Hi Yoav,

My responses are embedded in the text, with "Denis:" in front of my
responses.

Hi, Denis

On 27 Mar 2017, at 3:16, Denis <denis.ietf@free.fr> wrote:

Hi Ben,

Hi Denis,

On Sat, Mar 25, 2017 at 04:39:06PM +0100, Denis wrote:

I would like to draw your attention, on the fact that the work performed
both by the OAuth WG and the Token Binding WG is currently
unable to counter a major threat scenario that has been described in an

With all due respect, I do not believe that there is consensus to
apply the modifier "major" to this threat scenario.


This depends of the content of the access token.


I don’t think the question is whether this is major or minor. The question
is whether this is without our threat model or not.


Denis : The threat was not placed voluntarily outside of the threat model.
It is currently outside the threat model because
no one thought about it. Now the threat has been identified. We can't ignore
it anymore.



If the access token contains a sufficient number of attributes able to fully
identify one individual in a given context,
Bob will disagree to collaborate with Alice because Alice would then be able
to impersonate as Bob.


This implies that Bob has a very complex trust policy for Alice. I don’t
think this reflects the real world. “Here, Alice, take my driver’s license.
Please don’t drink too much†is far more realistic.


Denis: One the contrary, this is a very simple psychology. If Bob "can be
seen and taken", he won't accept,
but if Bob "cannot be seen and cannot be taken", there is no danger anymore
and he may accept.


On the contrary, if the access token does not contain a sufficient number of
attributes able to fully identify one individual
in a given context, Bob cannot be identified as being the one who got the
access token that has been transmitted to Alice
and thus Bob is very likely to accept to collaborate with Alice based on the
property: "not seen, not takenâ€.


Regardless of the psychology of Bob, this goes against the data minimization
recommendation from RFC 6973.


Denis: No it doesn't.

How do you come to this conclusion?  Am I missing something from your
explanation?  I had the same reaction as Yoav when reading this
thread.  In line with RFC6973, we try to minimize identifying
information to reduce the chance of tracking and assist in increasing
user privacy.


Thanks,
Kathleen

One of the attractive properties of OAuth is that Bob does not need to send
name, address, fingerprint and SSN to the resource server in order to buy
(for example) vodka.
All he needs to do is send a token proving he’s over 18. There is a balance
to be struck between the need to prevent Bob from misusing his ability to
get a token and
the need to limit information shared with the resource server.


Denis: We agree that "All he needs to do is send a token proving he’s over
18".


If anything, the part of the process that needs to be fixed is not that the
access token is used by (not Bob),
but that Bob was able to obtain a token for (not Bob). Not that I have a
good solution for that.


Denis :  It seems that we agree that needs to be fixed 'one way or the
other'.

But absent technical solutions that are also workable, it is enough to say
that the Authorization Server has a trust relationship with Bob,
and trusts Bob to not obtain tokens on behalf of others. Same as the DMV
trusts him not to give his driver’s license to his niece.


Denis: Not exactly: Bob obtains the token for himself, but the current Token
Binding mechanisms are insufficient to prevent him to forward the token
to Alice so that she can successfully use it. The Authorization Server will
not know that Alice indeed used the token - instead of Bob.


This is why I said : "This means in particular that these methods [U-Prove,
Idemix, the IRMA Project, OpenID Connect and OAuth 2.0]
are unable to support an ABAC (Attribute Based Access Control) model".

Atttribute-based authentication aims to provide a mechanism for precisely
doing this: allowing transactions on the basis of those attributes
which are required for the transaction. (...) The attribute that is most
needed now is probably the minimal-age attribute, like ‘over 18’.

Extract from "Credential Design in Attribute-Based Identity Management"
available at:
https://www.cs.ru.nl/~gergely/objects/TILTing_Alpar-Jacobs_CredentialDesign.pdf

If a person over 18 can transmit an access token to anybody under 18 and if
this person is then able to use that token,
without the server being able to detect that this is a collusion attack,
then I consider that this is a major problem.


You know, Bob can just buy the vodka himself and give it to her.


Denis: Yes indeed, but the situation is worse. Since Alice has been able to
get once an access token proving that she is over 18, she is then able
to get any number of bottles every week without any need to bother Bob again
and again: the server will remember that she is over 18
and hence it will not ask her to prove it again at every access. If she is
over 18 today, obviously she will still be over 18 tomorrow.

Denis



This is not only a major problem for OAuth 2.0, but also a major problem for
both U-Prove and Idemix, and as a consequence
for the now-closed ABC4Trust project.


earlier e-mail sent to the OAuth WG as the "ABC attack" or
the "Alice and Bob Collusion attack".

See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html

While it may be the case that the authors and participants of these
working groups are interested in desiging protocols that allow
non-malicious clients to gain protection for themselves from
malicious third parties even though the actual text of the charter
permits designing protections against malicious clients, it seems
that the proper response may be to reevaluate the charter text and
the desired goals from the work and the working group, rather than
to insist that this attack be considered and addressed.


If you have a technique able to counter the ABC attack, then it will also
protect users from malicious third parties,
while the reverse is not true.


That is to say, though there are threat models in which the ABC attack is a
"real" attack, those are not necessarily the threat models in which
people are interested in working, and I do not think there is much
support for attempting to force one threat model on other WG
participants absent explicit consensus to adopt such a threat model
for the scope of some work.

-Ben


OAuth 2.0 is currently not restricting access tokens to only contain a
sufficient set of attributes that allows to fully identify
an individual in a given context.

To me, this is a feature.

Since OAuth 2.0 allows access tokens to contain non-directly identifiable
attributes, this is indeed a major problem.

Denis




_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag


--------------5768A060C3C136D519F36E5F-- From nobody Mon Mar 27 13:56:29 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570DC129640 for ; Mon, 27 Mar 2017 13:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 t5IwPEk7VOmP for ; Mon, 27 Mar 2017 13:56:26 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46E2129636 for ; Mon, 27 Mar 2017 13:56:25 -0700 (PDT) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id 0E91E608B4; Mon, 27 Mar 2017 22:56:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1490648184; bh=TadJ4XR6eqvN9tWJsZ2GgcTkpUq0b1tcEC2jZ2F6nfo=; h=Date:From:To; b=G8AOgnZMSVZ9Z6CxAGlrm9RTAFQ3W1A2tkHt0Oz4zqWrkk5gZRPMwavcbVOOgCxtk eQcNAOvae1e4IvE0gvxWum5CByYbuipw05JepO6LMFc9MPHQWEvHJTJl4RzodweyJb 3n1LPdQfmHsZn6DchM+GqJ4iTPpGzgawqUrR06AY= Date: Mon, 27 Mar 2017 22:56:23 +0200 (CEST) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: Andrew Sullivan Cc: saag@ietf.org Message-ID: <1548121100.5379.1490648183855.JavaMail.zimbra@nic.cz> In-Reply-To: <20170327190948.GC35484@mx4.yitter.info> References: <20170327190603.95464.qmail@ary.lan> <20170327190948.GC35484@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - SAF10 (Linux)/8.7.0_GA_1659) Thread-Topic: Hello from the Ethereum Foundation Thread-Index: ijvzd4Vf0QV6H+Jchj/nhni/8mvQ4Q== X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [saag] Hello from the Ethereum Foundation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 20:56:28 -0000 ----- Original Message ----- > From: "Andrew Sullivan" > To: saag@ietf.org > Sent: Monday, 27 March, 2017 21:09:48 > Subject: Re: [saag] Hello from the Ethereum Foundation [...] > But in any case, I don't believe any of this is a good idea. I am with Andrew on this. I believe that you would have a very convincing arguments why you need TLD for your use-case, and why Ethereum is so special (all I saw in your email were just opinions). It seems to me that the reasons for requesting .eth are just pure cosmetics, as eth. would serve you as good as .eth for experimenting with block-chain zones. Cheers, -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- From nobody Mon Mar 27 14:05:13 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0CC12962E for ; Mon, 27 Mar 2017 14:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 iX_1H7SUeQne for ; Mon, 27 Mar 2017 14:05:09 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B48E129674 for ; Mon, 27 Mar 2017 14:05:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 134BA200A3 for ; Mon, 27 Mar 2017 17:28:57 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 441A9636E0 for ; Mon, 27 Mar 2017 17:05:08 -0400 (EDT) From: Michael Richardson To: saag@ietf.org In-Reply-To: <1548121100.5379.1490648183855.JavaMail.zimbra@nic.cz> References: <20170327190603.95464.qmail@ary.lan> <20170327190948.GC35484@mx4.yitter.info> <1548121100.5379.1490648183855.JavaMail.zimbra@nic.cz> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] Hello from the Ethereum Foundation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 21:05:12 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ond=C5=99ej Sur=C3=BD wrote: > I am with Andrew on this. I believe that you would have a very > convincing arguments why you need TLD for your use-case, and why > Ethereum is so special (all I saw in your email were just opinions). > It seems to me that the reasons for requesting .eth are just pure > cosmetics, as eth. would serve you as good as .eth for > experimenting with block-chain zones. I think, because anyone who has the block-chain data verified, can authoritatively serve/resolve queries against this zone without reference to any other authority. As such, it would be more similar to onion. and homenet., except that the names could *also* be publically resolvable via port-53. eth., would be subject to policy whims of , and National Security Letters against , which would affect users who see the data via port-53. I also think that this zone would have some strange DNSSEC status, because I don't think we can easily secure it with DNSSEC, and yet it should perhaps be considered secure. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljZfoEACgkQgItw+93Q 3WWMzAf/aPxs/96U3B8brf1P6LkyolSVOoF8UaUZJnueyIWuAgVK08RVsHjpx7KC 2L+Tb1I/wmM5RUzVino6AsxRZxt8vp1O/xF0dl8cB4+gCydN9Jdok7gmq7lb+xQw teLBe/oQLV/hELLspqhZklNc5I6rYBkNY2imCdrvk3CEcxNQuSJWuAICQziCCMk9 ZUSBdScm5o/j+bQGYqmmEiPFbWM2e7PJm+T7TJWxGphZzy8n0LWTG4gg95SRSjNI xUVv4lJRj3/NO1CnSCY7wVrGBldNrqk/DhdaQ7dHnoEG/BPrafgrg3rHeQGcjiu0 mA0qQeK0VztgYWRfyovUXGWw1C5n2A== =80xR -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 27 14:29:21 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B7D12773A for ; Mon, 27 Mar 2017 14:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=EFS9im4r; dkim=pass (1024-bit key) header.d=yitter.info header.b=IBiP36qq 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 3U7y7OxdBT6P for ; Mon, 27 Mar 2017 14:29:16 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B32126DEE for ; Mon, 27 Mar 2017 14:29:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 114C8BB82E for ; Mon, 27 Mar 2017 21:28:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1490650126; bh=IOvZ69nDs9lU28tj1eMNv8wj3n90i1Edr4NVQJLxRjQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=EFS9im4rg9ICTU7D4/dcm+UAuRIfH7bNeLxx9yNj4n2kq0I4WzgFVEj2NC59aJA/a 16B75Z7ymFBE3h6ou68IO0pFfk75zVmBu5YGccAaJftJrtNON1k2+PpB7tmIZG+4CI xJO1npOgod4CTxZmg/UhVI/gowjl2sEwDBoi00ss= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRHrOmkKzl6z for ; Mon, 27 Mar 2017 21:28:44 +0000 (UTC) Date: Mon, 27 Mar 2017 17:28:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1490650124; bh=IOvZ69nDs9lU28tj1eMNv8wj3n90i1Edr4NVQJLxRjQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=IBiP36qqWSMBZa8umppKbx8K2mX76DvQOtpRP27Kj2+Hw4aRBdCVr7ZD1VxXBBPaX ts7nW3LXcZp+Pdf6bOyVkeWbKEx84lRrKG54kctVXjczXE0HidvRoIZMAFwImLGzcg qcGWlbaEkC1gNzpSV0PjJ70ZQYItz5ThDlfPe9R0= From: Andrew Sullivan To: saag@ietf.org Message-ID: <20170327212842.GE36142@mx4.yitter.info> References: <20170327190603.95464.qmail@ary.lan> <20170327190948.GC35484@mx4.yitter.info> <1548121100.5379.1490648183855.JavaMail.zimbra@nic.cz> <7458.1490648708@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7458.1490648708@obiwan.sandelman.ca> Archived-At: Subject: Re: [saag] Hello from the Ethereum Foundation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 21:29:18 -0000 On Mon, Mar 27, 2017 at 05:05:08PM -0400, Michael Richardson wrote: > > As such, it would be more similar to onion. and homenet., except that the > names could *also* be publically resolvable via port-53. Since homenet. hasn't reached IETF consensus yet, it seems a problematic example here, so I'll set it aside. The "except" above is waving away the important difference here. The reservation of onion. is the reservation of an in-band protocol control switch: if you get a name beneath onion., you're _never_ supposed to look it up in DNS. You're supposed to use a different protocol. The proposed eth. case appears not to do that -- instead it is specifying a use _in_ the DNS, which means that it's just like any other delegation in the DNS and ought to be correctly delegated from the parent zone according to that zone's delegation policies. That's not a special-use name. It's just a name in the DNS. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Mar 27 15:19:40 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7707B126BFD for ; Mon, 27 Mar 2017 15:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 NsrvcB2YIQQy for ; Mon, 27 Mar 2017 15:19:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6898129479 for ; Mon, 27 Mar 2017 15:19:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id ACFBA200A3; Mon, 27 Mar 2017 18:43:24 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B5DB5636E0; Mon, 27 Mar 2017 18:19:35 -0400 (EDT) From: Michael Richardson To: Andrew Sullivan cc: saag@ietf.org In-Reply-To: <20170327212842.GE36142@mx4.yitter.info> References: <20170327190603.95464.qmail@ary.lan> <20170327190948.GC35484@mx4.yitter.info> <1548121100.5379.1490648183855.JavaMail.zimbra@nic.cz> <7458.1490648708@obiwan.sandelman.ca> <20170327212842.GE36142@mx4.yitter.info> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] Hello from the Ethereum Foundation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 22:19:39 -0000 --=-=-= Content-Type: text/plain Andrew Sullivan wrote: > The proposed eth. case appears not to do that -- instead it is > specifying a use _in_ the DNS, which means that it's just like any > other delegation in the DNS and ought to be correctly delegated from > the parent zone according to that zone's delegation policies. That's > not a special-use name. It's just a name in the DNS. I agree with you. The *except* matters a lot... and I wasn't trying to gloss it over. But, it is *also* a protocol switch that says you can resolve this DNS name, without using port-53. I think it's a pretty hairy situation, and I agree that neither ICANN nor IETF route is appropriate as yet. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljZj/MACgkQgItw+93Q 3WWa1AgAlmijSggGe997/vcvDT293y93K6UW3zOlUq66hfAGVNYg4IWOfWlkWc3p zDc0SfLkkfCDHn2+VJM3k6K1evmRVopDcDo5ZdJZ5LX5qaZ953itGfe8t8ikqn9X 7kD1z2Csl+zeVsxQY8hvwcfo1+PtNnrBNDkYiLTs0grAouHOtIOjhaFYxVaNSZ3v Th758reuQ65/+QVon2aeUWaVE5yst3xeIkUxXjtJBvLHfyFgs/fVFxCij5FhsZAW 316P5GIp8wkzNJDUWpJlWVOaDOHVBY4CwhPHRG1Vu1N3OnZn4jJJFPsJFATVyHz5 CBaNpHfH01yy5lsFIcg0LeFvYujIpw== =DANW -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 27 16:09:48 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616511296BF for ; Mon, 27 Mar 2017 16:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 8Uecp5d7g_vU for ; Mon, 27 Mar 2017 16:09:46 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096FB1296B9 for ; Mon, 27 Mar 2017 16:09:45 -0700 (PDT) Received: (qmail 8452 invoked from network); 27 Mar 2017 23:09:43 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 27 Mar 2017 23:09:43 -0000 Date: 27 Mar 2017 23:09:21 -0000 Message-ID: <20170327230921.972.qmail@ary.lan> From: "John Levine" To: saag@ietf.org In-Reply-To: <20170327212842.GE36142@mx4.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [saag] Hello from the Ethereum Foundation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 23:09:47 -0000 In article <20170327212842.GE36142@mx4.yitter.info> you write: >The proposed eth. case appears not to do that -- instead it is >specifying a use _in_ the DNS, which means that it's just like any >other delegation in the DNS and ought to be correctly delegated from >the parent zone according to that zone's delegation policies. That's >not a special-use name. It's just a name in the DNS. FYI, Namecoin wants the same thing, and is currently set up so you can resolve it via OpenNIC. It is my impression that its main use is for botnet software to locate control and command hosts. R's, John From nobody Tue Mar 28 00:02:26 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D11A129887 for ; Tue, 28 Mar 2017 00:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=virgil.gr 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 VAUrAFo2pK4C for ; Tue, 28 Mar 2017 00:02:12 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 57B09128DF6 for ; Tue, 28 Mar 2017 00:02:00 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id p77so47147536ywg.1 for ; Tue, 28 Mar 2017 00:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virgil.gr; s=dkim; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=spT2A0G+y8smhoV61KtfXS8YzHL17YySGOubyFAFZN8=; b=cc9X6LFC3Vm5HbNoPXNjWsVe1jgIGsVI0L0ZePukhbfFrI/amPybYKsi8dfXs/KHQB 1794Ji8IkV2XNJXJxXYqzTDHmRjpyIsgbxmqGd+iDqKHbk7J0KNA3FHi/yKUtTx2aHI3 lMIOpYxGyaAyiiNnq42iEPUAJzz05woEWtywM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=spT2A0G+y8smhoV61KtfXS8YzHL17YySGOubyFAFZN8=; b=oj2HRsiIoNQaF1LmWR9ZQMij/502a/cklqoSwso+dYjGk/HqW7lyXcGKiM1O4KtD/E VbsatedefS64APGa7aSAAn0D49wE1xRTHeIABJQxeQXPtejfx2nIYq0oXtPlaluWjeA4 PHD/VqXcrosXxVEB6dncZVqX2T6X8RRmA8wURSZzRvWIA46imBr+G8Nd5INH/Ph0/17f v25FUWZnJZA+fvNsMsnHhE3DetICZQdFtPwyvXvWUNN2JgflIWVzSwoZaXbgQAf6wuKb m0EhuAFrX1UkBhoCgW7FHHEUcMqpNNHhkPSbvRnwOKxRnXgnriwasGsd2+BnRoC08Uc7 gyxA== X-Gm-Message-State: AFeK/H3hfx15vmmb/U+W8/o9gOXHGt7HjTqFglNbxHWa/fG/PEpa0j67OpWayPQ4+SmQGX2e1Miy45s3+I+f9A== X-Received: by 10.13.225.80 with SMTP id k77mr21135931ywe.83.1490684518975; Tue, 28 Mar 2017 00:01:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.252.26 with HTTP; Tue, 28 Mar 2017 00:01:38 -0700 (PDT) In-Reply-To: <20170327230921.972.qmail@ary.lan> References: <20170327212842.GE36142@mx4.yitter.info> <20170327230921.972.qmail@ary.lan> From: Virgil Griffith Date: Tue, 28 Mar 2017 15:01:38 +0800 Message-ID: To: IETF Security Area Advisory Group Content-Type: multipart/alternative; boundary=94eb2c07194439dd52054bc5096f Archived-At: Subject: Re: [saag] Hello from the Ethereum Foundation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 07:02:25 -0000 --94eb2c07194439dd52054bc5096f Content-Type: text/plain; charset=UTF-8 Thanks for the feedback everyone. Just as a high-level view, the Ethereum Foundation's goal is lead by example operating a decentralized, transparent DNS registry. Our hope is that after showing a proof-of-concept with .eth, that future TLDs will follow suit putting their registries on whatever blockchain-based system they prefer (they are of course welcome to use Ethereum). Lets take comments one at a time. > On Tue, Mar 28, 2017 at 5:05 AM, Michael Richardson > wrote: > I think, because anyone who has the block-chain data verified, can > authoritatively serve/resolve queries against this zone without reference to > any other authority. > As such, it would be more similar to onion. and homenet., except that the > names could *also* be publically resolvable via port-53. > eth., would be subject to policy whims of , > and National Security Letters against , which would affect > users who see the data via port-53. Yes this is exactly our reasoning. It's also unclear to us how to handle DNSSEC. > On Tue, Mar 28, 2017 at 5:28 AM, Andrew Sullivan > wrote: > The proposed eth. case appears not to do that -- instead it is > specifying a use _in_ the DNS, which means that it's just like any > other delegation in the DNS and ought to be correctly delegated from > the parent zone according to that zone's delegation policies. That's > not a special-use name. It's just a name in the DNS. Okay. So it sounds like we're better served by ICANN. Okay, can do. > On Tue, Mar 28, 2017 at 7:09 AM, John Levine wrote: > FYI, Namecoin wants the same thing, and is currently set up so > you can resolve it via OpenNIC. Thanks! We'll explore OpenNIC in parallel. That sounds like a good stepping stone. ============= I think for now our best bet to implement what exactly we want within OpenNIC, and then we'll all have a better idea of where to slot this for larger adoption. Thank you everyone! -V On Tue, Mar 28, 2017 at 7:09 AM, John Levine wrote: > In article <20170327212842.GE36142@mx4.yitter.info> you write: > >The proposed eth. case appears not to do that -- instead it is > >specifying a use _in_ the DNS, which means that it's just like any > >other delegation in the DNS and ought to be correctly delegated from > >the parent zone according to that zone's delegation policies. That's > >not a special-use name. It's just a name in the DNS. > > FYI, Namecoin wants the same thing, and is currently set up so > you can resolve it via OpenNIC. > > It is my impression that its main use is for botnet software to > locate control and command hosts. > > R's, > John > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --94eb2c07194439dd52054bc5096f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Than= ks for the feedback everyone.=C2=A0 Just as a high-level view, the Ethereum= Foundation's goal is lead by example operating a decentralized, transp= arent DNS registry.=C2=A0 Our hope is that after showing a proof-of-concept= with .eth, that future TLDs will follow suit putting their registries on w= hatever blockchain-based system they prefer (they are of course welcome to = use Ethereum).

Lets take comments one at a time.
=
> On Tue, Mar 28, 2017 at 5:05 AM, = Michael Richardson <mcr+ietf@= sandelman.ca>=C2=A0
> wrote:
> I think, because anyone who has the block-= chain data verified, can
> authoritative= ly serve/resolve queries against this zone without reference to
> any other authority.

> As such, it would be more sim= ilar to onion. and homenet., except that the
> names could *also* be publically resolvable via port-53.

> eth.<any-= other-tld>, would be subject to policy whims of <any-other-tld>,
> and National Security Letters against &= lt;any-other-tld>, which would affect
&g= t; users who see the data via port-53.

=
Yes this is exactly our reasoning.=C2=A0 I= t's also unclear to us how to handle DNSSEC.



> On Tue, Mar 28, 2017 at 5:28= AM, Andrew Sullivan <ajs@anvi= lwalrusden.com>=C2=A0
> wrote:
> The proposed eth. case appears not to do= that -- instead it is
> specifying a us= e _in_ the DNS, which means that it's just like any
> other delegation in the DNS and ought to be correctly del= egated from
> the parent zone according = to that zone's delegation policies.=C2=A0 That's
> not a special-use name.=C2=A0 It's just a name in th= e DNS.

Okay.=C2=A0 So it sounds like we're better served by ICANN.=C2=A0 Okay= , can do.


> On Tue, Mar 28, 2017 at 7:09 = AM, John Levine <johnl@taugh.com&= gt; wrote:
> FYI, Namecoin wants the sam= e thing, and is currently set up so
> yo= u can resolve it via OpenNIC.

Thanks!=C2=A0 We'll explore OpenNIC in parallel= .=C2=A0 That sounds like a good stepping stone.

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

I think for now our best bet to implement what exactly we want within Open= NIC, and then we'll all have a better idea of where to slot this for la= rger adoption.

Thank you everyone!

-V

On Tue, Mar 28, 2017 at 7:09 AM, John Levine <johnl@tau= gh.com> wrote:
In article <20170327212842.GE36142@mx4.yitter.info= > you write:
>The proposed eth. case appears not to do that -- instead it is
>specifying a use _in_ the DNS, which means that it's just like any<= br> >other delegation in the DNS and ought to be correctly delegated from >the parent zone according to that zone's delegation policies.=C2=A0= That's
>not a special-use name.=C2=A0 It's just a name in the DNS.

FYI, Namecoin wants the same thing, and is currently set up so
you can resolve it via OpenNIC.

It is my impression that its main use is for botnet software to
locate control and command hosts.

R's,
John

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--94eb2c07194439dd52054bc5096f-- From nobody Tue Mar 28 03:27:51 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5881297D6 for ; Tue, 28 Mar 2017 03:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 AdWUrpa-Eh3l for ; Tue, 28 Mar 2017 03:27:47 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B67E129353 for ; Tue, 28 Mar 2017 03:27:47 -0700 (PDT) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id 1B8A762681; Tue, 28 Mar 2017 12:27:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1490696866; bh=zdXb/hcm1z0dIy4KnAvQtQUTYN9ycSW08q5o/43B66s=; h=Date:From:To; b=TvTC+MzeTHXyeK81QSIeM094sB7ixnDThtY1amOXpX/k2fCKzppYtPjbipUsiJOBZ OAEXG+xQsUYH/609cWLUVktkjAM+ufec1r0FX3W3vsDjN5IRh5Khymq7H+EA4qeP88 ct+h4cVUEdsibb/aHweqo9KR+RcD5KHLfZLE3JvY= Date: Tue, 28 Mar 2017 12:27:45 +0200 (CEST) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: Virgil Griffith Cc: saag Message-ID: <951026273.5846.1490696865863.JavaMail.zimbra@nic.cz> In-Reply-To: References: <20170327212842.GE36142@mx4.yitter.info> <20170327230921.972.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - SAF10 (Linux)/8.7.0_GA_1659) Thread-Topic: Hello from the Ethereum Foundation Thread-Index: Obht7Py/rhs/l0kTjcLtF4l5wEPlAg== X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [saag] Hello from the Ethereum Foundation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 10:27:50 -0000 ----- Original Message ----- > From: "Virgil Griffith" > To: "saag" > Sent: Tuesday, 28 March, 2017 02:01:38 > Subject: Re: [saag] Hello from the Ethereum Foundation > Thanks for the feedback everyone. Just as a high-level view, the Ethereum > Foundation's goal is lead by example operating a decentralized, transpare= nt DNS > registry. Our hope is that after showing a proof-of-concept with .eth, th= at > future TLDs will follow suit putting their registries on whatever > blockchain-based system they prefer (they are of course welcome to use > Ethereum). The problem is that you don't need TLD for demoing blockchain based registr= y. You can have a DNS registry at any level of the DNS tree. The technical implementation of the domain registry (or it's business model) is irrelevan= t to the special use domains applications. In the .onion case, the goal was to *remove* .onion from the global DNS space. Henceforth my opinion is that you don't have any supporting arguments for IETF SU domain reservation= . >> eth., would be subject to policy whims of = , >> and National Security Letters against , which would affec= t >> users who see the data via port-53. + > Okay. So it sounds like we're better served by ICANN. Okay, can do. Those two together doesn't make any sense. By applying for newGTLD, you would be subject to ICANN rules, which is exactly the thing you aim to avoid according to your three-letter-agency fear. > It's also unclear to us how to handle DNSSEC. This is irrelevant to SU domains, but ICANN has/had a very strict rules on DNSSEC for newGTLDs, aka you must offer DNSSEC on newGTLD. But I leave it absolutely up for you whether you want to spend 180 grand on newGTLD application. ICANN won't certainly mind accepting your non-refundable fee and then rejecting your application :). O. -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- From nobody Tue Mar 28 07:41:47 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481A11296ED for ; Tue, 28 Mar 2017 07:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 X0UoozTT__z3 for ; Tue, 28 Mar 2017 07:41:43 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 07B981294CD for ; Tue, 28 Mar 2017 07:41:43 -0700 (PDT) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cssJZ-0004ca-Fv for saag@ietf.org; Tue, 28 Mar 2017 16:41:42 +0200 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cssJU-0001Hj-CJ for saag@ietf.org; Tue, 28 Mar 2017 10:41:40 -0400 Received: (qmail 30376 invoked from network); 28 Mar 2017 14:41:34 -0000 Received: from unknown (HELO [31.133.141.120]) (Authenticated-user:_huitema@huitema.net@[31.133.141.120]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Mar 2017 14:41:33 -0000 To: saag@ietf.org References: <20170327212842.GE36142@mx4.yitter.info> <20170327230921.972.qmail@ary.lan> <951026273.5846.1490696865863.JavaMail.zimbra@nic.cz> From: Christian Huitema Message-ID: Date: Tue, 28 Mar 2017 09:41:32 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <951026273.5846.1490696865863.JavaMail.zimbra@nic.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: 168.144.250.234 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.53) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49FXKwZbSflcvTu2SSy6NnOlTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXoX0kjfsu8V68X8KGEdGLEcRcOb18WfxGyg6Om6u4YYm8I1T5JMCJwBbgsY 3R28NjU5hjoyEb9Oq0NWpyO3vrfYzS02aeiYw+GANPqwVsDMNz3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBcKaDTe3QRRhTm1Fh3Md1t3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0JMqkH13u Qi/3utit1z0crLbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgAg eNjxIyqtWcsHzPElnaBFglzR8EKamCCPLRQqfIrw/hgiR8Q/nWpUrU3XNrJtb82kJdODM1Y8txE7 bZgWIHQ/GyoCJJa3e874rwXXGPuEmSKg33smtlc64dR/aNUnR+kcQlvCYTspYJdGl64rm9ixxYJS vH1uwzGpXypuXzvU+UY3yPaqxR17HQXP1rUv1USKe72V7y3QDXL8JTpxprEN X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [saag] Hello from the Ethereum Foundation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 14:41:46 -0000 >>> eth., would be subject to policy whims of , >>> and National Security Letters against , which would affect >>> users who see the data via port-53. > That may well be. On the other hand, if the goal is to demonstrate a proof of concept, eth.arpa would probably work just fine, and only be subject to IETF rules. -- Christian Huitema From nobody Tue Mar 28 07:47:42 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F801299F7 for ; Tue, 28 Mar 2017 07:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 ERhjabwRAgXX for ; Tue, 28 Mar 2017 07:47:37 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 191481287A5 for ; Tue, 28 Mar 2017 07:47:37 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.20/8.16.0.20) with SMTP id v2SEeaMB030458; Tue, 28 Mar 2017 15:47:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=v8c/v4K/i8tFP3uHFRShM/2oMBNLKHdMDRrJq4vEbTk=; b=iiCeKfJg8jED0DgqyZh02rFHHDdvYXeT8BQ/wsviK8iBVmIlcIDx5I9pHbdS4WHftC7+ yPbsEZHzVU1EzNTXX3GrAVSpC0tvJKXsEyurXdKHMBXEIExye4tBJv/yvNhUvfn76cnE DD/WsIje/2bHT5aXRWUJFNHq4JzCdWOhcUtk3CqCF9zbea5+DgcPz+mEiYBuzbNjhxrv ofu4FZwxXmLmibBddXAX6nkwIp5t38uwT5ZUW6vOszv0xSt1rW9bq9nhVVUFeIrZDAM7 5KqKH7lzhGG01nyLaHwRAWL75i0Qcc2G7V5adL1XAiFDL7yBv+TVZVfyLxziKR/YNODn cw== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 29fst302b7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Mar 2017 15:47:28 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v2SEZost004593; Tue, 28 Mar 2017 10:47:26 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 29fspy80qr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 28 Mar 2017 10:47:26 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Mar 2017 07:47:26 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Tue, 28 Mar 2017 10:47:25 -0400 From: "Salz, Rich" To: Christian Huitema , "saag@ietf.org" Thread-Topic: [saag] Hello from the Ethereum Foundation Thread-Index: AQHSp65hQnL17dezJUKhUrhIA/gt1KGqlnkA//++ATA= Date: Tue, 28 Mar 2017 14:47:25 +0000 Message-ID: <59ae3dc22ec040bab42e7d5d669f44f1@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170327212842.GE36142@mx4.yitter.info> <20170327230921.972.qmail@ary.lan> <951026273.5846.1490696865863.JavaMail.zimbra@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.227] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-28_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703280127 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-28_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703280127 Archived-At: Subject: Re: [saag] Hello from the Ethereum Foundation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 14:47:39 -0000 > >>> , and National Security Letters against > >>> , which would affect users who see the data via port-5= 3. NSL's (at least the US/American kind) don't care about the name in the doma= in. They only care about if the controlling organization is subject to US = rules. So that would leave out arpa I find the concept of a blockchain-based DNS worrying about NSL's a bit amu= sing. As this is just PoC, pick any darn domain and see. From nobody Tue Mar 28 08:03:46 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A3F128B37 for ; Tue, 28 Mar 2017 08:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=opentechinstitute-org.20150623.gappssmtp.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 KsVPjj-Gt7-b for ; Tue, 28 Mar 2017 08:03:42 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 1952A128C83 for ; Tue, 28 Mar 2017 08:03:41 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id p22so67882775qka.3 for ; Tue, 28 Mar 2017 08:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opentechinstitute-org.20150623.gappssmtp.com; s=20150623; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version; bh=GyqPvYD7oba0fyQGVwAb38PAzoTSa1baVi6bxti8wfo=; b=b8/+OySx+h4t1qFKAzKqJNn1ey8C+taSG3o0/NIsFgG2JyLDZ/FWwI6ldkeQytQNJ3 /f2OAq+VUTAhtP5wmzEPB1omfqDVtn/+8yjucpd47WaBO0x59Lw95isyAvEr7L6v1p7l O4R19uFQIhGDuZsFShw7j1KTp8gW/Gr7WiFFa4ekgjddMjVq4XIMIVW+2N02CpX5wRzk upsIrZY0xTZ8dSDHuFgXEmE1FSO98LpYz7BdjGDrgYPs0Cz8c2OaOzz5nJGpeESArYEL 5tyZxEmvX3TKbH667+QRSRUmRyR4bspHByXXyyOjSwjk8B0yDyAq5RsmuwosUepenxd1 p++w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=GyqPvYD7oba0fyQGVwAb38PAzoTSa1baVi6bxti8wfo=; b=YiAp5JV+zHvzQ1g2ghOHcjTvWmLbRLwRYrmEinY34g5WcHqwIAzbbDVBtPySLSVO2o rpwYPeyXto9+4udw9KOIvYjgQqCoev54xCEFATubjzyMbFHcJlc87E1v7fMFc+vOlSx9 boTuaVFdvyJLyDhddUttN+6GxjNxQhlx77PFEzQcVDTNhGB7xfYmgSHnALOMEW7PjVih 6NF6IeQKHQkHg9v/ql80Ipg1zuStBXLA57Z8TH9gCwcFWkVQjj4w1NN466/eGrHob3jA rTaHROLOJ4Qsk48Aj3F9ibO5+6B9wb4uZlGF6zo1suinhBxROvpwEmODh9U1hs03ezMN tMHQ== X-Gm-Message-State: AFeK/H168Fi5StPDPEJY98g7ObEdRPQQLcZmGJ+k9mPI6drN1xjl7KyUEuGWxnbokgOWrg+8 X-Received: by 10.55.104.14 with SMTP id d14mr2298081qkc.299.1490713421021; Tue, 28 Mar 2017 08:03:41 -0700 (PDT) Received: from Techs-MacBook-Air-5.local ([165.117.251.76]) by smtp.gmail.com with ESMTPSA id e55sm2795772qte.52.2017.03.28.08.03.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 08:03:40 -0700 (PDT) References: <20170327212842.GE36142@mx4.yitter.info> <20170327230921.972.qmail@ary.lan> <951026273.5846.1490696865863.JavaMail.zimbra@nic.cz> User-agent: mu4e 0.9.18; emacs 25.1.1 From: Ross Schulman To: Christian Huitema Cc: saag@ietf.org In-reply-to: Date: Tue, 28 Mar 2017 17:03:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [saag] Hello from the Ethereum Foundation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 15:03:45 -0000 Perhaps this conversation would be better served if Virgil could chime in with what Ethereum wants to accomplish in the short and long term, which would give us at IETF and ICANNthe ability to suggest best courses of action. I think generally speaking we should not be reflexively hostile to means of integrating DNS and blockchain if we can see a way to make the two work together. Christian Huitema writes: >>>> eth., would be subject to policy whims of >>>> , >>>> and National Security Letters against , which >>>> would affect >>>> users who see the data via port-53. >> > That may well be. On the other hand, if the goal is to > demonstrate a > proof of concept, eth.arpa would probably work just fine, and > only be > subject to IETF rules. > > -- Christian Huitema > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- Ross Schulman Co-Director, New America's Cybersecurity Initiative Senior Policy Counsel, New America's Open Technology Institute ross@opentechinstitute.org 202-986-0427 PGP: 4D20 3824 9463 34C5 37EF FB0C 5A05 EB1F 5BBE 56EE From nobody Tue Mar 28 11:38:47 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAF01299F8 for ; Tue, 28 Mar 2017 11:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 ozZcYnVrryp3 for ; Tue, 28 Mar 2017 11:38:41 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 B76061297ED for ; Tue, 28 Mar 2017 11:38:39 -0700 (PDT) Received: from [10.47.60.80] (dhcp-80bd.meeting.ietf.org [31.133.128.189]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v2SIcSNh058065 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 28 Mar 2017 11:38:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host dhcp-80bd.meeting.ietf.org [31.133.128.189] claimed to be [10.47.60.80] From: "Paul Hoffman" To: "saag@ietf.org" Date: Tue, 28 Mar 2017 13:38:38 -0500 Message-ID: <7A8F415A-3BE0-46D4-80FF-B8DB50634B94@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: [saag] Distributed ledgers and control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 18:38:43 -0000 Greetings. A few folks have recently been discussing which ledger and = ledger-esque protocols should be used with upcoming IETF protocols. It = is easy to conflate the governance of the ledger with its uses. A good = article that helps make the distinction is: https://www.oii.ox.ac.uk/blog/the-blockchain-paradox-why-distributed-ledg= er-technologies-may-do-little-to-transform-the-economy/ From nobody Tue Mar 28 11:45:46 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F82612943B for ; Tue, 28 Mar 2017 11:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 taTujb0LggLQ for ; Tue, 28 Mar 2017 11:45:42 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 9A68A1270FC for ; Tue, 28 Mar 2017 11:45:42 -0700 (PDT) X-AuditID: 1209190e-443ff70000003f09-b7-58daaf540cd4 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 6C.42.16137.45FAAD85; Tue, 28 Mar 2017 14:45:40 -0400 (EDT) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v2SIjdVG023121; Tue, 28 Mar 2017 14:45:39 -0400 Received: from W92EXEDGE5.EXCHANGE.MIT.EDU (w92exedge5.exchange.mit.edu [18.7.73.22]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id v2SIjaAH019529; Tue, 28 Mar 2017 14:45:38 -0400 Received: from OC11EXHUB11.exchange.mit.edu (18.9.3.25) by W92EXEDGE5.EXCHANGE.MIT.EDU (18.7.73.22) with Microsoft SMTP Server (TLS) id 14.3.339.0; Tue, 28 Mar 2017 14:44:50 -0400 Received: from OC11EXPO33.exchange.mit.edu ([169.254.1.109]) by OC11EXHUB11.exchange.mit.edu ([18.9.3.25]) with mapi id 14.03.0235.001; Tue, 28 Mar 2017 14:45:36 -0400 From: Thomas Hardjono To: Paul Hoffman , "saag@ietf.org" Thread-Topic: [saag] Distributed ledgers and control Thread-Index: AQHSp/KNE8FGxooQ90aYVSKVjslIYaGqlZgX Date: Tue, 28 Mar 2017 18:45:35 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342AC1D65964@OC11EXPO33.exchange.mit.edu> References: <7A8F415A-3BE0-46D4-80FF-B8DB50634B94@vpnc.org> In-Reply-To: <7A8F415A-3BE0-46D4-80FF-B8DB50634B94@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.38.117.81] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHKsWRmVeSWpSXmKPExsUixG6nrhuy/laEwY05Gha31n9htZjS38nk wOSxZMlPJo/Ps68yBzBFcdmkpOZklqUW6dslcGUs3P+LqaCRo6Jx1l6WBsb7bF2MnBwSAiYS K1dfZupi5OIQEmhjkth9ZxELhHOAUWLPsQYo5xijRNevBVDOdkaJ7l93WCGc1YwSj5ZfZgEZ xiagIdH2o5cdxBYR8JR4ufM4mC0sYCxx788iFoi4icTUlW1QNUYSP198AYuzCKhKLHwEUc8r ECTx5MhLZhBbSMBaYt7t/WA2p4CNxKLe/WCHMwqISXw/tYYJxGYWEJe49WQ+E8RDghKLZu9h hrDFJP7teghUzwFkK0q836gGUa4jsWD3JzYIW1ti2cLXzBBrBSVOznzCMoFRfBaSqbOQtMxC 0jILScsCRpZVjLIpuVW6uYmZOcWpybrFyYl5ealFusZ6uZkleqkppZsYQdHGKcm3g3FSg/ch RgEORiUe3h15tyKEWBPLiitzDzFKcjApifLOXQ4U4kvKT6nMSCzOiC8qzUktPsQowcGsJMI7 fxlQjjclsbIqtSgfJiXNwaIkziuu0RghJJCeWJKanZpakFoEk5Xh4FCS4GVYB9QoWJSanlqR lplTgpBm4uAEGc4DNFwWpIa3uCAxtzgzHSJ/ilFRSpw3ZS1QQgAkkVGaB9cLSYaeYq8YxYFe EeZ1AWnnASZSuO5XQIOZgAaL24ANLklESEk1MF6qZl6lPvOypW5E0EEW1jky5ulCxs0/L/1s YbWUz9CXTn26ld95ak9XhXebhoXz0bh61WUnl9z4U2bybVq534EfPI5iHv+8nl4PaOV6kRw4 jZmteo5SXtL6C9Ypcr0mpY4Xp85Vd38j8fvqBekZ6XH3m//rJp7zP/1r4+o3F//M1bJZZfSp WomlOCPRUIu5qDgRAKCbAQ1hAwAA Archived-At: Subject: Re: [saag] Distributed ledgers and control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 18:45:44 -0000 Agree Paul. (1) Decentralization \neq user-centric control. (2) Distributed/Decentralization \neq empowerment (3) Decentralized \neq "trustless" (4) Decentralized \neq trust (or more trust) ( \neq means not-equal) /thomas/ ________________________________________ From: saag [saag-bounces@ietf.org] on behalf of Paul Hoffman [paul.hoffman@= vpnc.org] Sent: Tuesday, March 28, 2017 2:38 PM To: saag@ietf.org Subject: [saag] Distributed ledgers and control Greetings. A few folks have recently been discussing which ledger and ledger-esque protocols should be used with upcoming IETF protocols. It is easy to conflate the governance of the ledger with its uses. A good article that helps make the distinction is: https://www.oii.ox.ac.uk/blog/the-blockchain-paradox-why-distributed-ledger= -technologies-may-do-little-to-transform-the-economy/ _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag= From nobody Tue Mar 28 12:54:12 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08EC12944C for ; Tue, 28 Mar 2017 12:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 CKXaAk1VprKS for ; Tue, 28 Mar 2017 12:54:07 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 645811201F2 for ; Tue, 28 Mar 2017 12:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1490730845; bh=p0m8X62AtDqTfDjaCY1DhfdermJE74JYpuPzTbgtydE=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NbdDZfNWooihrhhRZQtRv748VarxCtB8CywhrDw9D6jTaMY6inu0HisDudx/W1d/6UsCpf+kyZzsLV/CboW6nKtagniMKqN7Dz8HVlFRviRSYX9/OxRODYZ77iq27d3IlaRslsME5dlLXfgUdiQTltvGEaA83XmPBbxp5ZmQV14= Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp0088.outbound.protection.outlook.com [94.245.120.88]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-70-aU-J8P4GMWK_n0w37vyqrg-1; Tue, 28 Mar 2017 20:54:00 +0100 Received: from VI1PR07MB1581.eurprd07.prod.outlook.com (10.165.239.15) by VI1PR07MB1583.eurprd07.prod.outlook.com (10.165.239.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Tue, 28 Mar 2017 19:53:59 +0000 Received: from VI1PR07MB1581.eurprd07.prod.outlook.com ([10.165.239.15]) by VI1PR07MB1581.eurprd07.prod.outlook.com ([10.165.239.15]) with mapi id 15.01.1005.010; Tue, 28 Mar 2017 19:53:59 +0000 From: Josh Howlett To: Paul Hoffman CC: "saag@ietf.org" Thread-Topic: [saag] Distributed ledgers and control Thread-Index: AQHSp/KgGLxU9lBt2E654kKNotdif6GqqFYw Date: Tue, 28 Mar 2017 19:53:59 +0000 Message-ID: References: <7A8F415A-3BE0-46D4-80FF-B8DB50634B94@vpnc.org> In-Reply-To: <7A8F415A-3BE0-46D4-80FF-B8DB50634B94@vpnc.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [217.33.116.188] x-microsoft-exchange-diagnostics: 1; VI1PR07MB1583; 7:0kppTZpzWCK+4Q/U7YOEHs8ZuLjMqrd8PyRCNhKaun+Ei1+eVX/REgbPS874TaH1Rb3WeIlDPLNV2e7Vj4QNJ/7gt3CRgypZnks56xcE+hEXoEaHDGcPoZXKA5PEfBgNa1qFIeS6ZmzQbxLutsM0uQbgTbXuZvpKI2CyIj4EY1ppxvLIU0uSrSS2n+kjeUi+SOzx52h/WH8ACpMBRnVJiu8BHJen2F8TLM2pzu4YD9knJkjn/KE13ZJuwJ98Ot4D7FZfimx8LDJ0hgzm1p3DdU5DKDiDlMkLHy7iIPtLpvugAgX5roA4nkNi+gaTIlrthyEPcGmLhwRtHrpt7LQXxg==; 20:w5sIPz5ZyBjhgA6oNQopYOqdu2iCFLQ9+WItgY92C7CVw3ougueZJARrTVVv2vOSYh74mj0oDkvPWctEKLfLvKnsYlzFp1cyLaJQ3dFGuUqn/yRJeZpNDt2zG26UHiEvj2WykhXo4nojHHnkVx6bVlDhh7UcG+ZSVFooGcB5RwI= x-ms-office365-filtering-correlation-id: aec02b48-e077-438a-3e00-08d476142d17 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423065)(201703031133071)(201702281549065); SRVR:VI1PR07MB1583; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040440)(601004)(2401047)(8121501046)(5005006)(93006029)(93001029)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(201703131423065)(201702281528065)(201702281529065)(201703061421065)(201703061406065)(20161123558025)(6072148); SRVR:VI1PR07MB1583; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1583; x-forefront-prvs: 0260457E99 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39410400002)(39400400002)(3846002)(102836003)(9686003)(99286003)(4326008)(110136004)(6116002)(3660700001)(55016002)(189998001)(8936002)(8676002)(81166006)(74482002)(25786009)(38730400002)(42882006)(6916009)(3280700002)(2906002)(53936002)(6246003)(2950100002)(77096006)(229853002)(86362001)(7696004)(50986999)(6436002)(5660300001)(6506006)(122556002)(33656002)(74316002)(305945005)(54356999)(2900100001)(76176999)(66066001)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1583; H:VI1PR07MB1581.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2017 19:53:59.2672 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1583 X-MC-Unique: aU-J8P4GMWK_n0w37vyqrg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] Distributed ledgers and control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 19:54:10 -0000 > Greetings. A few folks have recently been discussing which ledger and led= ger- > esque protocols should be used with upcoming IETF protocols. It is easy t= o > conflate the governance of the ledger with its uses. That's a great article -- thank you. While you definitely can't do without = either, effective trust infrastructure is more about institutions than cryp= tography. Josh. Jisc is a registered charity (number 1149740) and a company limited by guar= antee which is registered in England under Company No. 5747339, VAT No. GB = 197 0632 86. Jisc=E2=80=99s registered office is: One Castlepark, Tower Hil= l, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limit= ed by guarantee which is registered in England under company number 2881024= , VAT number GB 197 0632 86. The registered office is: One Castle Park, Tow= er Hill, Bristol BS2 0JA. T 0203 697 5800. =20 From nobody Tue Mar 28 15:16:27 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E13B129677 for ; Tue, 28 Mar 2017 15:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 6fnkad8pb6ZL for ; Tue, 28 Mar 2017 15:16:23 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 B4A25127076 for ; Tue, 28 Mar 2017 15:16:22 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id d10so72543776qke.1 for ; Tue, 28 Mar 2017 15:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yi2zgO26nmEuseeo4ADDvwNzJQChwjsMO3GMKAsDMcU=; b=ZPLkerEAiri/wRMh5c1e3fsk7ostMO8pxoSMK/Z6NM3FrBrCny1rtRiJqG3tr4wuxr RhNY8XUD0oXOWp6tnU/GuGFhaoDsStiBP/SppHZWJ/xjKLj41YJr/zb//J865q1afyYM TfC2BedLyLn53FimBMO6ZXQJm3psYsfI0h6Qo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yi2zgO26nmEuseeo4ADDvwNzJQChwjsMO3GMKAsDMcU=; b=l/LxL8FwlxymGXcbqRqz0ETvU8RuEDIgrtn59iF43BG3dV7jFVcbthqsPBa7nBFkGY s5vv3XUs+u9ftY2fUkyTKcoFmJRGOJ+rkyK6glQdWzBWKFU0YrReBiHBcqMr2Y29Ejmx bqIcg1GjZ7eMiIpGbb6Kqw03zxMGaKER7n2+CwnDBiYIBORpVL5KCrJPY6wE+/3yIQbE 5xGK/6K0UcUC2bclYuduEC3WASp70rOmDcVh5alhiYHfjEUC5Q47AyTfIsPS68qmxHyV F3R8/hAiernMBPGVZFDgYP2oTQEBm+ivEcCT0M4hMuCSOKMKYsoOJIX9g7ATMWv+m894 cVZA== X-Gm-Message-State: AFeK/H0XErMvyriSc6kFhJDFVIDhmnNM5cRnn8spN9fs7rUPRTquaQ3GZqqzhEGN8FfF9kM+IsrgVJ21bZpWdg== X-Received: by 10.55.142.69 with SMTP id q66mr26526137qkd.13.1490739381486; Tue, 28 Mar 2017 15:16:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Tue, 28 Mar 2017 15:16:20 -0700 (PDT) X-Originating-IP: [31.133.141.179] In-Reply-To: <7A8F415A-3BE0-46D4-80FF-B8DB50634B94@vpnc.org> References: <7A8F415A-3BE0-46D4-80FF-B8DB50634B94@vpnc.org> From: Kyle Rose Date: Tue, 28 Mar 2017 17:16:20 -0500 Message-ID: To: Paul Hoffman Cc: "saag@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c083c7a495623054bd1cfcb Archived-At: Subject: Re: [saag] Distributed ledgers and control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 22:16:26 -0000 --94eb2c083c7a495623054bd1cfcb Content-Type: text/plain; charset=UTF-8 The fact that disagreement over a controversial block size change proposal in Bitcoin resulted in conflict between factions, rather than in a unilateral change by a governance committee, suggests that there is some benefit to transparency of whatever combination of characteristics distinguish Bitcoin from systems employing explicit trusted third parties: separation of rule making from enforcement, consensus requirement, open membership, forkability, etc. For example, ISTM that a strength of Bitcoin is that attempts by a cabal to apply computing power to take over the network and change the rules in its favor would likely result in a fork by the legitimate users of the system. That class of mitigation doesn't exist when title to assets resides with a trusted third-party that can change or apply rules capriciously or unfairly: ultimately, your recourse is the legal system, which in many cases is in collusion with (or simply is) the third-party. There are problems with blockchain systems (e.g., consensus virtually rules out evolution, as we're witnessing with Bitcoin), but I'm not sure I buy the conclusion that they provide no real benefit over traditional trusted third-party mechanisms. It may be that blockchains constrain governance in ways of real benefit to users. Kyle On Tue, Mar 28, 2017 at 1:38 PM, Paul Hoffman wrote: > Greetings. A few folks have recently been discussing which ledger and > ledger-esque protocols should be used with upcoming IETF protocols. It is > easy to conflate the governance of the ledger with its uses. A good article > that helps make the distinction is: > > https://www.oii.ox.ac.uk/blog/the-blockchain-paradox-why-dis > tributed-ledger-technologies-may-do-little-to-transform-the-economy/ > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --94eb2c083c7a495623054bd1cfcb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The fact that disagreement over a controversial block= size change proposal in Bitcoin resulted in conflict between factions, rat= her than in a unilateral change by a governance committee, suggests that th= ere is some benefit to transparency of whatever combination of characterist= ics distinguish Bitcoin from systems employing explicit trusted third parti= es: separation of rule making from enforcement, consensus requirement, open= membership, forkability, etc.

For example, ISTM that a s= trength of Bitcoin is that attempts by a cabal to apply computing power to = take over the network and change the rules in its favor would likely result= in a fork by the legitimate users of the system. That class of mitigation = doesn't exist when title to assets resides with a trusted third-party t= hat can change or apply rules capriciously or unfairly: ultimately, your re= course is the legal system, which in many cases is in collusion with (or si= mply is) the third-party.

There are problems with blockch= ain systems (e.g., consensus virtually rules out evolution, as we're wi= tnessing with Bitcoin), but I'm not sure I buy the conclusion that they= provide no real benefit over traditional trusted third-party mechanisms. I= t may be that blockchains constrain governance in ways of real benefit to u= sers.

Kyle


On Tue, Mar 28, 2017 at 1:38 PM, = Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Greetings. A few folks have recently been discussing = which ledger and ledger-esque protocols should be used with upcoming IETF p= rotocols. It is easy to conflate the governance of the ledger with its uses= . A good article that helps make the distinction is:

https://www.oii.ox.ac.uk/blog/the-blockcha= in-paradox-why-distributed-ledger-technologies-may-do-little-to-t= ransform-the-economy/

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--94eb2c083c7a495623054bd1cfcb-- From nobody Tue Mar 28 15:43:52 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5350D127B57; Tue, 28 Mar 2017 15:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Ey7jtiiybL2t; Tue, 28 Mar 2017 15:43:49 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 0D145124234; Tue, 28 Mar 2017 15:43:49 -0700 (PDT) X-AuditID: c6180641-c3fff70000000a06-42-58daa0c92dec Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by (Symantec Mail Security) with SMTP id 50.A7.02566.9C0AAD85; Tue, 28 Mar 2017 19:43:40 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 18:43:44 -0400 From: Daniel Migault To: Jim Schaad , "curdle@ietf.org" CC: "saag@ietf.org" , "spasm@ietf.org" , "tls@ietf.org" , IPsecME WG Thread-Topic: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt Thread-Index: AQEf37CDGDDCSU9BXbxVbCIypDLQd6MQV6aggAAQoyA= Date: Tue, 28 Mar 2017 22:43:44 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> In-Reply-To: <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLonQffMglsRBlf/qlhsXTiL2WL19O9s Fvu3vGCzmNLfyWQx71qyxafzXYwObB4b50xn81iy5CdTAFMUl01Kak5mWWqRvl0CV8bMva+Z CmaJV7z5MI2xgfG1UBcjB4eEgIlEU6dJFyMXh5DABkaJ3YfPsEE4yxklju+/wNTFyMnBJmAk 0Xaonx3EFhHwkbjy4AwrSBGzQAujxIorPxlBEsICYRKzZ79ngygKlzjd+ZkFwraSmLd/CyuI zSKgKnHh2XdGkM28Ar4SU954QSxrYpS4crgZbA6ngIPErca5YIsZBcQkvp9aA2YzC4hL3Hoy H8yWEBCQWLLnPDOELSrx8vE/VghbSeLj7/nsEPU6Egt2f2KDsLUlli18DVbPKyAocXLmE5YJ jKKzkIydhaRlFpKWWUhaFjCyrGLkKC0uyMlNNzLcxAiMmmMSbI47GPf2eh5iFOBgVOLhVTC5 FSHEmlhWXJl7iFGCg1lJhHf+MqAQb0piZVVqUX58UWlOavEhRmkOFiVx3nflFyKEBNITS1Kz U1MLUotgskwcnFINjOsanG9H7tCr+HAwitn45eSlPqKHWv7UhyuH2VjdcGmW6cxYespAukhA xKd0ztH7NgIdAeoLOLdfzTl4bnpTcm4jx/vHuueYL89ZMXtK9butNncZzPfo/H9RsmfHnw13 jD/lbOg4NHfRFfufv24uyFCb2m7X3fF9rk3Ywy9eb/4nm4tfr+UzmqbEUpyRaKjFXFScCAAN fttwlgIAAA== Archived-At: Subject: Re: [saag] [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 22:43:51 -0000 Hi,=20 Thank you Jim for the update. Here is the version resulting from the discus= sion we had during the WG meeting yesterday. Please review the document an= d provide your feed backs by April 4 so we can move the draft to the IESG.= =20 Yours,=20 Daniel -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Tuesday, March 28, 2017 4:40 PM To: curdle@ietf.org Subject: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-0= 4.txt Here is the promised updated draft. Changes: 1. Fixed an example that David Benjamin found was wrong. (Incorrect sign = bit in public key.) 2. Remove all of the pre-hash text except to note that= it does exist. 3. No changes to the OID arc being used despite the agreement during the m= eeting. After the meeting, Russ, the chairs and I had a short talk and dec= ided that this did not need to occur. The problem was only with getting ne= w values assigned not with the current values which were already assigned. That should be the final issues in the draft Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, March 28, 2017 4:31 PM > To: Jim Schaad ; Simon Josefsson=20 > > Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt >=20 >=20 > A new version of I-D, draft-ietf-curdle-pkix-04.txt has been=20 > successfully submitted by Jim Schaad and posted to the IETF repository. >=20 > Name: draft-ietf-curdle-pkix > Revision: 04 > Title: Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for > use in the Internet X.509 Public Key Infrastructure > Document date: 2017-03-28 > Group: curdle > Pages: 15 > URL: https://www.ietf.org/internet-drafts/draft-ietf-curdle-pk= ix-04.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ > Htmlized: https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-curdle-p= kix-04 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-pki= x-04 >=20 > Abstract: > This document specifies algorithm identifiers and ASN.1 encoding > formats for Elliptic Curve constructs using the Curve25519 and > Curve448 curves. The signature algorithms covered are Ed25519 and > Ed448. The key agreement algorithm covered are X25519 and X448. The > encoding for Public Key, Private Key and EdDSA digital signature > structures is provided. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Tue Mar 28 16:00:49 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7969712773A for ; Tue, 28 Mar 2017 16:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 OaHLkX_xJSlg for ; Tue, 28 Mar 2017 16:00:46 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 8503F1271DF for ; Tue, 28 Mar 2017 16:00:45 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 190so37431400itm.0 for ; Tue, 28 Mar 2017 16:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=xYl7zZTwcGSTU4EjkErT8MdNMNAwdtIdUkLigyyTdvI=; b=Wl5uxvzeRg6abb3JiUUESwI0xo3WqDgb1SLOsg84sWzOI6aE7C0ceqatZ6uj7xvC9b DUURKBidEYpr+dhpbKf13c6rCJNnoEpVHPSrnKydUG9dzIzOMV7EXFXCuCQFXZa1Kd5x usWbBGXvdY+L6Yblv/c9Z+dOia63XjdgJriCDdXBTXA0V2TAYGJ9fWW3u3JUWuKyksgk 7q8E8aAam4QumvPYJ3l1zwVVC0BoCMsxDx1LqaXn+/Z1exL/ozMsdtZfptfpfsceUCTQ BrAZfPiHl1IAn4CFbqRDitQyyghDCn+SIsypEHXl30Z2dLf6bNxWsbhsIcANYLoPRQIn /V8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=xYl7zZTwcGSTU4EjkErT8MdNMNAwdtIdUkLigyyTdvI=; b=mcppoFWgaU+NFYIpBikwNT4LfTWO98EulxoLnb8y5WNrVLAHz+s5jg/wcUkwz7D2Fb N4fctVZJbJ9deMb1Oq83O1+Vj4XexASdRZ2Ac+DCufN9vmAtGlouvUuaaMvsM34Ki2j2 lJSHghviTOlLXtk0hC6Ev07n/ZvdN6MEX2Ahrrtmsov01DH8ggK97WN1lmQmfclStwkW tfoUAx24u7sim6OCCvNdXwt7EHZYkKJ+SjHNFtx1sOamPn25N9PQJUdBqx/ueoyeqinG 4nQTOLAYhj9er0lzdMwfpJrEwxV8HmkRdiDWNQZWR06gTk9KyyfU8yntG6oOny88rWE9 s7tA== X-Gm-Message-State: AFeK/H2oVidioVH8L65vm3NZ4i7Y29QtgCdSDv+5FnaFnEFQhEwZFUotzudz+5BYSQrhN6zRTzeasQgbaAIrYw== X-Received: by 10.36.112.212 with SMTP id f203mr19253469itc.107.1490742044731; Tue, 28 Mar 2017 16:00:44 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.35.200 with HTTP; Tue, 28 Mar 2017 16:00:44 -0700 (PDT) From: Barry Leiba Date: Tue, 28 Mar 2017 18:00:44 -0500 X-Google-Sender-Auth: 7Et6TT6j4BvJKLz2tZLaaf7bVyk Message-ID: To: saag Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] OpenPGP report for IETF 98 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 23:00:47 -0000 OpenPGP is not meeting at IETF 98 In general, OpenPGP is rather stalled. My sense is that the only way to proceed is to work out a schedule between the chairs and the document editor, pass it by the working group, and make it clear that if we can't meet the schedule we'll close the working group. There has been a burst of recent discussion on the mailing list, and some of it is related to open issues, but it's not resolving the stall. -- Barry (and DKG) From nobody Tue Mar 28 16:09:14 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EB0129507; Tue, 28 Mar 2017 16:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 ujJlZA9pHeFR; Tue, 28 Mar 2017 16:09:06 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 9BF211294E0; Tue, 28 Mar 2017 16:09:05 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.20/8.16.0.20) with SMTP id v2SN7102002475; Wed, 29 Mar 2017 00:09:04 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=1KInCOaj5PlpD+XLgJ1SFO795EHb9AifZJe00cLc5iw=; b=JlwgW/t+aDXyD4RoWNPsaUzHzLFvOMO1UZqib/HiEI8oq0hnoJ5LWbi48tvUA3Mnfdi7 XVthaJ95sO5OGwJPHkz6Ja7z0XnT3J29DElBDLHXRD0rdIIRWh359tO+yvIg1NwxPQPd g5riLHuSyCy2DJ3Yfj3P9sadRqLZOTk29QlJik+asTPH1HhFjeOcmuNElYnucUXqR501 jeIk2Pm1EtFntO8c6Q7HiIFRNRSAw6dhzdi7vdiK+Fv0QKY7uTKlC4FDjc5diCLQWSK/ Vma7dak8CfLjBYaTTwVERmf21EHVARf6/rSNR6YAeN7kBvXfsIS9SG3HFYkP54pzjVrq iw== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 29fsyu2pdq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Mar 2017 00:09:04 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v2SN6mUN024385; Tue, 28 Mar 2017 19:09:03 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 29fsutr75k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 28 Mar 2017 19:09:03 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Mar 2017 16:09:02 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Mar 2017 19:09:02 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Tue, 28 Mar 2017 19:09:02 -0400 From: "Salz, Rich" To: "saag@ietf.org" , "curdle@ietf.org" Thread-Topic: Curdle IETF98 report to the SAAG Thread-Index: AdKoF884M4y6bNoNSXmEPLlvgi2sow== Date: Tue, 28 Mar 2017 23:09:02 +0000 Message-ID: <3bba6233b0df467d9602709f60b5ae41@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.81] Content-Type: multipart/alternative; boundary="_000_3bba6233b0df467d9602709f60b5ae41usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-28_18:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703280186 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-28_18:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703280186 Archived-At: Subject: [saag] Curdle IETF98 report to the SAAG X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 23:09:08 -0000 --_000_3bba6233b0df467d9602709f60b5ae41usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Curdle contains maintaining the speed record of having the highest ratio of= I-D's/WG-minute. After all, isn't that the point of ECC crypto? :) We will be moving PKIX and CMS documents to IESG review. We have resolved most of the open issues in the current drafts. We will be moving SSH drafts to WGLC. Our incoming queue is progressing nicely, quickly, smoothly. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_3bba6233b0df467d9602709f60b5ae41usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Curdle contains maintaining the speed record of havi= ng the highest ratio of I-D’s/WG-minute.  After all, isn’t= that the point of ECC crypto? J

 

We will be moving PKIX and CMS documents to IESG rev= iew.

We have resolved most of the open issues in the curr= ent drafts.

We will be moving SSH drafts to WGLC.

 

Our incoming queue is progressing nicely, quickly, s= moothly.

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_3bba6233b0df467d9602709f60b5ae41usma1exdag1mb1msgcorpak_-- From nobody Tue Mar 28 16:22:42 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0C1126CE8 for ; Tue, 28 Mar 2017 16:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 J5U5Ybhqsm5n for ; Tue, 28 Mar 2017 16:22:39 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B71D126BFD for ; Tue, 28 Mar 2017 16:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6476; q=dns/txt; s=iport; t=1490743359; x=1491952959; h=from:to:subject:date:message-id:mime-version; bh=y/VgnzL5Fu7Ub9sesz60ifG/rca36daRZqW0IF2k09o=; b=GUMm5d4ThLt/sffCEBXqeBxwAb9TnZLtXIyayszMSHVKQiDSglxL5dVK AFGBvSkDYUfi/CenttIxbUtoB2BIMwJfMCu9NYcvflSvDeO0cu0+oIiNo DUAs9kpQksrbp1oC/9I1s5HL4ImaYATZ2+8TScpj+uOe67bOaxG4LOpkr g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVBAC779pY/4cNJK1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBgm5mYYESg1uKD5EykDqDIoIPgg4qhhSDCz8YAQIBAQEBAQEBax0LhT9oAUo?= =?us-ascii?q?CBDAPGASKGg6dYJAGgiYriiIBAQEBAQEBAQIBAQEBAQEBAQEBARgFiFMIhASGO?= =?us-ascii?q?C6CMQWcYAGGe4tTgXyJAYY2k2kBHziBBFkVUgGERh2BY4k6gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,238,1486425600"; d="scan'208,217";a="8028857" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Mar 2017 23:22:38 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2SNMcKG026233 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 28 Mar 2017 23:22:38 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Mar 2017 19:22:37 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 28 Mar 2017 19:22:37 -0400 From: "Nancy Cam-Winget (ncamwing)" To: "saag@ietf.org" Thread-Topic: MILE report Thread-Index: AQHSqBowVRs6d1lCZkewUIOBqRkDpA== Date: Tue, 28 Mar 2017 23:22:37 +0000 Message-ID: <9671E507-3801-4EF1-9F9E-5F389032D462@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.91.200] Content-Type: multipart/alternative; boundary="_000_9671E50738014EF19F9E5F389032D462ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [saag] MILE report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 23:22:41 -0000 --_000_9671E50738014EF19F9E5F389032D462ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TUlMRSBtZXQgb24gTW9uZGF5IE1hcmNoIDI3LCBTZXNzaW9uIElJ4oCmYSBzdW1tYXJ5IHJlcG9y dDoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWlsZS1yb2xpZS0w NiB3YXMgdXBkYXRlZCBhbmQgdGhlIGNoYW5nZXMgcmVwb3J0ZWQgYnkgU3RlcGhlbiBCYWdoYXJ0 LiAgR2l2ZW4gdGhlIGRyYWZ0IGhhZCBtYWpvciBjaGFuZ2VzLCB0aGVyZSB3aWxsIGJlIGFub3Ro ZXIgMzAgZGF5IFdHTEMuDQoNClVwZGF0ZXMgdG8gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLW1pbGUtaW9kZWYtZ3VpZGFuY2Ugd2VyZSBhbHNvIHByb3Zp ZGVkIGJ5IE1pbyBTdXp1a2kuICBBcyB0aGVyZSB3ZXJlIG9ubHkgYSBmZXcgd2hvIGhhZCByZWFk IHRoZSB1cGRhdGVzIChhbmQgc2FtZSB2b2x1bnRlZXJzIHRvIHJldmlldyB0aGlzIGRyYWZ0IGFz IHdlbGwgYXMgUk9MSUUpLCB0aGVyZSB3aWxsIGJlIGEgMzBkYXkgV0dMQyBmb3IgdGhpcyBkcmFm dCBhcyB3ZWxsLg0KDQpUaGVyZSB3ZXJlIG5vIHVwZGF0ZXMgbm9yIGNvbW1lbnRzIHRvIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1taWxlLXhtcHAtZ3Jp ZCAsIHNvIGFub3RoZXIgV0dMQyB3aWxsIGJlIGlzc3VlZCB0byBzb2xpY2l0IG1vcmUgZmVlZGJh Y2suDQoNClRoZXJlIHdhcyBkaXNjdXNzaW9uIHRvIG90aGVyIGV4dGVuc2lvbnMgdGhhdCBjYW4g YmUgZGVmaW5lZCBmcm9tIHRoZSBST0xJRSBkcmFmdC4NCg0KVGhlIGdyb3VwIGlzIHN0YXlpbmcg b24gdHJhY2sgd2l0aCB0aGVpciBtaWxlc3RvbmVzLg0KDQpSZWdhcmRzLCBOYW5jeQ0K --_000_9671E50738014EF19F9E5F389032D462ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NSUxFIG1l dCBvbiBNb25kYXkgTWFyY2ggMjcsIFNlc3Npb24gSUnigKZhIHN1bW1hcnkgcmVwb3J0OjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWlsZS1yb2xpZS0wNiI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWlsZS1yb2xpZS0wNjwvYT4gd2FzIHVwZGF0ZWQg YW5kIHRoZSBjaGFuZ2VzIHJlcG9ydGVkIGJ5IFN0ZXBoZW4gQmFnaGFydC4mbmJzcDsgR2l2ZW4g dGhlIGRyYWZ0IGhhZCBtYWpvciBjaGFuZ2VzLA0KIHRoZXJlIHdpbGwgYmUgYW5vdGhlciAzMCBk YXkgV0dMQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlVwZGF0 ZXMgdG8gPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1pZXRmLW1pbGUtaW9kZWYtZ3VpZGFuY2UiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLW1pbGUtaW9kZWYtZ3VpZGFuY2U8L2E+IHdlcmUgYWxzbyBw cm92aWRlZCBieSBNaW8gU3V6dWtpLiZuYnNwOyBBcyB0aGVyZSB3ZXJlIG9ubHkgYSBmZXcgd2hv IGhhZCByZWFkIHRoZSB1cGRhdGVzIChhbmQgc2FtZSB2b2x1bnRlZXJzIHRvIHJldmlldyB0aGlz IGRyYWZ0IGFzIHdlbGwgYXMgUk9MSUUpLCB0aGVyZSB3aWxsIGJlIGEgMzBkYXkgV0dMQyBmb3Ig dGhpcyBkcmFmdA0KIGFzIHdlbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5UaGVyZSB3ZXJlIG5vIHVwZGF0ZXMgbm9yIGNvbW1lbnRzIHRvDQo8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbWlsZS14bXBw LWdyaWQiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1t aWxlLXhtcHAtZ3JpZDwvYT4gLCBzbyBhbm90aGVyIFdHTEMgd2lsbCBiZSBpc3N1ZWQgdG8gc29s aWNpdCBtb3JlIGZlZWRiYWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+VGhlcmUgd2FzIGRpc2N1c3Npb24gdG8gb3RoZXIgZXh0ZW5zaW9ucyB0aGF0IGNhbiBi ZSBkZWZpbmVkIGZyb20gdGhlIFJPTElFIGRyYWZ0LiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGUgZ3JvdXAgaXMgc3RheWluZyBvbiB0cmFjayB3 aXRoIHRoZWlyIG1pbGVzdG9uZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5SZWdhcmRzLCBOYW5jeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_9671E50738014EF19F9E5F389032D462ciscocom_-- From nobody Tue Mar 28 19:03:59 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8976127337; Tue, 28 Mar 2017 19:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Szi1JkGThhjc; Tue, 28 Mar 2017 19:03:56 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 267061200F1; Tue, 28 Mar 2017 19:03:56 -0700 (PDT) X-AuditID: 12074422-4d3ff70000002527-8b-58db1609150a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 3D.AA.09511.9061BD85; Tue, 28 Mar 2017 22:03:55 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v2T23r9p009509; Tue, 28 Mar 2017 22:03:53 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v2T23nMa016911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Mar 2017 22:03:52 -0400 Date: Tue, 28 Mar 2017 21:03:49 -0500 From: Benjamin Kaduk To: saag@ietf.org Cc: kitten@ietf.org Message-ID: <20170329020348.GR30306@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJIsWRmVeSWpSXmKPExsUixG6nrsstdjvC4M5sfoujm1exWEzp72Ry YPJYsuQnUwBjFJdNSmpOZllqkb5dAlfGm/d3WAqesFZMnjCBsYHxKUsXIyeHhICJxNyj3cxd jFwcQgJtTBLn+3tYIJyNjBL9U66yQzhXmSS2LGsFa2ERUJW43vSMCcRmE1CRaOi+zAxiiwgI SjzomwRWwywgLLF8zVm2LkYODmEBTYk/2/JBwrxA21ZOOMQCYQtKnJz5BKpcS+LGv5dMIOXM AtISy/9xgIRFBZQlGmY8YJ7AyDcLSccsJB2zEDoWMDKvYpRNya3SzU3MzClOTdYtTk7My0st 0jXVy80s0UtNKd3ECA41F6UdjBP/eR1iFOBgVOLh3ZF3K0KINbGsuDL3EKMkB5OSKG/NAaAQ X1J+SmVGYnFGfFFpTmrxIUYJDmYlEd4VnLcjhHhTEiurUovyYVLSHCxK4rziGo0RQgLpiSWp 2ampBalFMFkZDg4lCV5xUaBGwaLU9NSKtMycEoQ0EwcnyHAeoOGnRECGFxck5hZnpkPkTzHq ctw4fuANkxBLXn5eqpQ4LztIkQBIUUZpHtwcUIqQyN5f84pRHOgtYd48kCoeYHqBm/QKaAkT 0BJxm1sgS0oSEVJSDYwKebFfu4Tzf//bmTe9Y/7+GaeVg3invN94hOX4Soti5ghF5bPCMlti D/F0/xd3rDq23deo1WDnhYwFP24ZX7k3OyZqrtHsXpnly5TC5GtVuxKjL3FLvTwWM03jf9TW oAWzZkuelX/Fv/3Qrre+uueavz+UX1J4PCzuxK20lxKXlvBYM7pnXp2mxFKckWioxVxUnAgA /p9/1ewCAAA= Archived-At: Subject: [saag] kitten status report for IETF 98 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 02:03:58 -0000 kitten is not meeting in Chicago. Since Seoul, we have been pretty succesful in clearing some backlog; we published three RFCs (8062, 8070, and 8129), and have another draft waiting for shepherd writeup (draft-ietf-kitten-rfc5653bis). We've adopted a new document (draft-ietf-kitten-krb-service-discovery) to document a scheme already deployed by MIT/Red Hat for consolidating KDC discovery into a single URI query. This leaves us in a position to pick up some additional new work; likely candidates include a PAKE preauthentication scheme for Kerberos that can do integrated second factor (no proper password + second factor scheme is standardized yet), and deprecating the triple-DES and RC4 kerberos enctypes. -Ben From nobody Tue Mar 28 22:37:27 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5BD12967A for ; Tue, 28 Mar 2017 22:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=virgil.gr 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 sphZhrKPrRrf for ; Tue, 28 Mar 2017 22:37:23 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 0119812963D for ; Tue, 28 Mar 2017 22:37:22 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id d191so3529229ywe.2 for ; Tue, 28 Mar 2017 22:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virgil.gr; s=dkim; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/RT4H7WnQR9KtLlp/R0m3U4hIsFkoXN/BZFQIir+NAY=; b=gDfu9322TBsMNRzBD2yoL2DvAEhHNFCX1pkurKDsN6YPkSIq+YkkBncNE7p5SmRinq H0miawU+a71SZaJkQdICh5LpNguwXxk2kFNqSq71H2vQIfdDtEUeXzJHlT920uTF3p9C IwEApbK5NkNB3Xp2eWFJq3zSG+ldAkbzCCBjg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/RT4H7WnQR9KtLlp/R0m3U4hIsFkoXN/BZFQIir+NAY=; b=RvyYwcPXMJ66tW1qPGkaUQ+KP/IlTEs+g8N8/GFgjhrQ40q/5oD5ewzyINMNwpIdJ1 EbwVnBK/A/r5OjX6Xi51xePzv3/QD7KH76ttQ35rhAFai/hBfYIlfpcY7k1zF8UiKNOq aYca4WMak1yG27RTANWI81sfTeJMqwf33nmxVFc2gn8Y/zYM/HVoI8FBza0Gj/xvb3fs v8VKh/j5KWd17S+N0sgZB4IR3+bP/b2saw/x2Ev7b1Io1RFJTql7IRnjVacAZsilJeBJ kLVMO+4AGP6irOwBZRjuSIgSe1h0JdRfYCZmugUv4Zk8bAEGNR3g9Dxp+ViZeI1IAn62 3Wqg== X-Gm-Message-State: AFeK/H2ji2mEDLJEyyV5jamEvPoLrbiZZZ2v4IzUnBIMakm6eeCFnVlqi2ffsjnMs/kFXR9Bjp12663orUs9gw== X-Received: by 10.37.164.136 with SMTP id g8mr22777261ybi.108.1490765841991; Tue, 28 Mar 2017 22:37:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.252.26 with HTTP; Tue, 28 Mar 2017 22:37:01 -0700 (PDT) In-Reply-To: References: <20170327212842.GE36142@mx4.yitter.info> <20170327230921.972.qmail@ary.lan> <951026273.5846.1490696865863.JavaMail.zimbra@nic.cz> From: Virgil Griffith Date: Wed, 29 Mar 2017 13:37:01 +0800 Message-ID: To: Ross Schulman Cc: Christian Huitema , IETF Security Area Advisory Group Content-Type: multipart/alternative; boundary=f403045c646e749a7d054bd7f81f Archived-At: Subject: Re: [saag] Hello from the Ethereum Foundation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 05:37:26 -0000 --f403045c646e749a7d054bd7f81f Content-Type: text/plain; charset=UTF-8 Thank you Ross. In the short term, the Ethereum Foundation is interested in: * Making "smart-contracts" on blockchain-based systems more accessible. This basically just means giving them all URLs. We currently partially have this with ens.domains, but we are unsatisfied with this because (1) it's such a hack (2) for such an infrastructure service, we'd prefer not to rely on the operator of the TLD .domains. In the long term, we argue that, relative to a trusted third party, public blockchain systems are more transparent as well as less prone to abuse by said third party. * For operators desiring those properties, we wish to demonstrate, by example, how to do so. For example, we would be immensely pleased if a future gTLD, entirely unrelated to the Ethereum Foundation, inspired by our success, decided to use a blockchain system for its registry. * Beyond DNS, there's also talk of using blockchain-based systems for storing BGP routes, but this is much less developed---so lets just stick to DNS. These are our goals in the short and long term. -Virgil On Tue, Mar 28, 2017 at 11:03 PM, Ross Schulman wrote: > Perhaps this conversation would be better served if Virgil could chime in > with what Ethereum wants to accomplish in the short and long term, which > would give us at IETF and ICANNthe ability to suggest best courses of > action. I think generally speaking we should not be reflexively hostile to > means of integrating DNS and blockchain if we can see a way to make the two > work together. > > > Christian Huitema writes: > > eth., would be subject to policy whims of , >>>>> and National Security Letters against , which would >>>>> affect >>>>> users who see the data via port-53. >>>>> >>>> >>> That may well be. On the other hand, if the goal is to demonstrate a >> proof of concept, eth.arpa would probably work just fine, and only be >> subject to IETF rules. >> >> -- Christian Huitema >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > > -- > Ross Schulman > Co-Director, New America's Cybersecurity Initiative > Senior Policy Counsel, New America's Open Technology Institute > ross@opentechinstitute.org > 202-986-0427 > > PGP: 4D20 3824 9463 34C5 37EF FB0C 5A05 EB1F 5BBE 56EE > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --f403045c646e749a7d054bd7f81f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Than= k you Ross.

In the short term, the Ethereum Foundation is interested in:
* Making "smart-contracts" on blockchain-= based systems more accessible.=C2=A0 This basically just means giving them = all URLs.=C2=A0 We currently partially have this with ens.domains, but we a= re unsatisfied with this because (1) it's such a hack (2) for such an i= nfrastructure service, we'd prefer not to rely on the operator of the T= LD .domains.

In the long term, we argue that, relative to a trusted third party, = public blockchain systems are more transparent as well as less prone to abu= se by said third party.
* For operators des= iring those properties, we wish to demonstrate, by example, how to do so.= =C2=A0 For example, we would be immensely pleased if a future gTLD, entirel= y unrelated to the Ethereum Foundation, inspired by our success, decided to= use a blockchain system for its registry.
= * Beyond DNS, there's also talk of using blockchain-based systems for s= toring BGP routes, but this is much less developed---so lets just stick to = DNS.

T= hese are our goals in the short and long term.
-Virgil


O= n Tue, Mar 28, 2017 at 11:03 PM, Ross Schulman <ross@opentechinst= itute.org> wrote:
Perhaps this conversation would be better served if Virgil could= chime in with what Ethereum wants to accomplish in the short and long term= , which would give us at IETF and ICANNthe ability to suggest best courses = of action. I think generally speaking we should not be reflexively hostile = to means of integrating DNS and blockchain if we can see a way to make the = two work together.


Christian Huitema writes:

=
eth.<any-other-tld>, would be subject to policy whims of <any-othe= r-tld>,
and National Security Letters against <any-other-tld>, which would af= fect
users who see the data via port-53.

=C2=A0That may well be. On the other hand, if the goal is to=C2=A0 demonstr= ate a
proof of concept, eth.arpa would probably work just fine, and only be
subject to IETF rules.

-- Christian Huitema

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag


--
Ross Schulman
Co-Director, New America's Cybersecurity Initiative
Senior Policy Counsel, New America's Open Technology Institute
ross@opente= chinstitute.org
202-9= 86-0427

PGP: 4D20 3824 9463 34C5 37EF=C2=A0 FB0C 5A05 EB1F 5BBE 56EE<= div class=3D"gmail-HOEnZb">


_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--f403045c646e749a7d054bd7f81f-- From nobody Wed Mar 29 04:43:21 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25651296AE; Wed, 29 Mar 2017 04:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 LbuxME4BK_04; Wed, 29 Mar 2017 04:43:10 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (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 56CA51296AD; Wed, 29 Mar 2017 04:43:09 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v2TBh8A2061932; Wed, 29 Mar 2017 04:43:08 -0700 (PDT) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v2TBh8Jb029362; Wed, 29 Mar 2017 04:43:08 -0700 (PDT) From: David Mazieres To: Paul Hoffman , "saag\@ietf.org" Cc: In-Reply-To: <7A8F415A-3BE0-46D4-80FF-B8DB50634B94@vpnc.org> References: <7A8F415A-3BE0-46D4-80FF-B8DB50634B94@vpnc.org> Reply-To: David Mazieres expires 2017-06-27 PDT Date: Wed, 29 Mar 2017 04:43:08 -0700 Message-ID: <87inmsxq9f.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [saag] Distributed ledgers and control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 11:43:12 -0000 Paul Hoffman writes: > Greetings. A few folks have recently been discussing which ledger and > ledger-esque protocols should be used with upcoming IETF protocols. It > is easy to conflate the governance of the ledger with its uses. A good > article that helps make the distinction is: > > https://www.oii.ox.ac.uk/blog/the-blockchain-paradox-why-distributed-ledger-technologies-may-do-little-to-transform-the-economy/ First, a plug for the IETF Internet-level consensus (ILC) mailing list (CCed), which is a good place to discuss these issues: https://www.ietf.org/mailman/listinfo/ilc as well as a reminder of the talk I'll be giving at the Thursday saag meeting: https://www.ietf.org/mail-archive/web/saag/current/msg07651.html The article you forwarded seems like a reaction to the notion that blockchain technologies can somehow supplant or circumvent regulation. That's a common view within the cryptocurrency community, but a highly controversial one outside. Nonetheless, there are different applications for some of the consensus technologies underlying blockchain systems that don't undermine governance and may be of interest to the IETF. In particular, given a mechanism for Internet-level consensus, it becomes possible to execute atomic transactions across parties that don't know or trust one another. Far from undermining regulation, this actually makes it practical to bridge various regulatory jurisdictions (e.g., create a total order across all certificates issued by all CAs, or atomically perform two funds transfers in two different countries). Furthermore, the notion of a blockchain-esque public log can be leveraged for various forms of transparency. For instance, last year there was a controversy in which Apple claimed to refuse an FBI request to sign a special compromised iPhone bootloader. Unfortunately, for all we know, Apple may have signed the software after all while claiming not to for the PR benefit. That they probably didn't yields the worst of both worlds--angering the FBI and still spooking potential customers. Requiring firmware updates to be published in a public log would allow the public to verify whether or not such activity is happening. David From nobody Wed Mar 29 06:25:02 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D9D1294F3 for ; Wed, 29 Mar 2017 06:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 3ZEuZDH2yl6w for ; Wed, 29 Mar 2017 06:24:59 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 215401294EC for ; Wed, 29 Mar 2017 06:24:59 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id v76so10332248ywg.0 for ; Wed, 29 Mar 2017 06:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bA4kvGwdVnRevzGyyNsGfvZFnBBBLYIiXJ1ZmzvcBR4=; b=WIt1BL4tEhH0QMb3EOxVgoX7W/t83AZXJHX/4rhwqLim/nbZLcpMSBGxlVgUyURtAI iy3BYTMoy+ih0PykSy9BAsbPgvR9E9AKLLPay77Zc01k3ZuhNY1z0xp6U+n8ddApeQzW qYpPuJwN5z10xZvr1VUshFLab50zClMD3QWSrWI7rtleyyn2KvYi2G1QxLJtNv2YKz72 l/XG2b66EBxfGwH5GD9dsgX+THH4RMgicYf1pZNNMDUHOIa9kTGhtiXArt7cBaYeO3H2 I6sRljEhOt+B7jt6NkaBH+CxsiHVKeBnappnP9QQndMPd4S9PLzetdSvQostvOGntL6l 89qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bA4kvGwdVnRevzGyyNsGfvZFnBBBLYIiXJ1ZmzvcBR4=; b=NaHgMKFjHVFJ1+o13t6/uNt/2VhHwNDQ0FoUhkqdeDXGanAhOxbviF8dSdHVqzbABp QS/1mHqVxzmYtIaTjkWcnUeOle64Yqj3lM/5s4rcJFhE78HMueoE7Z38esbLmmkL6zwl n/oCknMJBUSp/GT/ZTaRM9RnkGb6MIzPSQBf/XC/T2tGrOeScK7r3eEv/Mxd7HmqZiBc lsEnfv1vtd8gFyZcgNUbwLQMiqtkSPkp8zT6XfptD08j+IWYqdUejE4f06Lfl/x09Kb/ lkzDb5TwZNcnCny0lUSqUDaQw2bDcs3QTr0l3mNJ3GzwuzQ78ipF8JOtCi8JMa0Tmdv9 J10w== X-Gm-Message-State: AFeK/H0bkjqi68dFLShELIcZ+8bn3SNlEL11GxZtO9gQz2P6SHUa7nuNXRB9Su9NElKchGNC75bK6Rm9eByQ8Q== X-Received: by 10.129.177.8 with SMTP id p8mr413311ywh.327.1490793898250; Wed, 29 Mar 2017 06:24:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Wed, 29 Mar 2017 06:24:17 -0700 (PDT) In-Reply-To: <87inmsxq9f.fsf@ta.scs.stanford.edu> References: <7A8F415A-3BE0-46D4-80FF-B8DB50634B94@vpnc.org> <87inmsxq9f.fsf@ta.scs.stanford.edu> From: Eric Rescorla Date: Wed, 29 Mar 2017 08:24:17 -0500 Message-ID: To: David Mazieres expires 2017-06-27 PDT Cc: Paul Hoffman , "saag@ietf.org" , ilc@ietf.org Content-Type: multipart/alternative; boundary=94eb2c13ce38bd2b34054bde8041 Archived-At: Subject: Re: [saag] Distributed ledgers and control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 13:25:01 -0000 --94eb2c13ce38bd2b34054bde8041 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 29, 2017 at 6:43 AM, David Mazieres < dm-list-ietf-ilc@scs.stanford.edu> wrote > > Furthermore, the notion of a blockchain-esque public log can be > leveraged for various forms of transparency. For instance, last year > there was a controversy in which Apple claimed to refuse an FBI request > to sign a special compromised iPhone bootloader. Unfortunately, for all > we know, Apple may have signed the software after all while claiming not > to for the PR benefit. That they probably didn't yields the worst of > both worlds--angering the FBI and still spooking potential customers. > Requiring firmware updates to be published in a public log would allow > the public to verify whether or not such activity is happening. Just for those who may not be tracking this kind of work, this is something that's starting to happen, though typically with semi-centralized consensus mechanisms. In that form, it's generally known as "Binary Transparency". See, for instance: - https://groups.google.com/forum/#!forum/binary-transparency and - https://wiki.mozilla.org/Security/Binary_Transparency -Ekr > David > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --94eb2c13ce38bd2b34054bde8041 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Mar 29, 2017 at 6:43 AM, David Mazieres <dm-list-i= etf-ilc@scs.stanford.edu> wrote
Furthermore, the notion of a blockchain-esque public log can be
leveraged for various forms of transparency.=C2=A0 For instance, last year<= br> there was a controversy in which Apple claimed to refuse an FBI request
to sign a special compromised iPhone bootloader.=C2=A0 Unfortunately, for a= ll
we know, Apple may have signed the software after all while claiming not to for the PR benefit.=C2=A0 That they probably didn't yields the worst= of
both worlds--angering the FBI and still spooking potential customers.
Requiring firmware updates to be published in a public log would allow
the public to verify whether or not such activity is happening.

Just for those who may not be tracking this kind of wo= rk, this is something
that's starting to happen, though typic= ally with semi-centralized consensus
mechanisms. In that form, it= 's generally known as "Binary Transparency".


David

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--94eb2c13ce38bd2b34054bde8041-- From nobody Wed Mar 29 07:07:31 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3553D1296CB for ; Wed, 29 Mar 2017 07:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 1uxoUqL1BzR7 for ; Wed, 29 Mar 2017 07:07:26 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 9A91D1296CC for ; Wed, 29 Mar 2017 07:07:20 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v2TE7Jwi012927 for ; Wed, 29 Mar 2017 10:07:19 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu v2TE7Jwi012927 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1490796439; bh=tzeL6IDMhwaPZM1w5XyO+pgVXy0JI/RCQe26K3Pbnng=; h=From:To:Subject:Date:From; b=sEp1HZXasRt1vb7LM/6mRdN+m4ZeO2fLgcR+P46tP6/NaSno/x0flPWbr/KTvhwBg lvnBIdOM89D4cQACGCSThw9ARVF77gkK1tbdfP5WA1VAQuUtbhHZmRiegOE3JcO21C 3jBQg1U8f6twhBx2nDLCRqXTu2QEN2gunts+a8i8= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v2TE7Igm008139 for ; Wed, 29 Mar 2017 10:07:18 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0319.002; Wed, 29 Mar 2017 10:07:17 -0400 From: Roman Danyliw To: "saag@ietf.org" Thread-Topic: DOTS status report for IETF 98 Thread-Index: AdKoiP5yi/GbdLEpSF+tW6gct1EVVA== Date: Wed, 29 Mar 2017 14:07:16 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104F294AC@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [saag] DOTS status report for IETF 98 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 14:07:29 -0000 DOTS met in Chicago on Tuesday, March 28. The WG discussed revisions to the use cases (draft-ietf-dots-use-cases-04),= requirements (draft-ietf-dots-requirements-04) and architecture (draft-iet= f-dots-architecture-01) drafts. The WG agreed to adopt draft-reddy-dots-signal-channel-09 for the signal ch= annel. The WG is still polling for adoption on draft-reddy-dots-data-chann= el-05 for the data channel. The milestones for the WG will be updated to reflect schedule slips and cha= nges in deliverables. Regards, Roman From nobody Wed Mar 29 08:11:00 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17F9127599 for ; Wed, 29 Mar 2017 08:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 FSgPcabuWB_s for ; Wed, 29 Mar 2017 08:10:50 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4F11296CE for ; Wed, 29 Mar 2017 08:10:49 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2TFAbK2030667; Wed, 29 Mar 2017 16:10:37 +0100 Received: from 950129200 (dhcp-8535.meeting.ietf.org [31.133.133.53]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2TFAWSs030592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Mar 2017 16:10:35 +0100 Reply-To: From: "Adrian Farrel" To: Cc: , Date: Wed, 29 Mar 2017 16:10:34 +0100 Message-ID: <009f01d2a89e$a019a4e0$e04ceea0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKonplWLmSwEsxmQ/m57UfjEBWx/g== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22972.007 X-TM-AS-Result: No-1.253-10.0-31-10 X-imss-scan-details: No-1.253-10.0-31-10 X-TMASE-MatchedRID: USa9Meaaua7UbBocSvqNd9OEZs/2oH3cbv16+gil4jdrE1c4mB5Umo2P N627X5nNcto9nSFCcQXIFub1ag4Y+/DZOKmFLlvIfoNDZMQOpmzp8lxWp2elloihb7XJPsbDQzd UTE52L+EdUFxPoCZVx3FypV9HM4SombVpQ1SsilqSRFDtqiM5SxkqnRJng/51xpgm5zeqAztux5 S3GdSrKK8C3TTERs2RkZOl7WKIImq0P2qkGU0XypaWKijZlsbB2bNx1HEv7HAqtq5d3cxkNXg/L e2jwNXdKy8ZFXEuE0qgI025x2FsmOkhHcZv1HyUsCu/tMTxVtpbcZfrxRXQSG+q6i1Yr3fpIiuJ tLHdD0DIcIo73Ngm0exxaF/gNBFyp8i26iGCN+fD/c2Y8mxrik1Z+dSdugwvQbnlFuFUfWhDDKa 3G4nrLQ== Archived-At: Subject: [saag] I2NSF status report - Chicago IETF-98 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 15:10:59 -0000 Met, Monday 27th March, 2017, 13:00-15:00 Chairs: Linda Dunbar, Adrian Farrel Status * WG progress has been slow but progress has been made * Our first document is with the AD for publication - Problem statement and use cases * Follow-up documents are about to enter WG last call - Terminology - Framework * Moving towards adoption of Information Model drafts * Chairs reset milestone dates after IETF-97 * No fights or massive contention in the WG * This meeting reflects a slight change in involvement at the WG as operators and implementers of security functions start to get involved - a timely thing as we start to consolidate data models. * Continued work at the hackathon from Sungkyunwan University demonstrates potential of the framework Agenda and Materials https://datatracker.ietf.org/meeting/98/session/i2nsf Adrian and Linda From nobody Wed Mar 29 08:24:49 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7F612778E for ; Wed, 29 Mar 2017 08:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 PPwavlQ7Z_J0 for ; Wed, 29 Mar 2017 08:24:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14B8126DC2 for ; Wed, 29 Mar 2017 08:24:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 50ED6BEDB for ; Wed, 29 Mar 2017 16:24:39 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Szzb0ndC24ww for ; Wed, 29 Mar 2017 16:24:37 +0100 (IST) Received: from [31.133.141.180] (dhcp-8db4.meeting.ietf.org [31.133.141.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C1094BE5C for ; Wed, 29 Mar 2017 16:24:36 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1490801077; bh=wpChfH7Oa69ZiP5NQRlsFaFePEcRX+VCyVXye0oscLs=; h=Subject:References:To:From:Date:In-Reply-To:From; b=TKE4Oka3hA1qq0QAKF1++a/NJJBhpu64divGmcOXelbwKv/uf+pqCSILCj2gyYgsF 9kbvQUiaJbtCVAM2DcGJ01ktB/kpaRwuJpTjjXk7Y7aPSUPT5MRbyW7+k5tnRW4cHq pZNWbClRrWy9eRR9/0QYq82orwMhm6OdPAWRtUFI= References: <009f01d2a89e$a019a4e0$e04ceea0$@olddog.co.uk> To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <009f01d2a89e$a019a4e0$e04ceea0$@olddog.co.uk> Message-ID: <9404fc30-0790-3727-aa69-5268e032adeb@cs.tcd.ie> Date: Wed, 29 Mar 2017 16:24:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <009f01d2a89e$a019a4e0$e04ceea0$@olddog.co.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SwWMdcsGsafkcII2edVJwhKiUrH5bEV6l" Archived-At: Subject: [saag] Fwd: I2NSF status report - Chicago IETF-98 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 15:24:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SwWMdcsGsafkcII2edVJwhKiUrH5bEV6l Content-Type: multipart/mixed; boundary="nCif0wWAQ9qoeBfcur85FMtMRiDMT83lh"; protected-headers="v1" From: Stephen Farrell To: "saag@ietf.org" Message-ID: <9404fc30-0790-3727-aa69-5268e032adeb@cs.tcd.ie> Subject: Fwd: I2NSF status report - Chicago IETF-98 References: <009f01d2a89e$a019a4e0$e04ceea0$@olddog.co.uk> In-Reply-To: <009f01d2a89e$a019a4e0$e04ceea0$@olddog.co.uk> --nCif0wWAQ9qoeBfcur85FMtMRiDMT83lh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable -------- Forwarded Message -------- Subject: I2NSF status report - Chicago IETF-98 Resent-Date: Wed, 29 Mar 2017 08:11:37 -0700 (PDT) Resent-From: alias-bounces@ietf.org, wg-alias-bounces@tools.ietf.org Resent-To: Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, stephen.farrell@cs.tcd.ie, i2nsf-chairs@ietf.org, sec-ads@ietf.org Date: Wed, 29 Mar 2017 16:10:34 +0100 From: Adrian Farrel Reply-To: adrian@olddog.co.uk To: saag@ietf.org CC: i2nsf-chairs@tools.ietf.org, sec-ads@tools.ietf.org Met, Monday 27th March, 2017, 13:00-15:00 Chairs: Linda Dunbar, Adrian Farrel Status * WG progress has been slow but progress has been made * Our first document is with the AD for publication - Problem statement and use cases * Follow-up documents are about to enter WG last call - Terminology - Framework * Moving towards adoption of Information Model drafts * Chairs reset milestone dates after IETF-97 * No fights or massive contention in the WG * This meeting reflects a slight change in involvement at the WG as operators and implementers of security functions start to get involved - a timely thing as we start to consolidate data models. * Continued work at the hackathon from Sungkyunwan University demonstrates potential of the framework Agenda and Materials https://datatracker.ietf.org/meeting/98/session/i2nsf Adrian and Linda --nCif0wWAQ9qoeBfcur85FMtMRiDMT83lh-- --SwWMdcsGsafkcII2edVJwhKiUrH5bEV6l Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY29GyAAoJEC88hzaAX42ibucH/3XAuQD7FM5U0VLK7Ow0ZAPC M/G38sOz0iOYPeLt7DcPuoKpFYth3doqhnrMV45s/GXLawO1h9H8xNYI279k9agx o34mxDfRuDLZRG3HRp9xRdzTex38HHvZVGrt94XHLsLGzDS2DLoFiNJfFK7KBcZv MxTDduuBcm08JEw9Ix4HuzVoa/m7qnJJ9bf6vi5ilfoH6CAqV6EbXYxs0YgjOWGo iJein0r5Txi2Ubku6LHCbw0ccmFdg/HwjwvBkMA1U34utOQ7tMm3HC8LUUm2eMsl gO/7mA4Qlk10VpVojioCv5ag8ByT91Xy2GrmXI8dRjIBSh17sh+RX6yzMxikL34= =6kvy -----END PGP SIGNATURE----- --SwWMdcsGsafkcII2edVJwhKiUrH5bEV6l-- From nobody Wed Mar 29 09:50:49 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3164E126FB3 for ; Wed, 29 Mar 2017 09:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 IAPV48_rNnA3 for ; Wed, 29 Mar 2017 09:50:44 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 B2CCD127B60 for ; Wed, 29 Mar 2017 09:50:43 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id z204so24956268vkd.1 for ; Wed, 29 Mar 2017 09:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1lxMWDspDKXjqjWbQNMhmV2aV+VAQT7GozRlQtXeW30=; b=Cz/Pa2AfPnX7JoWx9QqWW8vb/S/KmOOQWnf/ptzNdtGh2pa+G8DsuZFuE1niHR8dyD 0V2WxR++6fTyhfhOf7c0HzY2RmRPNEjN4hv0BqOE8J6OjngeXUCEi0ol2QPI9Mx7GRoB Mwys5DIPs/menHwAzoCJV2Ua4NbLcrrlfoM1f0jRZMqtXGyJZnqgLoweVkULk5M8p+ZH iP/QIQ9RmIdiGpPxcSMT+GZmIL1ILDd95XLlPOHmBp4QS6Xwa30Vrwmi/6rrQdK/M0hO ZNBC5pjui2/JiDiYOUiXwdoUsgvJkJ06q50wr3w7FFyiM/cOp8AzFEKOIyBAmE0h1h9q nT4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1lxMWDspDKXjqjWbQNMhmV2aV+VAQT7GozRlQtXeW30=; b=s+7pp9iH+uHfqBFXlwwQrxTJxc5ftVgfHJ4+5SLJ23O4/1/e9lGd0JAUXukyi4ART6 TWSo6vaZ0FWaINxTdpyXDBZxfRnglU/XxUMZ9R9IYpNoMQ5Wdm7Jc7V7pYhslnIM34A+ p8AkD07ivXMYXholRrcNwNL2LPKMEWSL/AJKKKrgqCNJ6psEW/Kdd2SJZZrQjN2v+UIb tR/svgPFbu5y2gOwqOSVvjs1Hyudilrcf6SK0aogbZM0Dc9CDOgkVpVukSywV+aVOLu7 CFE3mfuWKhBk/z+dYm+eL8BnwOObtYSZSAMdo2mtTcTlnVUqbVhMo68LFbPOoirV81RZ aQqg== X-Gm-Message-State: AFeK/H0eijzPvnI+H9cRuE/DibsnB0B6tXRKGteI4BberRO+Fh8GJmXE7ge79dGvYz4zF/uo7uZm0DaYNXorO52F X-Received: by 10.31.110.138 with SMTP id j132mr610670vkc.103.1490806242524; Wed, 29 Mar 2017 09:50:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.174.73 with HTTP; Wed, 29 Mar 2017 09:50:41 -0700 (PDT) In-Reply-To: References: <22519.43588.421250.807948@fireball.acr.fi> From: Ben Laurie Date: Wed, 29 Mar 2017 17:50:41 +0100 Message-ID: To: Watson Ladd Cc: Yoav Nir , "saag@ietf.org" , Tero Kivinen Content-Type: multipart/alternative; boundary=94eb2c14a23a84472a054be16097 Archived-At: Subject: Re: [saag] Possible backdoor in RFC 5114 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 16:50:47 -0000 --94eb2c14a23a84472a054be16097 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 22 March 2017 at 18:20, Watson Ladd wrote: > > > On Mar 22, 2017 8:15 AM, "Ben Laurie" wrote: > > > > On 7 October 2016 at 16:56, Yoav Nir wrote: > >> >> > On 7 Oct 2016, at 16:59, Tero Kivinen wrote: >> > >> > Stephen Farrell writes: >> >> >> >> So I'm not seeing anyone so far argue to not >> >> deprecate these somehow. >> >> >> >> We could just make 5114 historic as Yoav suggests, >> >> or, if someone writes an I-D to explain why, we >> >> could obsolete 5114. (Such an I-D would presumably >> >> also say something about codepoints that point at >> >> 5114 from other registries.) >> >> >> >> Assuming nobody shows up saying these are in >> >> fact in widespread use I'd be supportive of us >> >> getting rid of cruft. >> > >> > I think the NIST ECP groups are quite widely supportd, and used. >> > RFC5114 includes both Nist ECP Groups (192, 224, 256, 384 and 521) and >> > 3 MODP groups. >> > >> > In IPsec, ECP groups are widely used, those MODP groups with subgroup >> > are not. On the other hand I think only those 192, 256 and 521 bit >> > groups are really used, and those are defined also in RFC5903 (which >> > obsoleted original 4753 which had serious bug in it). >> >> >> First, I think you meant 256, 384 and 521 bit, not the 192. >> >> Second, 5114 did not fix the bug in 4753. It just referenced 4753 for >> formatting. You know this better than I do, but I don=E2=80=99t think th= e IANA >> registry ever referenced 5114 for these ECP groups. >> >> So for the three useful groups in 5114 you didn=E2=80=99t need it (as 47= 53) >> already existed, and you don=E2=80=99t need it now, as 5903 exists. I do= n=E2=80=99t see >> anything standing in the way of moving to historic or obsoleting it. >> > > Possibly I missed something here: why should we be any happier about 5903 > than we are about 5114? > > > Can you prepare a backdoored elliptic curve that passes all acceptence > critera? > No, but can the NSA? The reason not to use 5114 is that one can construct moduli with hidden > SNFS structure. > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > > --94eb2c14a23a84472a054be16097 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 22 March 2017 at 18:20, Watson Ladd <watsonbladd@gmail.com&= gt; wrote:
=


On Mar 22, 2017 8:15 AM, "Ben Laurie" <benl@google.com> wrote:


On 7 October 2016 at 16:56, Yo= av Nir <ynir.ietf@gmail.com> wrote:

> On 7 Oct 2016, at 16:59, Tero Kivinen <kivinen@iki.fi> wrote:
>
> Stephen Farrell writes:
>>
>> So I'm not seeing anyone so far argue to not
>> deprecate these somehow.
>>
>> We could just make 5114 historic as Yoav suggests,
>> or, if someone writes an I-D to explain why, we
>> could obsolete 5114. (Such an I-D would presumably
>> also say something about codepoints that point at
>> 5114 from other registries.)
>>
>> Assuming nobody shows up saying these are in
>> fact in widespread use I'd be supportive of us
>> getting rid of cruft.
>
> I think the NIST ECP groups are quite widely supportd, and used= .
> RFC5114 includes both Nist ECP Groups (192, 224, 256, 384 and 52= 1) and
> 3 MODP groups.
>
> In IPsec, ECP groups are widely used, those MODP groups with subgroup<= br> > are not. On the other hand I think only those 192, 256 and 521 bit
> groups are really used, and those are defined also in RFC5903 (which > obsoleted original 4753 which had serious bug in it).


First, I think you meant 256, 384 and 521 bit, not the 192.

Second, 5114 did not fix the bug in 4753. It just referenced 4753 for forma= tting. You know this better than I do, but I don=E2=80=99t think the IANA r= egistry ever referenced 5114 for these ECP groups.

So for the three useful groups in 5114 you didn=E2=80=99t need it (as 4753)= already existed, and you don=E2=80=99t need it now, as 5903 exists. I don= =E2=80=99t see anything standing in the way of moving to historic or obsole= ting it.

Possibly I missed someth= ing here: why should we be any happier about 5903 than we are about 5114?

=
Can you prepare a backdoored elliptic c= urve that passes all acceptence critera?

<= /div>
No, but can the NSA?

The reason not to use 5114 is th= at one can construct moduli with hidden SNFS structure.

=


_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag



--94eb2c14a23a84472a054be16097-- From nobody Wed Mar 29 10:17:38 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9A6129466 for ; Wed, 29 Mar 2017 10:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CRN4vywND1Zv for ; Wed, 29 Mar 2017 10:17:34 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 350EB12944F for ; Wed, 29 Mar 2017 10:17:34 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id e75so97816273itd.1 for ; Wed, 29 Mar 2017 10:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JmCYdbra6kF3+qg8b5pQJgMAvulLmUBqFZFPJXjWE44=; b=Bs72DGP8c9ZvGD2Tqvka1mHgHwd+/iICFOVbzTFjaDpqJmWPB2KpQF/gyh6cxcV2ro RF5PIln4laCBq/HKHJIWwiq/qkmovVcwlZKlwHG2cJrJHuI/hbAJoIK4vNIR2tHo73nl IoazAFeuWkLrgOE+TO6QvSBrltOtRqPmYD3wq+wSiENUm/ez2Z7A4SD7Veu9l4c8Kioy oiD571TvX1y/x/WVIiPycO1T02NAU8ycERUAmCuBscMfo6lfa6XLQlmGbwk+aCdfxZqm PsimKj1Z2+VMY8walDiIiWum7ONA7lrjvM1u6tVyopf8/NsrolagHeRnO19b5TH6IVD0 Ysxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JmCYdbra6kF3+qg8b5pQJgMAvulLmUBqFZFPJXjWE44=; b=BwhbxJ9X2q0Irsnpz+mpC8adMZ4zeIuKIVzfx3rRAqia8fYg0ZVRIPH8fUVAXoN4zT ERNsDa2wEtNF68DuzYxMFEsh436MxMUr22hvCAjK8wfgkyiRruLiGiGeeIPt1N1Gf3OJ VgJtgPY+k4xl7geRkhR0Th1tOzCt2k7GWJtVzjX8NGQ5k+uL54OOMbK/+ENx4ampOK+B 5oyABJ7eVeebC5gOqjbtbP04icNQb7edFYWhDb8s2h9Dyg5MqRNLDQdIKdcQD4vWClQZ IGy0AUGkdxeL2/sm2x6ZMfUvF2B+87rpSQ8UBUldFDkoJcpq+54AycBLLAk8XOLUFzKR Llsg== X-Gm-Message-State: AFeK/H1M3W4ocTw4MSmYqOqvNfrva0O61MeF7y8GrjBWaYnS8xL5CKOFrindanHtfaaK1g== X-Received: by 10.36.23.84 with SMTP id 81mr1848545ith.14.1490807853566; Wed, 29 Mar 2017 10:17:33 -0700 (PDT) Received: from t2001067c03700128b0793f6a25433c5b.v6.meeting.ietf.org (t2001067c03700128b0793f6a25433c5b.v6.meeting.ietf.org. [2001:67c:370:128:b079:3f6a:2543:3c5b]) by smtp.gmail.com with ESMTPSA id y7sm3607042itc.27.2017.03.29.10.17.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 10:17:32 -0700 (PDT) From: Yoav Nir Message-Id: <8B462FE6-E8CD-4E79-A15C-AE722CEF9C72@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_03996D0D-758D-49CB-959F-AF2CDBE37917"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 29 Mar 2017 12:17:31 -0500 In-Reply-To: Cc: Watson Ladd , Security Area Advisory Group , Tero Kivinen To: Ben Laurie References: <22519.43588.421250.807948@fireball.acr.fi> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [saag] Possible backdoor in RFC 5114 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 17:17:36 -0000 --Apple-Mail=_03996D0D-758D-49CB-959F-AF2CDBE37917 Content-Type: multipart/alternative; boundary="Apple-Mail=_3228A2C6-6C36-4AB6-8CA6-A6F93E877869" --Apple-Mail=_3228A2C6-6C36-4AB6-8CA6-A6F93E877869 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 29 Mar 2017, at 11:50, Ben Laurie wrote: >=20 >=20 >=20 > On 22 March 2017 at 18:20, Watson Ladd > wrote: >=20 >=20 > On Mar 22, 2017 8:15 AM, "Ben Laurie" > wrote: >=20 >=20 > On 7 October 2016 at 16:56, Yoav Nir > wrote: >=20 > > On 7 Oct 2016, at 16:59, Tero Kivinen > wrote: > > > > Stephen Farrell writes: > >> > >> So I'm not seeing anyone so far argue to not > >> deprecate these somehow. > >> > >> We could just make 5114 historic as Yoav suggests, > >> or, if someone writes an I-D to explain why, we > >> could obsolete 5114. (Such an I-D would presumably > >> also say something about codepoints that point at > >> 5114 from other registries.) > >> > >> Assuming nobody shows up saying these are in > >> fact in widespread use I'd be supportive of us > >> getting rid of cruft. > > > > I think the NIST ECP groups are quite widely supportd, and used. > > RFC5114 includes both Nist ECP Groups (192, 224, 256, 384 and 521) = and > > 3 MODP groups. > > > > In IPsec, ECP groups are widely used, those MODP groups with = subgroup > > are not. On the other hand I think only those 192, 256 and 521 bit > > groups are really used, and those are defined also in RFC5903 (which > > obsoleted original 4753 which had serious bug in it). >=20 >=20 > First, I think you meant 256, 384 and 521 bit, not the 192. >=20 > Second, 5114 did not fix the bug in 4753. It just referenced 4753 for = formatting. You know this better than I do, but I don=E2=80=99t think = the IANA registry ever referenced 5114 for these ECP groups. >=20 > So for the three useful groups in 5114 you didn=E2=80=99t need it (as = 4753) already existed, and you don=E2=80=99t need it now, as 5903 = exists. I don=E2=80=99t see anything standing in the way of moving to = historic or obsoleting it. >=20 > Possibly I missed something here: why should we be any happier about = 5903 than we are about 5114? >=20 > Can you prepare a backdoored elliptic curve that passes all acceptence = critera? >=20 > No, but can the NSA? I don=E2=80=99t know, but we can speculate all day about what the NSA = can or cannot do, including wandless magic or generally solving the DLP. = We can only make decisions on the basis of what we know or can = reasonably project. Yoav --Apple-Mail=_3228A2C6-6C36-4AB6-8CA6-A6F93E877869 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 29 Mar 2017, at 11:50, Ben Laurie <benl@google.com> = wrote:



On 22 March 2017 at 18:20, Watson = Ladd <watsonbladd@gmail.com> wrote:


On Mar 22, 2017 8:15 AM, "Ben Laurie" <benl@google.com> wrote:


On 7 October 2016 at 16:56, = Yoav Nir <ynir.ietf@gmail.com> wrote:

> On 7 Oct 2016, at 16:59, Tero Kivinen = <kivinen@iki.fi> wrote:
>
> Stephen Farrell writes:
>>
>> So I'm not seeing anyone so far argue to not
>> deprecate these somehow.
>>
>> We could just make 5114 historic as Yoav = suggests,
>> or, if someone writes an I-D to explain = why, we
>> could obsolete 5114. (Such an I-D would = presumably
>> also say something about codepoints = that point at
>> 5114 from other registries.)
>>
>> Assuming nobody shows up = saying these are in
>> fact in widespread use I'd be = supportive of us
>> getting rid of cruft.
>
> I think the NIST ECP groups = are quite widely supportd, and used.
> = RFC5114 includes both Nist ECP Groups (192, 224, 256, 384 and 521) = and
> 3 MODP groups.
>
> In IPsec, ECP groups are widely used, those MODP groups = with subgroup
> are not. On the other hand I think only = those 192, 256 and 521 bit
> groups are really used, = and those are defined also in RFC5903 (which
> = obsoleted original 4753 which had serious bug in it).


First, I think you meant 256, 384 and = 521 bit, not the 192.

Second, 5114 did not = fix the bug in 4753. It just referenced 4753 for formatting. You know = this better than I do, but I don=E2=80=99t think the IANA registry ever = referenced 5114 for these ECP groups.

So = for the three useful groups in 5114 you didn=E2=80=99t need it (as 4753) = already existed, and you don=E2=80=99t need it now, as 5903 exists. I = don=E2=80=99t see anything standing in the way of moving to historic or = obsoleting it.

Possibly I missed something here: = why should we be any happier about 5903 than we are about = 5114?

Can you prepare a backdoored elliptic curve that passes all = acceptence critera?

No, but can the = NSA?

I don=E2=80=99= t know, but we can speculate all day about what the NSA can or cannot = do, including wandless magic or generally solving the DLP. We can only = make decisions on the basis of what we know or can reasonably = project.

Yoav

= --Apple-Mail=_3228A2C6-6C36-4AB6-8CA6-A6F93E877869-- --Apple-Mail=_03996D0D-758D-49CB-959F-AF2CDBE37917 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY2+wsAAoJELhJCxUKWMyZzR8H/jg2w/gv3Ccfk+27QHrzIC9j RbplK/v2/SVoM2eX1kaKLsw6bhytSyxJ504jSAJ/xq487BSSmTC7raZs94h+Q4S8 UWdqTyvdueOFb+PEmVbZ1Qxk1FJrXbv9s61r6MznYD9bgYXCh0qiyAH/8RossHwQ i3lDL7fzYJQfMBmwqmS9ojg5SJdoTJXtyHT/i0GJX4r7ie8RssKIWwjq2gq6eL4Q zlP1TQQssP6kWe92qAeuDYzLpMsSgM1gaUmA3358E9m7Pt9Yxw0wkJ0S+My4+Sjn bqZ3bWYYJJuXER2Hpwyv3XHTin6qBvekV+aaDAVIAJpyUfZngNxL5gjOyvPAPeg= =fVCb -----END PGP SIGNATURE----- --Apple-Mail=_03996D0D-758D-49CB-959F-AF2CDBE37917-- From nobody Wed Mar 29 10:43:37 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DC912940B for ; Wed, 29 Mar 2017 10:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 lZgO2RyPqC-X for ; Wed, 29 Mar 2017 10:43:33 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 98B27128CD5 for ; Wed, 29 Mar 2017 10:43:32 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id z13so3759391iof.2 for ; Wed, 29 Mar 2017 10:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=Q32hXA27tXXhLkaSMEdW31hIoMUlT9CLykJnc5u/rnU=; b=QH21+oyXt33d2HYENxz4R+UYBwtwwv7faudLDxTkSgM/l3CxmjvcyMrB5ZQp3pPox0 98Y5QhK6xa4y6dTa6AQSa9wh6+ln5D8DO1u7hM4BFJcDol08pohQu6ITMvnMMqPZ5Xfj C1qML2PHzCei8QqDSqXj0+PN9328MFi6OkYVkhzrOSshZSj21zHLNMBc6ZQq1+9xINIi c9nQit/94OKdpYiFztsdTQ+dlxLzJZTC4hXYx8n13VcmxQsxHbJejs5sxoXmmY5Du4A9 yqET/GD82uMhLByR0Qxatk3mM2/tZ8h89fs0SHrOf/lwfdHH6+Zx4CubdixQV+PAhoCO whNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=Q32hXA27tXXhLkaSMEdW31hIoMUlT9CLykJnc5u/rnU=; b=OLB4IbLQG7rDdEIIAr3QJhl6WmEEgJDXEUVwK+g7LmJxRtMgvLmyqNpE1CkgNEDudi 5aSdoQaMEMS1EfJfhGnmF8g1ruL1HQSYr1jWyFgxhLNhwDrWam+kkH9vG2ovSPGrqEm+ wV0xc4N/shftJg9dT/CiDyWVV3Zfv5FNwspPR/NuKQyYnOFa3ALnSPhHC93Fl6l4MH8P dgHI5sa1t7Cs97RvsCFmAOpA/VgR8sj1iBgqA0oZk+dK6yCc9wmhIAeIM4JKePJVg0+E ZxDKJgiIqlDTIS//PQzMihSljuZ4ggH5BWXEmxxwhOgo2Mwcois0+RnG9BPfOqqnpkLU jq0A== X-Gm-Message-State: AFeK/H1Ml78NAijqoR3OCYy930W8W9V5Zw15ix81A9Arz8Zbl7VgfxSqQwvf5e5JYwxttg== X-Received: by 10.107.142.139 with SMTP id q133mr2013035iod.99.1490809411423; Wed, 29 Mar 2017 10:43:31 -0700 (PDT) Received: from dhcp-95ff.meeting.ietf.org (dhcp-95ff.meeting.ietf.org. [31.133.149.255]) by smtp.gmail.com with ESMTPSA id h12sm4047943iod.57.2017.03.29.10.43.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 10:43:30 -0700 (PDT) To: saag@ietf.org From: Melinda Shore Message-ID: Date: Wed, 29 Mar 2017 12:43:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wRAEb1gX6HL557GNotkTC7pEcBVSAIWkO" Archived-At: Subject: [saag] trans report for IETF 98 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 17:43:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wRAEb1gX6HL557GNotkTC7pEcBVSAIWkO Content-Type: multipart/mixed; boundary="90SeW63ovlR3JOmi5g0qa2LaFB1nLXPWD"; protected-headers="v1" From: Melinda Shore To: saag@ietf.org Message-ID: Subject: trans report for IETF 98 --90SeW63ovlR3JOmi5g0qa2LaFB1nLXPWD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable trans met Tuesday afternoon. There were two mail areas of discussion: 1) changes required to be able to support putting log verification into the certificate validation process, and 2) redaction of names in logged certificates because of privacy concerns. Authors are working together with the people who've raised the issue on resolving the first matter, and we've got several proposals for addressing the name redaction issue that need to be evaluated. Thanks, Melinda --90SeW63ovlR3JOmi5g0qa2LaFB1nLXPWD-- --wRAEb1gX6HL557GNotkTC7pEcBVSAIWkO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY2/JCAAoJELiGRpM6HoEu/BYP/0QaW+hcF+b810NXWtV1dnsl 182Ij3scYLjog65gvoyxEzRBV8UblR71qwWiUR6bzPu/pK0gfXSlCy21Y3/XoC2R cxERLB+8qP6aLfmZEXUSDSd3pyA69U0R4zfJPJuOPVkHgPhVmljJ/v886KNbI/hx MLCEkL8tGY4uF5r4/f04KWo0cQIXtR3xiRyXRRpKmOTLRixw3P5ussjw1F64Gw00 cokbfoohbMbqpvNzyCrC4zRug/1vTOWBg7EPq8IkC0xR5r4M5E3IPcpJSRJOPnfu H1bVJ6iqAQCPh4WAq0hFWTE+NuGm03UJJOMCSOfAmoC+tZgj1G4m/Awsu8wkMsQq OGRE6GAYMcXAHVlM86+mjwAUO1yLmF/MRDIDuSIy0L3xVfTOphWVK8vzkJLovm8P vlm8lZEtGK9zdJk2YlpKQ8BZpHgXdQ6AoFM93k4MzbRuRPbL4PKK7VlSWLuakKVY g8XUNYNH3ANzlYW5vf03G8oZu7Sck2AvhuGmnRLYWtYwlOGN1R0pxiUKmcWzl4r2 jXz8XmhwdUmFPgEmtNQCZpw+tAu/GVdmQhnVY8lkOs9HOdZcnisexpe1mJwsIFrB 3c56tQosKS7JdaoPUt+mMjX9IqFk3oUORqe/gJ8PAV8rDbxVZiKF9V/foh6kf4r7 R4Df8tyRTG6idvZFvpBx =/h9U -----END PGP SIGNATURE----- --wRAEb1gX6HL557GNotkTC7pEcBVSAIWkO-- From nobody Wed Mar 29 10:48:18 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50607129436 for ; Wed, 29 Mar 2017 10:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 75p28pdYs5D1 for ; Wed, 29 Mar 2017 10:48:15 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 2339E1292F4 for ; Wed, 29 Mar 2017 10:48:15 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id z13so3844828iof.2 for ; Wed, 29 Mar 2017 10:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version; bh=CRA041IAXWWAgejSEoYkO3lyblpE8T6eXBb5gM/Lw7Y=; b=dVr64iILjgWFA4RBLBpj04Ne7Mc5Sc0FIMGqx0FlB0OhMER30j7vMwdC4+vcaZJLrT V0qN3TwJJT5giCDfLyg5BoD8ODUjX4n24YtlCnboDYqfi4wl+SK1Ulg3UuPjcGeYTScg j9s9wx9vPX6qVQerDb2aUB2z83inwXtAzbsmJWv4dA0AEkE1LPQ34idKPMW/fX8z5jFi l5L1+K0CE7DbGk8fqbkJlZ3yCLKozLyfukKmxVZUCIUADH6Ngr6NZi5zcwPZlCsYvtFV 5tUTkY156Yg+XI4ZCRETCe9Btz0IjBqelYPoKSmuMPzRow4DMddY2AUny7iUo44QXpAS d/sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version; bh=CRA041IAXWWAgejSEoYkO3lyblpE8T6eXBb5gM/Lw7Y=; b=swI92Y8SW52/gIV/ccqSENxVrsKySJtv3LGyMfo/4S8VbFtEHZ2hPdO9YTFp/g2KuI s+OI7P0kVQWqz/ESIZzqor6YJl37rRTaoGtorjHj8GQOpyzQipetbmMRtoNr7F4jsqqo VFUSIswbMmJcKs2JQ9kygR6Q+be7HgGH8ZQaqbZBZUb9ZHO0cviudOoB/+mvmRcUiyoS FcXmnARqQ3qs4jKJb+HeQhos1OcnAnQpX8PKU3xjw/+P0iH7/Ns/LlaAEBFckVuMwjsr +oxMYqQMd0O5lSehos+HVzhoBe+6VCT+Kuqim/vtjmZW5k+6OmFeVTq5vLD0Frki3rHX Q7TQ== X-Gm-Message-State: AFeK/H3YrLQmR4PUXYCQAfQGdLFo4jOEIkIEtd3G+aDxF+EAgJGwhsSFy+1ODeffWgd8HA== X-Received: by 10.107.180.200 with SMTP id d191mr2077908iof.42.1490809694264; Wed, 29 Mar 2017 10:48:14 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:c031:aaf4:f432:ed10? (t2001067c03700128c031aaf4f432ed10.v6.meeting.ietf.org. [2001:67c:370:128:c031:aaf4:f432:ed10]) by smtp.gmail.com with ESMTPSA id i89sm4051851ioo.52.2017.03.29.10.48.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 10:48:13 -0700 (PDT) From: Yaron Sheffer To: "saag@ietf.org" Message-ID: <43d1fb0a-2816-dc64-931a-ed559c1242b6@gmail.com> Date: Wed, 29 Mar 2017 12:48:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------94441459CA768107DF6B5644" Archived-At: Subject: [saag] SecEvent report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 17:48:17 -0000 This is a multi-part message in MIME format. --------------94441459CA768107DF6B5644 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit SecEvent met Wednesday morning. Since the last meeting we adopted the SET event token format document, and we discussed issues associated with it. Specifically some thorny security issues about the possibility of confusing SET tokens with other JWT statements. We heard a report about JOSE/JWT security, with a bit of discussion about the need for published guidelines that JWT profiles, such as us, can use to improve security across the board. There was discussion of SET use cases, which helped clarify what's needed from the SET transport. Lastly we discussed the distribution draft, which is still not a WG document. Thanks, Dick and Yaron --------------94441459CA768107DF6B5644 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

SecEvent met Wednesday morning. Since the last meeting we adopted the SET event token format document, and we discussed issues associated with it. Specifically some thorny security issues about the possibility of confusing SET tokens with other JWT statements. We heard a report about JOSE/JWT security, with a bit of discussion about the need for published guidelines that JWT profiles, such as us, can use to improve security across the board. There was discussion of SET use cases, which helped clarify what's needed from the SET transport. Lastly we discussed the distribution draft, which is still not a WG document.

Thanks,

    Dick and Yaron

--------------94441459CA768107DF6B5644-- From nobody Wed Mar 29 11:05:03 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA591289B0 for ; Wed, 29 Mar 2017 11:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 ig9oKJdgnU8e for ; Wed, 29 Mar 2017 11:04:54 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 70499127843 for ; Wed, 29 Mar 2017 11:04:54 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id i5so11105187pfc.2 for ; Wed, 29 Mar 2017 11:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=l/jtAntXx19wISAayqseToo22q/MWX30347X7ugmAaU=; b=G4Qg1/rqNzhiXreE63kIyiP5jvA1amu6RFtawUVPht/cuUJIgjDvhJlKGJ3p7KXr5+ zMs6Mh4sshCuEn9VNShycywclaW2ugAR8xYRsou7aIMwDrIQd2to4dlLAY8MUyZJY7JM KM5g9O0E+sRRuFRAUYUa7m84huP3/0kMx6XqTjrZLq0WWVXwnguR0UDZhkbyLhm8P2Gl s9P98hTqFf83Vp0RJig3ksSlxKCS5FHSpzOib2dv7PoP2BeG3gjHWzhvs/wd7cDOoYut TLLilDq3c7dkWTHm6QFB9uHv2sKWeBsnAYdR6i3iYWzVb3Lc73Pkp6/E6Tw6LuT1ozDZ b64Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=l/jtAntXx19wISAayqseToo22q/MWX30347X7ugmAaU=; b=ssnPi4CpmGe+YEAXO0Iae2hbLGMDgrq0iHvGVWM6Ma6tcPVh0wz9Ipciut8vNcmnU8 Plx40SL4Ar5HgwlvzrNP7vD0XxmSX8uILJEZObhzsEc7HjjVTNsUcN+Y6xk3xVNBKRjc fGt02vBezqaK31jG0uweJON2C5tuoMPXst9Iqnp+vpNbuRgv2H+DtEazjtun3/RCG+nh eBMp+Prm/kDp0ydLsZ14Cf7175CyQC0lgroAk2TQCvFScXz/TgfoC5MtBSFappC2eSy6 v7fx4Lp+bKEueYVM8XmZgFhQ+wrs4f6a2cu6/FqtnKW6ea4i21czTS4KiV0zQwPBvWil VxdQ== X-Gm-Message-State: AFeK/H0GoCh60Hgtuvkvo3DcSE8rHTJE1p7Tx3tGcmTPQ1GhnpEZQ26EgXd3aVFGJQjhFEYJtJcvwEvCfV8uyg== X-Received: by 10.84.215.23 with SMTP id k23mr2057718pli.58.1490810694044; Wed, 29 Mar 2017 11:04:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.165.141 with HTTP; Wed, 29 Mar 2017 11:04:33 -0700 (PDT) From: Joseph Salowey Date: Wed, 29 Mar 2017 13:04:33 -0500 Message-ID: To: "saag@ietf.org" Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1a1402d8a587054be26992 Archived-At: Subject: [saag] TLS SAAG report for IETF98 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 18:04:57 -0000 --94eb2c1a1402d8a587054be26992 Content-Type: text/plain; charset=UTF-8 The TLS working group met on Tuesday morning. The main topic was discussion of WGLC issues of TLS 1.3. We continue to work on issues and plan on having a draft -20 that will go to the IESG. We had updates on DTLS, DNSSEC chain extension, certificate compression and delegated credentials. There was support in the room for adopting the following drafts (pending confirmation on the list): draft-rescorla-tls-dtls13, draft-ghedini-tls-certificate-compression, draft-rescorla-tls-subcerts and draft-sullivan-tls-exported-authenticator. There was not clear support to adopt the following drafts: draft-gutmann-tls-ltss and draft-sheffer-tls-pinning-ticket. --94eb2c1a1402d8a587054be26992 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The TLS working group met= on Tuesday morning.=C2=A0 The main topic was discussion of WGLC issues of = TLS 1.3.=C2=A0 We continue to work on issues and plan on having a draft -20= that will go to the IESG. =C2=A0 We had updates on DTLS, =C2=A0DNSSEC chai= n extension, certificate compression and delegated credentials.=C2=A0

= There was support in the room for adopting the following drafts (pending co= nfirmation on the list): =C2=A0draft-rescorla-tls-dtls13,=C2=A0draft-g= hedini-tls-certificate-compression, =C2=A0draft-rescorla-tls-subcerts= =C2=A0and=C2=A0draft-sullivan-tls-exported-authenticator. =C2=A0 = There was not clear support to adopt the following drafts:=C2=A0draft-gutma= nn-tls-ltss and=C2=A0draft-sheffer-tls-pinning-ticket. =C2=A0
--94eb2c1a1402d8a587054be26992-- From nobody Wed Mar 29 11:26:39 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DE912940F for ; Wed, 29 Mar 2017 11:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Ke04Zl4sNdid for ; Wed, 29 Mar 2017 11:26:32 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 226D1129455 for ; Wed, 29 Mar 2017 11:26:27 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id w11so26324826wrc.3 for ; Wed, 29 Mar 2017 11:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=0UQx1k0L6l+XjLJMU56zVqSL/lcQu8yDZOnIIcpIjSw=; b=WNS+sdlgIExxIF84yIN0ddVN33B99r6rLj+QdlePXqDxSzWN6lnRS7MlVQ6lZQyJ6o 8R1lnC2KduKjgvU5p0MilA58foq1p4TGF8HY7AX4hvZqi5SH9Se4XT2Aqj1eYHbeAmyH cShyP0J2SHw8b3ioVGNVKz3z6exfKXZ10rh0tgxBkPVS7cH0ZBgmKSiOSWU3ZtXz5s/5 lBkU1BaNZnpP62cMm519I/JmCM1f+qXmbPKSUklFcmlrm3enzevsrXENgFOTWq20pXxP V/YODuwZA+tkgTZiygPzCZ0xZrGX2upe9+FSyk0Ms0vQDR6QeP3AHZGWg6DD/dasOtB9 pTeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=0UQx1k0L6l+XjLJMU56zVqSL/lcQu8yDZOnIIcpIjSw=; b=Hwrvy6t6AwTgKhU9OeWGHx8ASer4ZQaR9HnqMSEKKvRqOxrmSgObI0VqBt6jf03LUU QBNZSSOM5a2ZJPRcIGZo9WrRy3TULzA/HjXFscgkWCQRImPI49gbG0+37TlbTR7T75gC Wwn4HBV3j4hG5W6GBAbE3j0RlQSzhN1sIZxb4PbBI/ErZIVgXDAnXUVYWwYH2bAjJNXz r0ZCR53YqEDYNJzBlPKB8RlP5Eqh7UHw+DEvJra4xzjTqU4lKSTp0siLVjuN8TMFOpfV 8TlwE7spz6lYgMQ2xIqa746P/ZT9fvakd3dDoQL9FrWjcPa4hAN/YDoO/KnyPidlxXSW q57Q== X-Gm-Message-State: AFeK/H1P2J+eWz2DPU6N35Qww5qkcc6kDcTgmTdsWtcn5mHJcHGcRSPOvWEC18+8P7hTnm8dj47NhmJWO2/+fQ== X-Received: by 10.28.66.211 with SMTP id k80mr1984889wmi.5.1490811985525; Wed, 29 Mar 2017 11:26:25 -0700 (PDT) MIME-Version: 1.0 Sender: benlaurie@gmail.com Received: by 10.28.166.208 with HTTP; Wed, 29 Mar 2017 11:26:24 -0700 (PDT) In-Reply-To: <8B462FE6-E8CD-4E79-A15C-AE722CEF9C72@gmail.com> References: <22519.43588.421250.807948@fireball.acr.fi> <8B462FE6-E8CD-4E79-A15C-AE722CEF9C72@gmail.com> From: Ben Laurie Date: Wed, 29 Mar 2017 19:26:24 +0100 X-Google-Sender-Auth: -7dbv9g7F9Uu1CEh6wTcsZKxA_M Message-ID: To: Yoav Nir Cc: Ben Laurie , Security Area Advisory Group , Tero Kivinen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] Possible backdoor in RFC 5114 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 18:26:34 -0000 On 29 March 2017 at 18:17, Yoav Nir wrote: > > On 29 Mar 2017, at 11:50, Ben Laurie wrote: > > > > On 22 March 2017 at 18:20, Watson Ladd wrote: >> >> >> >> On Mar 22, 2017 8:15 AM, "Ben Laurie" wrote: >> >> >> >> On 7 October 2016 at 16:56, Yoav Nir wrote: >>> >>> >>> > On 7 Oct 2016, at 16:59, Tero Kivinen wrote: >>> > >>> > Stephen Farrell writes: >>> >> >>> >> So I'm not seeing anyone so far argue to not >>> >> deprecate these somehow. >>> >> >>> >> We could just make 5114 historic as Yoav suggests, >>> >> or, if someone writes an I-D to explain why, we >>> >> could obsolete 5114. (Such an I-D would presumably >>> >> also say something about codepoints that point at >>> >> 5114 from other registries.) >>> >> >>> >> Assuming nobody shows up saying these are in >>> >> fact in widespread use I'd be supportive of us >>> >> getting rid of cruft. >>> > >>> > I think the NIST ECP groups are quite widely supportd, and used. >>> > RFC5114 includes both Nist ECP Groups (192, 224, 256, 384 and 521) an= d >>> > 3 MODP groups. >>> > >>> > In IPsec, ECP groups are widely used, those MODP groups with subgroup >>> > are not. On the other hand I think only those 192, 256 and 521 bit >>> > groups are really used, and those are defined also in RFC5903 (which >>> > obsoleted original 4753 which had serious bug in it). >>> >>> >>> First, I think you meant 256, 384 and 521 bit, not the 192. >>> >>> Second, 5114 did not fix the bug in 4753. It just referenced 4753 for >>> formatting. You know this better than I do, but I don=E2=80=99t think t= he IANA >>> registry ever referenced 5114 for these ECP groups. >>> >>> So for the three useful groups in 5114 you didn=E2=80=99t need it (as 4= 753) >>> already existed, and you don=E2=80=99t need it now, as 5903 exists. I d= on=E2=80=99t see >>> anything standing in the way of moving to historic or obsoleting it. >> >> >> Possibly I missed something here: why should we be any happier about 590= 3 >> than we are about 5114? >> >> >> Can you prepare a backdoored elliptic curve that passes all acceptence >> critera? > > > No, but can the NSA? > > > I don=E2=80=99t know, but we can speculate all day about what the NSA can= or cannot > do, including wandless magic or generally solving the DLP. We can only ma= ke > decisions on the basis of what we know or can reasonably project. But isn't that the point of nothing up my sleeve numbers? Which 5903 doesn't use... From nobody Wed Mar 29 11:34:02 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22301270AC for ; Wed, 29 Mar 2017 11:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 9oWiytZ58aFI for ; Wed, 29 Mar 2017 11:33:55 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 764A81293E4 for ; Wed, 29 Mar 2017 11:33:53 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id r142so20860570qke.2 for ; Wed, 29 Mar 2017 11:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=Lby0idJ0uUeMohIJv2T2Zxr9q87eAJ0W6dH/FDDjTsQ=; b=lnhVeNcGMipj2/ldwU+JQrbEdz10v7qoBKG7iU/2Te+mWi818YNffLl6zwHi1fvSAL 7OAc72TALYvmuJC/mKEWnmInFN5cVZOc0JU78g3sSkTqsu6+PjCqbySekZvVh1BN08kg FC5OJ5WfGsQ63TvaNQ3mBwKI5VXMxTXDzzIPo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Lby0idJ0uUeMohIJv2T2Zxr9q87eAJ0W6dH/FDDjTsQ=; b=AWczkL3IKI5378o0EhUGUsTmTFUngHsHjOOEx43sSlatx4T0oyvZxMCeKECM/KaQ7E ph9ko+w06AyWsWLkUAu+3wmigVOeP1LeqrYzCVrhyqckulhNC7oqJx/pw6nEPXK9i0Cw f37o291n6URa6o6LjvPsiz8ek+Q5/cPd2tDw9ZN/Vs80qMrKOrZtBJivmJDvpUklXdG7 g+zsxi4dfPcQNRnCTp60RiO2ijsz81hew9FReHKgbQHmJ1de35E/xDKUL4kC3kCMqLGm jEe6z4oVBrV9YFFzKlb/TeJVt5+jmcMQHiYypc/dIajgl/ckS9+d+gcYjPzE49HtLZWE GKGA== X-Gm-Message-State: AFeK/H0ISVDTPGnEqTnL5Pg9rC47rz4r/1UOuJt2+AzuVTykE4pTqrEE5IMBwZXTdv/sHMljFlfIKgRD7LpJcA== X-Received: by 10.55.11.207 with SMTP id 198mr2114419qkl.100.1490812432212; Wed, 29 Mar 2017 11:33:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Wed, 29 Mar 2017 11:33:51 -0700 (PDT) X-Originating-IP: [31.133.148.145] From: Kyle Rose Date: Wed, 29 Mar 2017 13:33:51 -0500 Message-ID: To: saag@ietf.org, tcpinc Content-Type: multipart/alternative; boundary=001a114c70b07330ab054be2d127 Archived-At: Subject: [saag] TCPINC status X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 18:33:57 -0000 --001a114c70b07330ab054be2d127 Content-Type: text/plain; charset=UTF-8 TCPINC is not meeting in Chicago. We have just ended WGLC on the two main documents, TCP-ENO and tcpcrypt: https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt We are still looking for implementors, and also co-authors for a middlebox probing document. Finally, there is still the abstract API draft in development that probably needs more eyeballs from folks who have put together similar documents in the past. Kyle (for David Black) --001a114c70b07330ab054be2d127 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
TCPINC is not meeting in Chicago.

W= e have just ended WGLC on the two main documents, TCP-ENO and tcpcrypt:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://da= tatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datat= racker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt

We are still= looking for implementors, and also co-authors for a middlebox probing docu= ment. Finally, there is still the abstract API draft in development that pr= obably needs more eyeballs from folks who have put together similar documen= ts in the past.

Kyle (for David Black)
--001a114c70b07330ab054be2d127-- From nobody Wed Mar 29 11:52:55 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9A81294FF for ; Wed, 29 Mar 2017 11:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 sETmjASOZxtv for ; Wed, 29 Mar 2017 11:52:51 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 6E0F9129525 for ; Wed, 29 Mar 2017 11:52:51 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id i34so20918541qtc.0 for ; Wed, 29 Mar 2017 11:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=07OQwGwO3RT9lQQtbSUgWreES5BtzSYLkRZQOjD2nGU=; b=gdzdJqZ5y5MuSI0Slr33etIjM5NmEt74ThFnPixlcj1dB7tuxqjlf3iMIMrGM9+Nr1 kXA9+OhD8DgYia7alFnWBLypo4RQqw58iDHSx+OdSFi4vJThRVsbk2hbInCldKhqPGZa qZwpx8e3N8qnmJURonG/qLwZimTKSRjilrYu6JkKN7EWdU2g7m41AcpeEPL1wS9OWMsd hEx95lLypPbx7cRV0UnIjNYdz5HnATg1MW4ZwO+FLpe924gkBGQUa91blq8Kp84q7zvc TvcZaWOTzlEvByXfORB75KS2U60QdocXdh1NMqklmPb/Ox+hcnW6p3B14LhF/zXt9579 sqTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=07OQwGwO3RT9lQQtbSUgWreES5BtzSYLkRZQOjD2nGU=; b=FDpwQnwRTGaE/3MKi42863e+Wf/AZtBwYeCiQQIcdst92HlQmDVbif3illuld4ydPn vESdm3eJ+k16Rwm9grtkaK1GjXBpJho9G+TT9izFalRq4/eBpr80nNdh/nE7aOwisATF loVDMObfra0BkvJ3htLuGylxVfEYDJOBfjAryiQiHMprI9JgWpE9d6WKFK8e1r+LM0IW 1CaUfInqPIaXsGi/wUbZvJPlw/R+5csUN7OLGefaaRpadPCVgqE1qoBhZzwCLvaT0EER pP5aSDxu39bRAlrw89SaxPufgElOTVSPdwED8yrxIL0sTs1Cap5gjHuuzsNOxYVQW0EK Ibsg== X-Gm-Message-State: AFeK/H3HwYDJN5q5DqYamenNWtE7RKVi3raiHmoNOwafSg5Xw3ndqlWoL81mvWLa24qZ+27mKZ2FPVCJHXBAAt8I X-Received: by 10.200.47.9 with SMTP id j9mr2305460qta.57.1490813570200; Wed, 29 Mar 2017 11:52:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.177.11 with HTTP; Wed, 29 Mar 2017 11:52:09 -0700 (PDT) From: Warren Kumari Date: Wed, 29 Mar 2017 13:52:09 -0500 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] DANE Status. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 18:52:53 -0000 DANE did not meet in Chicago. This is because we have declared success and shut down :-) Our final document: "draft-ietf-dane-smime-16 - Using Secure DNS to Associate Certificates with Domain Names For S/MIME" lies with the RFC Editor. Thanks to all of our participants, Warren -- 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 From nobody Wed Mar 29 13:42:30 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8421B1201F2; Wed, 29 Mar 2017 13:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 gGmLV8P5-rxf; Wed, 29 Mar 2017 13:42:06 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0098.outbound.protection.outlook.com [23.103.200.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74055129481; Wed, 29 Mar 2017 13:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=w3Gma++M9mODIA8/U+rJLTU2z37VjY89vzwisgNlYyI=; b=mDBytFIu/s6c65I+1o8OErJY2xzT6TfzqPchKLjvDoKZmoSZCna4xB099oUnG8/e+AFTPy9nLb2ReJIiLk/ltF1yiU0BVnHg0fk7bm0NjbYnRaUz7wNrXubW6v7qjdcHFtBLglX9mIHPYIOL8y9kgdN8eSHw1XSdHuwtAAAZ10M= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Wed, 29 Mar 2017 20:42:04 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0991.021; Wed, 29 Mar 2017 20:42:04 +0000 From: "Waltermire, David A. (Fed)" To: "saag@ietf.org" , "opsawg@ietf.org" , "netconf@ietf.org" , "netmod@ietf.org" Thread-Topic: PANIC Bar BoF Tonight @ 6:30pm CDT Thread-Index: AdKoyz/2/d9baDSGTnuHD2EJjZ7Mgw== Date: Wed, 29 Mar 2017 20:42:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.222.87] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1440; 7:MRz0WSeTiWWcEhsHvpdzglCWeYt10yvdJL2HAM7tWMGoGl4fZ6pjnisT6YM4hGexNOoWOCm5NeE3pWeaCCBiezL3s0n0EVCAoLPMstiTbJEmLCN46tegb36TvmcCDHqJo8cU+YuenCc6+3tO74BzGcpl3tyywY0a6G2mNqIK68Q/FhptBRZZxWy/LoL6AEX0Pr4RRpmuAnL7M3lYf/4RI4jjDz81lgkDjfo3qZ0y+bI5jSWddlbyxn1HC7xwDAZ6ZfsO1t29VTfNbUPR2LNjA3INADhXpccxGwzlPnlN25nJSvJYCZfdBwwgmQNAibjz2eqxMzcK5U8D5H9xmwaILQ== x-ms-office365-filtering-correlation-id: ca08842c-5a57-4a1f-02fa-08d476e40f60 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:MWHPR09MB1440; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123564025)(20161123555025)(20161123558025)(20161123560025)(6072148); SRVR:MWHPR09MB1440; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1440; x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39840400002)(39450400003)(39850400002)(39400400002)(7696004)(6506006)(2501003)(53936002)(77096006)(74316002)(305945005)(9686003)(55016002)(33656002)(6436002)(99286003)(8676002)(81166006)(8936002)(3660700001)(2201001)(86362001)(25786009)(102836003)(3280700002)(50986999)(54356999)(2900100001)(3846002)(189998001)(6116002)(2906002)(5660300001)(7736002)(122556002)(38730400002)(450100002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1440; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 20:42:04.5631 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1440 Archived-At: Subject: [saag] PANIC Bar BoF Tonight @ 6:30pm CDT X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 20:42:09 -0000 Just a quick reminder... the Posture Assessment through Network Information= Collection (PANIC) bar BoF is tonight right after the IETF 98 Technical an= d Administrative Plenary at 6:30pm CDT in Vevey 4 at the Swissotel Conferen= ce Center. We are hoping to start a discussion about how to leverage the ex= isting IETF network management protocols to best address security automatio= n for network infrastructure devices. We would like your ideas on how to be= st pursue this work, and your insights into network infrastructure security= problems that will impact our networks in the future. We are holding a sid= e meeting at IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a disc= ussion about how to move forward on this topic. Given the late hour, we will have some light snacks. We hope to see you the= re. Regards, David Waltermire From nobody Wed Mar 29 14:52:36 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E6212945D for ; Wed, 29 Mar 2017 14:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 WVIF-8Q4wXmp for ; Wed, 29 Mar 2017 14:52:32 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 4A2FE1295D0 for ; Wed, 29 Mar 2017 14:52:32 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id 21so19374790pgg.1 for ; Wed, 29 Mar 2017 14:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zXRKjTtQfAhIof4f1bpFuN6kApdYi2rF9TK55RsxInI=; b=ZtvR2tYRx5QmITGhY7wIKPy3LYvKdQXBcyyeUPsAfGBkMUWxZeBWflZROH52HuKhMC 5r4/aR7egTtXJgapJtJ1eTiJyN0hf8o8+PjamU6c6wcUL3xOFPIg2rPOi70Nqilw6dLg ALgyV2no5eApz7+8zarO8FNbkCOSz7OjtW7saUY4OUisqFU8KF7cqzWPGNi/ADvmTniH rqzNf6dq/7NhRl18NcjszGvK4i9I+upy1b/3GLkwkp6lGpRXWFSl7Om/5zeaIOH2maUx t7Xuq6iDQ98VT95eMNvNZ+zFj8VNuhIyfsJrVijyhygZ+N3gqz/Wpca+NOGSVv578Gdf 2VVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zXRKjTtQfAhIof4f1bpFuN6kApdYi2rF9TK55RsxInI=; b=fMCFLeHsbR+JvVih0Zh1NIpHWNvlhlJJfkc61wkr9KFiXBDVCKWeplL7+34XAIOLaC yAgCcRXm6Ij8pYU0s5iCh15IByWeAU1Bn3IWlR1UGndQUrXOmbpN3YKswW96Gc++vzIg jcwqWKVC6BL6VvFA+UgQ/9Mj43zTsws3h3fRVVD5qO7ZPr97Py0E/fempaUsM/HHoFdT NJMTLJMUHMAnHMkZdJIT5WlzytMQ9whrhT5XRYeRafono6SfbydVUqE3tBbA0AtAtZMQ 5NNQf6WC4SgsOsZ/AjeJopGda2WBOuo50O2DVFgjNAdAq9nGbugtwZPD9rw9I26pdHRk t6VQ== X-Gm-Message-State: AFeK/H3R/LnlA78P2JBxuwiLaQwPumFfEpP4ZTuEgcN6ahEYrNeLjCWOlcStQwp3PKybO0dFmONxS5fzr1mJ5A== X-Received: by 10.84.231.9 with SMTP id f9mr3023723plk.191.1490824351804; Wed, 29 Mar 2017 14:52:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.160.194 with HTTP; Wed, 29 Mar 2017 14:52:31 -0700 (PDT) In-Reply-To: References: <22519.43588.421250.807948@fireball.acr.fi> <8B462FE6-E8CD-4E79-A15C-AE722CEF9C72@gmail.com> From: Watson Ladd Date: Wed, 29 Mar 2017 15:52:31 -0600 Message-ID: To: Ben Laurie Cc: Yoav Nir , Security Area Advisory Group , Tero Kivinen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] Possible backdoor in RFC 5114 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 21:52:35 -0000 On Wed, Mar 29, 2017 at 12:26 PM, Ben Laurie wrote: > On 29 March 2017 at 18:17, Yoav Nir wrote: >> >> On 29 Mar 2017, at 11:50, Ben Laurie wrote: >> >> >> >> On 22 March 2017 at 18:20, Watson Ladd wrote: >>> >>> >>> >>> On Mar 22, 2017 8:15 AM, "Ben Laurie" wrote: >>> >>> >>> >>> On 7 October 2016 at 16:56, Yoav Nir wrote: >>>> >>>> >>>> > On 7 Oct 2016, at 16:59, Tero Kivinen wrote: >>>> > >>>> > Stephen Farrell writes: >>>> >> >>>> >> So I'm not seeing anyone so far argue to not >>>> >> deprecate these somehow. >>>> >> >>>> >> We could just make 5114 historic as Yoav suggests, >>>> >> or, if someone writes an I-D to explain why, we >>>> >> could obsolete 5114. (Such an I-D would presumably >>>> >> also say something about codepoints that point at >>>> >> 5114 from other registries.) >>>> >> >>>> >> Assuming nobody shows up saying these are in >>>> >> fact in widespread use I'd be supportive of us >>>> >> getting rid of cruft. >>>> > >>>> > I think the NIST ECP groups are quite widely supportd, and used. >>>> > RFC5114 includes both Nist ECP Groups (192, 224, 256, 384 and 521) a= nd >>>> > 3 MODP groups. >>>> > >>>> > In IPsec, ECP groups are widely used, those MODP groups with subgrou= p >>>> > are not. On the other hand I think only those 192, 256 and 521 bit >>>> > groups are really used, and those are defined also in RFC5903 (which >>>> > obsoleted original 4753 which had serious bug in it). >>>> >>>> >>>> First, I think you meant 256, 384 and 521 bit, not the 192. >>>> >>>> Second, 5114 did not fix the bug in 4753. It just referenced 4753 for >>>> formatting. You know this better than I do, but I don=E2=80=99t think = the IANA >>>> registry ever referenced 5114 for these ECP groups. >>>> >>>> So for the three useful groups in 5114 you didn=E2=80=99t need it (as = 4753) >>>> already existed, and you don=E2=80=99t need it now, as 5903 exists. I = don=E2=80=99t see >>>> anything standing in the way of moving to historic or obsoleting it. >>> >>> >>> Possibly I missed something here: why should we be any happier about 59= 03 >>> than we are about 5114? >>> >>> >>> Can you prepare a backdoored elliptic curve that passes all acceptence >>> critera? >> >> >> No, but can the NSA? >> >> >> I don=E2=80=99t know, but we can speculate all day about what the NSA ca= n or cannot >> do, including wandless magic or generally solving the DLP. We can only m= ake >> decisions on the basis of what we know or can reasonably project. > > But isn't that the point of nothing up my sleeve numbers? Which 5903 > doesn't use... Ben: Do you understand the difference between an attack that has been demonstrated to be possible, and one that we have no idea how to do? I'm forced to assume not from the contents of the thread. Futhermore, the alternative is to go to the MODP groups which do not have this backdoor possibility if you really think the NSA is a few decades ahead in number theory. Sincerely, Watson Ladd > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Mar 29 15:16:58 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C332129416 for ; Wed, 29 Mar 2017 15:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 qDWk7h47hpyO for ; Wed, 29 Mar 2017 15:16:55 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 D42A6126C23 for ; Wed, 29 Mar 2017 15:16:54 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v2TMGpSl000826 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 30 Mar 2017 01:16:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v2TMGprd005199; Thu, 30 Mar 2017 01:16:51 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22748.12883.842505.256435@fireball.acr.fi> Date: Thu, 30 Mar 2017 01:16:51 +0300 From: Tero Kivinen To: saag@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 7 min Archived-At: Subject: [saag] IPsecME Status X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 22:16:56 -0000 IPsecME met on Wednesday afternoon for two hours. We were originally scheduled to meet on Friday, but we got rescheduled to Wednesday when tcpinc WG was cancelled. We have two drafts (rfc4307bis and rfc7321bis) which has been approved by the IESG, but both of them had some nits we needed to fix. New version of the 4307bis has already been published, and that should solve issues for it. The 7321bis needs bit more work, as there is text about the manual keys that requires bit more work. EdDSA draft is through WGLC and should be going forward soon. TCP encapsulation draft is now in the IETF LC. Work is ongoing on the split DNS and Quantum resistance drafts. Implicit IV draft is now in the WG adoptation call. We have now finished 5 of our 9 milestones, so work is going on nicely. -- kivinen@iki.fi From nobody Wed Mar 29 15:29:41 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF455129519 for ; Wed, 29 Mar 2017 15:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 fXj55ZBJNIMN for ; Wed, 29 Mar 2017 15:29:32 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 ED63E126C23 for ; Wed, 29 Mar 2017 15:29:31 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v2TMTT1f002219 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 30 Mar 2017 01:29:29 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v2TMTTG5028856; Thu, 30 Mar 2017 01:29:29 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22748.13641.494892.882586@fireball.acr.fi> Date: Thu, 30 Mar 2017 01:29:29 +0300 From: Tero Kivinen To: saag@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 7 min Archived-At: Subject: [saag] TEEP BoF status X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 22:29:34 -0000 TEEP BoF (A Protocol for Dynamic Trusted Execution Environment Enablement) met on Tuesday afternoon, and was quite well attended. We had overview presentation what TEEP is supposed to be, and two examples of different trusted execution environment hardware platforms. Then we had use cases presentation and presentation about the possible architecture for the teep. In the end we made hum for whether we actually understand the problem and work to be done and the results was split, so there was no point of asking other questions as if we do not understand the problem and work to be done, we cannot go forward. We also polled how many people are interested working on this subject, and there were about 14-15 people showing interest, so we will be continuing this work on the teep list [1]. [1] https://www.ietf.org/mailman/listinfo/teep -- kivinen@iki.fi From nobody Thu Mar 30 05:30:27 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6F11294E4 for ; Thu, 30 Mar 2017 05:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 mQyQTeD9AG9s for ; Thu, 30 Mar 2017 05:30:19 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 843C5129692 for ; Thu, 30 Mar 2017 05:30:19 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id z204so52069244vkd.1 for ; Thu, 30 Mar 2017 05:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nPh6Yb++ajmfFol1eTM0SNg+vMDFKwRbitJp6WPX9dA=; b=QpFF7/CBJ19ck1RghQLUV96uUxb/pzjrNBttrRcogzmtYE6rG6h8v3TI7/kOcMtCKh X/IYwsce8V1wewFwiGc5pxB2E0ictvltn0L1i1mkKMCpMauTIe22f6QIObGOjex5dPI5 KNCObNqc2TLmYHMeNos7AXgwvn7i9J019J3xYVBqRgmjehBejOvAcwZ7G9N1WTbFUd4Y KxGS2gg0ctS8zP64Letg7bNkCfCPXRnLVCLtUEaII0u0oWFXQklYhIv2PoCX9GfeJJ7k ijU6at7rIkv+Evc9Eax7jch1m74duwkp7F2CoLzrx0FXrGfJsqgWJh+4+5DjsYfvdDli PJIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nPh6Yb++ajmfFol1eTM0SNg+vMDFKwRbitJp6WPX9dA=; b=sjOHMV9IgnDdvNeb7kUQBscdRWIhp+HJlT1DHSZx0R91Z6jHWXxIVi9BOENLSoJdcZ urE8Bwvm41HxJtp10Hmz3+Q6CqLaE3T9A2jWaiyLIbwNEOc2k1fQZoKGmCnXJqZ3y5YZ jZx4qgiqCOW2RKglDXkN7KWkfeU8HNz2QLNDLlYSc1m87h2hlNl5P3MecY0vZVmr+uVH EpMkVQjkbLHodiEsFWHUStVGBfAx6uggedp1QyMw/ntsQtEMi1/eM9aTGaygEzZ+CV3y EKjzSs8w771YesulAq+1RuuBnfd8dUcOvdVmdKJ9r2QgYOa95ha5TGjH8smXlVLJozby /zaA== X-Gm-Message-State: AFeK/H0vX/A9U3iGiCrgoXONjEbQ9kkEdKnb7IFfu9Q+vuJObBGTUzSGEIEi4caC+7zzHJNHaLH22wOMS7AIOotY X-Received: by 10.31.235.198 with SMTP id j189mr2658783vkh.75.1490877018353; Thu, 30 Mar 2017 05:30:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.110.201 with HTTP; Thu, 30 Mar 2017 05:30:17 -0700 (PDT) In-Reply-To: References: <22519.43588.421250.807948@fireball.acr.fi> <8B462FE6-E8CD-4E79-A15C-AE722CEF9C72@gmail.com> From: Ben Laurie Date: Thu, 30 Mar 2017 13:30:17 +0100 Message-ID: To: Watson Ladd Cc: Ben Laurie , Security Area Advisory Group , Tero Kivinen Content-Type: multipart/alternative; boundary=94eb2c0929c815a304054bf1db21 Archived-At: Subject: Re: [saag] Possible backdoor in RFC 5114 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 12:30:22 -0000 --94eb2c0929c815a304054bf1db21 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29 March 2017 at 22:52, Watson Ladd wrote: > On Wed, Mar 29, 2017 at 12:26 PM, Ben Laurie wrote: > > On 29 March 2017 at 18:17, Yoav Nir wrote: > >> > >> On 29 Mar 2017, at 11:50, Ben Laurie wrote: > >> > >> > >> > >> On 22 March 2017 at 18:20, Watson Ladd wrote: > >>> > >>> > >>> > >>> On Mar 22, 2017 8:15 AM, "Ben Laurie" wrote: > >>> > >>> > >>> > >>> On 7 October 2016 at 16:56, Yoav Nir wrote: > >>>> > >>>> > >>>> > On 7 Oct 2016, at 16:59, Tero Kivinen wrote: > >>>> > > >>>> > Stephen Farrell writes: > >>>> >> > >>>> >> So I'm not seeing anyone so far argue to not > >>>> >> deprecate these somehow. > >>>> >> > >>>> >> We could just make 5114 historic as Yoav suggests, > >>>> >> or, if someone writes an I-D to explain why, we > >>>> >> could obsolete 5114. (Such an I-D would presumably > >>>> >> also say something about codepoints that point at > >>>> >> 5114 from other registries.) > >>>> >> > >>>> >> Assuming nobody shows up saying these are in > >>>> >> fact in widespread use I'd be supportive of us > >>>> >> getting rid of cruft. > >>>> > > >>>> > I think the NIST ECP groups are quite widely supportd, and used. > >>>> > RFC5114 includes both Nist ECP Groups (192, 224, 256, 384 and 521) > and > >>>> > 3 MODP groups. > >>>> > > >>>> > In IPsec, ECP groups are widely used, those MODP groups with > subgroup > >>>> > are not. On the other hand I think only those 192, 256 and 521 bit > >>>> > groups are really used, and those are defined also in RFC5903 (whi= ch > >>>> > obsoleted original 4753 which had serious bug in it). > >>>> > >>>> > >>>> First, I think you meant 256, 384 and 521 bit, not the 192. > >>>> > >>>> Second, 5114 did not fix the bug in 4753. It just referenced 4753 fo= r > >>>> formatting. You know this better than I do, but I don=E2=80=99t thin= k the IANA > >>>> registry ever referenced 5114 for these ECP groups. > >>>> > >>>> So for the three useful groups in 5114 you didn=E2=80=99t need it (a= s 4753) > >>>> already existed, and you don=E2=80=99t need it now, as 5903 exists. = I don=E2=80=99t > see > >>>> anything standing in the way of moving to historic or obsoleting it. > >>> > >>> > >>> Possibly I missed something here: why should we be any happier about > 5903 > >>> than we are about 5114? > >>> > >>> > >>> Can you prepare a backdoored elliptic curve that passes all acceptenc= e > >>> critera? > >> > >> > >> No, but can the NSA? > >> > >> > >> I don=E2=80=99t know, but we can speculate all day about what the NSA = can or > cannot > >> do, including wandless magic or generally solving the DLP. We can only > make > >> decisions on the basis of what we know or can reasonably project. > > > > But isn't that the point of nothing up my sleeve numbers? Which 5903 > > doesn't use... > > Ben: > Do you understand the difference between an attack that has been > demonstrated to be possible, and one that we have no idea how to do? > Indeed I do. > > I'm forced to assume not from the contents of the thread. Futhermore, > the alternative is to go to the MODP groups which do not have this > backdoor possibility if you really think the NSA is a few decades > ahead in number theory. > Hasn't it been repeatedly demonstrated that the NSA is ahead? What I'm saying is why should we trust parameters generated by an opaque process by someone who has been shown to misbehave in the generation of such parameters? Particularly if there's a way to generate appropriate parameters that is not opaque? Perhaps I'm missing something (but I am not missing that we don't currently know how to exploit the opaque process, I get that)? > > Sincerely, > Watson Ladd > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --94eb2c0929c815a304054bf1db21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 29 March 2017 at 22:52, Watson Ladd <watsonbladd@gmail.com&= gt; wrote:
<= div class=3D"h5">On Wed, Mar 29, 2017 at 12:26 PM, Ben Laurie <ben@links.org> wrote:
> On 29 March 2017 at 18:17, Yoav Nir <ynir.ietf@gmail.com> wrote:
>>
>> On 29 Mar 2017, at 11:50, Ben Laurie <benl@google.com> wrote:
>>
>>
>>
>> On 22 March 2017 at 18:20, Watson Ladd <watsonbladd@gmail.com> wrote:
>>>
>>>
>>>
>>> On Mar 22, 2017 8:15 AM, "Ben Laurie" <benl@google.com> wrote:
>>>
>>>
>>>
>>> On 7 October 2016 at 16:56, Yoav Nir <ynir.ietf@gmail.com> wrote:
>>>>
>>>>
>>>> > On 7 Oct 2016, at 16:59, Tero Kivinen <kivinen@iki.fi> wrote:
>>>> >
>>>> > Stephen Farrell writes:
>>>> >>
>>>> >> So I'm not seeing anyone so far argue to not<= br> >>>> >> deprecate these somehow.
>>>> >>
>>>> >> We could just make 5114 historic as Yoav suggests= ,
>>>> >> or, if someone writes an I-D to explain why, we >>>> >> could obsolete 5114. (Such an I-D would presumabl= y
>>>> >> also say something about codepoints that point at=
>>>> >> 5114 from other registries.)
>>>> >>
>>>> >> Assuming nobody shows up saying these are in
>>>> >> fact in widespread use I'd be supportive of u= s
>>>> >> getting rid of cruft.
>>>> >
>>>> > I think the NIST ECP groups are quite widely supportd= , and used.
>>>> > RFC5114 includes both Nist ECP Groups (192, 224, 256,= 384 and 521) and
>>>> > 3 MODP groups.
>>>> >
>>>> > In IPsec, ECP groups are widely used, those MODP grou= ps with subgroup
>>>> > are not. On the other hand I think only those 192, 25= 6 and 521 bit
>>>> > groups are really used, and those are defined also in= RFC5903 (which
>>>> > obsoleted original 4753 which had serious bug in it).=
>>>>
>>>>
>>>> First, I think you meant 256, 384 and 521 bit, not the 192= .
>>>>
>>>> Second, 5114 did not fix the bug in 4753. It just referenc= ed 4753 for
>>>> formatting. You know this better than I do, but I don=E2= =80=99t think the IANA
>>>> registry ever referenced 5114 for these ECP groups.
>>>>
>>>> So for the three useful groups in 5114 you didn=E2=80=99t = need it (as 4753)
>>>> already existed, and you don=E2=80=99t need it now, as 590= 3 exists. I don=E2=80=99t see
>>>> anything standing in the way of moving to historic or obso= leting it.
>>>
>>>
>>> Possibly I missed something here: why should we be any happier= about 5903
>>> than we are about 5114?
>>>
>>>
>>> Can you prepare a backdoored elliptic curve that passes all ac= ceptence
>>> critera?
>>
>>
>> No, but can the NSA?
>>
>>
>> I don=E2=80=99t know, but we can speculate all day about what the = NSA can or cannot
>> do, including wandless magic or generally solving the DLP. We can = only make
>> decisions on the basis of what we know or can reasonably project.<= br> >
> But isn't that the point of nothing up my sleeve numbers? Which 59= 03
> doesn't use...

Ben:
Do you understand the difference between an attack that has been
demonstrated to be possible, and one that we have no idea how to do?

Indeed I do.
=C2=A0

I'm forced to assume not from the contents of the thread. Futhermore, the alternative is to go to the MODP groups which do not have this
backdoor possibility if you really think the NSA is a few decades
ahead in number theory.

Hasn't it b= een repeatedly demonstrated that the NSA is ahead?

What I'm saying is why should we trust parameters generated by an opaq= ue process by someone who has been shown to misbehave in the generation of = such parameters? Particularly if there's a way to generate appropriate = parameters that is not opaque? Perhaps I'm missing something (but I am = not missing that we don't currently know how to exploit the opaque proc= ess, I get that)?
=C2=A0

Sincerely,
Watson Ladd
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag


--
"Man is born free, but everywhere he is in chains".
--Rousseau.

____________________________= ___________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--94eb2c0929c815a304054bf1db21-- From nobody Thu Mar 30 07:44:58 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AE51294F5 for ; Thu, 30 Mar 2017 07:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3n_Ykq2mOhUb for ; Thu, 30 Mar 2017 07:44:49 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 B338612706D for ; Thu, 30 Mar 2017 07:44:49 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id 81so41953210pgh.2 for ; Thu, 30 Mar 2017 07:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=l8gpU9HKa//xgexu+Vfr3X7reioV7QeVZ9r89QSIr5U=; b=c49SzWhJlbO40UrjW1/M5IM1QfU1RMTAunELVbH44eLgIf7Y5DC3INql1cXDs1ELJy r3M0RGKNMj4dUJjZYMRwRtGttX7pXzTuFSs01tFqvDFP2GZ73q0H0s7i+Pt5ad/XR4XA tAyFvto7A6fTZnjNRz6oTd3MHn5hKEB5OPD1+6tRWH45ixVAQASHS2acCkdT324Kc6hn S162u07p/kCv3Qkve/BOK95TYvAyVmHEmbIg7GrMlexOot8ZjTkoRuzbJKWxf4cw9Ng2 Z/tFd7pz5LubhkFNAYl4XCslmBM09G0XRQy/7DmUNqDdoBXbLFUojpwlRB0TzVT9FeQR eUsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=l8gpU9HKa//xgexu+Vfr3X7reioV7QeVZ9r89QSIr5U=; b=EFKfbUWJ6qk3DpFZp4RJ0yJIBTQ9vL21E7tElPqTHMCb/jgZK+lZ7BheHJ90ZBr3Q2 WBh2c83fDV8Sl7NkCxnm/NvYkAbqcvquK8uwIlv3DR8oeJsqFMeGS6VMUz4/a5qW5+20 IQ36j+h8b/KKSpkJ/3ssz+5ZKjin2U7hskvAAULvorjPXIcfLQSvrYL5OxeLEGCfcGd3 ozlwfFZ76MTtzusPmAoYBecZ8odNBHtJVf1f5/3MQ7mReU8aIINUx6iS/NHRhOjmgAEf xs+GzCKJ7NR1i46lFb6G6taW9P9cwQzAnLn9PicqrOeMZNDYMqgFdBeZFwxgtB8QHezZ C96w== X-Gm-Message-State: AFeK/H0B6Fhi/aURN4qS/wasS5rrv8sR9qB1oIRpdNCFexZzPN80LLSkfpnzESQONKYtXdlf3MnJEZzA6o7DtQ== X-Received: by 10.98.201.212 with SMTP id l81mr76961pfk.13.1490885089184; Thu, 30 Mar 2017 07:44:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.141 with HTTP; Thu, 30 Mar 2017 07:44:08 -0700 (PDT) From: Kathleen Moriarty Date: Thu, 30 Mar 2017 10:44:08 -0400 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] Jabber Scribe? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 14:44:53 -0000 Can we get a volunteer to be the jabber scribe at SAAG later today? TIA! -- Best regards, Kathleen From nobody Thu Mar 30 07:47:54 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48BE12950C for ; Thu, 30 Mar 2017 07:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 gcCFDB2ZvJEU for ; Thu, 30 Mar 2017 07:47:45 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (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 6A66E12706D for ; Thu, 30 Mar 2017 07:47:39 -0700 (PDT) Received: from t2001067c0370012899ae7108e85d5996.v6.meeting.ietf.org ([2001:67c:370:128:99ae:7108:e85d:5996]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ctbMP-0005kv-PZ; Thu, 30 Mar 2017 14:47:37 +0000 From: Wendy Seltzer To: saag@ietf.org Organization: W3C Message-ID: <2532c61a-fed1-f353-040e-07820c24e64c@w3.org> Date: Thu, 30 Mar 2017 10:47:36 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [saag] W3C update for IETF 98 (WebCrypto REC, WebAppSec Recharter, WebAuthn, Web Payments) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 14:47:48 -0000 An update on security-related W3C activities: * WebCrypto is a W3C Recommendation https://www.w3.org/TR/WebCryptoAPI/ * The Web Application Security WG re-chartered through 2018: https://www.w3.org/2011/webappsec/charter-2017.html The group's mission is to develop security and policy mechanisms to improve the security of Web Applications, and enable secure cross-origin communication. The re-charter extended its scope to include Vulnerability Mitigation, new work on Attack Surface Reduction, and work on the Web Security Model. Content Security Policy Level 2 is a Recommendation; development is ongoing in CSP Level 3 https://www.w3.org/TR/CSP2/ https://www.w3.org/TR/CSP/ Candidate Recommendations: Referrer Policy: https://www.w3.org/TR/referrer-policy/ Secure Contexts: https://www.w3.org/TR/secure-contexts/ Mixed Content: https://www.w3.org/TR/mixed-content/ Upgrade Insecure Requests: * Web Authentication WG is actively developing the WebAuthn API https://www.w3.org/TR/webauthn/ * Web Payments drafts are nearing Candidate Recommendation https://www.w3.org/Payments/WG/ Overview of related groups: https://www.w3.org/Security/ PING (Privacy Interest Group) will meet informally over lunch Thursday. https://www.w3.org/Privacy Happy to talk about any of these. --Wendy -- Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office) Policy Counsel and Domain Lead, World Wide Web Consortium (W3C) http://wendy.seltzer.org/ +1.617.863.0613 (mobile) From nobody Thu Mar 30 09:40:16 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBCA129869 for ; Thu, 30 Mar 2017 09:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 u6QmUQ4sXqMw for ; Thu, 30 Mar 2017 09:40:12 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589E6129857 for ; Thu, 30 Mar 2017 09:40:12 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 84F7928B0041 for ; Thu, 30 Mar 2017 12:40:11 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 566CE1F8036; Thu, 30 Mar 2017 12:40:11 -0400 (EDT) From: Sandra Murphy X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_92D8035F-B0A9-4523-8CB9-CB2BBE614FB5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 30 Mar 2017 12:39:57 -0400 Message-Id: <0241DAC8-DAFF-45DF-BAB7-44507A9674B0@tislabs.com> To: saag@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [saag] SIDR status X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 16:40:15 -0000 --Apple-Mail=_92D8035F-B0A9-4523-8CB9-CB2BBE614FB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 SIDR did not meet at this IETF, but status and discussion in SIDROPS = 14:50-16:20 Tuesday Afternoon session II WG Highlights: dewindling down to a precious few remaining work items; six drafts = transferred to the new sidrops wg WG Status Summary 9 drafts in RFC Editor queue drafts remaining: 1 post IESG, 2 expired to be renewed, 1 wglc = requested, 1 waiting resolution of AD comments, 1 waiting resolution of = AD query, 1 blocked by idr draft progress. There was a discussion at the sidrops meeting about that last draft. The = bgpsec-protocol (presently in RFC Editor queue) has a normative = reference to the idr wg's extended messages drafts, which has been = returned to the idr wg for more work. Various opinions were expressed as to whether the delay was acceptable = and what we could do to the bgpsec draft to remove the block if the = delay was not acceptable, etc. One option for dealing with a bgpsec update that would exceed the = maximum size was to drop the bgpsec signatures. One operator was = concerned that this was a =E2=80=9Cfail open=E2=80=9D. No decision was = made, discussions will continue. =E2=80=94Sandy --Apple-Mail=_92D8035F-B0A9-4523-8CB9-CB2BBE614FB5 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 iQIcBAEBCgAGBQJY3TTpAAoJEHplpQeet0IZxL8QAKaMAwYNfi9Psa3sSX1LDwdc QecwbU9weH2Ty6jnpV+TREa2m7EGw23OX6hnjDY8IBlmfwa6WW1f9J1JbMi+rj33 SyCP4O9yJmExoyuM1uy+u95yhFfl5sobvQe/zf+nsdkPhfn/JNi/WL2o4Js+2Hch NFhCvd4aXeLpTUwKbPE2Ut/tuHegEwyy+4K3hrvuU3/k+SwkktwMbI3EG9syL68c 69++9SNjrGwOQcHa9dd05IhR4DmZs61qC8/JLZZwZPzsPXHAduG5p9xOwr3K/U62 LkREQj3/jOaa42wnIsjq4EOqHcqkGYZZt+j+eyN5PX9zOgTKGZZeuyrZvzDaXlRD AGzdbQ68Nc4kwZFWeHbqmpjpDJAOphs4urkxNWDEc0VA1nmrNx9pU5O+ngZGqGnu 5QY2jlfUVrVkN7ZZb0mi45Sq1P2zyrV3a+CcEC1yX31C6MqtYVAoNjesY2XnBeKw gd8Ib54GMuvLomTb32kyCr9Y72BG/iY96LdejTuRAkzs+blYNVrCmppZ3xQQxYfg PuT5gcRI2KYUECjItynSHR7JxIBZAJZEbwSYWaBp8wuIpMx0CQXQsbRy5kwVD1pw vEd/vUvaLwhZsKgPHTc+tXh2Tv+VFr2wdmwU8LchwLCpfcPIrQQ5h/GUHm8eCM+d zoJ0MD5fR+Cf+j3s/Zkl =jG02 -----END PGP SIGNATURE----- --Apple-Mail=_92D8035F-B0A9-4523-8CB9-CB2BBE614FB5-- From nobody Thu Mar 30 10:14:02 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCEB129450 for ; Thu, 30 Mar 2017 10:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 fCGdxDQ0eRwv for ; Thu, 30 Mar 2017 10:14:00 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 1A34F126D74 for ; Thu, 30 Mar 2017 10:14:00 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id r203so37553652oib.3 for ; Thu, 30 Mar 2017 10:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=3Dq2Xu4Ai7bQRHGXPpI2aQjhuq/2KxrQ09658aJEqLU=; b=XCzrAgTF+M5FOI0NJTcFjenD39ezjZWq1weCbRunacehfobXeMkAKEtFTv/PMLWsr6 uZQXAM5QPKMfO+lcTGfWX6AErNhixLvSJG3LJo9UbCInLNRl0gbU/BPfPR+h2+8P8MYf fRgnTYHqUEXzDpjINFWvVFyFP3Hb4XDkfEm85aGd76mznBGTCRduY97luC5U+r6TQPBh Te/ErB4tg33HeLaSy49w/O43cJpnJS/b0kpAeIZ9hAiEai2lyzn2kSkeJbt3LXfrRFdJ 7SkLgiS6I3tF3mcZX4AheqckRb2KswZCDlXtjdgNc58ka3sQNf9JGubE3gwE0jtXlezU PVGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3Dq2Xu4Ai7bQRHGXPpI2aQjhuq/2KxrQ09658aJEqLU=; b=JNr9RrkESaCmHdpIb+6FpzIdsCRHCzWcENCisOrss5n0iCRwuURPVGaEas10lIwVPq OVlY/v0plSJE6r4YkutEoYns1RA3YblN9lf3TD670zlE3dojbHqL08yAen8I5HpE0vnM 4OQjlJcpEPmQr3Oxjp1RP0vgEyWAUyOX8HGBApbcHjQNtwXQ0KsHgA529Qct4gjCRZ4T HDlWmFI8lGqtTYJv/n1YHnuW6LQ5gq/gtZBY7Uch2xkeU6FqSGbII9MJuCiLs/zRS460 0j8XYV6CW0GAD1rBJVB7bHPPe6fZRAoto9SQVliyD8zNZsUmljww4ftBPx3X+dCBw+w+ qdug== X-Gm-Message-State: AFeK/H3FmDXKVm2zcSXRUKO8tmgonbyRsW2XD8/5qWlNR3Jn/vstnvTVKiQQjTziJ2V14Elvs4C9dVtM1LB+5A== X-Received: by 10.157.61.33 with SMTP id a30mr429498otc.73.1490894039055; Thu, 30 Mar 2017 10:13:59 -0700 (PDT) MIME-Version: 1.0 From: Adam Montville Date: Thu, 30 Mar 2017 17:13:48 +0000 Message-ID: To: saag Content-Type: multipart/alternative; boundary=001a1140919a988537054bf5d11b Archived-At: Subject: [saag] SACM Staus X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 17:14:02 -0000 --001a1140919a988537054bf5d11b Content-Type: text/plain; charset=UTF-8 SACM met this morning and spent most of our session discussing the details of vulnerability assessment. We also reviewed some changes to our COSWID and Terminology drafts. Next steps involve planning for vulnerability assessment work to be done at the IETF 99 Hackathon. --001a1140919a988537054bf5d11b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable SACM met this morning and spent most of our session discussing the details = of vulnerability assessment. We also reviewed some changes to our COSWID an= d Terminology drafts. Next steps involve planning for vulnerability assessm= ent work to be done at the IETF 99 Hackathon. --001a1140919a988537054bf5d11b-- From nobody Thu Mar 30 11:27:22 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAAC129A18 for ; Thu, 30 Mar 2017 11:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PuypXFbkgLDL for ; Thu, 30 Mar 2017 11:27:19 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (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 9514A129A11 for ; Thu, 30 Mar 2017 11:27:17 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id x125so47124722pgb.0 for ; Thu, 30 Mar 2017 11:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=5ZDc1/Is3BjkV58M8Lgk9vhAzWeGHb8bFmRz4wPYtdE=; b=QJX0ASnvjH4+ABYonJMFaUlvqvrRO0yho140/Ys4WCI9ABo1fGE/PnIf0ESJxdOngU GB0ok3vfUtqC6hTYWNAeKOPmp1324tDJnLohd0wdTsFCf5CS8ohrnP7JY8YKnJpLEdTC bdqEnr4ZIyfBnUU8oMkiJHpqnZfZ9o6pZO1ytAOCaj4Eb08GW29w77jqSrR1qA7kzbwT f8VbGcsOHiCPqCW2c5p1OreBYi+sOeEGwFUVM+6sDApcuTqARXgC1sb5QIVBPJI+pIfg ZH6HF76Q/ePCYF6mSUw09YqwS1fKM6zrhdhR3nEJ2fvD2LwwvRZx3//+9poRTOiBx5nI gg6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=5ZDc1/Is3BjkV58M8Lgk9vhAzWeGHb8bFmRz4wPYtdE=; b=H7K+QERH08M1T4MsoQLC3KRONazbcRxeYRitSeFie1aRP61WMRJLiWvdrnPDPmbbiI e2ECgs8qw3eB66cT/x8/wX9qHwWZAJTGmLi/83hciOOTPpZauUq4xyqtArEbgUCtsJ2W F2OEfc5uqM+MAHQKJy8c7N75clkvn3R6VXf5LXgx1zoWKmZpugCt/b3ERp7/RCRdzpMC DpUkEBbqSMCm0xIv/fJWy4tOn105TlgNUJ8TnqLGf5WFua9w/lQ7wsaQn98szi8Uhk4Z lGLZq0UtqyvwkUbc0rROVrCVtOlwNtAeYDzGE+oZv+K1NPHep0fObyG8jnPcz+y80fiD dojQ== X-Gm-Message-State: AFeK/H0ie/Nmj3wyFu/O3Qlz/SyjVcihdRvItlB7u68ArnsSs6vtjETL4jU6MGMjYmyhJhPyxoN92i0Glo+kgA== X-Received: by 10.98.201.212 with SMTP id l81mr805201pfk.13.1490898437144; Thu, 30 Mar 2017 11:27:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.141 with HTTP; Thu, 30 Mar 2017 11:26:36 -0700 (PDT) In-Reply-To: References: From: Kathleen Moriarty Date: Thu, 30 Mar 2017 14:26:36 -0400 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [saag] minutes and jabber X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 18:27:21 -0000 It looks like we still need one minute taker and a jabber scribe. Volunteers? On Mon, Mar 27, 2017 at 10:49 AM, Kathleen Moriarty wrote: > Hello, > > Can we have a couple of volunteers to take minutes and one to help as > a jabber scribe? > > Thank you in advance! > -- > > Best regards, > Kathleen -- Best regards, Kathleen From nobody Thu Mar 30 11:30:27 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EE9129A09 for ; Thu, 30 Mar 2017 11:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 R8K-vmX8-lZ9 for ; Thu, 30 Mar 2017 11:30:22 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 02420127698 for ; Thu, 30 Mar 2017 11:30:21 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id b140so25259550iof.1 for ; Thu, 30 Mar 2017 11:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VBGhNNuHvEtCV4I0MrFPX6qUYDgGos88LMNnQnLtoAk=; b=gM+ScC2/YnW1t3aRw+AoqJYm0wpd08NXaqGEUheg4OswhBlq27zmHIoHSph6w1B425 QYRc8GP/q3I3YOiEMM97OJgZMAWlAs9GohrobP68Dre8B6uKemVPWUh8rg0I/AeZmjRz qCQMTvpNZU/s/p9XAo2XybfXU6hC+DeUdJgIkznsUqqlHBx2+sHZ5u43UuNXq7LVg/4V alCcqbyWVxdiqv6/Fc4OPaMs7bBBE02I5dMdooFA1Ch22+RK8rJNk2mHpp6xSS8xaqh/ SQRt4lmsJVD7fHhddjXDSKUU75Jt3xQHYnkt17D/4WNejppb6YQhyRonOig7VmFo3eVh sXwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VBGhNNuHvEtCV4I0MrFPX6qUYDgGos88LMNnQnLtoAk=; b=Q0jXnhZZOp4tpYdEWzl1LzJJjmF5F119SInCg4icY3qNq7fupbST3zi2nFXTKZ1qA/ Akv49ZIyjoTfRFg2fbZ1Byj1G6p5HQ3Mr64Elrqg5Acj6IwEoLXVHgB9Rla2g2f6Wekv Ud8t6aGiStk9BY+X4jR8F3/SMOS080zsoWihQE6NPBSwKA3Pc3RKiP77vF3N8UrxsHGW 9EMXj37+ZBvj7NvsGLXdOFEi/5oCipjFK3toWTT4ZPYyrCPkrkYmO/8kd2HwIKC71GyC JiToBJzqj+lIwNYh9gWe/xhDM8AU7/I+TUuwfayDc9YZ0jU1eZlvHXv+C66O81uJggzu VTtw== X-Gm-Message-State: AFeK/H3oRFEaOgzn7OVcxEprSJ5e9B6mhcHGgL45PklUJJMJ6gjMsWCfgxGMf9FyhRBROA== X-Received: by 10.107.129.75 with SMTP id c72mr2340535iod.23.1490898619857; Thu, 30 Mar 2017 11:30:19 -0700 (PDT) Received: from t2001067c037001289c36b1496911e5aa.v6.meeting.ietf.org (t2001067c037001289c36b1496911e5aa.v6.meeting.ietf.org. [2001:67c:370:128:9c36:b149:6911:e5aa]) by smtp.gmail.com with ESMTPSA id g19sm1787483ioj.37.2017.03.30.11.30.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 11:30:18 -0700 (PDT) From: Yoav Nir Message-Id: <6C0BDE83-A64C-47E8-A0B0-A34D07D3BD6B@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_2F863239-BAC7-4F9C-BB09-F7FC40865247"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 30 Mar 2017 13:30:16 -0500 In-Reply-To: Cc: Security Area Advisory Group To: Kathleen Moriarty References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [saag] minutes and jabber X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 18:30:25 -0000 --Apple-Mail=_2F863239-BAC7-4F9C-BB09-F7FC40865247 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99ll take the notes on etherpad, so anyone who wants to join in = is welcome. Yoav > On 30 Mar 2017, at 13:26, Kathleen Moriarty = wrote: >=20 > It looks like we still need one minute taker and a jabber scribe. >=20 > Volunteers? >=20 > On Mon, Mar 27, 2017 at 10:49 AM, Kathleen Moriarty > wrote: >> Hello, >>=20 >> Can we have a couple of volunteers to take minutes and one to help as >> a jabber scribe? >>=20 >> Thank you in advance! >> -- >>=20 >> Best regards, >> Kathleen >=20 >=20 >=20 > -- >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail=_2F863239-BAC7-4F9C-BB09-F7FC40865247 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY3U65AAoJELhJCxUKWMyZBDEH/2fKef6yLYWdwNmXmJZzlbES ckBl0CrqGfyeN39PdsySlbF0BPN+cxVLJ3ucNt81Q4R2Q/hIz5j655rZs7R3fVnW 3PQ53lNGVNu9cgVCWwi4zwDHGCS/AmqDPuUdHwJrkwjzhwh0MP1ab9NBb3tgCxWN NETTDi4qhTfdwsMc7EmYSzsU4KQj4gEHD9txexPGHuDWq21UYVqB0R3TAPST46Uo nAiB59iARXJhG073CJEUQHwEt8TO3oyzLIMZm9VgJxDWZtH7fo4sYYZvZiMSPFOb yIyttbbTLoRACD3tElhpVtvH0lmFV31nSvi2i9JTOj6lniVmEgXSmQfZ2pAwqso= =Jmw5 -----END PGP SIGNATURE----- --Apple-Mail=_2F863239-BAC7-4F9C-BB09-F7FC40865247-- From nobody Thu Mar 30 11:46:50 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC3F129454; Thu, 30 Mar 2017 11:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 YrJkw6vzh-OY; Thu, 30 Mar 2017 11:46:42 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (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 AA562127843; Thu, 30 Mar 2017 11:46:42 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v2UIkgo9075499; Thu, 30 Mar 2017 11:46:42 -0700 (PDT) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v2UIkgjs044018; Thu, 30 Mar 2017 11:46:42 -0700 (PDT) From: David Mazieres To: saag@ietf.org, ilc@ietf.org, trans@ietf.org In-Reply-To: <87a88uksu0.fsf@ta.scs.stanford.edu> References: <87a88uksu0.fsf@ta.scs.stanford.edu> Reply-To: David Mazieres expires 2017-06-28 PDT Date: Thu, 30 Mar 2017 11:46:41 -0700 Message-ID: <8760iqr4a6.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [saag] Internet-Level Consensus bar BoF tonight 7:30pm, Amuse X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 18:46:44 -0000 For those interested in further discussion of Internet-level Consensus (ILC) following my talk at the SAAG open meeting, let's meet at 7:30pm at Amuse, the bar inside Swissotel right near the lobby. David David Mazieres writes: > I'll be giving the following 30-minute talk during the saag session at > the upcoming IETF meeting in Chicago, likely followed by a "bar bof" on > Internet-level consensus that evening. > > > Internet-Level Consensus is Practical > > David Mazi=C3=A8res > > Security Area Open Meeting > Thursday March 30, 2017 15:20-17:20 > Zurich D room >=20=09=09=09=09=20=20=20 > Consensus is the problem of agreeing on a valid input value among > members of a distributed system. Internet-level consensus extends the > concept to global agreement, despite the fact that the Internet has no > meaningful notion of membership. This talk will report on the Stellar > consensus protocol (SCP), an existence proof that secure consensus > does not require well-defined membership. SCP's key idea is for > individual participants to decide for themselves which other > participants they cannot afford to diverge from. SCP guarantees > agreement so long as there is transitive overlap in these > dependencies. SCP is in production use by the Stellar payment > network, but has broader potential applications ranging from secure > package distribution to key management in end-to-end email encryption. From nobody Thu Mar 30 11:50:29 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02E0129A18 for ; Thu, 30 Mar 2017 11:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1KRjfzWDPl4F for ; Thu, 30 Mar 2017 11:50:27 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 E5D0D126B72 for ; Thu, 30 Mar 2017 11:50:26 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id 68so3271474itx.0 for ; Thu, 30 Mar 2017 11:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=B3kb6kU/8NpbRCPBhQ2NraoEVkzszSV+uu3njl8UeEg=; b=t0Z8YTWmsTnKllpfCAVIHYUF/TyQVjqWeBq3WL//oA9oAiR33jHB7att/OHtE0TzAY NOQwQGjCj9cq68hWEDH4rOyYDwapR1oSO/boLtGhX8uOhUyRTkaDwO418GgjM3a8Daf4 0AvXdLL0uZ5WhwY6ztEjZV2m5aYU0yyqTGMyEZLL+SZHCl5U5XPumvRbdNLVYuf8B6KG Yyih+CM96fLQSAXQhmOHARxcWna6Y5LtfJ45UVuik2bMVLx4q/N/gIVKSsyOXvh5fYfH fo4jbwHMg/+aPE276cljk/9Wv0uFWur6YXV75L5QDQeRTxKFnxeEwLE/WQHoBfzTlHvM wW6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=B3kb6kU/8NpbRCPBhQ2NraoEVkzszSV+uu3njl8UeEg=; b=lxQ1fLeKN7mCHbA8zEpINqoRg26YuBurz6+3BN+oiNoKu444iWHQoZuU0oG2cWOOVk yOvFn5MrVy1YAy1z8abUT5vkTDtb76OyWQ7RW+JRZu15x8dV2k9u5edjGGKkqknHut9M f2NNPdZ87AgTpKWURSSWlbM0rOXlgXEGKKRNndnrZ8TRQYVFf9kzYKziBHzHFDS0STSe W6qQPz/wwYR4W4pHurTL4lyA1IRneuvIXGAnOeTw53L7Joo2IkBoA5EVql4xqbKuX2J1 DgyrsMEotXxDaPyFVXAlKpS+QW8/NnD46atAgdpOSC/SK/N1foDd0ROyy2gC+swWjE0H vZeA== X-Gm-Message-State: AFeK/H2+pZfX6AVLi+Nm95R0s1GaxtdtIJ1BGoRBa0bp1xpBl68ASzj5EZix1B5jHXO1Pw== X-Received: by 10.36.65.203 with SMTP id b72mr6283124itd.24.1490899825944; Thu, 30 Mar 2017 11:50:25 -0700 (PDT) Received: from dhcp-8d8c.meeting.ietf.org (t2001067c03700128cdd8db8952e7de76.v6.meeting.ietf.org. [2001:67c:370:128:cdd8:db89:52e7:de76]) by smtp.gmail.com with ESMTPSA id k66sm1852741itg.8.2017.03.30.11.50.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 11:50:25 -0700 (PDT) To: David Mazieres expires 2017-06-28 PDT References: <87a88uksu0.fsf@ta.scs.stanford.edu> <8760iqr4a6.fsf@ta.scs.stanford.edu> Cc: saag@ietf.org From: Melinda Shore Message-ID: <8951becb-fca3-2520-11f1-a05615b49826@gmail.com> Date: Thu, 30 Mar 2017 13:50:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8760iqr4a6.fsf@ta.scs.stanford.edu> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="g48pK7LaR1sACFmu2g6EuoLuSG1alo7ee" Archived-At: Subject: Re: [saag] Internet-Level Consensus bar BoF tonight 7:30pm, Amuse X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 18:50:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --g48pK7LaR1sACFmu2g6EuoLuSG1alo7ee Content-Type: multipart/mixed; boundary="8Xv30g9oofjTIo5H9SNcxKLopxsxW6x48"; protected-headers="v1" From: Melinda Shore To: David Mazieres expires 2017-06-28 PDT Cc: saag@ietf.org Message-ID: <8951becb-fca3-2520-11f1-a05615b49826@gmail.com> Subject: Re: [saag] Internet-Level Consensus bar BoF tonight 7:30pm, Amuse References: <87a88uksu0.fsf@ta.scs.stanford.edu> <8760iqr4a6.fsf@ta.scs.stanford.edu> In-Reply-To: <8760iqr4a6.fsf@ta.scs.stanford.edu> --8Xv30g9oofjTIo5H9SNcxKLopxsxW6x48 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, David: I'd love to be there but unfortunately I'm already booked for the evening. Would you be willing to post a summary of the discussion to the saag mailing list afterwards? Thanks, Melinda --8Xv30g9oofjTIo5H9SNcxKLopxsxW6x48-- --g48pK7LaR1sACFmu2g6EuoLuSG1alo7ee Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY3VNzAAoJELiGRpM6HoEuSbIQAJScbHdZtnljwvVC8/4gqehx OQLR5SZEPtncqVJwJKAZZm5Ut05oF96/2qV+wezeVbpb9ymCwunt/7g1OOPqKRUO F3zjk1i3Z0P/dbtiS2P+eQgDrUNxuc3pN6xDEv28QN8lT85djrbnqXP0/X2AXHj1 BBQp0L7PWjn1CyeaHjqAnWsGY333As01y/6ggbhBjle/iaa1VvVJ+8AD61VfHTn1 fhMtvEH2lTx6bEbpCGl3dF5VdcR3XTqqcpOBZ5eJOtHz3DJIlNb2MMVZkQ3a0lHD g+BRCaOTkp7aZ2zf+5UqCzr8zOOONeQnUdG+Ej8qSe9TGJJDOaagXGabgYKHTjKy 4mMToXvFvogxPp5sBOSfrOOWIJU+qZ/Q97y/m+wKpvnuSqYKL+j+zDjomuaqKmaS 5m7f7pIybb7MFYk+/9NuFOy6cYkkvEXk98zDds66lkSpv7tIRpJyqbUVc/M7R+s8 1RsHv+6wXoTPu3WeEuZd/qmzOV5O44AZfMgXxTclZZJBlfaAi2i4Ovc+G07ZUFk5 Hw80zUHkrBRINVXgeNhLoZr3x7mC6e93tymhGKFFHQyHnv6e2SB6RK2hsctWddOq mRb7D1LXkgnxmTPlHY9ZVSD8UKD0W/MdZ+TihHQFrUWAsDXqFJarNWPvmCRR3GjZ GSFcvujQblUFPF0lbDJh =BtJf -----END PGP SIGNATURE----- --g48pK7LaR1sACFmu2g6EuoLuSG1alo7ee-- From nobody Thu Mar 30 12:01:40 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB858129A2C for ; Thu, 30 Mar 2017 12:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 ZX0ZhGG7Vlui for ; Thu, 30 Mar 2017 12:01:36 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (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 076C7129A3C for ; Thu, 30 Mar 2017 12:01:14 -0700 (PDT) Received: from t2001067c0370012899ae7108e85d5996.v6.meeting.ietf.org ([2001:67c:370:128:99ae:7108:e85d:5996]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ctfJo-00039C-Sa; Thu, 30 Mar 2017 19:01:12 +0000 To: Yoav Nir , Kathleen Moriarty References: <6C0BDE83-A64C-47E8-A0B0-A34D07D3BD6B@gmail.com> Cc: Security Area Advisory Group From: Wendy Seltzer Organization: W3C Message-ID: <5215b996-3e36-e7b7-0fc7-5874823f777f@w3.org> Date: Thu, 30 Mar 2017 15:01:11 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <6C0BDE83-A64C-47E8-A0B0-A34D07D3BD6B@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [saag] minutes and jabber X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 19:01:39 -0000 On 03/30/2017 02:30 PM, Yoav Nir wrote: > I’ll take the notes on etherpad, so anyone who wants to join in is welcome. I'll join the etherpad note-taking. --Wendy > > Yoav > >> On 30 Mar 2017, at 13:26, Kathleen Moriarty wrote: >> >> It looks like we still need one minute taker and a jabber scribe. >> >> Volunteers? >> >> On Mon, Mar 27, 2017 at 10:49 AM, Kathleen Moriarty >> wrote: >>> Hello, >>> >>> Can we have a couple of volunteers to take minutes and one to help as >>> a jabber scribe? >>> >>> Thank you in advance! >>> -- >>> >>> Best regards, >>> Kathleen >> >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office) Strategy Lead, World Wide Web Consortium (W3C) https://wendy.seltzer.org/ +1.617.863.0613 (mobile) From nobody Thu Mar 30 12:02:40 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DEE129A42 for ; Thu, 30 Mar 2017 12:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 SXe00rWEJ617 for ; Thu, 30 Mar 2017 12:02:36 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 275FB129A2F for ; Thu, 30 Mar 2017 12:02:31 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id 21so47782441pgg.1 for ; Thu, 30 Mar 2017 12:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eOSfnHNymy3ee2rrZMLbbyX1iSzcrn649YxjcOpdmjM=; b=qg1yp7uJCl3qXT1oLjoXelcoL/VY8DIGC/wyXgLQlBwovocRrU/P2mc1hR8TD+o6Br NXD06XcyOpcRd3SE8Hgf+XSDMLw1884uGyJCez2Db7pXZ/ZJgm058eZUor5iIw3OmJth 6HeBmhzDenUvmGeeuzj8cgzHjYWBW9RiUKpHvTOqYq72FxKrlGu86jCvnBGCOnPrSbSR YG9FBKSbGHFf19vhShc23Tc/zJsDqlJezNp6VUbjmlifWHwzxBgR6qsIxa2RhcUnr84e vS4zwroGAdWoB5tSr183pxhA0SXy2lrOjIX0NFvMgEIuqXFqeIEBKvq/SDkORaFgulaA 6r+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eOSfnHNymy3ee2rrZMLbbyX1iSzcrn649YxjcOpdmjM=; b=oT/Ok2BpNoism2DgfBL+sfcGyO3AEV0NDiWdK9cO5s3qnGVN+BAow1CwpIaL19Ebt0 RPKOPb01gnoP8Qi69lINZwXCl8k6FKCyZN7ZB/+MIXmYnz/bVIkDW/Z/NtRDM94qoUkW CcVZKAHm9qgvCGUqQcaZTwxzRIOUP0R56/FFXOy7TbniTJV3YKOjA+wiwgh0xk35A1dm vO7DUsq9qBGWsY6z3KPCsZht1ZEAgzHNSef2Ylb8QP+nkLTCUXZBZoc4ozgWPUOWUTsg U630SKXhEynB/YinerWYfmHafTkR0ul8lbcD9wLfg8aJ5dqYWqH2ncKiCgGCP1uFVtXY nD3A== X-Gm-Message-State: AFeK/H2k8gTAVYafiCMJYcMT2RKGLndR1+Sy2CJKQvTX8PSvcztVT++Owm69okJAvY2lnn0kwTX9oGQhVv/HSg== X-Received: by 10.98.201.212 with SMTP id l81mr856110pfk.13.1490900550780; Thu, 30 Mar 2017 12:02:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.141 with HTTP; Thu, 30 Mar 2017 12:01:50 -0700 (PDT) In-Reply-To: <5215b996-3e36-e7b7-0fc7-5874823f777f@w3.org> References: <6C0BDE83-A64C-47E8-A0B0-A34D07D3BD6B@gmail.com> <5215b996-3e36-e7b7-0fc7-5874823f777f@w3.org> From: Kathleen Moriarty Date: Thu, 30 Mar 2017 15:01:50 -0400 Message-ID: To: Wendy Seltzer Cc: Yoav Nir , Security Area Advisory Group Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] minutes and jabber X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 19:02:38 -0000 Thank you, Wendy! On Thu, Mar 30, 2017 at 3:01 PM, Wendy Seltzer wrote: > On 03/30/2017 02:30 PM, Yoav Nir wrote: >> I=E2=80=99ll take the notes on etherpad, so anyone who wants to join in = is welcome. > > I'll join the etherpad note-taking. > > --Wendy > >> >> Yoav >> >>> On 30 Mar 2017, at 13:26, Kathleen Moriarty wrote: >>> >>> It looks like we still need one minute taker and a jabber scribe. >>> >>> Volunteers? >>> >>> On Mon, Mar 27, 2017 at 10:49 AM, Kathleen Moriarty >>> wrote: >>>> Hello, >>>> >>>> Can we have a couple of volunteers to take minutes and one to help as >>>> a jabber scribe? >>>> >>>> Thank you in advance! >>>> -- >>>> >>>> Best regards, >>>> Kathleen >>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >> >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > > -- > Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office) > Strategy Lead, World Wide Web Consortium (W3C) > https://wendy.seltzer.org/ +1.617.863.0613 (mobile) > > --=20 Best regards, Kathleen From nobody Thu Mar 30 12:13:13 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9741292FD; Thu, 30 Mar 2017 12:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 TuR-8vDeN4UZ; Thu, 30 Mar 2017 12:13:10 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0138.outbound.protection.outlook.com [104.47.40.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C50126B6D; Thu, 30 Mar 2017 12:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tqPjjhmHwE2zrx0P77wengOGFm4hSN9OvyRKuEmYgyI=; b=mxRPv7EAFeAQSoXPcgyEBP7VFKw0hXQEWB/wWgR/ck4gWJpIkBJrEmrcnIndWXKaO6wnYEg4EZccYqLBKbVMGhpA+bm+ySSXxg/VQFi5Jgi2r4hnKJRS7LcBkzmmmuDdOXPw9tLq4odKfvvCBAs3qS/INipdqA3SHTA1KKEzLV8= Received: from CY1PR0301MB2122.namprd03.prod.outlook.com (10.164.2.156) by CY1PR0301MB2123.namprd03.prod.outlook.com (10.164.2.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Thu, 30 Mar 2017 19:13:05 +0000 Received: from CY1PR0301MB2122.namprd03.prod.outlook.com ([10.164.2.156]) by CY1PR0301MB2122.namprd03.prod.outlook.com ([10.164.2.156]) with mapi id 15.01.1005.013; Thu, 30 Mar 2017 19:13:05 +0000 From: Orit Levin To: "saag@IETF.org" CC: "uta@ietf.org" Thread-Topic: UTA WG report Thread-Index: AdKpiVl4npOFw8VXR1uQSoEzKgRD0A== Date: Thu, 30 Mar 2017 19:13:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: IETF.org; dkim=none (message not signed) header.d=none;IETF.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [31.133.149.103] x-microsoft-exchange-diagnostics: 1; CY1PR0301MB2123; 7:60H1jpqHzhwMsBKRlEw68BVRc9Yla8O8PbObN0BL4gEdpkybKkk7tj/PFSg0ylv1n0TqGDGhsDUKYG+cPrCjA4l/x8VwGscVAYD5nRJNV/aXd7EFkAibBxysmnB4IwGpA/j2219HKrr2Ku8zeYK38NguLABaapDGTJIs61ttTEW6740JwPsVijEQa+ZbsOGOFhbrsI6SDjtrmMf4uX3uD0QNHEMKoF45cEdz+nqtOWssmCLus/rA0bfCYtDC+YedCX5ZAMIofVR4AqxDlzcynKdIxyA4MgSxQv2YXB1gkCL2kN1pidZi0xusVLth5N/8mfpJJcgwudn6OSTeMb8Nyj1lnt5yX8FtpkOeQEQBv+0= x-ms-office365-filtering-correlation-id: 9606d3c6-3a11-414e-94a7-08d477a0cb54 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR0301MB2123; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:CY1PR0301MB2123; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB2123; x-forefront-prvs: 02622CEF0A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39400400002)(39840400002)(39860400002)(39450400003)(31014005)(110136004)(6116002)(102836003)(33656002)(790700001)(6916009)(74316002)(25786009)(3280700002)(6306002)(2351001)(9686003)(3480700004)(54896002)(3846002)(86362001)(7696004)(4326008)(122556002)(3660700001)(8936002)(53936002)(5630700001)(66066001)(189998001)(38730400002)(54356999)(450100002)(50986999)(6436002)(10090500001)(86612001)(2501003)(8990500004)(77096006)(55016002)(7736002)(10290500002)(81166006)(5005710100001)(5640700003)(1730700003)(2900100001)(5660300001)(7116003)(99286003)(6506006)(8676002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB2123; H:CY1PR0301MB2122.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB212290BDEA02EDE3ECEE0724AD340CY1PR0301MB2122_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 19:13:05.2435 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB2123 Archived-At: Subject: [saag] UTA WG report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 19:13:12 -0000 --_000_CY1PR0301MB212290BDEA02EDE3ECEE0724AD340CY1PR0301MB2122_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable UTA WG met on Tue. All agenda topics relate to using TLS with e-mail protoc= ols. MTA-MTA interface: The drafts are very close to WG LC. The only real open i= ssue remains the choice between Jason and tag-value format. Implementers ch= oice is split 50/50. Vast majority (if not all) are OK with implementing ei= ther. The AD (Alexei) will suggest specific syntax for tag-value format. Al= l interested parties (i.e., potential implementers) are encouraged to chime= in on UTA list because we will be resolving this last issue in the upcomin= g weeks and moving the draft to LC. MUA-MTA interface: the draft has been further updated. The relevancy (and t= he complexity) of the proposed protocol has been questioned during the meet= ing. Even if the answer is "irrelevant", the BCP part of the draft is still= very useful. The authors will investigate and proceed according to the res= ults. (Potentially, the draft could be shorten or split and the status chan= ged to BCP, Experimental, or both.) REQUIRE-TLS draft: the draft has been discussed and found valuable for spec= ific critical cases. It was suggested to continue working on the draft with= an intent to be adopted by UTA or other (new) WG going forward. Orit. --_000_CY1PR0301MB212290BDEA02EDE3ECEE0724AD340CY1PR0301MB2122_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

UTA WG met on Tue. All agenda topics relate to us= ing TLS with e-mail protocols.

 

MTA-MTA interface: The drafts are very close to W= G LC. The only real open issue remains the choice between Jason and tag-val= ue format. Implementers choice is split 50/50. Vast majority (if not all) a= re OK with implementing either. The AD (Alexei) will suggest specific syntax for tag-value format. All interes= ted parties (i.e., potential implementers) are encouraged to chime in on UT= A list because we will be resolving this last issue in the upcoming weeks a= nd moving the draft to LC.

 

MUA-MTA interface: the draft has been further upd= ated. The relevancy (and the complexity) of the proposed protocol has been = questioned during the meeting. Even if the answer is “irrelevant̶= 1;, the BCP part of the draft is still very useful. The authors will investigate and proceed according to the results. (Potent= ially, the draft could be shorten or split and the status changed to BCP, E= xperimental, or both.)

 

REQUIRE-TLS draft: the draft has been discussed a= nd found valuable for specific critical cases. It was suggested to continue= working on the draft with an intent to be adopted by UTA or other (new) WG= going forward.

 

Orit.

 

--_000_CY1PR0301MB212290BDEA02EDE3ECEE0724AD340CY1PR0301MB2122_-- From nobody Thu Mar 30 12:42:04 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A0512943D for ; Thu, 30 Mar 2017 12:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 1w-GdAx8XJGR for ; Thu, 30 Mar 2017 12:41:59 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 546A81293F4 for ; Thu, 30 Mar 2017 12:41:54 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id AFC94209FA; Thu, 30 Mar 2017 15:41:53 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 30 Mar 2017 15:41:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=91BzrF925d6kBq0aR1 I/Xog71wYeX2moUzZK3rgUHn4=; b=kcwSD6ZdiLObNm069EiPCLycVzZOjLtnI4 j9BdVp/t7eHl8MiOyFmkpbwaRcgGsPk4T1M7gcg/eY/FysduH/cuHcqDjCmflUGo 4+z95uQYItNZI64idYHb30Zkm6fOO+6VxtFEFQADOCFIcgVyOFsMxQ1h6ajutEAD jzmRq6BUH3gH0gquxDEW93Y7MgWWBpA5JrOR0ZUVBVv7IVU6sKry+mKDRFJPVe/j ZZTXyeGA9460zSN3z+S+fMM/807Ws6DEnnvFSba/M4vSw/WrfXonyD476hwW6H5G ZV1QpszxPZirdDpMD300268ipoDLi2YHYWy0I8Hp0HODOxrx2srg== X-ME-Sender: X-Sasl-enc: 9bWhLNMuIS6TWe3ePDqQLSyq4/Y9Q4+s3SlUPGQx3Osm 1490902913 Received: from [10.59.24.82] (unknown [96.47.143.36]) by mail.messagingengine.com (Postfix) with ESMTPA id 54BFB246D1; Thu, 30 Mar 2017 15:41:53 -0400 (EDT) To: saag@ietf.org References: From: Keith Moore Message-ID: <866da370-1475-c4cb-f86a-7a92b3778160@network-heretics.com> Date: Thu, 30 Mar 2017 15:41:52 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7520235FE3F0348FB5C24C3D" Archived-At: Subject: Re: [saag] UTA WG report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 19:42:02 -0000 This is a multi-part message in MIME format. --------------7520235FE3F0348FB5C24C3D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit As co-author of this document, I frankly don't understand what the "BCP part" of draft-ietf-email-deep-06 is. BCP is appropriate for process documents, or for specifications that don't lend themselves to interoperability testing and thus cannot progress to full standard. Neither of those is the case for deep. The assertion was made by one of the meeting attendees that the goals of this specification can be met by mail service providers (MSPs) incrementally blocking access to customers whose mail user agents (MUAs) don't negotiate TLS. While I acknowledge that one MSP has successfully employed this strategy, I personally wonder how well this works for very large MSPs. To me it seems like the customer support burden would be substantial. But I'm working on getting feedback on the draft - both from implementors of widely-used MUAs, and from other MSPs - to see what they say about the draft. Regardless of whether this protocol gets support from implementors, I would not consider this work finished until we have consensus on how to upgrade all MUA-server traffic to use TLS 1.1 or better, and have confidence that this will enable us to deprecate cleartext and TLS <= 1.0 access to these services within a year or two. Of course, if there's general agreement among MSPs that they can do this without changes to MUAs and servers, so much the better. But the work isn't done until we have consensus on a way forward (whether it happens in UTA or not). Keith On 03/30/2017 03:13 PM, Orit Levin wrote: > > UTA WG met on Tue. All agenda topics relate to using TLS with e-mail > protocols. > > MTA-MTA interface: The drafts are very close to WG LC. The only real > open issue remains the choice between Jason and tag-value format. > Implementers choice is split 50/50. Vast majority (if not all) are OK > with implementing either. The AD (Alexei) will suggest specific syntax > for tag-value format. All interested parties (i.e., potential > implementers) are encouraged to chime in on UTA list because we will > be resolving this last issue in the upcoming weeks and moving the > draft to LC. > > MUA-MTA interface: the draft has been further updated. The relevancy > (and the complexity) of the proposed protocol has been questioned > during the meeting. Even if the answer is “irrelevant”, the BCP part > of the draft is still very useful. The authors will investigate and > proceed according to the results. (Potentially, the draft could be > shorten or split and the status changed to BCP, Experimental, or both.) > > REQUIRE-TLS draft: the draft has been discussed and found valuable for > specific critical cases. It was suggested to continue working on the > draft with an intent to be adopted by UTA or other (new) WG going > forward. > > Orit. > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------7520235FE3F0348FB5C24C3D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

As co-author of this document, I frankly don't understand what the "BCP part" of draft-ietf-email-deep-06 is.   BCP is appropriate for process documents, or for specifications that don't lend themselves to interoperability testing and thus cannot progress to full standard.  Neither of those is the case for deep.

The assertion was made by one of the meeting attendees that the goals of this specification can be met by mail service providers (MSPs) incrementally blocking access to customers whose mail user agents (MUAs) don't negotiate TLS.   While I acknowledge that one MSP has successfully employed this strategy, I personally wonder how well this works for very large MSPs.  To me it seems like the customer support burden would be substantial.   But I'm working on getting feedback on the draft - both from implementors of widely-used MUAs, and from other MSPs - to see what they say about the draft.

Regardless of whether this protocol gets support from implementors, I would not consider this work finished until we have consensus on how to upgrade all MUA-server traffic to use TLS 1.1 or better, and have confidence that this will enable us to deprecate cleartext and TLS <= 1.0 access to these services within a year or two.  

Of course, if there's general agreement among MSPs that they can do this without changes to MUAs and servers, so much the better.    But the work isn't done until we have consensus on a way forward (whether it happens in UTA or not).

Keith


On 03/30/2017 03:13 PM, Orit Levin wrote:

UTA WG met on Tue. All agenda topics relate to using TLS with e-mail protocols.

 

MTA-MTA interface: The drafts are very close to WG LC. The only real open issue remains the choice between Jason and tag-value format. Implementers choice is split 50/50. Vast majority (if not all) are OK with implementing either. The AD (Alexei) will suggest specific syntax for tag-value format. All interested parties (i.e., potential implementers) are encouraged to chime in on UTA list because we will be resolving this last issue in the upcoming weeks and moving the draft to LC.

 

MUA-MTA interface: the draft has been further updated. The relevancy (and the complexity) of the proposed protocol has been questioned during the meeting. Even if the answer is “irrelevant”, the BCP part of the draft is still very useful. The authors will investigate and proceed according to the results. (Potentially, the draft could be shorten or split and the status changed to BCP, Experimental, or both.)

 

REQUIRE-TLS draft: the draft has been discussed and found valuable for specific critical cases. It was suggested to continue working on the draft with an intent to be adopted by UTA or other (new) WG going forward.

 

Orit.

 



_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--------------7520235FE3F0348FB5C24C3D-- From nobody Thu Mar 30 13:27:05 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36F81293D9 for ; Thu, 30 Mar 2017 13:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 MYFYzpiIM2CK for ; Thu, 30 Mar 2017 13:26:52 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 30DD4129470 for ; Thu, 30 Mar 2017 13:26:51 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id r142so50914766qke.2 for ; Thu, 30 Mar 2017 13:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=3TB6BLe6bZN+ENiPFUCtP3VJZuuZf4Q74gp11g2HHGc=; b=qFxyyhMp+Q6IuJTa1DYdhxUhJ8/ta20BFRTgUDSmisie7/gPeR7lpbInYEx+1/X/P5 1qNJ4Fi+XBfMAfz86vnXqHLXMSgK9phaZzV4UdioB55b2eqydd0sU94d4lkGmaanDwEj +ce/qWcSDwRaiCfcJDHEAVh8Cx1W6/S+0euYEbVKn8q1Gsr9zhWZkOaqS+XZ21C6qUbq MJmZbrAfb7XHyDfm2HF9b6YLaetb3sws9OS+eP/wTYAE12LIT6JPe+wyVVLIOb2IFr7v f+/Nuiv5aGoVEOr4rEQdOSQkQHh1CKN5m3U6vYhtKJ+tEx3NYjPKFIbAzoYip1FCjFbs GgIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3TB6BLe6bZN+ENiPFUCtP3VJZuuZf4Q74gp11g2HHGc=; b=n7TQOQ1BzHUFcAEZuHxNX4jX0EkBtjhyLfX4Ei0ytlos5QRhiP/+h2WabUhYQnKpc0 aU1lEfSF85Re1wHVygJqGb8J8FlZ7kODRFQ41G2rLLuaDgjOAQRsD3l8dhb2jeArEsHu HKTzZJYgUIHPUswDjUN3Kt5Zri1wH3U8tV0ZcUTFia0nJ/VnA5fBnJZOYAPS9p7QnW2f 3w2wRt7haOuwP+BmNq23bNPigFqDQU4fmbI5rSuO1m69x/rxqHlTk0qFBYtsY5XJK0j7 fbl5xcwrzOpDIUps8RtVBNbV1ben6jvoio2vj0N4lZb9joPz0o9D1Z1+yZikUNcuZqfB qvZA== X-Gm-Message-State: AFeK/H0YDFSawouIW7zsI+mM5SPndkOMWVuZUGCUiEYo9IDua9YZs7fOaU+6UPv3Bz1EFF5WvwXPvAuTnGFPbw== X-Received: by 10.55.10.20 with SMTP id 20mr1602053qkk.119.1490905610039; Thu, 30 Mar 2017 13:26:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.54.2 with HTTP; Thu, 30 Mar 2017 13:26:19 -0700 (PDT) From: Ted Hardie Date: Thu, 30 Mar 2017 15:26:19 -0500 Message-ID: To: "Salz, Rich" , "saag@ietf.org" Content-Type: multipart/alternative; boundary=001a114c6cc447e7a2054bf88387 Archived-At: Subject: [saag] ACME X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 20:26:55 -0000 --001a114c6cc447e7a2054bf88387 Content-Type: text/plain; charset=UTF-8 All open issues which were raised during the WGLC were addressed by the end of the meeting. The draft will be revised and, after a second WG last call, will be forwarded to the IESG. Discussion of extensions and future work will occur on the list after that, with resolution at or after the upcoming Prague meeting. Ted and Rich --001a114c6cc447e7a2054bf88387 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All open issues which were raised during the WGL= C were addressed by the end of the meeting.=C2=A0 The draft will be revised= and, after a second WG last call, will be forwarded to the IESG.

Discussion of extensions and future work will occur on the list after t= hat, with resolution at or after the upcoming Prague meeting.

= Ted and Rich
--001a114c6cc447e7a2054bf88387-- From nobody Thu Mar 30 13:50:42 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C80129538; Thu, 30 Mar 2017 13:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 GJpKg5BC5nIB; Thu, 30 Mar 2017 13:50:38 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0103.outbound.protection.outlook.com [104.47.41.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC831294A2; Thu, 30 Mar 2017 13:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JdlTtnaDL5TgNpo4ey5QTwyV2a+lsVTGEdBAYp/6vag=; b=WblJ/IcoO64GTbLVlwTfM0P1ZZO4SfVWG50FibVKVQm9ZvbGeRB3a4vCntVYRvLS/9YGyiLheDilAKTw1VSgRAcUaLbGvhtZq++hSqIn681i4C9/x7wGqkbykcgDtgyZlvLpXkOIjoPOSFJV/0C1G3WoanPPaVCFncKBcam1F/c= Received: from CY1PR0301MB2122.namprd03.prod.outlook.com (10.164.2.156) by CY1PR0301MB2122.namprd03.prod.outlook.com (10.164.2.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Thu, 30 Mar 2017 20:50:26 +0000 Received: from CY1PR0301MB2122.namprd03.prod.outlook.com ([10.164.2.156]) by CY1PR0301MB2122.namprd03.prod.outlook.com ([10.164.2.156]) with mapi id 15.01.1005.013; Thu, 30 Mar 2017 20:50:26 +0000 From: Orit Levin To: Keith Moore , "saag@ietf.org" CC: "uta@ietf.org" Thread-Topic: [saag] UTA WG report Thread-Index: AdKpiVl4npOFw8VXR1uQSoEzKgRD0AABFRoAAAIV6MA= Date: Thu, 30 Mar 2017 20:50:26 +0000 Message-ID: References: <866da370-1475-c4cb-f86a-7a92b3778160@network-heretics.com> In-Reply-To: <866da370-1475-c4cb-f86a-7a92b3778160@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: network-heretics.com; dkim=none (message not signed) header.d=none;network-heretics.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:67c:370:128:5cc:d8dd:f79e:d91b] x-microsoft-exchange-diagnostics: 1; CY1PR0301MB2122; 7:9cUaf0kgdpG8Mnp9eeRxQmiXsGpipTouFDnwWpZzws7oPpVLwc0ym8g4ZmfdR6JBm1Eq5VrzlBeyIBT1TYNMjkDqiqGZlhwL5E8yoPAXb+hgRDysIik8I+X+MtdDMGwgpRW2MZ8p552rB1MeRJg5AisnnbV/JfR3a9UCbWX/pOk6kStqn+DATIjJCzFALap6xi6JjIYkv+yMikcVWuWABtrHrZETaOQeIoJ5dsq+V9jTgNrzIRsBtGC/XbgiUTTTOhlqPsge5trL+l80IgFTq6Ul+HoiccTtExSXV4wPC7EfoUhFjxzxJKlFRTV/qo1jLgLkuHpC/wGrCC3Gz6Hf6k530DQORpePPCF072usmhY= x-ms-office365-filtering-correlation-id: 3492a6cc-e855-4de8-de90-08d477ae64cf x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR0301MB2122; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123562025)(6072148); SRVR:CY1PR0301MB2122; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB2122; x-forefront-prvs: 02622CEF0A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39860400002)(39410400002)(39840400002)(39850400002)(39400400002)(24454002)(31014005)(377454003)(54356999)(236005)(8990500004)(3660700001)(122556002)(50986999)(10090500001)(76176999)(99286003)(6306002)(54896002)(9686003)(81166006)(8676002)(5005710100001)(7696004)(5660300001)(2950100002)(3280700002)(10290500002)(33656002)(53936002)(77096006)(6506006)(6436002)(2501003)(55016002)(4326008)(7906003)(7736002)(6116002)(102836003)(2900100001)(790700001)(6246003)(53546009)(189998001)(2906002)(606005)(74316002)(229853002)(8936002)(86362001)(38730400002)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB2122; H:CY1PR0301MB2122.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB21225D1659C24FD946B66E5AAD340CY1PR0301MB2122_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 20:50:26.3723 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB2122 Archived-At: Subject: Re: [saag] UTA WG report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 20:50:41 -0000 --_000_CY1PR0301MB21225D1659C24FD946B66E5AAD340CY1PR0301MB2122_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Keith, Great intro to gathering the very much needed feedback. Adding UTA so we can continue the discussion there. Thanks, Orit. From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Keith Moore Sent: Thursday, March 30, 2017 12:42 PM To: saag@ietf.org Subject: Re: [saag] UTA WG report As co-author of this document, I frankly don't understand what the "BCP par= t" of draft-ietf-email-deep-06 is. BCP is appropriate for process documen= ts, or for specifications that don't lend themselves to interoperability te= sting and thus cannot progress to full standard. Neither of those is the c= ase for deep. The assertion was made by one of the meeting attendees that the goals of th= is specification can be met by mail service providers (MSPs) incrementally = blocking access to customers whose mail user agents (MUAs) don't negotiate = TLS. While I acknowledge that one MSP has successfully employed this stra= tegy, I personally wonder how well this works for very large MSPs. To me i= t seems like the customer support burden would be substantial. But I'm wo= rking on getting feedback on the draft - both from implementors of widely-u= sed MUAs, and from other MSPs - to see what they say about the draft. Regardless of whether this protocol gets support from implementors, I would= not consider this work finished until we have consensus on how to upgrade = all MUA-server traffic to use TLS 1.1 or better, and have confidence that t= his will enable us to deprecate cleartext and TLS <=3D 1.0 access to these = services within a year or two. Of course, if there's general agreement among MSPs that they can do this wi= thout changes to MUAs and servers, so much the better. But the work isn'= t done until we have consensus on a way forward (whether it happens in UTA = or not). Keith On 03/30/2017 03:13 PM, Orit Levin wrote: UTA WG met on Tue. All agenda topics relate to using TLS with e-mail protoc= ols. MTA-MTA interface: The drafts are very close to WG LC. The only real open i= ssue remains the choice between Jason and tag-value format. Implementers ch= oice is split 50/50. Vast majority (if not all) are OK with implementing ei= ther. The AD (Alexei) will suggest specific syntax for tag-value format. Al= l interested parties (i.e., potential implementers) are encouraged to chime= in on UTA list because we will be resolving this last issue in the upcomin= g weeks and moving the draft to LC. MUA-MTA interface: the draft has been further updated. The relevancy (and t= he complexity) of the proposed protocol has been questioned during the meet= ing. Even if the answer is "irrelevant", the BCP part of the draft is still= very useful. The authors will investigate and proceed according to the res= ults. (Potentially, the draft could be shorten or split and the status chan= ged to BCP, Experimental, or both.) REQUIRE-TLS draft: the draft has been discussed and found valuable for spec= ific critical cases. It was suggested to continue working on the draft with= an intent to be adopted by UTA or other (new) WG going forward. Orit. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --_000_CY1PR0301MB21225D1659C24FD946B66E5AAD340CY1PR0301MB2122_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Keith,

Great intro to gath= ering the very much needed feedback.

Adding UTA so we ca= n continue the discussion there.

Thanks,<= /span>

Orit.

 

From:= saag [mailto:saag-bounces@ietf.org] On Behalf Of Keith Moore
Sent: Thursday, March 30, 2017 12:42 PM
To: saag@ietf.org
Subject: Re: [saag] UTA WG report

 

As co-author of this document, I frankly don't understand what the "= ;BCP part" of draft-ietf-email-deep-06 is.   BCP is appropri= ate for process documents, or for specifications that don't lend themselves= to interoperability testing and thus cannot progress to full standard.  Neither of those is the case for deep.

The assertion was made by one of the meeting attendees that the goals of th= is specification can be met by mail service providers (MSPs) incrementally = blocking access to customers whose mail user agents (MUAs) don't negotiate = TLS.   While I acknowledge that one MSP has successfully employed this strategy, I personally wonder how w= ell this works for very large MSPs.  To me it seems like the customer = support burden would be substantial.   But I'm working on getting= feedback on the draft - both from implementors of widely-used MUAs, and from other MSPs - to see what they say about the = draft.

Regardless of whether this protocol gets support from implementors, I would= not consider this work finished until we have consensus on how to upgrade = all MUA-server traffic to use TLS 1.1 or better, and have confidence that t= his will enable us to deprecate cleartext and TLS <=3D 1.0 access to these services within a year or tw= o.  

Of course, if there's general agreement among MSPs that they can do this wi= thout changes to MUAs and servers, so much the better.    Bu= t the work isn't done until we have consensus on a way forward (whether it = happens in UTA or not).

Keith

 

On 03/30/2017 03:13 PM, Orit Levin wrote:=

UTA WG met on Tue. All agenda topics relate to us= ing TLS with e-mail protocols.

 

MTA-MTA interface: The drafts are very close to W= G LC. The only real open issue remains the choice between Jason and tag-val= ue format. Implementers choice is split 50/50. Vast majority (if not all) a= re OK with implementing either. The AD (Alexei) will suggest specific syntax for tag-value format. All interes= ted parties (i.e., potential implementers) are encouraged to chime in on UT= A list because we will be resolving this last issue in the upcoming weeks a= nd moving the draft to LC.

 

MUA-MTA interface: the draft has been further upd= ated. The relevancy (and the complexity) of the proposed protocol has been = questioned during the meeting. Even if the answer is “irrelevant̶= 1;, the BCP part of the draft is still very useful. The authors will investigate and proceed according to the results. (Potent= ially, the draft could be shorten or split and the status changed to BCP, E= xperimental, or both.)

 

REQUIRE-TLS draft: the draft has been discussed a= nd found valuable for specific critical cases. It was suggested to continue= working on the draft with an intent to be adopted by UTA or other (new) WG= going forward.

 

Orit.

 




_______________________________________________
saag mailing list
saag@ietf.org
https://www.iet=
f.org/mailman/listinfo/saag

 

--_000_CY1PR0301MB21225D1659C24FD946B66E5AAD340CY1PR0301MB2122_-- From nobody Thu Mar 30 15:04:36 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0644F129492 for ; Thu, 30 Mar 2017 15:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.997 X-Spam-Level: X-Spam-Status: No, score=-4.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=fLsUAasw; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=X17sXkYX 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 eiyXOUtyzBNg for ; Thu, 30 Mar 2017 15:04:34 -0700 (PDT) Received: from esa5.dell-outbound.iphmx.com (esa5.dell-outbound.iphmx.com [68.232.153.95]) (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 6B9CD1252BA for ; Thu, 30 Mar 2017 15:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1490911357; x=1522447357; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=8TGUPtP9Zd8lhzEtc56xfcxJ31YMFk2RqIXrcwU6PQU=; b=fLsUAaswEaEiAkjR4ghyFCbRIAtWhrgM9gd97A/NljXAMVRKeHJ2Z03Y yf97Rq//hRBzjEN8XDiSEpjHya9D+Mvc4i3IXAHURpYkxdpDVICbUNxlB +pko+VkRj6xAX7uP6UJfOlhzi8fkZi5UoMbuZaJ1XsgXCb1/8PdGGqulc 0=; Received: from esa1.dell-outbound2.iphmx.com ([68.232.153.201]) by esa5.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Mar 2017 17:02:37 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Mar 2017 03:57:16 +0600 Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v2UM4VvU028816 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 30 Mar 2017 18:04:32 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com v2UM4VvU028816 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1490911472; bh=vnAr7cjAvYt42o3J+QBkOki99bg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=X17sXkYXn0FMMtRA+ANLpOLSFLrO2CX9gECmD6k4RbD/tOdLsn9jy3w9Hsu1EKM+I WG5yecEYj8Pm7mj3Gl3NVdTTw+X1HFsW7dj6fdlTeJUKVR3/XMgcqywnbsOsz+0Xzj xsWC+00zTLG4PfgOVioE2oujg4sv7/G7B39tT9bo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com v2UM4VvU028816 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd05.lss.emc.com (RSA Interceptor) for ; Thu, 30 Mar 2017 18:03:42 -0400 Received: from MXHUB320.corp.emc.com (MXHUB320.corp.emc.com [10.146.3.98]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v2UM4F7Y023371 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Thu, 30 Mar 2017 18:04:15 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB320.corp.emc.com ([10.146.3.98]) with mapi id 14.03.0266.001; Thu, 30 Mar 2017 18:04:15 -0400 To: "saag@ietf.org" Thread-Topic: OPS review checklist Thread-Index: AdKpoZen/l3v/2U8RPK1QjzZDG4LoA== Date: Thu, 30 Mar 2017 22:04:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [saag] OPS review checklist X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 22:04:36 -0000 The operations and management (OPS Area) review checklist that I mentioned = during discussion of updating RFC 3552 (Guidelines for Writing RFC Text on = Security Considerations) can be found in Appendix A of RFC 5706: https://da= tatracker.ietf.org/doc/html/rfc5706#appendix-A Thanks, --David (with credit to Hannes for prompting me to go find this and send out the po= inter). From nobody Thu Mar 30 15:06:30 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DD21295E7 for ; Thu, 30 Mar 2017 15:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GxxCHmomUJTq for ; Thu, 30 Mar 2017 15:06:26 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 58AAB1252BA for ; Thu, 30 Mar 2017 15:06:26 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id z13so28967296iof.2 for ; Thu, 30 Mar 2017 15:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=/Sp9UZSrdfJh9duZqvWKVBaC7mrukmoLuDbpkmwmq8U=; b=pCiRo9NELLbBeVaN2bZrm0spadhyWoC9dlqn2Qp2AYO5yPzSPH83wUKbHIoIooRNrK SromK0jtEao/eQ+DciFiBVSAXwKFmP/DbiFCWOtYhGnWR18jmdwz502pcBnFBbYcmUB6 NNHOZXZv4K7QWsxGpWNVvHJMUdeZ1qmQpSaDe2ct0LV9iLB2BM8XgJXcdrKEfMg68nYk MEzdnGu+xYzQK423R36Uc6JwQV2iYWSHG8iL4IfRJoM3NgMrjp2NpqhdBE9xAkjLir4O n6vMeuuAfO0NUd9GXnRPDjbTU++ukA3gCSQUY1ZbMQZ2XHz5kOI762qhICcIRhT6VmIP sJhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=/Sp9UZSrdfJh9duZqvWKVBaC7mrukmoLuDbpkmwmq8U=; b=RfNneC77amZWeU2yKUjrUedSAj/uRv71MfFGrdPPGnu/OIjEk++eqU8nZjrxmk5rp/ BR0NvPRfoJhzd7KZXWPEdpRuSTM8SgAgtUWIGiQcxIkBAh0hgbqG5CG4YV3FSK9afJsz skyjladX5XWvN7Y+kg7WjRB+a3rNOueiR1QiryApmJG/gmDQgUkaBAIwV/p7deP/Jye1 m4HN9F29RjZO2qUU41pTt9OTXAI9cgfo2RyyLuQ7GZPmCelE/UAbkuagkPERS+1qAjDV nK7sySQWxPe8uX6fWfDSDCiNFjvZtUaeM7pkrrWSA9CVfTO2EzOL9I8eqNkTHKb/Nvds 1fxQ== X-Gm-Message-State: AFeK/H1c9ccUVzmanmzgBpZPnbh/xYompn+OYPtSV5wuXLrfRiOdT+keWfL1qScabAzZ6Pw0GYS8g2uTh7WcYg== X-Received: by 10.107.129.75 with SMTP id c72mr3617842iod.23.1490911585551; Thu, 30 Mar 2017 15:06:25 -0700 (PDT) MIME-Version: 1.0 Sender: sharon.goldbe@gmail.com Received: by 10.107.141.197 with HTTP; Thu, 30 Mar 2017 15:05:45 -0700 (PDT) From: Sharon Goldberg Date: Thu, 30 Mar 2017 18:05:45 -0400 X-Google-Sender-Auth: ZL39qrjvLBtzPpHYaAScT3lRtRg Message-ID: To: saag@ietf.org Content-Type: multipart/alternative; boundary=001a113f99b072e681054bf9e74c Archived-At: Subject: [saag] Following up today's VRF presentation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 22:06:28 -0000 --001a113f99b072e681054bf9e74c Content-Type: text/plain; charset=UTF-8 Thanks all for your comments and questions during my presentation on VRFs. (VRF = Verifiable Random Function, the public-key version of a cryptographic hash function). Draft and slides here: https://datatracker.ietf.org/doc/draft-goldbe-vrf/ https://www.ietf.org/proceedings/98/slides/slides-98-saag-verifiable-random-functions-vrfs-00.pdf Below is a list of all the places I've seen VRFs used so far. Let me know if you know of others, or could think of ways to use them in other applications, or have other comments on the draft. https://whispersystems.org/docs/specifications/xeddsa/ https://github.com/isislovecruft/curve25519-dalek/issues/9 https://github.com/google/keytransparency/blob/master/core/vrf/p256/p256.go#L73 https://github.com/coniks-sys/coniks-go/pull/167 https://www.ietf.org/proceedings/98/slides/slides-98-dnsop-nsec5-ietf98-01.pdf Thanks, Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --001a113f99b072e681054bf9e74c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks all for your comments and questions = during my presentation on VRFs. (VRF =3D Verifiable Random Function, the pu= blic-key version of a cryptographic hash function). Draft and slides here:<= br>
https= ://datatracker.ietf.org/doc/draft-goldbe-vrf/
https://www.ietf.org/proceedings/98/slides/slides-98-saag-veri= fiable-random-functions-vrfs-00.pdf

Below is a list of all= the places I've seen VRFs used so far. Let me know if you know of othe= rs, or could think of ways to use them in other applications, or have other comments on the draft.

https://whispersys= tems.org/docs/specifications/xeddsa/
https://github.com/isislovecruft/cu= rve25519-dalek/issues/9
https://github.com/google/k= eytransparency/blob/master/core/vrf/p256/p256.go#L73
https://github.com/coniks-sys= /coniks-go/pull/167
https://www.ietf.org/proceedings= /98/slides/slides-98-dnsop-nsec5-ietf98-01.pdf

Thanks,
=
Sharon

--
Sharon Goldberg
Computer Science, Boston University
= http://www.cs.= bu.edu/~goldbe
--001a113f99b072e681054bf9e74c-- From nobody Thu Mar 30 15:25:09 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC191293EE for ; Thu, 30 Mar 2017 15:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 g5butwcf3aGp for ; Thu, 30 Mar 2017 15:25:04 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 87449126C2F for ; Thu, 30 Mar 2017 15:25:04 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id 190so2770458itm.0 for ; Thu, 30 Mar 2017 15:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=kzlzzt616cEoNyM5MdK1zTgyUPaANdfHdan7cqLtP60=; b=FGD2wB6UXAC1AzE9dFp+r15yb6awsD0/+Bx8W83p8lYPSstQagmUyJwpxTL75ULGSo aDQ3NFTp0XVhw69QMqaLzGPU/+da5wn0xYJl1cNvfLidWJJshM6B0sjqT/winujCark9 4b/1bDtlV6scvoZNAu5eYTvlFQNJtxI2BFzGQoxUkPZXSOU1U1GfvSKOZfJqsHlt6L/a lWl8rjfonLQ//D7XLsHH4idM8dk/feQLyHb6yJo65ap7A/asf6/tcSKB2O2vIVCLMqZt 5o1T0lyAA6OYEfXMWlH0/xxsVbehgdYebBrPBHfGFaUUO32msla837/egBMKG9RoSg9q /XXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=kzlzzt616cEoNyM5MdK1zTgyUPaANdfHdan7cqLtP60=; b=KiTArf/7iJ2ASHVR+ybViR2bcPbWb2/z1XY5fuS7Hivy9Yl4eKoVnf4aQ2xZKx72Xr RHsiXyvLq27z1bGItsl7gGlxfBSwaHCedmN2q5ZfTgbwQYLTiO9XCuecw8ilAyktt+mU +Agiys8PEvJ7PiotrQoomz2hxm+JPTkJ1Wu8vryr4FZyKe/yWReFnc9mZOLCcOWdEZm9 jb/J2Q/y5BrWAh8lD3mqEw8VqxqtyKI/0IghnZLqHQ5I0nvYYLkinCNwBUxcwo0StnOQ 7F6xkP+LTNsEgQm0YNOR3WU1lttmxADHRIT2MjW7Lbw1H8eWaCMB1BUVi14g3QuY/HuQ B9lg== X-Gm-Message-State: AFeK/H2+QW2ChtOrZJdMOUt5RzfsRgaRAJ+m2UhOiS6wmin3BGioD4ykSKE6NwTsNs8j2A== X-Received: by 10.36.240.9 with SMTP id s9mr629836ith.45.1490912703775; Thu, 30 Mar 2017 15:25:03 -0700 (PDT) Received: from ?IPv6:2001:67c:1233::5d0b:8075:5f5a:9c25? ([2001:67c:1233:0:5d0b:8075:5f5a:9c25]) by smtp.gmail.com with ESMTPSA id k63sm2134151ioi.19.2017.03.30.15.25.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 15:25:03 -0700 (PDT) From: Yoav Nir Content-Type: multipart/signed; boundary="Apple-Mail=_F1FE8C81-F655-44D1-9029-1FBE662FCBAB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Thu, 30 Mar 2017 17:25:02 -0500 To: Security Area Advisory Group X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [saag] A revision of RFC 3552 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 22:25:07 -0000 --Apple-Mail=_F1FE8C81-F655-44D1-9029-1FBE662FCBAB Content-Type: multipart/alternative; boundary="Apple-Mail=_C23B8057-5F9C-4159-AD49-37989ED35111" --Apple-Mail=_C23B8057-5F9C-4159-AD49-37989ED35111 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Following on the discussion of a revision of RFC 3552, here=E2=80=99s a = link to the draft: https://tools.ietf.org/html/draft-nir-saag-rfc3552bis-00 = As you can tell, it=E2=80=99s expired, but if there=E2=80=99s interest, = I will re-publish. There are very few changes from RFC 3552 - mostly = updated references. If you want to pitch in, reviews and suggestions to the list are = welcome. And PRs are even more welcome: https://github.com/IETF-SAAG/RFC3552bis = If we don=E2=80=99t get any input, we might as well give up on this. Yoav --Apple-Mail=_C23B8057-5F9C-4159-AD49-37989ED35111 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Following on the discussion of a revision of RFC 3552, = here=E2=80=99s a link to the draft:

https://tools.ietf.org/html/draft-nir-saag-rfc3552bis-00

As you can tell, = it=E2=80=99s expired, but if there=E2=80=99s interest, I will = re-publish.  There are very few changes from RFC 3552 - mostly = updated references.

If you want to pitch in, reviews and suggestions to the =  list are welcome. And PRs are even more welcome: 
https://github.com/IETF-SAAG/RFC3552bis

If we don=E2=80=99t get = any input, we might as well give up on this.

Yoav

= --Apple-Mail=_C23B8057-5F9C-4159-AD49-37989ED35111-- --Apple-Mail=_F1FE8C81-F655-44D1-9029-1FBE662FCBAB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY3YW+AAoJELhJCxUKWMyZRQIIALkBihvFEvdfBZsVb4wn55Bb x+kcIqkp9xBsQ454LqJKrDCNe4QTV/qlNDQ6To088fUPNBQhQryaHo7N4GbeE5Nf V12B3p/7qYj1MyrH2teAHESkAl5+ywwBCisyeJrlq5hbISlwYcbfA0IxFmoWIrd5 TNq66POR2/Fouz4F+3nP2VdbaKWr7qPyADK2ZAAwsehnHUMaezz0msTky34tinrM 5Hzv+K2RgcgthSaTQ76AfQa1yeglmNqubS/d7uF88e3woiwgyOtcowO57JKWdhvP gzYDStZzZPIBVMuuAlkIYWLkZc99WOKToqpWqW3SXmM99WRTabEfXzjEPIgS0og= =rfmF -----END PGP SIGNATURE----- --Apple-Mail=_F1FE8C81-F655-44D1-9029-1FBE662FCBAB-- From nobody Thu Mar 30 22:20:25 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B955128C81; Thu, 30 Mar 2017 22:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 H_H0g2R7dfKo; Thu, 30 Mar 2017 22:20:17 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (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 115631292D3; Thu, 30 Mar 2017 22:20:17 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v2V5KG9f091376; Thu, 30 Mar 2017 22:20:16 -0700 (PDT) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v2V5KGtZ098614; Thu, 30 Mar 2017 22:20:16 -0700 (PDT) From: David Mazieres To: saag@ietf.org, ilc@ietf.org In-Reply-To: <8951becb-fca3-2520-11f1-a05615b49826@gmail.com> References: <87a88uksu0.fsf@ta.scs.stanford.edu> <8760iqr4a6.fsf@ta.scs.stanford.edu> <8951becb-fca3-2520-11f1-a05615b49826@gmail.com> Reply-To: David Mazieres expires 2017-06-28 PDT Date: Thu, 30 Mar 2017 22:20:16 -0700 Message-ID: <87bmsi81kf.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [saag] ILC bar BoF summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 05:20:18 -0000 Just a brief follow-up to the bar BoF. We talked about several potential applications of ILC, including enhanced versions of certificate transparency, pseudonymous reputation systems, and software/package transparency. The application that stood out as the most compelling was binary transparency of firmware updates for IoT devices. There's a good chance that powerful actors will attempt to compromise such devices' firmware on a large scale. Merely requiring updates to be digitally signed could prove insufficient if the manufacturer is compromised. By contrast, publicly logging any updates in some data structure checkpointed by all of the world's log authorities would require a far higher level of complicity by the manufacturer and greatly increase the chances of exposing nefarious firmware. We also thought that it might be best to include transparency from the start in any standard for authenticating firmware updates. If we try to add some kind of transparency to an existing firmware update standard, it seems unlikely to get as widespread adoption as if transparency is an integral part of any update standard from day one. David From nobody Fri Mar 31 06:16:18 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD0F1296AE for ; Fri, 31 Mar 2017 06:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 I95GIqAm0Vnj for ; Fri, 31 Mar 2017 06:16:09 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 5972712969C for ; Fri, 31 Mar 2017 06:16:09 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id v76so38159561ywg.0 for ; Fri, 31 Mar 2017 06:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=8+T87fKZoX00/v+BBZ3Vo2m7LTB0/sYeOaOuZqqxv+s=; b=1edKTCY5nWFmi8MGyQYG0S1tFzJP5ECyB0CLUmvKoVWlTGiNOfgfIysSM0LcGgqAVf BRURD1jrsSdVWWjXy7QvoKtG/Opc50zyry9cZhkeC0Q6RtlmW4mp8uwQhoiMN6brq83V SXaCJ+lEryEB3rkTEtxciObOIZWSRVObN5gUevKD0ouGwLlXKMwQ04ys28FvqDjtsfLV YxMpQAQXTstqHAYgIK+XEfHDTta5BUAkphREeLGADT1Kjy+blLEKOguF9N9PbajZNd8Z KTqIqMKophmZa2rJvwMfsYioRqUpoQ4oo+wNytmoukLMWj9qE351n6+ALeO13PL3R0xK eCcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8+T87fKZoX00/v+BBZ3Vo2m7LTB0/sYeOaOuZqqxv+s=; b=Th4t/SjO95gezD5oJZMO7m+YLKBcrPdjc2D6KlFYJ7OM+uq/3vVZ/KMaHPCTutOvqQ H71+rn9FHWfj6jaTRcsM4uuM4lRJyyeI0USXUwu+8bIV5O42b2r4DdNFe70ByltSDToV tKnkRAck6+n+GUU5E0NawQ9Ipo5jZRIFbcbKxgiSHw0uV7jAq/B+9usjJV+Nf6amCeii 7g7NdWGX3mHH6fXBJzf75yMEwkRoNyAqeOulP0iZrBOHT5TSfFDpbUfLas+iGMfihO9o 99myQwwSB1+CTGuQdipNn8xWo+mebLaXZ5/tH7qekFrdToV999c4PGjVlIiPQVK4BiBr XvNw== X-Gm-Message-State: AFeK/H1zVsFA44fJrBFO8/gHLoTbsmXT68BsTjsuw0z2MK6D2Rn6Ktgg0FMv0FBLoQ6YzDCg0PuQ5anJ4rBZQA== X-Received: by 10.13.240.199 with SMTP id z190mr2079307ywe.125.1490966168287; Fri, 31 Mar 2017 06:16:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Fri, 31 Mar 2017 06:15:27 -0700 (PDT) From: Eric Rescorla Date: Fri, 31 Mar 2017 08:15:27 -0500 Message-ID: To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c03380cd563a5054c069c8c Archived-At: Subject: [saag] Draft minutes X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 13:16:12 -0000 --94eb2c03380cd563a5054c069c8c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here are the draft minutes (thanks to Yoav and Wendy). Yoav, I edited your remarks about 3552 bis a bit to try to get at what I thought you were saying. Can you check and see if I have it right and otherwise send a correction? Thanks -Ekr Meeting started right on time - 15:20 Showed Note Well ; thanked Stephen Farrell Going through working group reports. Most had been sent to the list. Going through related working groups. Paul Hoffman talked for a bit about DPrive. Karen talked about NTP. Wendy sent a message to the list about W3C Hannes talked about the TEEP BoF. Half the room didn't understand what they were trying to do. Thinking about what to do next. Presentations: *** Hannes about "EEMBC IoT Security Benchmarks" Hannes's slides: https://www.ietf.org/proceedings/98/slides/slides-98-saag-eembc-iot-securit= y-benchmarks-00.pdf Even lightweight devices can do crypto. http://www.eembc.org/iot-secure/about.php *** David Mazieres "Internet Level Consensus is Practical" David's slides: https://www.ietf.org/proceedings/98/slides/slides-98-saag-internet-level-co= nsensus-ilc-01.pdf Note that there is an IETF mailing list for this subject: https://www.ietf.org/mailman/listinfo/ilc [slide 15] Ted Hardie: A node can select more than one slice? David: Yes, for redundancy. Ted: How can it get a super-set if there's more than one? David: Needs to be a super-set of one? Ted: Does is work if there's only one? David: Yes, but if one member of the slice is down, you can't get a quorum and thus no consensus. * Bar BoF tonight, 7:30pm=E2=80=939:00pm MCR: You talked about CAs and public knowledge. Financial transactions are not public knowledge. How is that handled? David: The log is public, but there are ways that people who don't know the transactions to not get this. It's on a different layer. Melinda Shore: This is a distributed computing problem more than security. We have a long history of kicking those down the road. Homenet, Trans are publishing consensus protocols. Christian Huitema: Sybil attack? (https://en.wikipedia.org/wiki/Sybil_attac= k) question about who is allowed to be on the tier of trusted nodes. David: decided by consensus. transitive trust. You might choose, e.g., 30 CAs + locally trusted org Kyle Rose: How do you converge if there is disagreement on timestamp David: You'll converge on a set of nominated values. Challenge depends on the usage. In markets, concerned about front-running, more of a concern than in software transparency Tim Sheppard: the problem of deciding who the roots of the CA us is solved? David: We'll have people decide for themselves. If there's enough overlap it will work. *** Sharon Goldberg on "Verifiable Random Function" Sharon's slides: https://www.ietf.org/proceedings/98/slides/slides-98-saag-verifiable-random= -functions-vrfs-00.pdf Ben Kaduk: Is there a way to verify that the hasher is not denying things in the data structure? Sharon: That is proved by the structure of the data structure itself. If something is absent the data structure will show it. The hasher cannot deny that something is present or absent. Richard Barnes: Trying to figure out what you can build on top of this. Are all VRFs of this form (hash + signature)? Sharon: (slide 17) - the signature is the proof. The signature needs to be deterministic, so you can't use ECDSA (which is non-deterministic). In EC-VRF we use the X coordinate of gamma for "hash". Phil???: Sharon: these are all VRFs in the ROM. Don't know what it says about post-quantum (?) Wes Hardaker: If I were able to collect a bunch of proofs over time, I could do dictionary attacks? Sharon: When you see a proof, you can verify it if works for an input. Wes: and it would be a strange protocol where I couldn't see the inputs but could see the proofs *** Phillip Hallam-Baker on "JSON implementation of Mesh/Remesh" PHB's slides: https://www.ietf.org/proceedings/98/slides/slides-98-saag-json-implementati= on-of-meshremesh-00.pdf (just one slide) (no questions) *** Open Mic Ingo Stieglitz : Thank you. You are all awesome. Is there any work here on ICMP NATing Kathleen: Recommend you ask in Ops Yoav Nir: A couple IETFs ago, started to discuss 3552bis, what should go into security considerations. I did a first transposition, called for comments, and got nothing. We shouldn't send the message that there's nothing to add since 2003 [by publishing a new unchanged document]. We need people to propose text and ideas. Hannes: We asked for update without knowing what the update would be. What is the target audience? What should the recommendation be? Yoav: 3552 and bis, target audience is people who write RFCs. Security Considerations sections target the same audiences as the RFCs themselves. Hannes: this isn't the way people write security considerations. they cut-and-paste from existing documents. Kathleen: At SecDir, not everyone is comfortable with privacy; we might do better on those reviews if we got more info into the bis. Paul Hoffman: One problem with the original document is its length: 40 pages. Mix of good examples, etc. but many people don't want to read that long. A shorter document would be better for doc authors. @@: speaking as an author in other WGs, the presence of Security Considerations section has caused us to take things out of documents; that the review doesn't pick thnigs up doesn't mean it hasn't helped. David Black: Example in Ops: appendix with a list of questions an ops reviewer should ask. Kathleen: How many people interested in an update? [about 20 hands]. Please discuss on SAAG list. And we're done (16:48) --94eb2c03380cd563a5054c069c8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here are the draft minutes (thanks to Yoav and Wendy). Yoa= v, I edited your remarks about 3552 bis a bit to try to get at what I thoug= ht you were saying. Can you check and see if I have it right and otherwise = send a correction?

Thanks
-Ekr


Meeting started right on time - 15:20
<= br>
Showed Note Well ; thanked Stephen Farrell

Going through working group reports. Most had been sent to the list.=

Going through related working groups.=C2=A0 Paul = Hoffman talked for a bit
about DPrive.=C2=A0 Karen talked about N= TP. Wendy sent a message to the
list about W3C

Hannes talked about the TEEP BoF. Half the room didn't understan= d what
they were trying to do. Thinking about what to do next.


Presentations:


*** Hannes about "EEMBC IoT Security Benchmarks"= ;
Even lightweight devices can do crypto.=C2=A0
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.eembc.org/iot-secure/about.php
=C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0

*** David Mazieres &quo= t;Internet Level Consensus is Practical"
Note that = there is an IETF mailing list for this subject: =C2=A0https://www.ietf.org/mailman/listinfo/ilc<= /a>
Ted: Does is work if there's only one?
David: Yes, but if one member of the slice is down, you can't g= et a quorum and thus no consensus.

* Bar BoF tonig= ht, 7:30pm=E2=80=939:00pm=C2=A0

MCR: You talked ab= out CAs and public knowledge. Financial transactions are not public knowled= ge. How is that handled?
David: The log is public, but there are = ways that people who don't know the transactions to not get this. It= 9;s on a different layer.
Melinda Shore: This is a distributed co= mputing problem more than security. We have a long history of kicking those= down the road. Homenet, Trans are publishing consensus protocols.=C2=A0
Christian Huitema: Sybil attack? (https://en.wikipedia.org/wiki/Sybil_attack) quest= ion about who is allowed to be on the tier of trusted nodes.
Davi= d: decided by consensus. transitive trust. You might choose, e.g., 30 CAs += locally trusted org
Kyle Rose: How do you converge if there is d= isagreement on timestamp
David: You'll converge on a set of n= ominated values. Challenge depends on the usage. In markets, concerned abou= t front-running, more of a concern than in software transparency
= Tim Sheppard: the problem of deciding who the roots of the CA us is solved?=
David: We'll have people decide for themselves. If there'= ;s enough overlap it will work.


***= Sharon Goldberg on "Verifiable Random Function"
*** Open Mic
Ingo Stieglitz : Thank you. You a= re all awesome. Is there any work here on ICMP NATing
Kathleen: R= ecommend you ask in Ops
Yoav Nir: A couple IETFs ago, started to = discuss 3552bis, what should go into security considerations. I did a first= transposition, called for comments, and got nothing. We shouldn't send= the message that there's nothing to add since 2003 [by publishing a ne= w unchanged document]. We need people to propose text and ideas.=C2=A0
Hannes: We asked for update without knowing what the update would be.= What is the target audience? What should the recommendation be?=C2=A0
Yoav: 3552 and bis, target audience is people who write RFCs. Securit= y Considerations sections target the same audiences as the RFCs themselves.= =C2=A0
Hannes: this isn't the way people write security consi= derations. they cut-and-paste from existing documents.=C2=A0
Kath= leen: At SecDir, not everyone is comfortable with privacy; we might do bett= er on those reviews if we got more info into the bis.=C2=A0
Paul = Hoffman: One problem with the original document is its length: 40 pages. Mi= x of good examples, etc. but many people don't want to read that long. = A shorter document would be better for doc authors.=C2=A0
@@: spe= aking as an author in other WGs, the presence of Security Considerations se= ction has caused us to take things out of documents; that the review doesn&= #39;t pick thnigs up doesn't mean it hasn't helped.
David= Black: Example in Ops: appendix with a list of questions an ops reviewer s= hould ask.
Kathleen: How many people interested in an update? [ab= out 20 hands]. Please discuss on SAAG list.=C2=A0

= And we're done (16:48)
--94eb2c03380cd563a5054c069c8c-- From nobody Fri Mar 31 06:19:51 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6121294F4 for ; Fri, 31 Mar 2017 06:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ouGZ384iLD1X for ; Fri, 31 Mar 2017 06:19:47 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 4750512954A for ; Fri, 31 Mar 2017 06:19:46 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id 81so71214002pgh.2 for ; Fri, 31 Mar 2017 06:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=xR1VV6bd9m8N0iWVavMc4Yg/GUzmWS//Yd4isgRQN8s=; b=FzGLZjk08dBV/WEXbbyCTnyY/TnbUEY70T9gmP/jnpi47Ni60xqhhqkUdCn0pHu60L Jt87TIBITfA7vzUusAQJ9k33CW3jnHA8s2N60ULRhYY8CV3p3LkP3aVrm1XoqUmuTwQ9 jXzDrj4LYdO26uHOW2PSvkbYhIjBDUEbvgx4LvXiOJ7nEusf6LE3jgiZlEzGTPUptG4M it3MBPmMu0yGSaQ4PjUSVQqWP3M+36Lj4tKgQ3Zxi1NItwp4zy1noiUMmKb5GARN08h/ hvkwA8JLWfHdim/HxfVIS0SytkPi6A+K89qB51ptkMhbIfX8E+NTL/zm2DEMK8MT2h8A fKIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=xR1VV6bd9m8N0iWVavMc4Yg/GUzmWS//Yd4isgRQN8s=; b=NcREY/Ejk52QaPQQMo6PaaoTGi90KLhwh8wETXkDoTFWaMJCMzxFzCk/OBGsK61gyE sSqR1WwmDQAQXe+b8HxLo7oXCRONO8hpT0mDbFqlvf/nGcokdh43VfzgCjIe0PZHj3Dz rA73ESoRbi6SnwPBzCkv9gWxNPmcIYyvWqt7lG69IMegYlUMSIpIkHsb392yADRFcBi4 WUEb4f6feE8zTOtBoF9pGeZUrMx0aZXLXLRdneAy4wlNmIyISjpWY9vmyfzNCxu0VB6a v5i7lEtKfs+tn+UG6EppEv+vGK2Lfv0uNL8i3WTi74UZZsWqSEg+jgjZkB7fPdVxRwd0 E8HQ== X-Gm-Message-State: AFeK/H0uOxE1EDdf8KDPam0zlYYi1cNaqQAhrMoZKmwZGbVOLIL/bSFMZgDI2rHxllWo06bfXMZh4xortlGuJg== X-Received: by 10.98.105.134 with SMTP id e128mr2820909pfc.19.1490966385917; Fri, 31 Mar 2017 06:19:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.141 with HTTP; Fri, 31 Mar 2017 06:19:05 -0700 (PDT) From: Kathleen Moriarty Date: Fri, 31 Mar 2017 09:19:05 -0400 Message-ID: To: "Black, David" Cc: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [saag] RFC3552-bis was Re: OPS review checklist X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 13:19:49 -0000 Thank you, David & Hannes. This could be helpful assuming we get good momentum around an update or new draft. Kathleen On Thu, Mar 30, 2017 at 6:04 PM, Black, David wrote: > The operations and management (OPS Area) review checklist that I mentione= d during discussion of updating RFC 3552 (Guidelines for Writing RFC Text o= n Security Considerations) can be found in Appendix A of RFC 5706: https://= datatracker.ietf.org/doc/html/rfc5706#appendix-A > > Thanks, --David > (with credit to Hannes for prompting me to go find this and send out the = pointer). > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --=20 Best regards, Kathleen From nobody Fri Mar 31 07:15:15 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A64E129471 for ; Fri, 31 Mar 2017 07:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Yujpp5qfOjhc for ; Fri, 31 Mar 2017 07:15:12 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0331296AA for ; Fri, 31 Mar 2017 07:15:12 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3E37C200A3; Fri, 31 Mar 2017 10:39:13 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 90841636BB; Fri, 31 Mar 2017 10:15:11 -0400 (EDT) From: Michael Richardson To: saag X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [saag] Internet Level Consensus and VRF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 14:15:14 -0000 --=-=-= Content-Type: text/plain At the mic, yesterday, I asked if the financial uses of ILC could in fact keep the identities of the parties, and the details of the transaction confidential, while still permitting verification by third parties. The use of pseudonyms has been the bitcoin answer, and I've never really been happy with that. This morning it occured to while dragging my suitcase along Michigan Avenue, that I think VRFs could be used to mask the identities, and perhaps even the amounts. At the least, a given transaction could select a particular hasher for all identities. Perhaps the amount of the transaction could also be put through a VRF. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljeZG8ACgkQgItw+93Q 3WUSsAgAvcAssWYSXAP1bw9OllSMR5lwIDVz6umMZzpwVigdAHbNZsahY8+dOiv0 1AmaMGdiWmPau/EyV4phw3iyrceeYzEZZTDKVkVJaKd4Um/L90ao/5VaQiDR47f5 R55g4hu2RYzNCQmbF6BW5Duu/3HPdobUWJxFcYcYWSXPDJcB4LArCu8soywoLO2W dGa3mBovOQIslIQyfTiSrOOzjg3Yjhnj2PaGjnI9pzSS/20hub59ei3WyGtoM2YR MakEKBtQFDHULsX0vN+UlJyycBlaaGBSI4i0yG6+hiRUjFdW6O/cMJLuMDEMIlAu Yey8nPSvpYswHPs40N6A0Lkap7dxvQ== =iQ8W -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 31 08:39:43 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C75D12995F for ; Fri, 31 Mar 2017 08:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=WKy9E3mu; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=rBiB8+i9 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 ZRNEDdiWORxW for ; Fri, 31 Mar 2017 08:39:24 -0700 (PDT) Received: from esa7.dell-outbound.iphmx.com (esa7.dell-outbound.iphmx.com [68.232.153.96]) (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 416911294DF for ; Fri, 31 Mar 2017 08:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1490974196; x=1522510196; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=sGgUl3CZ2Opv5dYVvkGLWuegYokzJSMvEfsJiahLoI8=; b=WKy9E3musiiQZ2K8n1zbXTsz6MKztWf1L4l/cvdKD2J6Y5v99CclJwO8 zSjNZQUB4bKL7xEFCOI7rhVzeYXJ4czCoEDHDCtc9l9eNO8o9jHAaTNgk hFQn6Sqdpl7rpKRmITB9BElWtU3Vnh4Cmb/QpSiVdrlWvyBb1w15KtCJm U=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa7.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Mar 2017 10:29:56 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Mar 2017 21:37:11 +0600 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v2VFdKB6032346 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 31 Mar 2017 11:39:22 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com v2VFdKB6032346 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1490974762; bh=RCj0TmnVdgh3KxhhizR8AzJRk3Q=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=rBiB8+i95RZo6/jmBm9kfi0x4ozneN+ZLNQgDSeZG00+trXVdHBScHesvlHXPJ6fy WrEZFPzTZwmUB44yFBuEbHZxE3BsUk0QzonklN9k8Hc82CFl/78ilCjbXHN+PGOx2G onHasSy3CHh6+sY1pnAYMWiCvl3FOTv+IFHjXF/8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com v2VFdKB6032346 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd01.lss.emc.com (RSA Interceptor); Fri, 31 Mar 2017 11:38:58 -0400 Received: from MXHUB309.corp.emc.com (MXHUB309.corp.emc.com [10.146.3.35]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v2VFd5Z7007981 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Fri, 31 Mar 2017 11:39:06 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB309.corp.emc.com ([10.146.3.35]) with mapi id 14.03.0266.001; Fri, 31 Mar 2017 11:39:05 -0400 To: Eric Rescorla , "saag@ietf.org" Thread-Topic: [saag] Draft minutes Thread-Index: AQHSqiEJwIUbt58B+0KscWNhoNGv6aGvFAfw Date: Fri, 31 Mar 2017 15:39:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362F98C6C8MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [saag] Draft minutes X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 15:39:27 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362F98C6C8MX307CL04corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBAQDogc3BlYWtpbmcgYXMgYW4gYXV0aG9yIGluIG90aGVyIFdHcywgdGhlIHByZXNlbmNlIG9m IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gaGFzIGNhdXNlZCB1cyB0byB0YWtlIHRo aW5ncyBvdXQgb2YgZG9jdW1lbnRzOw0KPiB0aGF0IHRoZSByZXZpZXcgZG9lc24ndCBwaWNrIHRo bmlncyB1cCBkb2Vzbid0IG1lYW4gaXQgaGFzbid0IGhlbHBlZC4NCg0K4oCcQEDigJ0gd2FzIE1h dHQgTWF0aGlzLg0KDQo+IERhdmlkIEJsYWNrOiBFeGFtcGxlIGluIE9wczogYXBwZW5kaXggd2l0 aCBhIGxpc3Qgb2YgcXVlc3Rpb25zIGFuIG9wcyByZXZpZXdlciBzaG91bGQgYXNrLg0KDQpJdCB3 b3VsZCBiZSBoZWxwZnVsIGZvciB0aGUgbWludXRlcyB0byBub3RlIHRoYXQgdGhpcyBpcyBBcHBl bmRpeCBBIG9mIFJGQyA1NzA2IChhcyBpbmRpY2F0ZWQgaW4gc3Vic2VxdWVudCBlbWFpbCB0byB0 aGUgbGlzdCkuDQoNClRoYW5rcywgLS1EYXZpZA0KDQpGcm9tOiBzYWFnIFttYWlsdG86c2FhZy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogRnJpZGF5 LCBNYXJjaCAzMSwgMjAxNyA5OjE1IEFNDQpUbzogc2FhZ0BpZXRmLm9yZw0KU3ViamVjdDogW3Nh YWddIERyYWZ0IG1pbnV0ZXMNCg0KSGVyZSBhcmUgdGhlIGRyYWZ0IG1pbnV0ZXMgKHRoYW5rcyB0 byBZb2F2IGFuZCBXZW5keSkuIFlvYXYsIEkgZWRpdGVkIHlvdXIgcmVtYXJrcyBhYm91dCAzNTUy IGJpcyBhIGJpdCB0byB0cnkgdG8gZ2V0IGF0IHdoYXQgSSB0aG91Z2h0IHlvdSB3ZXJlIHNheWlu Zy4gQ2FuIHlvdSBjaGVjayBhbmQgc2VlIGlmIEkgaGF2ZSBpdCByaWdodCBhbmQgb3RoZXJ3aXNl IHNlbmQgYSBjb3JyZWN0aW9uPw0KDQpUaGFua3MNCi1Fa3INCg0KDQpNZWV0aW5nIHN0YXJ0ZWQg cmlnaHQgb24gdGltZSAtIDE1OjIwDQoNClNob3dlZCBOb3RlIFdlbGwgOyB0aGFua2VkIFN0ZXBo ZW4gRmFycmVsbA0KDQpHb2luZyB0aHJvdWdoIHdvcmtpbmcgZ3JvdXAgcmVwb3J0cy4gTW9zdCBo YWQgYmVlbiBzZW50IHRvIHRoZSBsaXN0Lg0KDQpHb2luZyB0aHJvdWdoIHJlbGF0ZWQgd29ya2lu ZyBncm91cHMuICBQYXVsIEhvZmZtYW4gdGFsa2VkIGZvciBhIGJpdA0KYWJvdXQgRFByaXZlLiAg S2FyZW4gdGFsa2VkIGFib3V0IE5UUC4gV2VuZHkgc2VudCBhIG1lc3NhZ2UgdG8gdGhlDQpsaXN0 IGFib3V0IFczQw0KDQpIYW5uZXMgdGFsa2VkIGFib3V0IHRoZSBURUVQIEJvRi4gSGFsZiB0aGUg cm9vbSBkaWRuJ3QgdW5kZXJzdGFuZCB3aGF0DQp0aGV5IHdlcmUgdHJ5aW5nIHRvIGRvLiBUaGlu a2luZyBhYm91dCB3aGF0IHRvIGRvIG5leHQuDQoNCg0KUHJlc2VudGF0aW9uczoNCg0KDQoqKiog SGFubmVzIGFib3V0ICJFRU1CQyBJb1QgU2VjdXJpdHkgQmVuY2htYXJrcyINCkhhbm5lcydzIHNs aWRlczogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVzL3NsaWRlcy05 OC1zYWFnLWVlbWJjLWlvdC1zZWN1cml0eS1iZW5jaG1hcmtzLTAwLnBkZg0KRXZlbiBsaWdodHdl aWdodCBkZXZpY2VzIGNhbiBkbyBjcnlwdG8uDQogICAgICAgIGh0dHA6Ly93d3cuZWVtYmMub3Jn L2lvdC1zZWN1cmUvYWJvdXQucGhwDQoNCg0KKioqIERhdmlkIE1hemllcmVzICJJbnRlcm5ldCBM ZXZlbCBDb25zZW5zdXMgaXMgUHJhY3RpY2FsIg0KRGF2aWQncyBzbGlkZXM6IGh0dHBzOi8vd3d3 LmlldGYub3JnL3Byb2NlZWRpbmdzLzk4L3NsaWRlcy9zbGlkZXMtOTgtc2FhZy1pbnRlcm5ldC1s ZXZlbC1jb25zZW5zdXMtaWxjLTAxLnBkZg0KTm90ZSB0aGF0IHRoZXJlIGlzIGFuIElFVEYgbWFp bGluZyBsaXN0IGZvciB0aGlzIHN1YmplY3Q6ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lsYw0KW3NsaWRlIDE1XQ0KVGVkIEhhcmRpZTogQSBub2RlIGNhbiBzZWxlY3Qg bW9yZSB0aGFuIG9uZSBzbGljZT8NCkRhdmlkOiBZZXMsIGZvciByZWR1bmRhbmN5Lg0KVGVkOiBI b3cgY2FuIGl0IGdldCBhIHN1cGVyLXNldCBpZiB0aGVyZSdzIG1vcmUgdGhhbiBvbmU/DQpEYXZp ZDogTmVlZHMgdG8gYmUgYSBzdXBlci1zZXQgb2Ygb25lPw0KVGVkOiBEb2VzIGlzIHdvcmsgaWYg dGhlcmUncyBvbmx5IG9uZT8NCkRhdmlkOiBZZXMsIGJ1dCBpZiBvbmUgbWVtYmVyIG9mIHRoZSBz bGljZSBpcyBkb3duLCB5b3UgY2FuJ3QgZ2V0IGEgcXVvcnVtIGFuZCB0aHVzIG5vIGNvbnNlbnN1 cy4NCg0KKiBCYXIgQm9GIHRvbmlnaHQsIDc6MzBwbeKAkzk6MDBwbQ0KDQpNQ1I6IFlvdSB0YWxr ZWQgYWJvdXQgQ0FzIGFuZCBwdWJsaWMga25vd2xlZGdlLiBGaW5hbmNpYWwgdHJhbnNhY3Rpb25z IGFyZSBub3QgcHVibGljIGtub3dsZWRnZS4gSG93IGlzIHRoYXQgaGFuZGxlZD8NCkRhdmlkOiBU aGUgbG9nIGlzIHB1YmxpYywgYnV0IHRoZXJlIGFyZSB3YXlzIHRoYXQgcGVvcGxlIHdobyBkb24n dCBrbm93IHRoZSB0cmFuc2FjdGlvbnMgdG8gbm90IGdldCB0aGlzLiBJdCdzIG9uIGEgZGlmZmVy ZW50IGxheWVyLg0KTWVsaW5kYSBTaG9yZTogVGhpcyBpcyBhIGRpc3RyaWJ1dGVkIGNvbXB1dGlu ZyBwcm9ibGVtIG1vcmUgdGhhbiBzZWN1cml0eS4gV2UgaGF2ZSBhIGxvbmcgaGlzdG9yeSBvZiBr aWNraW5nIHRob3NlIGRvd24gdGhlIHJvYWQuIEhvbWVuZXQsIFRyYW5zIGFyZSBwdWJsaXNoaW5n IGNvbnNlbnN1cyBwcm90b2NvbHMuDQpDaHJpc3RpYW4gSHVpdGVtYTogU3liaWwgYXR0YWNrPyAo aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvU3liaWxfYXR0YWNrKSBxdWVzdGlvbiBhYm91 dCB3aG8gaXMgYWxsb3dlZCB0byBiZSBvbiB0aGUgdGllciBvZiB0cnVzdGVkIG5vZGVzLg0KRGF2 aWQ6IGRlY2lkZWQgYnkgY29uc2Vuc3VzLiB0cmFuc2l0aXZlIHRydXN0LiBZb3UgbWlnaHQgY2hv b3NlLCBlLmcuLCAzMCBDQXMgKyBsb2NhbGx5IHRydXN0ZWQgb3JnDQpLeWxlIFJvc2U6IEhvdyBk byB5b3UgY29udmVyZ2UgaWYgdGhlcmUgaXMgZGlzYWdyZWVtZW50IG9uIHRpbWVzdGFtcA0KRGF2 aWQ6IFlvdSdsbCBjb252ZXJnZSBvbiBhIHNldCBvZiBub21pbmF0ZWQgdmFsdWVzLiBDaGFsbGVu Z2UgZGVwZW5kcyBvbiB0aGUgdXNhZ2UuIEluIG1hcmtldHMsIGNvbmNlcm5lZCBhYm91dCBmcm9u dC1ydW5uaW5nLCBtb3JlIG9mIGEgY29uY2VybiB0aGFuIGluIHNvZnR3YXJlIHRyYW5zcGFyZW5j eQ0KVGltIFNoZXBwYXJkOiB0aGUgcHJvYmxlbSBvZiBkZWNpZGluZyB3aG8gdGhlIHJvb3RzIG9m IHRoZSBDQSB1cyBpcyBzb2x2ZWQ/DQpEYXZpZDogV2UnbGwgaGF2ZSBwZW9wbGUgZGVjaWRlIGZv ciB0aGVtc2VsdmVzLiBJZiB0aGVyZSdzIGVub3VnaCBvdmVybGFwIGl0IHdpbGwgd29yay4NCg0K DQoqKiogU2hhcm9uIEdvbGRiZXJnIG9uICJWZXJpZmlhYmxlIFJhbmRvbSBGdW5jdGlvbiINClNo YXJvbidzIHNsaWRlczogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVz L3NsaWRlcy05OC1zYWFnLXZlcmlmaWFibGUtcmFuZG9tLWZ1bmN0aW9ucy12cmZzLTAwLnBkZg0K QmVuIEthZHVrOiBJcyB0aGVyZSBhIHdheSB0byB2ZXJpZnkgdGhhdCB0aGUgaGFzaGVyIGlzIG5v dCBkZW55aW5nIHRoaW5ncyBpbiB0aGUgZGF0YSBzdHJ1Y3R1cmU/DQpTaGFyb246IFRoYXQgaXMg cHJvdmVkIGJ5IHRoZSBzdHJ1Y3R1cmUgb2YgdGhlIGRhdGEgc3RydWN0dXJlIGl0c2VsZi4gSWYg c29tZXRoaW5nIGlzIGFic2VudCB0aGUgZGF0YSBzdHJ1Y3R1cmUgd2lsbCBzaG93IGl0LiBUaGUg aGFzaGVyIGNhbm5vdCBkZW55IHRoYXQgc29tZXRoaW5nIGlzIHByZXNlbnQgb3IgYWJzZW50Lg0K UmljaGFyZCBCYXJuZXM6IFRyeWluZyB0byBmaWd1cmUgb3V0IHdoYXQgeW91IGNhbiBidWlsZCBv biB0b3Agb2YgdGhpcy4gQXJlIGFsbCBWUkZzIG9mIHRoaXMgZm9ybSAoaGFzaCArIHNpZ25hdHVy ZSk/DQpTaGFyb246IChzbGlkZSAxNykgLSB0aGUgc2lnbmF0dXJlIGlzIHRoZSBwcm9vZi4gVGhl IHNpZ25hdHVyZSBuZWVkcyB0byBiZSBkZXRlcm1pbmlzdGljLCBzbyB5b3UgY2FuJ3QgdXNlIEVD RFNBICh3aGljaCBpcyBub24tZGV0ZXJtaW5pc3RpYykuIEluIEVDLVZSRiB3ZSB1c2UgdGhlIFgg Y29vcmRpbmF0ZSBvZiBnYW1tYSBmb3IgImhhc2giLg0KUGhpbD8/PzoNClNoYXJvbjogdGhlc2Ug YXJlIGFsbCBWUkZzIGluIHRoZSBST00uIERvbid0IGtub3cgd2hhdCBpdCBzYXlzIGFib3V0IHBv c3QtcXVhbnR1bSAoPykNCldlcyBIYXJkYWtlcjogSWYgSSB3ZXJlIGFibGUgdG8gY29sbGVjdCBh IGJ1bmNoIG9mIHByb29mcyBvdmVyIHRpbWUsIEkgY291bGQgZG8gZGljdGlvbmFyeSBhdHRhY2tz Pw0KU2hhcm9uOiBXaGVuIHlvdSBzZWUgYSBwcm9vZiwgeW91IGNhbiB2ZXJpZnkgaXQgaWYgd29y a3MgZm9yIGFuIGlucHV0Lg0KV2VzOiBhbmQgaXQgd291bGQgYmUgYSBzdHJhbmdlIHByb3RvY29s IHdoZXJlIEkgY291bGRuJ3Qgc2VlIHRoZSBpbnB1dHMgYnV0IGNvdWxkIHNlZSB0aGUgcHJvb2Zz DQoNCioqKiBQaGlsbGlwIEhhbGxhbS1CYWtlciBvbiAiSlNPTiBpbXBsZW1lbnRhdGlvbiBvZiBN ZXNoL1JlbWVzaCINClBIQidzIHNsaWRlczogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGlu Z3MvOTgvc2xpZGVzL3NsaWRlcy05OC1zYWFnLWpzb24taW1wbGVtZW50YXRpb24tb2YtbWVzaHJl bWVzaC0wMC5wZGYgIChqdXN0IG9uZSBzbGlkZSkNCihubyBxdWVzdGlvbnMpDQoNCg0KKioqIE9w ZW4gTWljDQpJbmdvIFN0aWVnbGl0eiA6IFRoYW5rIHlvdS4gWW91IGFyZSBhbGwgYXdlc29tZS4g SXMgdGhlcmUgYW55IHdvcmsgaGVyZSBvbiBJQ01QIE5BVGluZw0KS2F0aGxlZW46IFJlY29tbWVu ZCB5b3UgYXNrIGluIE9wcw0KWW9hdiBOaXI6IEEgY291cGxlIElFVEZzIGFnbywgc3RhcnRlZCB0 byBkaXNjdXNzIDM1NTJiaXMsIHdoYXQgc2hvdWxkIGdvIGludG8gc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMuIEkgZGlkIGEgZmlyc3QgdHJhbnNwb3NpdGlvbiwgY2FsbGVkIGZvciBjb21tZW50cywg YW5kIGdvdCBub3RoaW5nLiBXZSBzaG91bGRuJ3Qgc2VuZCB0aGUgbWVzc2FnZSB0aGF0IHRoZXJl J3Mgbm90aGluZyB0byBhZGQgc2luY2UgMjAwMyBbYnkgcHVibGlzaGluZyBhIG5ldyB1bmNoYW5n ZWQgZG9jdW1lbnRdLiBXZSBuZWVkIHBlb3BsZSB0byBwcm9wb3NlIHRleHQgYW5kIGlkZWFzLg0K SGFubmVzOiBXZSBhc2tlZCBmb3IgdXBkYXRlIHdpdGhvdXQga25vd2luZyB3aGF0IHRoZSB1cGRh dGUgd291bGQgYmUuIFdoYXQgaXMgdGhlIHRhcmdldCBhdWRpZW5jZT8gV2hhdCBzaG91bGQgdGhl IHJlY29tbWVuZGF0aW9uIGJlPw0KWW9hdjogMzU1MiBhbmQgYmlzLCB0YXJnZXQgYXVkaWVuY2Ug aXMgcGVvcGxlIHdobyB3cml0ZSBSRkNzLiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9u cyB0YXJnZXQgdGhlIHNhbWUgYXVkaWVuY2VzIGFzIHRoZSBSRkNzIHRoZW1zZWx2ZXMuDQpIYW5u ZXM6IHRoaXMgaXNuJ3QgdGhlIHdheSBwZW9wbGUgd3JpdGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMuIHRoZXkgY3V0LWFuZC1wYXN0ZSBmcm9tIGV4aXN0aW5nIGRvY3VtZW50cy4NCkthdGhsZWVu OiBBdCBTZWNEaXIsIG5vdCBldmVyeW9uZSBpcyBjb21mb3J0YWJsZSB3aXRoIHByaXZhY3k7IHdl IG1pZ2h0IGRvIGJldHRlciBvbiB0aG9zZSByZXZpZXdzIGlmIHdlIGdvdCBtb3JlIGluZm8gaW50 byB0aGUgYmlzLg0KUGF1bCBIb2ZmbWFuOiBPbmUgcHJvYmxlbSB3aXRoIHRoZSBvcmlnaW5hbCBk b2N1bWVudCBpcyBpdHMgbGVuZ3RoOiA0MCBwYWdlcy4gTWl4IG9mIGdvb2QgZXhhbXBsZXMsIGV0 Yy4gYnV0IG1hbnkgcGVvcGxlIGRvbid0IHdhbnQgdG8gcmVhZCB0aGF0IGxvbmcuIEEgc2hvcnRl ciBkb2N1bWVudCB3b3VsZCBiZSBiZXR0ZXIgZm9yIGRvYyBhdXRob3JzLg0KQEA6IHNwZWFraW5n IGFzIGFuIGF1dGhvciBpbiBvdGhlciBXR3MsIHRoZSBwcmVzZW5jZSBvZiBTZWN1cml0eSBDb25z aWRlcmF0aW9ucyBzZWN0aW9uIGhhcyBjYXVzZWQgdXMgdG8gdGFrZSB0aGluZ3Mgb3V0IG9mIGRv Y3VtZW50czsgdGhhdCB0aGUgcmV2aWV3IGRvZXNuJ3QgcGljayB0aG5pZ3MgdXAgZG9lc24ndCBt ZWFuIGl0IGhhc24ndCBoZWxwZWQuDQpEYXZpZCBCbGFjazogRXhhbXBsZSBpbiBPcHM6IGFwcGVu ZGl4IHdpdGggYSBsaXN0IG9mIHF1ZXN0aW9ucyBhbiBvcHMgcmV2aWV3ZXIgc2hvdWxkIGFzay4N CkthdGhsZWVuOiBIb3cgbWFueSBwZW9wbGUgaW50ZXJlc3RlZCBpbiBhbiB1cGRhdGU/IFthYm91 dCAyMCBoYW5kc10uIFBsZWFzZSBkaXNjdXNzIG9uIFNBQUcgbGlzdC4NCg0KQW5kIHdlJ3JlIGRv bmUgKDE2OjQ4KQ0K --_000_CE03DB3D7B45C245BCA0D243277949362F98C6C8MX307CL04corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0 eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jmd0Ow0KPC9zcGFuPkBAOiBzcGVha2luZyBhcyBhbiBhdXRob3IgaW4gb3RoZXIgV0dzLCB0aGUg cHJlc2VuY2Ugb2YgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBoYXMgY2F1c2VkIHVz IHRvIHRha2UgdGhpbmdzIG91dCBvZiBkb2N1bWVudHM7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mZ3Q7IHRoYXQgdGhlIHJldmlldyBkb2Vzbid0IHBpY2sgdGhuaWdzIHVw IGRvZXNuJ3QgbWVhbiBpdCBoYXNuJ3QgaGVscGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJxAQOKAnSB3YXMgTWF0dCBNYXRo aXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mZ3Q7DQo8L3NwYW4+RGF2aWQgQmxhY2s6IEV4YW1wbGUgaW4gT3BzOiBh cHBlbmRpeCB3aXRoIGEgbGlzdCBvZiBxdWVzdGlvbnMgYW4gb3BzIHJldmlld2VyIHNob3VsZCBh c2suPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkl0IHdvdWxkIGJlIGhlbHBmdWwgZm9yIHRoZSBtaW51dGVzIHRvIG5vdGUgdGhhdCB0 aGlzIGlzIEFwcGVuZGl4IEEgb2YgUkZDIDU3MDYgKGFzIGluZGljYXRlZCBpbiBzdWJzZXF1ZW50 IGVtYWlsIHRvIHRoZSBsaXN0KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcywgLS1EYXZpZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzYWFnIFttYWlsdG86c2FhZy1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+ U2VudDo8L2I+IEZyaWRheSwgTWFyY2ggMzEsIDIwMTcgOToxNSBBTTxicj4NCjxiPlRvOjwvYj4g c2FhZ0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbc2FhZ10gRHJhZnQgbWludXRlczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJl IGFyZSB0aGUgZHJhZnQgbWludXRlcyAodGhhbmtzIHRvIFlvYXYgYW5kIFdlbmR5KS4gWW9hdiwg SSBlZGl0ZWQgeW91ciByZW1hcmtzIGFib3V0IDM1NTIgYmlzIGEgYml0IHRvIHRyeSB0byBnZXQg YXQgd2hhdCBJIHRob3VnaHQgeW91IHdlcmUgc2F5aW5nLiBDYW4geW91IGNoZWNrIGFuZCBzZWUg aWYgSSBoYXZlIGl0IHJpZ2h0IGFuZCBvdGhlcndpc2Ugc2VuZCBhIGNvcnJlY3Rpb24/PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3M8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NZWV0aW5nIHN0YXJ0ZWQgcmln aHQgb24gdGltZSAtIDE1OjIwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNob3dlZCBOb3RlIFdlbGwgOyB0aGFua2VkIFN0ZXBoZW4gRmFycmVs bDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5H b2luZyB0aHJvdWdoIHdvcmtpbmcgZ3JvdXAgcmVwb3J0cy4gTW9zdCBoYWQgYmVlbiBzZW50IHRv IHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Hb2luZyB0aHJvdWdoIHJlbGF0ZWQgd29ya2luZyBncm91cHMuJm5ic3A7IFBhdWwg SG9mZm1hbiB0YWxrZWQgZm9yIGEgYml0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5hYm91dCBEUHJpdmUuJm5ic3A7IEthcmVuIHRhbGtlZCBhYm91 dCBOVFAuIFdlbmR5IHNlbnQgYSBtZXNzYWdlIHRvIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bGlzdCBhYm91dCBXM0M8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFubmVzIHRhbGtlZCBh Ym91dCB0aGUgVEVFUCBCb0YuIEhhbGYgdGhlIHJvb20gZGlkbid0IHVuZGVyc3RhbmQgd2hhdDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhleSB3 ZXJlIHRyeWluZyB0byBkby4gVGhpbmtpbmcgYWJvdXQgd2hhdCB0byBkbyBuZXh0LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlByZXNlbnRh dGlvbnM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+KioqIEhhbm5lcyBhYm91dCAmcXVvdDtFRU1CQyBJb1QgU2VjdXJpdHkgQmVuY2htYXJr cyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGFubmVzJ3Mgc2xpZGVzOiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVk aW5ncy85OC9zbGlkZXMvc2xpZGVzLTk4LXNhYWctZWVtYmMtaW90LXNlY3VyaXR5LWJlbmNobWFy a3MtMDAucGRmIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk4L3NsaWRlcy9z bGlkZXMtOTgtc2FhZy1lZW1iYy1pb3Qtc2VjdXJpdHktYmVuY2htYXJrcy0wMC5wZGY8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FdmVuIGxp Z2h0d2VpZ2h0IGRldmljZXMgY2FuIGRvIGNyeXB0by4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LmVlbWJjLm9yZy9pb3Qtc2VjdXJlL2Fib3V0LnBocCI+ DQpodHRwOi8vd3d3LmVlbWJjLm9yZy9pb3Qtc2VjdXJlL2Fib3V0LnBocDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4qKiogRGF2aWQgTWF6aWVyZXMgJnF1b3Q7SW50ZXJuZXQgTGV2ZWwg Q29uc2Vuc3VzIGlzIFByYWN0aWNhbCZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGF2aWQncyBzbGlkZXM6IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk4L3NsaWRlcy9zbGlkZXMtOTgtc2FhZy1pbnRlcm5l dC1sZXZlbC1jb25zZW5zdXMtaWxjLTAxLnBkZiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9j ZWVkaW5ncy85OC9zbGlkZXMvc2xpZGVzLTk4LXNhYWctaW50ZXJuZXQtbGV2ZWwtY29uc2Vuc3Vz LWlsYy0wMS5wZGY8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Ob3RlIHRoYXQgdGhlcmUgaXMgYW4gSUVURiBtYWlsaW5nIGxpc3QgZm9yIHRo aXMgc3ViamVjdDogJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pbGMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWxjPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W3Ns aWRlIDE1XTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGVkIEhhcmRpZTogQSBub2RlIGNhbiBzZWxlY3QgbW9yZSB0aGFuIG9uZSBzbGljZT88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdmlkOiBZ ZXMsIGZvciByZWR1bmRhbmN5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGVkOiBIb3cgY2FuIGl0IGdldCBhIHN1cGVyLXNldCBpZiB0aGVyZSdz IG1vcmUgdGhhbiBvbmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5EYXZpZDogTmVlZHMgdG8gYmUgYSBzdXBlci1zZXQgb2Ygb25lPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGVkOiBEb2VzIGlz IHdvcmsgaWYgdGhlcmUncyBvbmx5IG9uZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdmlkOiBZZXMsIGJ1dCBpZiBvbmUgbWVtYmVyIG9mIHRo ZSBzbGljZSBpcyBkb3duLCB5b3UgY2FuJ3QgZ2V0IGEgcXVvcnVtIGFuZCB0aHVzIG5vIGNvbnNl bnN1cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+KiBCYXIgQm9GIHRvbmlnaHQsIDc6MzBwbeKAkzk6MDBwbSZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NQ1I6IFlvdSB0YWxrZWQg YWJvdXQgQ0FzIGFuZCBwdWJsaWMga25vd2xlZGdlLiBGaW5hbmNpYWwgdHJhbnNhY3Rpb25zIGFy ZSBub3QgcHVibGljIGtub3dsZWRnZS4gSG93IGlzIHRoYXQgaGFuZGxlZD88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdmlkOiBUaGUgbG9nIGlz IHB1YmxpYywgYnV0IHRoZXJlIGFyZSB3YXlzIHRoYXQgcGVvcGxlIHdobyBkb24ndCBrbm93IHRo ZSB0cmFuc2FjdGlvbnMgdG8gbm90IGdldCB0aGlzLiBJdCdzIG9uIGEgZGlmZmVyZW50IGxheWVy LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWVs aW5kYSBTaG9yZTogVGhpcyBpcyBhIGRpc3RyaWJ1dGVkIGNvbXB1dGluZyBwcm9ibGVtIG1vcmUg dGhhbiBzZWN1cml0eS4gV2UgaGF2ZSBhIGxvbmcgaGlzdG9yeSBvZiBraWNraW5nIHRob3NlIGRv d24gdGhlIHJvYWQuIEhvbWVuZXQsIFRyYW5zIGFyZSBwdWJsaXNoaW5nIGNvbnNlbnN1cyBwcm90 b2NvbHMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5DaHJpc3RpYW4gSHVpdGVtYTogU3liaWwgYXR0YWNrPyAoPGEgaHJlZj0iaHR0cHM6 Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvU3liaWxfYXR0YWNrIj5odHRwczovL2VuLndpa2lwZWRp YS5vcmcvd2lraS9TeWJpbF9hdHRhY2s8L2E+KSBxdWVzdGlvbiBhYm91dCB3aG8gaXMgYWxsb3dl ZCB0byBiZSBvbiB0aGUgdGllciBvZiB0cnVzdGVkIG5vZGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGF2aWQ6IGRlY2lkZWQgYnkgY29uc2Vu c3VzLiB0cmFuc2l0aXZlIHRydXN0LiBZb3UgbWlnaHQgY2hvb3NlLCBlLmcuLCAzMCBDQXMgJiM0 MzsgbG9jYWxseSB0cnVzdGVkIG9yZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+S3lsZSBSb3NlOiBIb3cgZG8geW91IGNvbnZlcmdlIGlmIHRoZXJl IGlzIGRpc2FncmVlbWVudCBvbiB0aW1lc3RhbXA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdmlkOiBZb3UnbGwgY29udmVyZ2Ugb24gYSBzZXQg b2Ygbm9taW5hdGVkIHZhbHVlcy4gQ2hhbGxlbmdlIGRlcGVuZHMgb24gdGhlIHVzYWdlLiBJbiBt YXJrZXRzLCBjb25jZXJuZWQgYWJvdXQgZnJvbnQtcnVubmluZywgbW9yZSBvZiBhIGNvbmNlcm4g dGhhbiBpbiBzb2Z0d2FyZSB0cmFuc3BhcmVuY3k8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRpbSBTaGVwcGFyZDogdGhlIHByb2JsZW0gb2YgZGVj aWRpbmcgd2hvIHRoZSByb290cyBvZiB0aGUgQ0EgdXMgaXMgc29sdmVkPzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGF2aWQ6IFdlJ2xsIGhhdmUg cGVvcGxlIGRlY2lkZSBmb3IgdGhlbXNlbHZlcy4gSWYgdGhlcmUncyBlbm91Z2ggb3ZlcmxhcCBp dCB3aWxsIHdvcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+KioqIFNoYXJvbiBHb2xkYmVyZyBvbiAmcXVvdDtWZXJpZmlhYmxlIFJhbmRv bSBGdW5jdGlvbiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U2hhcm9uJ3Mgc2xpZGVzOiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9wcm9jZWVkaW5ncy85OC9zbGlkZXMvc2xpZGVzLTk4LXNhYWctdmVyaWZpYWJsZS1yYW5kb20t ZnVuY3Rpb25zLXZyZnMtMDAucGRmIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdz Lzk4L3NsaWRlcy9zbGlkZXMtOTgtc2FhZy12ZXJpZmlhYmxlLXJhbmRvbS1mdW5jdGlvbnMtdnJm cy0wMC5wZGY8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5CZW4gS2FkdWs6IElzIHRoZXJlIGEgd2F5IHRvIHZlcmlmeSB0aGF0IHRoZSBoYXNo ZXIgaXMgbm90IGRlbnlpbmcgdGhpbmdzIGluIHRoZSBkYXRhIHN0cnVjdHVyZT88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNoYXJvbjogVGhhdCBp cyBwcm92ZWQgYnkgdGhlIHN0cnVjdHVyZSBvZiB0aGUgZGF0YSBzdHJ1Y3R1cmUgaXRzZWxmLiBJ ZiBzb21ldGhpbmcgaXMgYWJzZW50IHRoZSBkYXRhIHN0cnVjdHVyZSB3aWxsIHNob3cgaXQuIFRo ZSBoYXNoZXIgY2Fubm90IGRlbnkgdGhhdCBzb21ldGhpbmcgaXMgcHJlc2VudCBvciBhYnNlbnQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SaWNo YXJkIEJhcm5lczogVHJ5aW5nIHRvIGZpZ3VyZSBvdXQgd2hhdCB5b3UgY2FuIGJ1aWxkIG9uIHRv cCBvZiB0aGlzLiBBcmUgYWxsIFZSRnMgb2YgdGhpcyBmb3JtIChoYXNoICYjNDM7IHNpZ25hdHVy ZSk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T aGFyb246IChzbGlkZSAxNykgLSB0aGUgc2lnbmF0dXJlIGlzIHRoZSBwcm9vZi4gVGhlIHNpZ25h dHVyZSBuZWVkcyB0byBiZSBkZXRlcm1pbmlzdGljLCBzbyB5b3UgY2FuJ3QgdXNlIEVDRFNBICh3 aGljaCBpcyBub24tZGV0ZXJtaW5pc3RpYykuIEluIEVDLVZSRiB3ZSB1c2UgdGhlIFggY29vcmRp bmF0ZSBvZiBnYW1tYSBmb3IgJnF1b3Q7aGFzaCZxdW90Oy4gJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QaGlsPz8/OiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2hhcm9uOiB0 aGVzZSBhcmUgYWxsIFZSRnMgaW4gdGhlIFJPTS4gRG9uJ3Qga25vdyB3aGF0IGl0IHNheXMgYWJv dXQgcG9zdC1xdWFudHVtICg/KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+V2VzIEhhcmRha2VyOiBJZiBJIHdlcmUgYWJsZSB0byBjb2xsZWN0IGEg YnVuY2ggb2YgcHJvb2ZzIG92ZXIgdGltZSwgSSBjb3VsZCBkbyBkaWN0aW9uYXJ5IGF0dGFja3M/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaGFy b246IFdoZW4geW91IHNlZSBhIHByb29mLCB5b3UgY2FuIHZlcmlmeSBpdCBpZiB3b3JrcyBmb3Ig YW4gaW5wdXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5XZXM6IGFuZCBpdCB3b3VsZCBiZSBhIHN0cmFuZ2UgcHJvdG9jb2wgd2hlcmUgSSBjb3Vs ZG4ndCBzZWUgdGhlIGlucHV0cyBidXQgY291bGQgc2VlIHRoZSBwcm9vZnM8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KioqIFBoaWxsaXAgSGFs bGFtLUJha2VyIG9uICZxdW90O0pTT04gaW1wbGVtZW50YXRpb24gb2YgTWVzaC9SZW1lc2gmcXVv dDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBI QidzIHNsaWRlczogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgv c2xpZGVzL3NsaWRlcy05OC1zYWFnLWpzb24taW1wbGVtZW50YXRpb24tb2YtbWVzaHJlbWVzaC0w MC5wZGYiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVzL3NsaWRl cy05OC1zYWFnLWpzb24taW1wbGVtZW50YXRpb24tb2YtbWVzaHJlbWVzaC0wMC5wZGY8L2E+ICZu YnNwOyhqdXN0IG9uZSBzbGlkZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPihubyBxdWVzdGlvbnMpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KioqIE9wZW4gTWljPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbmdvIFN0aWVnbGl0eiA6IFRo YW5rIHlvdS4gWW91IGFyZSBhbGwgYXdlc29tZS4gSXMgdGhlcmUgYW55IHdvcmsgaGVyZSBvbiBJ Q01QIE5BVGluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+S2F0aGxlZW46IFJlY29tbWVuZCB5b3UgYXNrIGluIE9wczxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW9hdiBOaXI6IEEgY291cGxlIElF VEZzIGFnbywgc3RhcnRlZCB0byBkaXNjdXNzIDM1NTJiaXMsIHdoYXQgc2hvdWxkIGdvIGludG8g c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuIEkgZGlkIGEgZmlyc3QgdHJhbnNwb3NpdGlvbiwgY2Fs bGVkIGZvciBjb21tZW50cywgYW5kIGdvdCBub3RoaW5nLiBXZSBzaG91bGRuJ3Qgc2VuZCB0aGUg bWVzc2FnZSB0aGF0IHRoZXJlJ3Mgbm90aGluZyB0byBhZGQgc2luY2UgMjAwMw0KIFtieSBwdWJs aXNoaW5nIGEgbmV3IHVuY2hhbmdlZCBkb2N1bWVudF0uIFdlIG5lZWQgcGVvcGxlIHRvIHByb3Bv c2UgdGV4dCBhbmQgaWRlYXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IYW5uZXM6IFdlIGFza2VkIGZvciB1cGRhdGUgd2l0aG91dCBr bm93aW5nIHdoYXQgdGhlIHVwZGF0ZSB3b3VsZCBiZS4gV2hhdCBpcyB0aGUgdGFyZ2V0IGF1ZGll bmNlPyBXaGF0IHNob3VsZCB0aGUgcmVjb21tZW5kYXRpb24gYmU/Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb2F2OiAzNTUyIGFuZCBi aXMsIHRhcmdldCBhdWRpZW5jZSBpcyBwZW9wbGUgd2hvIHdyaXRlIFJGQ3MuIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zIHNlY3Rpb25zIHRhcmdldCB0aGUgc2FtZSBhdWRpZW5jZXMgYXMgdGhlIFJG Q3MgdGhlbXNlbHZlcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhhbm5lczogdGhpcyBpc24ndCB0aGUgd2F5IHBlb3BsZSB3cml0ZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucy4gdGhleSBjdXQtYW5kLXBhc3RlIGZyb20gZXhpc3Rpbmcg ZG9jdW1lbnRzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+S2F0aGxlZW46IEF0IFNlY0Rpciwgbm90IGV2ZXJ5b25lIGlzIGNvbWZvcnRh YmxlIHdpdGggcHJpdmFjeTsgd2UgbWlnaHQgZG8gYmV0dGVyIG9uIHRob3NlIHJldmlld3MgaWYg d2UgZ290IG1vcmUgaW5mbyBpbnRvIHRoZSBiaXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QYXVsIEhvZmZtYW46IE9uZSBwcm9ibGVt IHdpdGggdGhlIG9yaWdpbmFsIGRvY3VtZW50IGlzIGl0cyBsZW5ndGg6IDQwIHBhZ2VzLiBNaXgg b2YgZ29vZCBleGFtcGxlcywgZXRjLiBidXQgbWFueSBwZW9wbGUgZG9uJ3Qgd2FudCB0byByZWFk IHRoYXQgbG9uZy4gQSBzaG9ydGVyIGRvY3VtZW50IHdvdWxkIGJlIGJldHRlciBmb3IgZG9jIGF1 dGhvcnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5AQDogc3BlYWtpbmcgYXMgYW4gYXV0aG9yIGluIG90aGVyIFdHcywgdGhlIHByZXNl bmNlIG9mIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gaGFzIGNhdXNlZCB1cyB0byB0 YWtlIHRoaW5ncyBvdXQgb2YgZG9jdW1lbnRzOyB0aGF0IHRoZSByZXZpZXcgZG9lc24ndCBwaWNr IHRobmlncyB1cCBkb2Vzbid0IG1lYW4gaXQgaGFzbid0IGhlbHBlZC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdmlkIEJsYWNrOiBFeGFtcGxl IGluIE9wczogYXBwZW5kaXggd2l0aCBhIGxpc3Qgb2YgcXVlc3Rpb25zIGFuIG9wcyByZXZpZXdl ciBzaG91bGQgYXNrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+S2F0aGxlZW46IEhvdyBtYW55IHBlb3BsZSBpbnRlcmVzdGVkIGluIGFuIHVwZGF0 ZT8gW2Fib3V0IDIwIGhhbmRzXS4gUGxlYXNlIGRpc2N1c3Mgb24gU0FBRyBsaXN0LiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQg d2UncmUgZG9uZSAoMTY6NDgpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CE03DB3D7B45C245BCA0D243277949362F98C6C8MX307CL04corpem_--