From nobody Tue Mar 1 07:20:51 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867391B2CF5 for ; Tue, 1 Mar 2016 07:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_y9porsSlYh for ; Tue, 1 Mar 2016 07:20:48 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c: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 337CB1B2CF1 for ; Tue, 1 Mar 2016 07:20:43 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id e185so170519587vkb.1 for ; Tue, 01 Mar 2016 07:20:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Eh87pJ/0AzDmXyp/9WPd3PNMxwGBr5anyIGUPVlYXnU=; b=kSGtpVvzj8JO015Y9AzlK1jhjXbcU64axarkLXaUfoQlrYjBoigexh/F2WlIJg5Wzu cGh0sC1OSo5UNLyZivMjxwvSI27xgxN274rYIfbaGXgXn5HAqjBF1GlOuBJ7VO01Wq0a bEHzc2IiTYOG6jk8P8IRMJ2km1B1U2ffFJbGw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Eh87pJ/0AzDmXyp/9WPd3PNMxwGBr5anyIGUPVlYXnU=; b=L8T7n/R7ry/zlcI05ZjprA4yMF81IQjT+qRxgdyFLHj1SliR0eMqYoxMv4xeAx8jUy p94CoznbGZjaSzBTb5nnEfltbUwZNWdAeaJ6zhJcRMKEK780OIblRgW5+TYPmCaJ6uvm 7FFTJT1iS+7+Ihf4qNVabz/5dutT3UYrGvw3ml2pad43l0dZBzlmF4Q9scCSTraKR1s7 2Sr4YWkpc5BZ1yBJ/o94qo1hoSMIK/5V3Z9I2GkHVVWIaJysuumBVTN6rwtD8iohlajA aBaM0VJP43tD2XsrTYZ+tL9qv3G9mqE/iTDZSiIWT1m75ndF6Z0xw6wgH4c1CkK5guju v4YQ== X-Gm-Message-State: AD7BkJI5d+6n9KOdwRM4TtTxAuQCx5bArtE1Sa18cT0m8RIZ1pJqO3WySQleZohvLNHIyJmm7tAQsEgwYbo5rmjx X-Received: by 10.31.168.135 with SMTP id r129mr16056410vke.7.1456845642234; Tue, 01 Mar 2016 07:20:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.88.138 with HTTP; Tue, 1 Mar 2016 07:20:22 -0800 (PST) In-Reply-To: <56B38293.6000800@si6networks.com> References: <20160204162945.16956.31282.idtracker@ietfa.amsl.com> <56B38293.6000800@si6networks.com> From: Joseph Lorenzo Hall Date: Tue, 1 Mar 2016 08:20:22 -0700 Message-ID: To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Greg Norcie , "saag@ietf.org" , =?UTF-8?Q?Iv=C3=A1n_Arce?= Subject: Re: [saag] Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols (Fwd: New Version Notification for draft-gont-predictable-numeric-ids-00.txt) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 15:20:50 -0000 Hi, here are some comments from our -- CDT's Joe Hall and Greg Norcie -- review of this document: * General: thanks for taking this on, it's a great resource and needed, in our opinion. * Do you have thoughts where you might go with this next? It seems like a BCP for "Guidelines on the use of identifiers in protocols" could be a very good thing. I know the IAB would be engaged as would folks on this list in ensuring that it resulted in good, flexible guidance. * There are a number of places in the ID where you state some assumptions about what the attacker can and cannot know. Maybe I missed this but are you adopting a specific threat model/attacker model from another RFC or publication? If so, it would be good to point to it (I may have missed this). If not, it would be good to add a paragraph that states you're considering a network attacker with no local physical or logical access to the device, etc. * I was expecting to see at some point a list of common vulnerabilities or bad design patterns with unique identifiers. E.g., "predictable identifiers", "predictable offsets in identifier sequences", "embedding IDs from one context into another" (see: https://tools.ietf.org/html/draft-huitema-dhc-anonymity-profile ). I'm not sure if section 8 lists vulnerabilities or something else (or if what I'm thinking of are not vulnerabilities). For example, where does the reuse of an identifier -- like that described across layers in draft-huitema-dhc-anonymity-profile -- fit in your scheme? * typos: * heading of 8.2 should capitalize "uniqueness" for consistency with other subsections around it. * p. 4, misspelling: "speification" should be "specification" * Section 7.4.1, "Predictable Linear Identifiers Algorithm" has a typo in the pseudocode, "next_ifd" should be "next_id". * p. 16: "does nto exist" should be "does not exist" * Section 7.4.5: remove "Sections" from "described in Sections Section 1.1.1 and Section 7.1.2" and one other instance later in that same paragraph. * Section 7.4.5 has a typo in pseudocode: "id_increment" should be "id_inc" Thanks! On Thu, Feb 4, 2016 at 9:55 AM, Fernando Gont wrote: > Folks, > > We have published a new IETF I-D entitled "Security and Privacy > Implications of Numeric Identifiers Employed in Network Protocols". > > It sheds light on the security and privacy implications of predictable > numeric identifiers, which have affected (and still affect) several IETF > protocols for ages, and that in some cases (such as IPv6 IIDs) can be > leveraged for pervasive monitoring. > > The I-D is available here: > > > Your feedback will be appreciated. > > Thanks! > > Best regards, > Fernando > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-predictable-numeric-ids-00.txt > Date: Thu, 04 Feb 2016 08:29:45 -0800 > From: internet-drafts@ietf.org > To: Ivan Arce , Fernando Gont > > > > A new version of I-D, draft-gont-predictable-numeric-ids-00.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Name: draft-gont-predictable-numeric-ids > Revision: 00 > Title: Security and Privacy Implications of Numeric Identifiers > Employed in Network Protocols > Document date: 2016-02-04 > Group: Individual Submission > Pages: 32 > URL: > https://www.ietf.org/internet-drafts/draft-gont-predictable-numeric-ids-00.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-predictable-numeric-ids/ > Htmlized: > https://tools.ietf.org/html/draft-gont-predictable-numeric-ids-00 > > > Abstract: > This document performs an analysis of the security and privacy > implications of different types of "numeric identifiers" used in IETF > protocols, and tries to categorize them based on their > interoperability requirements and the assoiated failure severity when > such requirements are not met. It describes a number of algorithms > that have been employed in real implementations to meet such > requirements and analyzes their security and privacy properties. > Additionally, it provides advice on possible algorithms that could be > employed to satisfy the interoperability requirements of each > identifier type, while minimizing the security and privacy > implications, thus providing guidance to protocol designers and > protocol implementers. Finally, it provides recommendations for > future protocol specifications regarding the specification of the > aforementioned numeric identifiers. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 CDT's annual dinner, Tech Prom, is April 6, 2016! https://cdt.org/annual-dinner From nobody Tue Mar 1 16:11:53 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF201A036A for ; Tue, 1 Mar 2016 16:11:51 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9z5xuDs9bHL4 for ; Tue, 1 Mar 2016 16:11:50 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 B4E021A010E for ; Tue, 1 Mar 2016 16:11:50 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id n190so38821961iof.0 for ; Tue, 01 Mar 2016 16:11:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to; bh=8u6qgBcCu18fm59BM3/J0rki7CeH3ANrozoazHu8SNQ=; b=gL+vZaybsryo84zMHR//IQbOmj9CDl1tVaXs1X7AQ6nlOEBsmFUwmRCjKyyc9u+HS5 FlIWJesDGazo6wgVeX9xK0+BYZXcJVJruWNcYOS+bNlUd7RZxJoUOLLSFIQHaKLVlgq4 afVasCn3hK04834A8FEEPZzKT1UzOG4jz2H5B8TokpxjrbyYHtCs5DdbSeGM0ssVKg4Z 7GzS5yTwHyDCe4uTZlHcZfIq0ia9cgjo8Ov2x9odd6D9EvT5oPnEiiVU8urnyjlaMAOL OItU24vKFbq0Zm7REL4IJvOgqfm0sumlqPXqmxjBNgoajt98LDnEF+uSwv78wAlhJmfB 278A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:date:message-id:subject :from:to; bh=8u6qgBcCu18fm59BM3/J0rki7CeH3ANrozoazHu8SNQ=; b=XMZYCgbz/yhAL1fk2c2oBNHbPwUtYNa2uVobb3ZfxbFrjW8aU+4uBpCIYbaocyF0qW BHuC1aVLJzVZfSiLQiTs5B/fU94Xc9Jmc0Z/kuYZ6nAWa2Ugc+3qR0Ai6G8/ZklY4CqD iddu5BXAkAZ1QOOHW/ebR59ATsm6lNCPCw3fYadDcoqkQsdA9tVC5GJhiIpYU2jqiaQ1 JKu3TzNqKDwuat7Ai9jCR2PwVSgVjgXT8yygmG+YvjalhFC4nEKMenZdGuOUGy4rqw68 Vd98kew5CQXxCA9J07pFxFI8WpTTosO/77hdpDFL8mKhvM1ukgnYrw1CHsVTaZs4iR4D LFhg== X-Gm-Message-State: AG10YOSQfp6sJ96Iz+TeJQ5DsP5PiCHQ0OiUElRvdwyj7j2JBahCyJ8cqwqTV0bHeVE2nU8UCxxLV7vVstTCXw== MIME-Version: 1.0 X-Received: by 10.107.132.205 with SMTP id o74mr26219544ioi.66.1456877510019; Tue, 01 Mar 2016 16:11:50 -0800 (PST) Received: by 10.36.195.133 with HTTP; Tue, 1 Mar 2016 16:11:49 -0800 (PST) Date: Tue, 1 Mar 2016 19:11:49 -0500 Message-ID: From: Jeffrey Walton To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] RFC 6979, Deterministic Signatures for DSA/ECDSA using SHA3? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 00:11:51 -0000 Hi Everyone, How does one use SHA-3 with a deterministic DSA/ECDSA signature under RFC 6979? Has anyone defined what HMAC/SHA-3 means? Jeff From nobody Tue Mar 1 23:05:31 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017E21A1C04 for ; Tue, 1 Mar 2016 23:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SBqcRr39Ym2 for ; Tue, 1 Mar 2016 23:05:24 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CEEA1A1EB7 for ; Tue, 1 Mar 2016 23:05:24 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 7AD6080D93; Wed, 2 Mar 2016 08:05:20 +0100 (CET) To: Joseph Lorenzo Hall References: <20160204162945.16956.31282.idtracker@ietfa.amsl.com> <56B38293.6000800@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56D62BC7.50003@si6networks.com> Date: Tue, 1 Mar 2016 20:54:47 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: privsec-program@iab.org, Greg Norcie , "saag@ietf.org" , =?UTF-8?Q?Iv=c3=a1n_Arce?= Subject: Re: [saag] Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols (Fwd: New Version Notification for draft-gont-predictable-numeric-ids-00.txt) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 07:05:26 -0000 Hi, Joseph! Thanks so much for your feedback! -- Please find my comments in-line.... On 03/01/2016 12:20 PM, Joseph Lorenzo Hall wrote: > Hi, here are some comments from our -- CDT's Joe Hall and Greg Norcie > -- review of this document: > > * General: thanks for taking this on, it's a great resource and > needed, in our opinion. > > * Do you have thoughts where you might go with this next? It seems > like a BCP for "Guidelines on the use of identifiers in protocols" > could be a very good thing. I know the IAB would be engaged as would > folks on this list in ensuring that it resulted in good, flexible > guidance. Yes, that's the intent: a BCP of similar nature to BCP 106/RFC 4086 which should be applied everytime a new numeric identifier is specified in a new protocol. And could b applied to existing protocols were the corresponding spec still allows or suggest the use of numeric identifiers that have negative security/privacy implications. > * There are a number of places in the ID where you state some > assumptions about what the attacker can and cannot know. Maybe I > missed this but are you adopting a specific threat model/attacker > model from another RFC or publication? If so, it would be good to > point to it (I may have missed this). If not, it would be good to add > a paragraph that states you're considering a network attacker with no > local physical or logical access to the device, etc. Yep, we assume that in many places. Will clarify this. > * I was expecting to see at some point a list of common > vulnerabilities or bad design patterns with unique identifiers. E.g., > "predictable identifiers", "predictable offsets in identifier > sequences", This is discussed throughout the document for each algorithm that results in predictable identifiers. For example, Section 7.4.1 (page 15), states: If a global counter is used (such as "next_id" in the example above), a node that learns one protocol identifier can also learn or guess values employed by past and future protocol instances. On the other hand, when the value of increments is known (such as "1" in this case), an attacker can sample two values, and learn the number of identifiers that were generated in-between. The consequences of an attacker learning "values employed by past and future protocol instances" or "the number of identifiers that were generated in-between" varies from one protocol to another. e.g., in the case of TCP ephemeral ports, predicting ephemeral ports would be of help for the attacker to perform e.g. TCP reset attacks, whereas "learning the number of ephemeral pots generated between two outgoing connections" would be an information leakage about the number of outgoing connections established by the victim (which might be of use in certain scenarios). OTOH, Sections 4.1 and 4.2 illustrate how predictable numeric IDs were found to be useful for performing different kinds of attacks. mmm.. were you expecting, in all of the sections that discuss specific algorithms, references/links to how such vulnerable algorithms result in specific vulnerabilities when applied to different protocols? (i.e., kind of a cross-reference), or something else? > "embedding IDs from one context into another" (see: > https://tools.ietf.org/html/draft-huitema-dhc-anonymity-profile ). We didn't cover "embedding IDs from one context into another". In principle, you just shouldn't do this, since this is kind of what we refer to as "Protocol specifications that over-specify their identifiers", in the sense that, when you employ a numeric identifier in a different context, you're implicitly enforcing requirements that you usually don't really need in the new context. -- e.g., using a MAC address to generate a DHCP DUID leaks information that you don't eally need to leak for complying with the corresponding *interoperability* requirements (uniqueness). > I'm > not sure if section 8 lists vulnerabilities or something else (or if > what I'm thinking of are not vulnerabilities). For example, where does > the reuse of an identifier -- like that described across layers in > draft-huitema-dhc-anonymity-profile -- fit in your scheme? As noted above, this one is not explicitly noted -- maybe we could say what I mentioned above ("this results in over-specification of the numeric id") in Section 3 of the document? > * typos: [....] We will fix all of these typos in the next rev of the document (that we plan to submit before the cutoff). Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Mar 2 08:25:09 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519CF1B2BEA for ; Wed, 2 Mar 2016 08:25:08 -0800 (PST) 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_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-HCmQc5l8FB for ; Wed, 2 Mar 2016 08:25:06 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0088.outbound.protection.outlook.com [65.55.169.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11661B2BE8 for ; Wed, 2 Mar 2016 08:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4hCJC3RUmEW5KlqAbMUHqGVcbSKdMBkzdsAkJB3cxyU=; b=wA6zXkFLFzSX7S/9oFHc1lpXPvQI1g0VBLhuFlD2FS0CPUD3stFst0EQodb9kKnlByEIW86ns8KrTkS3s2/L+EAQ70/c/ejX+6eBSUMKaWPbbDPy6XXlj7gT91HZxWOJ/DYDMLawuZje+/bbtje9rCUFGMfl9T4326G5lbVRqWU= Received: from DM2PR0601MB1118.namprd06.prod.outlook.com (10.160.218.139) by DM2PR0601MB1117.namprd06.prod.outlook.com (10.160.218.13) with Microsoft SMTP Server (TLS) id 15.1.415.20; Wed, 2 Mar 2016 16:25:03 +0000 Received: from DM2PR0601MB1118.namprd06.prod.outlook.com ([10.160.218.139]) by DM2PR0601MB1118.namprd06.prod.outlook.com ([10.160.218.139]) with mapi id 15.01.0415.022; Wed, 2 Mar 2016 16:25:03 +0000 From: Karen O'Donoghue To: "saag@ietf.org" Thread-Topic: WGLC on Network Time Security documents (3 documents) Thread-Index: AQHRc4SmJvZM3oW8r0KOfm1KiYexWA== Date: Wed, 2 Mar 2016 16:25:03 +0000 Message-ID: <4575050B-5717-409A-866F-1F0D33CEB41B@isoc.org> References: 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=isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [74.214.42.47] x-microsoft-exchange-diagnostics: 1; DM2PR0601MB1117; 5:hQU6WLvvq/wivyv2V59cbYDT80VZJFLPEQzBctmHoQmJvnfhWi6VzWvjmu+EIN72fNIkGQznRZye7IAnewaT6bXpgfMG4YfHZXaQS9dmXKhVliOycr24Ez0OnT0j/i9sT5tkiGarLZXfmvzZ69BK9Q==; 24:0QWqanhy8Cj/TyAt14Jf1nMTC80U2LSQjx66u4Z2sk/cZFCe8lc0UCB78XQtfkqfsv6lRWvETXc4qsmb0P0HntLVBRtzrujD9y/4YK+2Z3E= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0601MB1117; x-ms-office365-filtering-correlation-id: b0b10467-25b1-4258-e258-08d342b735a9 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DM2PR0601MB1117; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0601MB1117; x-forefront-prvs: 086943A159 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(83716003)(87936001)(82746002)(1096002)(19617315012)(2900100001)(15650500001)(86362001)(1220700001)(1730700002)(16236675004)(33656002)(2501003)(81156010)(66066001)(106116001)(19580405001)(19580395003)(2351001)(99286002)(10400500002)(40100003)(3280700002)(76176999)(450100001)(15975445007)(92566002)(77096005)(3660700001)(5008740100001)(54356999)(122556002)(102836003)(3846002)(6116002)(2906002)(586003)(107886002)(189998001)(5001960100004)(36756003)(11100500001)(110136002)(5004730100002)(5002640100001)(50986999)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0601MB1117; H:DM2PR0601MB1118.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_4575050B5717409A866F1F0D33CEB41Bisocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2016 16:25:03.3802 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0601MB1117 Archived-At: Subject: [saag] Fwd: WGLC on Network Time Security documents (3 documents) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 16:25:08 -0000 --_000_4575050B5717409A866F1F0D33CEB41Bisocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Security Folks, Additional security eyes on these documents would be greatly appreciated. Regards, Karen Begin forwarded message: From: Karen O'Donoghue > Subject: WGLC on Network Time Security documents (3 documents) Date: March 1, 2016 at 1:36:11 AM EST To: ntpwg@lists.ntp.org Cc: tictoc@ietf.org Folks, This email starts a three week working group last call on the three documen= ts that comprise the Network Time Security effort. Please review and send a= ny comments to the mailing list including your assessment of whether these = documents are mature enough to proceed or not. Please send all comments in = by Wednesday 23 March 2016. Network Time Security draft-ietf-ntp-network-time-security-13 https://datatracker.ietf.org/doc/draft-ietf-ntp-network-time-security/ Using the Network Time Security Specification to Secure the Network Time Pr= otocol draft-ietf-ntp-using-nts-for-ntp-04 https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ Protecting Network Time Security Messages with the Cryptographic Message Sy= ntax (CMS) draft-ietf-ntp-cms-for-nts-message-06 https://datatracker.ietf.org/doc/draft-ietf-ntp-cms-for-nts-message/ Regards, Karen --_000_4575050B5717409A866F1F0D33CEB41Bisocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <4DA67DC7FE95F14F8C8D208FE438849E@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Security Folks,

Additional security eyes on these documents would be greatl= y appreciated.

Regards,
Karen

Begin forwarded message:

From: Karen O'Donoghue <odonoghue@isoc.org>
Subject: WGLC on Network Time Secu= rity documents (3 documents)
Date: March 1, 2016 at 1:36:11 AM EST
To: ntpwg@lists.ntp.org
Cc: tictoc@ietf.org

Folks,

This email starts a three week working group last call on the three documen= ts that comprise the Network Time Security effort. Please review and send a= ny comments to the mailing list including your assessment of whether these = documents are mature enough to proceed or not. Please send all comments in by Wednesday 23 March 2016.

Network Time Security
draft-ietf-ntp-network-time-security-13
https://datatracker.ietf.org/doc/draft-ietf-ntp-network-= time-security/

Using the Network Time Security Specification to Secure the Network Time Pr= otocol
draft-ietf-ntp-using-nts-for-ntp-04
https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

Protecting Network Time Security Messages with the Cryptographic Message Sy= ntax (CMS)
draft-ietf-ntp-cms-for-nts-message-06
https://datatracker.ietf.org/doc/draft-ietf-ntp-cms-for-nts-message/

Regards,
Karen


--_000_4575050B5717409A866F1F0D33CEB41Bisocorg_-- From nobody Thu Mar 3 01:20:13 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246B21A6FB2 for ; Thu, 3 Mar 2016 01:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tGOaBu81xi1 for ; Thu, 3 Mar 2016 01:20:02 -0800 (PST) Received: from smtp-out-01.aalto.fi (smtp-out-01.aalto.fi [130.233.228.120]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9351A6FC8 for ; Thu, 3 Mar 2016 01:20:01 -0800 (PST) Received: from smtp-out-01.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id EE2371153D8_6D801BDB; Thu, 3 Mar 2016 09:19:57 +0000 (GMT) Received: from EXHUB01.org.aalto.fi (exhub01.org.aalto.fi [130.233.222.118]) by smtp-out-01.aalto.fi (Sophos Email Appliance) with ESMTP id A6FC011531A_6D801BCF; Thu, 3 Mar 2016 09:19:56 +0000 (GMT) Received: from EXMDB01.org.aalto.fi ([169.254.2.222]) by EXHUB01.org.aalto.fi ([130.233.222.118]) with mapi id 14.03.0224.002; Thu, 3 Mar 2016 11:19:56 +0200 From: Aura Tuomas To: Josh Howlett , Mohit Sethi , "saag@ietf.org" Thread-Topic: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt Thread-Index: AQHRYmyDaEz8z8wkLU+ZyRerPC0UrZ8iJdqAgA/XEQCAACY7gP//7+QAgAAFVYCAESlggIAASFqAgAQG1AA= Date: Thu, 3 Mar 2016 09:19:56 +0000 Message-ID: <7F9C975440487E49BBD35F4FB088ED74CFCEC2B1@EXMDB01.org.aalto.fi> References: <20160208123035.1562.80507.idtracker@ietfa.amsl.com> <56B8B561.8040300@ericsson.com> <7F9C975440487E49BBD35F4FB088ED74CFCDBF14@EXMDB01.org.aalto.fi> <56D47B79.7010306@ericsson.com> In-Reply-To: Accept-Language: fi-FI, en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [87.100.167.70] Content-Type: multipart/alternative; boundary="_000_7F9C975440487E49BBD35F4FB088ED74CFCEC2B1EXMDB01orgaalto_" MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 09:20:11 -0000 --_000_7F9C975440487E49BBD35F4FB088ED74CFCEC2B1EXMDB01orgaalto_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Josh, I think I got your point. There are two questions here. The first is about who will manage the AAA server for the devices. We have = primarily thought it will be the user organization, which may outsource the= authentication and authorization to a third party of their choice. You see= m to be thinking that the device vendors will run the AAA server for their = own devices. Both scenarios are certainly possible. The vendor-specific sol= ution would not necessarily even need standard for the EAP method because i= t could be specified by the vendor alone. We have focused on the scenario w= here the AAA server is not necessarily the device vendor, and a standard fo= r interoperability is needed. The second question is whether all the devices in the same user organizatio= n should be handled by one AAA server, or if there should be multiple class= es of devices that are handled by different AAA servers. Adding support for= device classes, e.g. as subdomains "XXX.eap-noob.net", is certainly possib= le. We'll think about this. I'm not sure about the extra complexity that it= will create. Tuomas L=E4hett=E4j=E4: Josh Howlett [mailto:Josh.Howlett@jisc.ac.uk] L=E4hetetty: Monday, 29 February, 2016 23:29 Vastaanottaja: Mohit Sethi ; Aura Tuomas ; saag@ietf.org Aihe: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.t= xt Hi Mohit, Thanks, but I still don't follow the use case. I thought the draft is tryin= g to address the scenario where I have devices from multiple vendors wantin= g to register themselves against each vendors' systems (e.g., my fridge reg= isters with my fridge vendor's AAA server; my washing machine with my washi= ng machine vendor's AAA server; etc.). How does my NAS know how to forward = a request to the correct realm if each request is using the same realm? Josh. From: Mohit Sethi [mailto:mohit.m.sethi@ericsson.com] Sent: 29 February 2016 17:10 To: Josh Howlett >;= Aura Tuomas >; Mohit Set= hi >; saag@ie= tf.org Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt Hi Josh Thanks again for your useful questions. 1. The requests for "eap-noob.net" would either be served by a local AAA se= rver or a remote AAA server for which a forwarding rule has been added. The= request would not be forwarded to a global server based on DNS lookups. He= nce, a DNS lookup for eap-noob.net is expected to respond with NXDOMAIN. 2. The need for the special purpose realm is to allow devices from any manu= facturer to be directed to the AAA server of your choice. You only need set= up the server or add the forwarding once for all the devices from any manuf= acturer. Not everyone wants to depend on the device vendor's AAA service fo= r security.Besides, depending on a vendor service may not be always safe. A= s Stephen had pointed out in another mail thread (https://www.ietf.org/mail= -archive/web/ace/current/msg01470.html), commercial devices will be end-of-= lifed by vendors, and yet they still need to be functional for the owner. /--Mohit On 02/18/2016 09:05 PM, Josh Howlett wrote: Sorry, ignore question 3, it makes no sense here. From: Josh Howlett Sent: 18 February 2016 18:47 To: Aura Tuomas; Mohit Sethi; saag@ietf.org; emu@ietf.org Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt Hi Aura, A couple of other questions on the deployment theme: 1. How would requests towards the single special people realm get dis= ambiguated among the multiple AAA servers? 2. In fact, what's the need for this special purpose realm at all - w= hy not let the vendor burn one into the firmware, and use an intermediate A= AA routing fabric do the AAA server discovery? 3. Why this and not WPS (or something similar?) Josh. Sent from Outlook Mail fo= r Windows 10 phone From: Aura Tuomas Sent: 18 February 2016 18:07 To: Josh Howlett; Mohit Sethi; saag@ietf.org; emu@ietf.org Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt Hi Josh, Good observation; we may need to be clearer about the intended usage scenar= ios for EAP-NOOB. In the home setting, the AAA server would typically be a cloud-based servic= e, where the consumer can register a user account. This does require the 80= 2.1X authentication (i.e. WPA2-Enterprise) to be configured at the home NAS= , so that authentication for "@eap-noob.net" is forwarded to the cloud-base= d AAA server. You only need to configure the NAS once, and all future devic= es can be connected without touching the NAS. This is a change from the way home wireless routers are configured today. W= e think that, as the number of IoT devices grows, configuring them with a s= hared passphrase will be too inconvenient. Obviously, the shared passphrase= is also vulnerable to a single untrusted IoT device that may leak the pass= phrase, and using EAP helps to isolate the devices. Of course, the benefits of EAP-NOOB will be greater in organizations which = already use 802.1X authentication and which have larger numbers of IoT devi= ces than a single home. Anything else that we need to address? Tuomas -----Original Message----- From: Josh Howlett [mailto:Josh.Howlett@jisc.ac.uk] Sent: Thursday, 18 February, 2016 19:28 To: Mohit Sethi ; saag@ietf.org; emu@ietf.org Cc: Aura Tuomas Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt Hi Mohit, This is an interesting draft, but I'm struggling to understand how this wou= ld be deployed in the consumer settings that the document alludes to. For e= xample, who do you anticipate will be operating the NAS (the consumer?), AA= A server (the vendor?), and the AAA fabric between these actors? Josh. > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Mohit Sethi > Sent: 08 February 2016 15:34 > To: saag@ietf.org; emu@ietf.org > Cc: tuomas.aura@aalto.fi > Subject: [saag] Fwd: New Version Notification for > draft-aura-eap-noob-00.txt > > Dear all > > We have just submitted a new IETF Draft titled "Nimble out-of-band > authentication for EAP (EAP-NOOB)". > > The draft defines an EAP method where the authentication is based on a > user-assisted out-of-band (OOB) channel between the server and peer. > It is intended as a generic bootstrapping solution for > Internet-of-Things devices which have no pre-configured authentication > credentials and which are not yet registered on the authentication > server. Consider devices you just bought or borrowed. > > The EAP-NOOB method is more generic than most ad-hoc bootstrapping > solutions in that it supports many types of OOB channels. We specify > the exact in-band messages but only the OOB message contents and not > the OOB channel details. Also, EAP-NOOB supports ubicomp devices with > only output (e.g. display) or only input (e.g. camera). Moreover, it > makes combined use of both secrecy and integrity of the OOB channel > for more robust security than the ad-hoc solutions. We have put a lot > of effort into designing a robust security protocol. > > For one application example, we have used an earlier version of the > protocol for bootstrapping security for ubiquitous displays: the user > can configure wireless network access, link the device to a cloud > service, and register ownership of the device for a specific cloud > user - all in one simple step of scanning a QR code with a smart > phone. There seemed to more potential to this idea than just using it > for our own system, and thus we decided to write a generic EAP method for= out-of-band authentication. > > The draft is available here: > https://tools.ietf.org/html/draft-aura-eap-noob-00 > > Please see if you can make use of it. We look forward to your feedback > and comments. > > Regards > /--Mohit > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-aura-eap-noob-00.txt > Date: Mon, 08 Feb 2016 04:30:35 -0800 > From: internet-drafts@ietf.org > To: Tuomas Aura , M= ohit Sethi > > > > > A new version of I-D, draft-aura-eap-noob-00.txt has been successfully > submitted by Tuomas Aura and posted to the IETF repository. > > Name: draft-aura-eap-noob > Revision: 00 > Title: Nimble out-of-band authentication for EAP (EAP-NOOB= ) > Document date: 2016-02-08 > Group: Individual Submission > Pages: 35 > URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-00.txt > Status:https://datatracker.ietf.org/doc/draft-aura-eap-noob/ > Htmlized:https://tools.ietf.org/html/draft-aura-eap-noob-00 > > > Abstract: > Extensible Authentication Protocol (EAP) [RFC3748] provides support > for multiple authentication methods. This document defines the EAP- > NOOB authentication method for nimble out-of-band (OOB) > authentication and key derivation. This EAP method is intended for > bootstrapping all kinds of Internet-of-Things (IoT) devices that have > a minimal user interface and no pre-configured authentication > credentials. The method makes use of a user-assisted one-directional > OOB channel between the peer device and authentication server. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. > > The IETF Secretariat > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag 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's registered office is: One Castlepark, Tower Hill, Brist= ol, 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. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --_000_7F9C975440487E49BBD35F4FB088ED74CFCEC2B1EXMDB01orgaalto_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Josh,=

 

I think I got your = point. There are two questions here.

 

The first is about = who will manage the AAA server for the devices. We have primarily thought i= t will be the user organization, which may outsource the authentication and= authorization to a third party of their choice. You seem to be thinking that the device vendors will run the AAA s= erver for their own devices. Both scenarios are certainly possible. The ven= dor-specific solution would not necessarily even need standard for the EAP = method because it could be specified by the vendor alone. We have focused on the scenario where the AAA server = is not necessarily the device vendor, and a standard for interoperability i= s needed.

 

The second question= is whether all the devices in the same user organization should be handled= by one AAA server, or if there should be multiple classes of devices that = are handled by different AAA servers. Adding support for device classes, e.g. as subdomains “XXX.eap-noob.= net”, is certainly possible. We’ll think about this. I’m = not sure about the extra complexity that it will create.

 

Tuomas

 

 

 

L=E4hett=E4j=E4:= Josh Howlett [mailto:Josh.Howl= ett@jisc.ac.uk]
L=E4hetetty: Monday, 29 February, 2016 23:29
Vastaanottaja= : Mohit Sethi <m= ohit.m.sethi@ericsson.com>; Aura Tuomas <tuomas.aura@aalto.fi>; sa= ag@ietf.org
Aihe: RE: [saag] Fwd: New Version Notification for draft-aura-eap-no= ob-00.txt

 

Hi Mohi= t,

&n= bsp;

Thanks,= but I still don’t follow the use case. I thought the draft is trying= to address the scenario where I have devices from multiple vendors wanting= to register themselves against each vendors’ systems (e.g., my fridge registers with my fridge vendor’s AAA serve= r; my washing machine with my washing machine vendor’s AAA server; et= c.). How does my NAS know how to forward a request to the correct realm if = each request is using the same realm?

&n= bsp;

Josh.

 

From:= Mohit Sethi [mailto:mohit.m.sethi@ericsson.com]
Sent: 29 February 2016 17:10
To: Josh Howlett <Josh= .Howlett@jisc.ac.uk>; Aura Tuomas <tuomas.aura@aalto.fi>; Mohit Sethi <mohit.m.sethi@ericsson.com>; saag@ietf.org
Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap= -noob-00.txt

 

= Hi Josh

Thanks again for your useful questions.

1. The requests for "eap-noob.net" would either be served by a lo= cal AAA server or a remote AAA server for which a forwarding rule has been = added. The request would not be forwarded to a global server based on DNS l= ookups. Hence, a DNS lookup for eap-noob.net is expected to respond with NXDOMAIN.

2. The need for the special purpose realm is to allow devices from any manu= facturer to be directed to the AAA server of your choice. You only need set= up the server or add the forwarding once for all the devices from any manuf= acturer. Not everyone wants to depend on the device vendor's AAA service for security.Besides, depending on a ve= ndor service may not be always safe. As Stephen had pointed out in another = mail thread (https://www.ietf.org/mail-archive/web/ace/current/msg01470.ht= ml), commercial devices will be end-of-lifed by vendors, and yet they still nee= d to be functional for the owner.

/--Mohit<= /span>

On 02/18/2016 09:05 PM, Josh Ho= wlett wrote:

Sorry, ignore question 3, it ma= kes no sense here.

 

From: Josh Howlett
Sent: 18 February 2016 18:47
To: Aura Tuomas; Mohit Sethi; saag@ietf.org; emu@ietf.org
Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap= -noob-00.txt

 

Hi Aura,

 

A couple of other questions o= n the deployment theme:

 

1.       How would requests towards the single special p= eople realm get disambiguated among the multiple AAA servers?

2.       In fact, what’s the need for this special= purpose realm at all – why not let the vendor burn one into the firm= ware, and use an intermediate AAA routing fabric do the AAA server discover= y?

3.       Why this and not WPS (or something similar?)

 

Josh.

 

 

 

Sent from Outlook Mail for Windows 10 phone

 

From: Aura Tuomas
Sent: 18 February 2016 18:07
To: Josh Howlett; Mohit Sethi; saag@ietf.org; emu@ietf.org
Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap= -noob-00.txt

 

Hi Josh,

Good observation; we may need to be clearer about the intended usage scenar= ios for EAP-NOOB.

In the home setting, the AAA server would typically be a cloud-based servic= e, where the consumer can register a user account. This does require the 80= 2.1X authentication (i.e. WPA2-Enterprise) to be configured at the home NAS= , so that authentication for "@eap-noob.net" is forwarded to the cloud-based AAA server. You only need to configure the= NAS once, and all future devices can be connected without touching the NAS= .

This is a change from the way home wireless routers are configured today. W= e think that, as the number of IoT devices grows, configuring them with a s= hared passphrase will be too inconvenient. Obviously, the shared passphrase= is also vulnerable to a single untrusted IoT device that may leak the passphrase, and using EAP helps to = isolate the devices.

Of course, the benefits of EAP-NOOB will be greater in organizations which = already use 802.1X authentication and which have larger numbers of IoT devi= ces than a single home.

Anything else that we need to address?

Tuomas



-----Original Message-----
From: Josh Howlett [mailto:Josh.= Howlett@jisc.ac.uk]
Sent: Thursday, 18 February, 2016 19:28
To: Mohit Sethi <mohit.m.s= ethi@ericsson.com>; saag@ietf.org; emu@ietf.org
Cc: Aura Tuomas <tuomas.aura@aal= to.fi>
Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt

Hi Mohit,

This is an interesting draft, but I'm struggling to understand how this wou= ld be deployed in the consumer settings that the document alludes to. For e= xample, who do you anticipate will be operating the NAS (the consumer?), AA= A server (the vendor?), and the AAA fabric between these actors?

Josh.

> -----Original Message-----
> From: saag [mailto:saag-bounc= es@ietf.org] On Behalf Of Mohit Sethi
> Sent: 08 February 2016 15:34
> To: saag@ietf.org; emu@ietf.org
> Cc: tuomas.aura@aalto.fi > Subject: [saag] Fwd: New Version Notification for
> draft-aura-eap-noob-00.txt
>
> Dear all
>
> We have just submitted a new IETF Draft titled “Nimble out-of-ba= nd
> authentication for EAP (EAP-NOOB)”.
>
> The draft defines an EAP method where the authentication is based on a=
> user-assisted out-of-band (OOB) channel between the server and peer. <= br> > It is intended as a generic bootstrapping solution for
> Internet-of-Things devices which have no pre-configured authentication=
> credentials and which are not yet registered on the authentication > server. Consider devices you just bought or borrowed.
>
> The EAP-NOOB method is more generic than most ad-hoc bootstrapping > solutions in that it supports many types of OOB channels. We specify <= br> > the exact in-band messages but only the OOB message contents and not <= br> > the OOB channel details. Also, EAP-NOOB supports ubicomp devices with =
> only output (e.g. display) or only input (e.g. camera). Moreover, it <= br> > makes combined use of both secrecy and integrity of the OOB channel > for more robust security than the ad-hoc solutions. We have put a lot =
> of effort into designing a robust security protocol.
>
> For one application example, we have used an earlier version of the > protocol for bootstrapping security for ubiquitous displays: the user =
> can configure wireless network access, link the device to a cloud
> service, and register ownership of the device for a specific cloud > user – all in one simple step of scanning a QR code with a smart=
> phone. There seemed to more potential to this idea than just using it =
> for our own system, and thus we decided to write a generic EAP method = for out-of-band authentication.
>
> The draft is available here:
> https:/= /tools.ietf.org/html/draft-aura-eap-noob-00
>
> Please see if you can make use of it. We look forward to your feedback=
> and comments.
>
> Regards
> /--Mohit
>
>
> -------- Forwarded Message --------
> Subject:       New Version Notification = for draft-aura-eap-noob-00.txt
> Date:  Mon, 08 Feb 2016 04:30:35 -0800
> From:  internet-draft= s@ietf.org
> To:    Tuomas Aura <tuomas.aura@aalto.fi>, Mohit Sethi
> <mohit@piuha.net>
>
>
>
> A new version of I-D, draft-aura-eap-noob-00.txt has been successfully=
> submitted by Tuomas Aura and posted to the IETF repository.
>
> Name:         draft-aura-eap-n= oob
> Revision:     00
> Title:          &nbs= p;     Nimble out-of-band authentication for EAP (EAP-N= OOB)
> Document date:        2016-02-08 > Group:          &nbs= p;     Individual Submission
> Pages:          &nbs= p;     35
> URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-00.txt
> Status:https://datatracker.ietf.org/doc/draft-aura-eap-noob/
> Htmlized:https://tools.ietf.org/html/draft-aura-eap-noob-00
>
>
> Abstract:
>     Extensible Authentication Protocol (EAP) [RFC3= 748] provides support
>     for multiple authentication methods.  Thi= s document defines the EAP-
>     NOOB authentication method for nimble out-of-b= and (OOB)
>     authentication and key derivation.  This = EAP method is intended for
>     bootstrapping all kinds of Internet-of-Things = (IoT) devices that have
>     a minimal user interface and no pre-configured= authentication
>     credentials.  The method makes use of a u= ser-assisted one-directional
>     OOB channel between the peer device and authen= tication server.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.= ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.iet= f.org/mailman/listinfo/saag

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’s registered office is: One Castlepark, Tower Hill,= 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.  


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

 

--_000_7F9C975440487E49BBD35F4FB088ED74CFCEC2B1EXMDB01orgaalto_-- From nobody Thu Mar 3 02:18:11 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBCA1B409D for ; Thu, 3 Mar 2016 02:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2kL3Ke3mIQc for ; Thu, 3 Mar 2016 02:17:58 -0800 (PST) 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 A02731B409A for ; Thu, 3 Mar 2016 02:17:57 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0183.outbound.protection.outlook.com [213.199.154.183]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-8-PqBoY4X_Tdq_oXOqZHpmqg-1; Thu, 03 Mar 2016 10:17:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fZuBQFUjS1bHNAdInDa8rYvLvRfSQnyY44NYus1IemY=; b=GiN9vDMnANKSgZP9By2USfjuHUv3fpcLuN218WvzD2E5PHx4x+A1RMphf41WOwi60Mv7n5cQZyHSp9r7icw3KMRXDanaWAmnQ6Fq+xFnVuxOldSazXAY1j0Dfs8h7ZuOdT4o0+S8uglBaqFZk/KR7WyJXhUgM6d5cwy7Xjn7ijo= 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 (TLS) id 15.1.434.11; Thu, 3 Mar 2016 10:17:31 +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.0434.013; Thu, 3 Mar 2016 10:17:31 +0000 From: Josh Howlett To: Aura Tuomas , Mohit Sethi , "saag@ietf.org" Thread-Topic: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt Thread-Index: AQHRYoZDK9zX977Aak+i2I4nCLSSvZ8yG4LAgAAN+ACAAArkq4AABVRigBEpYICAAEYSoIAD7YMAgAALBdA= Date: Thu, 3 Mar 2016 10:17:30 +0000 Message-ID: References: <20160208123035.1562.80507.idtracker@ietfa.amsl.com> <56B8B561.8040300@ericsson.com> <7F9C975440487E49BBD35F4FB088ED74CFCDBF14@EXMDB01.org.aalto.fi> <56D47B79.7010306@ericsson.com> <7F9C975440487E49BBD35F4FB088ED74CFCEC2B1@EXMDB01.org.aalto.fi> In-Reply-To: <7F9C975440487E49BBD35F4FB088ED74CFCEC2B1@EXMDB01.org.aalto.fi> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.129.19.245] x-ms-office365-filtering-correlation-id: 82c3af7d-9b74-43c8-b60b-08d3434d07c1 x-microsoft-exchange-diagnostics: 1; VI1PR07MB1583; 5:m7ySh57wwQ+VBCkNI1vDMSHUfmACg8riTvUff7E8onn8oJJRH7yLfgkZkH1jAfjRYuFWnHa5q9SLy/tUUyBioxsKoDavqEFuXMT9L/t8IOcPyWLdhuWCjqi+zcEq72d+t+hJBelcQcZxN1mRp6Cmtw==; 24:lV7jky1nUVObDkRetYeg0av1/tWXRmnbX/L/mq+dCaPiLvCNP9yaxNqghclQvNsIHWBakhnUPbn2PZVDYxcIEcInvb+VY5GjyGKMxSZurEc=; 20:YAEJsEvZnjPAXAYsxDza3iOA99kJcB/+ATWkPBrO/mvKl/d7S4F5aORLTSwhBVkWvSYgy7n5N++gsUHobP9anRaZnUbiSca+5eV1OK0FFgJqkhQUyFcODKN4cVx2DNyb/NP/0YopyVKgQAnbfTcPzso4TrgG7N7ngKXnw87iXhQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1583; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:VI1PR07MB1583; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1583; x-forefront-prvs: 0870212862 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377424004)(2473001)(3905003)(479174004)(13464003)(43784003)(164054003)(24454002)(377454003)(86362001)(54356999)(76176999)(93886004)(92566002)(5003600100002)(40100003)(19580395003)(107886002)(87936001)(50986999)(19300405004)(5001960100004)(5001770100001)(74482002)(2420400007)(3900700001)(74316001)(3660700001)(15650500001)(2501003)(3280700002)(5004730100002)(19580405001)(2900100001)(586003)(1220700001)(6116002)(16236675004)(122556002)(102836003)(3846002)(106116001)(790700001)(10400500002)(15975445007)(77096005)(11100500001)(230783001)(7110500001)(19617315012)(10710500007)(19625215002)(76576001)(5008740100001)(5002640100001)(66066001)(33656002)(2906002)(1096002)(189998001)(2950100001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1583; H:VI1PR07MB1581.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2016 10:17:30.8862 (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: PqBoY4X_Tdq_oXOqZHpmqg-1 Content-Type: multipart/alternative; boundary="_000_VI1PR07MB1581902057E3BBE23C90642DBCBD0VI1PR07MB1581eurp_" Archived-At: Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 10:18:11 -0000 --_000_VI1PR07MB1581902057E3BBE23C90642DBCBD0VI1PR07MB1581eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Tuomas, I think it would be really helpful if you documented the intended deploymen= t ecosystem at a high level (consumer, enterprise, vendor, AAA providers, e= tc.) and how these map to the protocol actors. I think the lack of a model = results in ambiguity (at least in my own mind) as to how this could or shou= ld be deployed. You might want to do this in a separate document. The Introduction also points to the need for establishment of "credentials = for [...] authentication-security". The draft doesn't appear to address thi= s requirement. Is this intentional? Josh. From: Aura Tuomas [mailto:tuomas.aura@aalto.fi] Sent: 03 March 2016 09:20 To: Josh Howlett ; Mohit Sethi ; saag@ietf.org Subject: VS: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt Hi Josh, I think I got your point. There are two questions here. The first is about who will manage the AAA server for the devices. We have = primarily thought it will be the user organization, which may outsource the= authentication and authorization to a third party of their choice. You see= m to be thinking that the device vendors will run the AAA server for their = own devices. Both scenarios are certainly possible. The vendor-specific sol= ution would not necessarily even need standard for the EAP method because i= t could be specified by the vendor alone. We have focused on the scenario w= here the AAA server is not necessarily the device vendor, and a standard fo= r interoperability is needed. The second question is whether all the devices in the same user organizatio= n should be handled by one AAA server, or if there should be multiple class= es of devices that are handled by different AAA servers. Adding support for= device classes, e.g. as subdomains "XXX.eap-noob.net", is certainly possib= le. We'll think about this. I'm not sure about the extra complexity that it= will create. Tuomas L=E4hett=E4j=E4: Josh Howlett [mailto:Josh.Howlett@jisc.ac.uk] L=E4hetetty: Monday, 29 February, 2016 23:29 Vastaanottaja: Mohit Sethi >; Aura Tuomas >; saag@ietf.org Aihe: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.t= xt Hi Mohit, Thanks, but I still don't follow the use case. I thought the draft is tryin= g to address the scenario where I have devices from multiple vendors wantin= g to register themselves against each vendors' systems (e.g., my fridge reg= isters with my fridge vendor's AAA server; my washing machine with my washi= ng machine vendor's AAA server; etc.). How does my NAS know how to forward = a request to the correct realm if each request is using the same realm? Josh. From: Mohit Sethi [mailto:mohit.m.sethi@ericsson.com] Sent: 29 February 2016 17:10 To: Josh Howlett >;= Aura Tuomas >; Mohit Set= hi >; saag@ie= tf.org Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt Hi Josh Thanks again for your useful questions. 1. The requests for "eap-noob.net" would either be served by a local AAA se= rver or a remote AAA server for which a forwarding rule has been added. The= request would not be forwarded to a global server based on DNS lookups. He= nce, a DNS lookup for eap-noob.net is expected to respond with NXDOMAIN. 2. The need for the special purpose realm is to allow devices from any manu= facturer to be directed to the AAA server of your choice. You only need set= up the server or add the forwarding once for all the devices from any manuf= acturer. Not everyone wants to depend on the device vendor's AAA service fo= r security.Besides, depending on a vendor service may not be always safe. A= s Stephen had pointed out in another mail thread (https://www.ietf.org/mail= -archive/web/ace/current/msg01470.html), commercial devices will be end-of-= lifed by vendors, and yet they still need to be functional for the owner. /--Mohit On 02/18/2016 09:05 PM, Josh Howlett wrote: Sorry, ignore question 3, it makes no sense here. From: Josh Howlett Sent: 18 February 2016 18:47 To: Aura Tuomas; Mohit Sethi; saag@ietf.org; emu@ietf.org Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt Hi Aura, A couple of other questions on the deployment theme: 1. How would requests towards the single special people realm get dis= ambiguated among the multiple AAA servers? 2. In fact, what's the need for this special purpose realm at all - w= hy not let the vendor burn one into the firmware, and use an intermediate A= AA routing fabric do the AAA server discovery? 3. Why this and not WPS (or something similar?) Josh. Sent from Outlook Mail fo= r Windows 10 phone From: Aura Tuomas Sent: 18 February 2016 18:07 To: Josh Howlett; Mohit Sethi; saag@ietf.org; emu@ietf.org Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt Hi Josh, Good observation; we may need to be clearer about the intended usage scenar= ios for EAP-NOOB. In the home setting, the AAA server would typically be a cloud-based servic= e, where the consumer can register a user account. This does require the 80= 2.1X authentication (i.e. WPA2-Enterprise) to be configured at the home NAS= , so that authentication for "@eap-noob.net" is forwarded to the cloud-base= d AAA server. You only need to configure the NAS once, and all future devic= es can be connected without touching the NAS. This is a change from the way home wireless routers are configured today. W= e think that, as the number of IoT devices grows, configuring them with a s= hared passphrase will be too inconvenient. Obviously, the shared passphrase= is also vulnerable to a single untrusted IoT device that may leak the pass= phrase, and using EAP helps to isolate the devices. Of course, the benefits of EAP-NOOB will be greater in organizations which = already use 802.1X authentication and which have larger numbers of IoT devi= ces than a single home. Anything else that we need to address? Tuomas -----Original Message----- From: Josh Howlett [mailto:Josh.Howlett@jisc.ac.uk] Sent: Thursday, 18 February, 2016 19:28 To: Mohit Sethi ; saag@ietf.org; emu@ietf.org Cc: Aura Tuomas Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt Hi Mohit, This is an interesting draft, but I'm struggling to understand how this wou= ld be deployed in the consumer settings that the document alludes to. For e= xample, who do you anticipate will be operating the NAS (the consumer?), AA= A server (the vendor?), and the AAA fabric between these actors? Josh. > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Mohit Sethi > Sent: 08 February 2016 15:34 > To: saag@ietf.org; emu@ietf.org > Cc: tuomas.aura@aalto.fi > Subject: [saag] Fwd: New Version Notification for > draft-aura-eap-noob-00.txt > > Dear all > > We have just submitted a new IETF Draft titled "Nimble out-of-band > authentication for EAP (EAP-NOOB)". > > The draft defines an EAP method where the authentication is based on a > user-assisted out-of-band (OOB) channel between the server and peer. > It is intended as a generic bootstrapping solution for > Internet-of-Things devices which have no pre-configured authentication > credentials and which are not yet registered on the authentication > server. Consider devices you just bought or borrowed. > > The EAP-NOOB method is more generic than most ad-hoc bootstrapping > solutions in that it supports many types of OOB channels. We specify > the exact in-band messages but only the OOB message contents and not > the OOB channel details. Also, EAP-NOOB supports ubicomp devices with > only output (e.g. display) or only input (e.g. camera). Moreover, it > makes combined use of both secrecy and integrity of the OOB channel > for more robust security than the ad-hoc solutions. We have put a lot > of effort into designing a robust security protocol. > > For one application example, we have used an earlier version of the > protocol for bootstrapping security for ubiquitous displays: the user > can configure wireless network access, link the device to a cloud > service, and register ownership of the device for a specific cloud > user - all in one simple step of scanning a QR code with a smart > phone. There seemed to more potential to this idea than just using it > for our own system, and thus we decided to write a generic EAP method for= out-of-band authentication. > > The draft is available here: > https://tools.ietf.org/html/draft-aura-eap-noob-00 > > Please see if you can make use of it. We look forward to your feedback > and comments. > > Regards > /--Mohit > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-aura-eap-noob-00.txt > Date: Mon, 08 Feb 2016 04:30:35 -0800 > From: internet-drafts@ietf.org > To: Tuomas Aura , M= ohit Sethi > > > > > A new version of I-D, draft-aura-eap-noob-00.txt has been successfully > submitted by Tuomas Aura and posted to the IETF repository. > > Name: draft-aura-eap-noob > Revision: 00 > Title: Nimble out-of-band authentication for EAP (EAP-NOOB= ) > Document date: 2016-02-08 > Group: Individual Submission > Pages: 35 > URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-00.txt > Status:https://datatracker.ietf.org/doc/draft-aura-eap-noob/ > Htmlized:https://tools.ietf.org/html/draft-aura-eap-noob-00 > > > Abstract: > Extensible Authentication Protocol (EAP) [RFC3748] provides support > for multiple authentication methods. This document defines the EAP- > NOOB authentication method for nimble out-of-band (OOB) > authentication and key derivation. This EAP method is intended for > bootstrapping all kinds of Internet-of-Things (IoT) devices that have > a minimal user interface and no pre-configured authentication > credentials. The method makes use of a user-assisted one-directional > OOB channel between the peer device and authentication server. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. > > The IETF Secretariat > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag 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's registered office is: One Castlepark, Tower Hill, Brist= ol, 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. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --_000_VI1PR07MB1581902057E3BBE23C90642DBCBD0VI1PR07MB1581eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Hi Tuomas,

 

I think it would be really helpful if you documented the intended depl= oyment ecosystem at a high level (consumer, enterprise, vendor, AAA provide= rs, etc.) and how these map to the protocol actors. I think the lack of a model results in ambiguity (at least in my o= wn mind) as to how this could or should be deployed. You might want to do t= his in a separate document.

 

The Introduction also points to the need for establishment of “c= redentials for […] authentication-security”. The draft doesn= 217;t appear to address this requirement. Is this intentional?

 

Josh.

 

F= rom: Aura Tuomas= [mailto:tuomas.aura@aalto.fi]
Sent: 03 March 2016 09:20
To: Josh Howlett <Josh.Howlett@jisc.ac.uk>; Mohit Sethi <mo= hit.m.sethi@ericsson.com>; saag@ietf.org
Subject: VS: [saag] Fwd: New Version Notification for draft-aura-eap= -noob-00.txt

 

Hi J= osh,

 

I th= ink I got your point. There are two questions here.

 

The = first is about who will manage the AAA server for the devices. We have prim= arily thought it will be the user organization, which may outsource the aut= hentication and authorization to a third party of their choice. You seem to be thinking that the device vendors wil= l run the AAA server for their own devices. Both scenarios are certainly po= ssible. The vendor-specific solution would not necessarily even need standa= rd for the EAP method because it could be specified by the vendor alone. We have focused on the scenario wh= ere the AAA server is not necessarily the device vendor, and a standard for= interoperability is needed.

 

The = second question is whether all the devices in the same user organization sh= ould be handled by one AAA server, or if there should be multiple classes o= f devices that are handled by different AAA servers. Adding support for device classes, e.g. as subdomains “= XXX.eap-noob.net”, is certainly possible. We’ll think about thi= s. I’m not sure about the extra complexity that it will create.

 

Tuom= as

 

 

 

L= =E4hett=E4j=E4: = Josh Howlett [mailto:Josh.Howlet= t@jisc.ac.uk]
L=E4hetetty: Monday, 29 February, 2016 23:29
Vastaanottaja= : Mohit Sethi <<= a href=3D"mailto:mohit.m.sethi@ericsson.com">mohit.m.sethi@ericsson.com= >; Aura Tuomas <tuomas.aura@a= alto.fi>; saag@ietf.org
Aihe: RE: [saag] Fwd: New Version Notification for draft-aura-eap-no= ob-00.txt

 

Hi Mohit,

 

Thanks, but I still do= n’t follow the use case. I thought the draft is trying to address the= scenario where I have devices from multiple vendors wanting to register th= emselves against each vendors’ systems (e.g., my fridge registers with my fridge vendor’s AAA server; my washing m= achine with my washing machine vendor’s AAA server; etc.). How does m= y NAS know how to forward a request to the correct realm if each request is= using the same realm?

 

Josh.

 

F= rom: Mohit Sethi= [mailto:mohit.m.sethi@ericss= on.com]
Sent: 29 February 2016 17:10
To: Josh Howlett <Josh= .Howlett@jisc.ac.uk>; Aura Tuomas <tuomas.aura@aalto.fi>; Mohit Sethi <mohit.m.sethi@ericsson.com>; saag@ietf.org
Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap= -noob-00.txt

 

Hi Josh

Thanks again for your useful questions.

1. The requests for "eap-noob.net" would either be served by a lo= cal AAA server or a remote AAA server for which a forwarding rule has been = added. The request would not be forwarded to a global server based on DNS l= ookups. Hence, a DNS lookup for eap-noob.net is expected to respond with NXDOMAIN.

2. The need for the special purpose realm is to allow devices from any manu= facturer to be directed to the AAA server of your choice. You only need set= up the server or add the forwarding once for all the devices from any manuf= acturer. Not everyone wants to depend on the device vendor's AAA service for security.Besides, depending on a ve= ndor service may not be always safe. As Stephen had pointed out in another = mail thread (https://www.ietf.org/mail-archive/web/ace/current/msg01470.ht= ml), commercial devices will be end-of-lifed by vendors, and yet they still nee= d to be functional for the owner.

/--Mohit

On 02/18/2016 09:05 PM, Josh Howlett wrote:

Sorry, ignore question 3, it makes no sense here.

 

From: Josh Howlett
Sent: 18 February 2016 18:47
To: Aura Tuomas; Mohit Sethi; saag@ietf.org; emu@ietf.org
Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap= -noob-00.txt

 

Hi Aura,

 

A couple of other questions on the deployment them= e:

 

1. &n= bsp;     How would requests towards the single special people realm get disam= biguated among the multiple AAA servers?

2. &n= bsp;     In fact, what’s the need for this special purpose realm at all= – why not let the vendor burn one into the firmware, and use an inte= rmediate AAA routing fabric do the AAA server discovery?

3. &n= bsp;     Why this and not WPS (or something similar?)

 

Josh.

 

 

 

Sent from Outlook Mail for Windows 10 phone

 

From: Aura Tuomas
Sent: 18 February 2016 18:07
To: Josh Howlett; Mohit Sethi; saag@ietf.org; emu@ietf.org
Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap= -noob-00.txt

 

Hi Josh,

Good observation; we may need to be clearer about the intended usage scenar= ios for EAP-NOOB.

In the home setting, the AAA server would typically be a cloud-based servic= e, where the consumer can register a user account. This does require the 80= 2.1X authentication (i.e. WPA2-Enterprise) to be configured at the home NAS= , so that authentication for "@eap-noob.net" is forwarded to the cloud-based AAA server. You only need to configure the= NAS once, and all future devices can be connected without touching the NAS= .

This is a change from the way home wireless routers are configured today. W= e think that, as the number of IoT devices grows, configuring them with a s= hared passphrase will be too inconvenient. Obviously, the shared passphrase= is also vulnerable to a single untrusted IoT device that may leak the passphrase, and using EAP helps to = isolate the devices.

Of course, the benefits of EAP-NOOB will be greater in organizations which = already use 802.1X authentication and which have larger numbers of IoT devi= ces than a single home.

Anything else that we need to address?

Tuomas



-----Original Message-----
From: Josh Howlett [mailto:Josh.= Howlett@jisc.ac.uk]
Sent: Thursday, 18 February, 2016 19:28
To: Mohit Sethi <mohit.m.s= ethi@ericsson.com>; saag@ietf.org; emu@ietf.org
Cc: Aura Tuomas <tuomas.aura@aal= to.fi>
Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt

Hi Mohit,

This is an interesting draft, but I'm struggling to understand how this wou= ld be deployed in the consumer settings that the document alludes to. For e= xample, who do you anticipate will be operating the NAS (the consumer?), AA= A server (the vendor?), and the AAA fabric between these actors?

Josh.

> -----Original Message-----
> From: saag [mailto:saag-bounc= es@ietf.org] On Behalf Of Mohit Sethi
> Sent: 08 February 2016 15:34
> To: saag@ietf.org; emu@ietf.org
> Cc: tuomas.aura@aalto.fi > Subject: [saag] Fwd: New Version Notification for
> draft-aura-eap-noob-00.txt
>
> Dear all
>
> We have just submitted a new IETF Draft titled “Nimble out-of-ba= nd
> authentication for EAP (EAP-NOOB)”.
>
> The draft defines an EAP method where the authentication is based on a=
> user-assisted out-of-band (OOB) channel between the server and peer. <= br> > It is intended as a generic bootstrapping solution for
> Internet-of-Things devices which have no pre-configured authentication=
> credentials and which are not yet registered on the authentication > server. Consider devices you just bought or borrowed.
>
> The EAP-NOOB method is more generic than most ad-hoc bootstrapping > solutions in that it supports many types of OOB channels. We specify <= br> > the exact in-band messages but only the OOB message contents and not <= br> > the OOB channel details. Also, EAP-NOOB supports ubicomp devices with =
> only output (e.g. display) or only input (e.g. camera). Moreover, it <= br> > makes combined use of both secrecy and integrity of the OOB channel > for more robust security than the ad-hoc solutions. We have put a lot =
> of effort into designing a robust security protocol.
>
> For one application example, we have used an earlier version of the > protocol for bootstrapping security for ubiquitous displays: the user =
> can configure wireless network access, link the device to a cloud
> service, and register ownership of the device for a specific cloud > user – all in one simple step of scanning a QR code with a smart=
> phone. There seemed to more potential to this idea than just using it =
> for our own system, and thus we decided to write a generic EAP method = for out-of-band authentication.
>
> The draft is available here:
> https:/= /tools.ietf.org/html/draft-aura-eap-noob-00
>
> Please see if you can make use of it. We look forward to your feedback=
> and comments.
>
> Regards
> /--Mohit
>
>
> -------- Forwarded Message --------
> Subject:       New Version Notification = for draft-aura-eap-noob-00.txt
> Date:  Mon, 08 Feb 2016 04:30:35 -0800
> From:  internet-draft= s@ietf.org
> To:    Tuomas Aura <tuomas.aura@aalto.fi>, Mohit Sethi
> <mohit@piuha.net>
>
>
>
> A new version of I-D, draft-aura-eap-noob-00.txt has been successfully=
> submitted by Tuomas Aura and posted to the IETF repository.
>
> Name:         draft-aura-eap-n= oob
> Revision:     00
> Title:          &nbs= p;     Nimble out-of-band authentication for EAP (EAP-N= OOB)
> Document date:        2016-02-08 > Group:          &nbs= p;     Individual Submission
> Pages:          &nbs= p;     35
> URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-00.txt
> Status:https://datatracker.ietf.org/doc/draft-aura-eap-noob/
> Htmlized:https://tools.ietf.org/html/draft-aura-eap-noob-00
>
>
> Abstract:
>     Extensible Authentication Protocol (EAP) [RFC3= 748] provides support
>     for multiple authentication methods.  Thi= s document defines the EAP-
>     NOOB authentication method for nimble out-of-b= and (OOB)
>     authentication and key derivation.  This = EAP method is intended for
>     bootstrapping all kinds of Internet-of-Things = (IoT) devices that have
>     a minimal user interface and no pre-configured= authentication
>     credentials.  The method makes use of a u= ser-assisted one-directional
>     OOB channel between the peer device and authen= tication server.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.= ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.iet= f.org/mailman/listinfo/saag

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’s registered office is: One Castlepark, Tower Hill,= 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. 

 = 

_=
______________________________________________
s=
aag mailing list
<=
a href=3D"mailto:saag@ietf.org">saag@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/saag">https://www.ietf.org/=
mailman/listinfo/saag

 

--_000_VI1PR07MB1581902057E3BBE23C90642DBCBD0VI1PR07MB1581eurp_-- From nobody Thu Mar 3 03:34:15 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B371A9069 for ; Thu, 3 Mar 2016 03:34:14 -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, 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 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 08MaPIl_hsPn for ; Thu, 3 Mar 2016 03:34:10 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0093.outbound.protection.outlook.com [23.103.201.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4083A1A906C for ; Thu, 3 Mar 2016 03:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QyiproGh2mHCAkQ+7pKcLrLy3OQLY6KDjRiF3cgVT7s=; b=1OegmbWFn+1tgbAq1PoyBKMpKROQAPV3yV1iRcG33Oj7Fm9GOOSqMQVyHAJXAueL7FjVM9SGUAUYybzVL1e156QH/Db3rAnpjEjXZvBldDK8WVbMMOtZoToPQip0l753r/aNWKZZHAgnPGSKaPes/ey8F+Y3yxNTiXD/Ue++Iq4= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) with Microsoft SMTP Server (TLS) id 15.1.415.20; Thu, 3 Mar 2016 11:34:08 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0415.024; Thu, 3 Mar 2016 11:34:08 +0000 From: "Dang, Quynh (Fed)" To: "saag@ietf.org" , "noloader@gmail.com" Thread-Topic: [saag] RFC 6979, Deterministic Signatures for DSA/ECDSA using SHA3? Thread-Index: AQHRdBgmZtHdGiUwiEaUZgsEaiPh6p9HlB+4 Date: Thu, 3 Mar 2016 11:34:07 +0000 Message-ID: References: In-Reply-To: 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.105.150] x-microsoft-exchange-diagnostics: 1; BN1PR09MB124; 5:dPqqsMwqpbUXc8t/A+/YZQgTdXceM2Vgu4p1ZQq8Zuo9Jj0PM9AxsVlUP0TQU47YPELteJX9W5CfuBoTPShm0HQYLP/OdTh7bjN0RdIvIeKSg2YsWgObMU271uIlYlxkdlNNbZNVGPe7CKX3HlZGSA==; 24:n7KE3QzjbA5W/2OTL+VuvDYHe97BbA6s8Ysu5Xj5lt9iuwHRIdsNxd1+kugSlilQICkaSg47PK9vS445Yb6kDpQPsTa+wyDpxsGEioF26Cs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB124; x-ms-office365-filtering-correlation-id: f6176f23-a3dd-43d4-7067-08d34357bbd2 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN1PR09MB124; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB124; x-forefront-prvs: 0870212862 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(53754006)(1096002)(3846002)(1220700001)(54356999)(50986999)(15975445007)(102836003)(76176999)(76576001)(6116002)(2906002)(5008740100001)(5001770100001)(77096005)(107886002)(74316001)(3280700002)(5002640100001)(11100500001)(66066001)(586003)(3660700001)(86362001)(2501003)(3900700001)(87936001)(106116001)(92566002)(5001960100004)(189998001)(2950100001)(122556002)(19580405001)(33656002)(5004730100002)(10400500002)(5003600100002)(40100003)(19580395003)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB124; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2016 11:34:07.3436 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB124 Archived-At: Subject: Re: [saag] RFC 6979, Deterministic Signatures for DSA/ECDSA using SHA3? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 11:34:14 -0000 Hi Jeff, One can use SHA3-224, SHA3-256, SHA3-384 and SHA3-512 as drop-in replacemen= ts for SHA2s in the HMAC construction. =20 In addition, we are specifying two more efficient MAC constructions from Ke= ccak. The first one is a single-pass MAC which does not use the HMAC construction= to produce Mac tags.=20 The second one is to use the SHAKE128 and SHAKE256 in the HMAC construction= . We are working on a formal specification of the SHAKEs being used as fix= ed output-length hash functions. Fixed output-length hash functions can be = used in the HMAC construction.=20 The first one (single-pass MAC) is the most efficient option. Quynh.=20 ________________________________________ From: saag on behalf of Jeffrey Walton Sent: Tuesday, March 1, 2016 7:11 PM To: saag@ietf.org Subject: [saag] RFC 6979, Deterministic Signatures for DSA/ECDSA using SHA3= ? Hi Everyone, How does one use SHA-3 with a deterministic DSA/ECDSA signature under RFC 6= 979? Has anyone defined what HMAC/SHA-3 means? Jeff _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag= From nobody Fri Mar 4 06:40:35 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C688C1A0A6A for ; Fri, 4 Mar 2016 06:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSlzSax04Jdl for ; Fri, 4 Mar 2016 06:40:32 -0800 (PST) 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 7AF051A03A1 for ; Fri, 4 Mar 2016 06:40:32 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id k1so39080530vkb.0 for ; Fri, 04 Mar 2016 06:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=plzmjtcjcbJzb8PF1UDrkZrNVcukrR0UdFJk3P8YJwQ=; b=sneugOjrFQrQrIqwcfTROHQFZJIF6QGyhCQy6/hrH/uEMOfjiqXwVarmE3KPEdpiB4 OvniuJUDEggMLp/04j0EztJIAVai2xryCSwlD2W5vKv573szqVNHO7W7S93AUKIxxfy3 1+L6+JBR8BBHKbUjWMil9g0pQt5FHlYt6gk7I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=plzmjtcjcbJzb8PF1UDrkZrNVcukrR0UdFJk3P8YJwQ=; b=ORETfCPZCG6NE9BZrcM3tvxNkfF2bMY9eTQY47I9m+j0SGaQag9Dm3I5e8wPTb3pa3 aitMq0b0rL7uCg1vif4SWrlbfj3ufRqivXlx2Iqg3ISrKOF3d3YbRoN+mkfTvDKkFSDN GW7zOZUDQXqAPAsqkmxbuHuCJPU75JP1fhmUYZNDsT8fwlfD3a1wfTYWrw9UpPruLEjV 55igMVBHLW3bCK50Jzmxzp5wwVquJ/BXMftl4Dpbq5E48UdsBKi+yMR5glSJkNI4wbrx tCkJrXzBmcigRKfTWZj3WwebGmIE4RDLoxJOTSCjEJdUoLR6lYCXYEqQbJIYeHjrq+yD bKjw== X-Gm-Message-State: AD7BkJKk4AhDxTTkKj9hCsn7ns43TMrICo1qin/2jm5Zax8KRQEQldH3oWIVS3XFjEH6r1Rz0LI+gBUv+JAJAl9A X-Received: by 10.31.151.75 with SMTP id z72mr5919169vkd.104.1457102431546; Fri, 04 Mar 2016 06:40:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.76.7 with HTTP; Fri, 4 Mar 2016 06:40:12 -0800 (PST) In-Reply-To: <56D62BC7.50003@si6networks.com> References: <20160204162945.16956.31282.idtracker@ietfa.amsl.com> <56B38293.6000800@si6networks.com> <56D62BC7.50003@si6networks.com> From: Joseph Lorenzo Hall Date: Fri, 4 Mar 2016 09:40:12 -0500 Message-ID: To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "privsec-program@iab.org" , Greg Norcie , "saag@ietf.org" , =?UTF-8?Q?Iv=C3=A1n_Arce?= Subject: Re: [saag] Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols (Fwd: New Version Notification for draft-gont-predictable-numeric-ids-00.txt) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 14:40:34 -0000 On Tue, Mar 1, 2016 at 6:54 PM, Fernando Gont wrote: > > Yes, that's the intent: a BCP of similar nature to BCP 106/RFC 4086 > which should be applied everytime a new numeric identifier is specified > in a new protocol. And could b applied to existing protocols were the > corresponding spec still allows or suggest the use of numeric > identifiers that have negative security/privacy implications. Superb! >> * I was expecting to see at some point a list of common >> vulnerabilities or bad design patterns with unique identifiers. E.g., >> "predictable identifiers", "predictable offsets in identifier >> sequences", > > This is discussed throughout the document for each algorithm that > results in predictable identifiers. For example, Section 7.4.1 (page > 15), states: > > If a global counter is used (such as "next_id" in the example above), > a node that learns one protocol identifier can also learn or guess > values employed by past and future protocol instances. On the other > hand, when the value of increments is known (such as "1" in this > case), an attacker can sample two values, and learn the number of > identifiers that were generated in-between. > > > The consequences of an attacker learning "values employed by past and > future protocol instances" or "the number of identifiers that were > generated in-between" varies from one protocol to another. e.g., in the > case of TCP ephemeral ports, predicting ephemeral ports would be of help > for the attacker to perform e.g. TCP reset attacks, whereas "learning > the number of ephemeral pots generated between two outgoing connections" > would be an information leakage about the number of outgoing > connections established by the victim (which might be of use in certain > scenarios). > > OTOH, Sections 4.1 and 4.2 illustrate how predictable numeric IDs were > found to be useful for performing different kinds of attacks. > > mmm.. were you expecting, in all of the sections that discuss specific > algorithms, references/links to how such vulnerable algorithms result in > specific vulnerabilities when applied to different protocols? (i.e., > kind of a cross-reference), or something else? I guess I found the discussion of specific vulnerabilities to be a bit abstract, but that could just be me with lower brain power than you authors. ::) If you feel it would be a good addition, links to examples of these kinds of vulnerabilities (either theoretical or in attacks in the field) would help make it a bit more concrete. Happy to try and help find some of these if you decide it would be a good addition. >> "embedding IDs from one context into another" (see: >> https://tools.ietf.org/html/draft-huitema-dhc-anonymity-profile ). > > We didn't cover "embedding IDs from one context into another". In > principle, you just shouldn't do this, since this is kind of what we > refer to as "Protocol specifications that over-specify their > identifiers", in the sense that, when you employ a numeric identifier in > a different context, you're implicitly enforcing requirements that you > usually don't really need in the new context. -- e.g., using a MAC > address to generate a DHCP DUID leaks information that you don't eally > need to leak for complying with the corresponding *interoperability* > requirements (uniqueness). That sounds reasonable... >> I'm >> not sure if section 8 lists vulnerabilities or something else (or if >> what I'm thinking of are not vulnerabilities). For example, where does >> the reuse of an identifier -- like that described across layers in >> draft-huitema-dhc-anonymity-profile -- fit in your scheme? > > As noted above, this one is not explicitly noted -- maybe we could say > what I mentioned above ("this results in over-specification of the > numeric id") in Section 3 of the document? Yes, it would be good to have a "don't do this, it's so stupid we don't even cover it here" section about these kinds of cross-protocol or over-specification examples. Again, thanks for taking this on. best, Joe -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 CDT's annual dinner, Tech Prom, is April 6, 2016! https://cdt.org/annual-dinner From nobody Sun Mar 6 23:02:09 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541981B3552 for ; Sun, 6 Mar 2016 23:02:08 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nMISf6bJjPf for ; Sun, 6 Mar 2016 23:02:06 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3043D1B354F for ; Sun, 6 Mar 2016 23:02:06 -0800 (PST) Received: from [IPv6:2001:1291:200:42e::2] (cl-1071.udi-01.br.sixxs.net [IPv6:2001:1291:200:42e::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 0E346801D0; Mon, 7 Mar 2016 08:01:58 +0100 (CET) To: Joseph Lorenzo Hall References: <20160204162945.16956.31282.idtracker@ietfa.amsl.com> <56B38293.6000800@si6networks.com> <56D62BC7.50003@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56DD26D5.1080908@si6networks.com> Date: Mon, 7 Mar 2016 03:59:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "privsec-program@iab.org" , Greg Norcie , "saag@ietf.org" , =?UTF-8?Q?Iv=c3=a1n_Arce?= Subject: Re: [saag] Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols (Fwd: New Version Notification for draft-gont-predictable-numeric-ids-00.txt) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 07:02:08 -0000 Hi, Joseph,>>> * I was expecting to see at some point a list of common >>> vulnerabilities or bad design patterns with unique identifiers. E.g., >>> "predictable identifiers", "predictable offsets in identifier >>> sequences", >> >> This is discussed throughout the document for each algorithm that >> results in predictable identifiers. For example, Section 7.4.1 (page >> 15), states: >> >> If a global counter is used (such as "next_id" in the example above), >> a node that learns one protocol identifier can also learn or guess >> values employed by past and future protocol instances. On the other >> hand, when the value of increments is known (such as "1" in this >> case), an attacker can sample two values, and learn the number of >> identifiers that were generated in-between. >> >> >> The consequences of an attacker learning "values employed by past and >> future protocol instances" or "the number of identifiers that were >> generated in-between" varies from one protocol to another. e.g., in the >> case of TCP ephemeral ports, predicting ephemeral ports would be of help >> for the attacker to perform e.g. TCP reset attacks, whereas "learning >> the number of ephemeral pots generated between two outgoing connections" >> would be an information leakage about the number of outgoing >> connections established by the victim (which might be of use in certain >> scenarios). >> >> OTOH, Sections 4.1 and 4.2 illustrate how predictable numeric IDs were >> found to be useful for performing different kinds of attacks. >> >> mmm.. were you expecting, in all of the sections that discuss specific >> algorithms, references/links to how such vulnerable algorithms result in >> specific vulnerabilities when applied to different protocols? (i.e., >> kind of a cross-reference), or something else? > > I guess I found the discussion of specific vulnerabilities to be a bit > abstract, but that could just be me with lower brain power than you > authors. ::) If you feel it would be a good addition, links to > examples of these kinds of vulnerabilities (either theoretical or in > attacks in the field) would help make it a bit more concrete. We'll do that! >>> "embedding IDs from one context into another" (see: >>> https://tools.ietf.org/html/draft-huitema-dhc-anonymity-profile ). >> >> We didn't cover "embedding IDs from one context into another". In >> principle, you just shouldn't do this, since this is kind of what we >> refer to as "Protocol specifications that over-specify their >> identifiers", in the sense that, when you employ a numeric identifier in >> a different context, you're implicitly enforcing requirements that you >> usually don't really need in the new context. -- e.g., using a MAC >> address to generate a DHCP DUID leaks information that you don't eally >> need to leak for complying with the corresponding *interoperability* >> requirements (uniqueness). > > That sounds reasonable... > >>> I'm >>> not sure if section 8 lists vulnerabilities or something else (or if >>> what I'm thinking of are not vulnerabilities). For example, where does >>> the reuse of an identifier -- like that described across layers in >>> draft-huitema-dhc-anonymity-profile -- fit in your scheme? >> >> As noted above, this one is not explicitly noted -- maybe we could say >> what I mentioned above ("this results in over-specification of the >> numeric id") in Section 3 of the document? > > Yes, it would be good to have a "don't do this, it's so stupid we > don't even cover it here" section about these kinds of cross-protocol > or over-specification examples. We'll add this to the next rev. Plan is to rev this doc next week or so (before the I-D submission cutoff). Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Mar 7 07:47:33 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61731B432D for ; Mon, 7 Mar 2016 07:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYoQXjUB8N3M for ; Mon, 7 Mar 2016 07:47:27 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFCC21B432C for ; Mon, 7 Mar 2016 07:47:17 -0800 (PST) X-AuditID: c1b4fb30-f79d26d000006389-75-56dda2837849 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 65.EE.25481.382ADD65; Mon, 7 Mar 2016 16:47:16 +0100 (CET) Received: from nomadiclab.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.248.2; Mon, 7 Mar 2016 16:47:15 +0100 Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 802D04E9FC; Mon, 7 Mar 2016 17:50:10 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C1D304E9B6; Mon, 7 Mar 2016 17:50:09 +0200 (EET) To: Josh Howlett , Aura Tuomas , "saag@ietf.org" References: <20160208123035.1562.80507.idtracker@ietfa.amsl.com> <56B8B561.8040300@ericsson.com> <7F9C975440487E49BBD35F4FB088ED74CFCDBF14@EXMDB01.org.aalto.fi> <56D47B79.7010306@ericsson.com> <7F9C975440487E49BBD35F4FB088ED74CFCEC2B1@EXMDB01.org.aalto.fi> From: Mohit Sethi Message-ID: <56DDA284.2030200@ericsson.com> Date: Mon, 7 Mar 2016 17:47:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090404060807010204020301" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7h27LorthBrtXcVlcu/mI3WJKfyeT xZuJG9kdmD2Ov17M6rFkyU8mj5W/r7AFMEdx2aSk5mSWpRbp2yVwZbxpXcBYsHQac8WGM59Z GhjvT2bqYuTkkBAwkdj3fy+ULSZx4d56ti5GLg4hgcOMEt833GGEcLYySsxo2MAMUiUksJZR 4vj9VAh7HqPEhffmILawQJDE5HUTGEFsEYFCiZPX3jBDNC9nldjU8Y4FJMEmoCfRee442CBe AW2JX/vmsoHYLAIqEm/v3AarERWIkDjc2cUOUSMocXLmE7A4p0CsxOmul2D1zAJhEn82XmaB OFtN4uq5TVDHqUts7TjAOIFRaBaS9llIWmYxcgDZ9hIPtpZBhOUlmrfOZoaw9SWu37nPiiy+ gJFtFaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZgpBzc8ttgB+PL546HGAU4GJV4eD+o3Q0T Yk0sK67MPcQowcGsJMIbNB8oxJuSWFmVWpQfX1Sak1p8iFGag0VJnJf10+UwIYH0xJLU7NTU gtQimCwTB6dUA2PtecWCzeoW27+kOczsXv8tafuZgEfrqxZf7+9LlVrmyXRvh+nX//x7by/S OKOX9dRa18uSiT91eav8IZ89n5mbW6vmrdr9+nOlt9jVD7Nn+Uya6DZJxlRgurN9iZnumXXG 396w5K9qVf8f+76qiL1P8K/SqQSlLRy/FvbWb2UqYbr7Vf2m/GUlluKMREMt5qLiRAAuMLh6 kAIAAA== Archived-At: Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 15:47:32 -0000 --------------090404060807010204020301 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Hi Josh Thanks for the suggestion. It is a good idea to document the ecosystem assumptions. When writing about our own ideas it is easy to think that the design assumptions are obvious. Regarding credentials for authentication, OOB authentication is an alternative to pre-established credentials. The secure channel created with OOB authentication could be used for setting up other credentials, such as a device certificate, but doing that is outside our protocol. /--Mohit On 03/03/2016 12:17 PM, Josh Howlett wrote: > > Hi Tuomas, > > I think it would be really helpful if you documented the intended > deployment ecosystem at a high level (consumer, enterprise, vendor, > AAA providers, etc.) and how these map to the protocol actors. I think > the lack of a model results in ambiguity (at least in my own mind) as > to how this could or should be deployed. You might want to do this in > a separate document. > > The Introduction also points to the need for establishment of > “credentials for […] authentication-security”. The draft doesn’t > appear to address this requirement. Is this intentional? > > Josh. > > *From:*Aura Tuomas [mailto:tuomas.aura@aalto.fi] > *Sent:* 03 March 2016 09:20 > *To:* Josh Howlett ; Mohit Sethi > ; saag@ietf.org > *Subject:* VS: [saag] Fwd: New Version Notification for > draft-aura-eap-noob-00.txt > > Hi Josh, > > I think I got your point. There are two questions here. > > The first is about who will manage the AAA server for the devices. We > have primarily thought it will be the user organization, which may > outsource the authentication and authorization to a third party of > their choice. You seem to be thinking that the device vendors will run > the AAA server for their own devices. Both scenarios are certainly > possible. The vendor-specific solution would not necessarily even need > standard for the EAP method because it could be specified by the > vendor alone. We have focused on the scenario where the AAA server is > not necessarily the device vendor, and a standard for interoperability > is needed. > > The second question is whether all the devices in the same user > organization should be handled by one AAA server, or if there should > be multiple classes of devices that are handled by different AAA > servers. Adding support for device classes, e.g. as subdomains > “XXX.eap-noob.net”, is certainly possible. We’ll think about this. I’m > not sure about the extra complexity that it will create. > > Tuomas > > *Lähettäjä:*Josh Howlett [mailto:Josh.Howlett@jisc.ac.uk] > *Lähetetty:* Monday, 29 February, 2016 23:29 > *Vastaano**ttaja:*Mohit Sethi >; Aura Tuomas > >; saag@ietf.org > > *Aihe:* RE: [saag] Fwd: New Version Notification for > draft-aura-eap-noob-00.txt > > Hi Mohit, > > Thanks, but I still don’t follow the use case. I thought the draft is > trying to address the scenario where I have devices from multiple > vendors wanting to register themselves against each vendors’ systems > (e.g., my fridge registers with my fridge vendor’s AAA server; my > washing machine with my washing machine vendor’s AAA server; etc.). > How does my NAS know how to forward a request to the correct realm if > each request is using the same realm? > > Josh. > > *From:*Mohit Sethi [mailto:mohit.m.sethi@ericsson.com] > *Sent:* 29 February 2016 17:10 > *To:* Josh Howlett >; Aura Tuomas >; Mohit Sethi > >; > saag@ietf.org > *Subject:* Re: [saag] Fwd: New Version Notification for > draft-aura-eap-noob-00.txt > > Hi Josh > > Thanks again for your useful questions. > > 1. The requests for "eap-noob.net" would either be served by a local > AAA server or a remote AAA server for which a forwarding rule has been > added. The request would not be forwarded to a global server based on > DNS lookups. Hence, a DNS lookup for eap-noob.net is expected to > respond with NXDOMAIN. > > 2. The need for the special purpose realm is to allow devices from any > manufacturer to be directed to the AAA server of your choice. You only > need setup the server or add the forwarding once for all the devices > from any manufacturer. Not everyone wants to depend on the device > vendor's AAA service for security.Besides, depending on a vendor > service may not be always safe. As Stephen had pointed out in another > mail thread > (https://www.ietf.org/mail-archive/web/ace/current/msg01470.html), > commercial devices will be end-of-lifed by vendors, and yet they still > need to be functional for the owner. > > /--Mohit > > On 02/18/2016 09:05 PM, Josh Howlett wrote: > > Sorry, ignore question 3, it makes no sense here. > > *From: *Josh Howlett > *Sent: *18 February 2016 18:47 > *To: *Aura Tuomas ; Mohit Sethi > ; saag@ietf.org > ; emu@ietf.org > *Subject: *Re: [saag] Fwd: New Version Notification for > draft-aura-eap-noob-00.txt > > Hi Aura, > > A couple of other questions on the deployment theme: > > 1.How would requests towards the single special people realm get > disambiguated among the multiple AAA servers? > > 2.In fact, what’s the need for this special purpose realm at all – > why not let the vendor burn one into the firmware, and use an > intermediate AAA routing fabric do the AAA server discovery? > > 3.Why this and not WPS (or something similar?) > > Josh. > > Sent from Outlook Mail > for Windows 10 phone > > *From: *Aura Tuomas > *Sent: *18 February 2016 18:07 > *To: *Josh Howlett ; Mohit Sethi > ; saag@ietf.org > ; emu@ietf.org > *Subject: *RE: [saag] Fwd: New Version Notification for > draft-aura-eap-noob-00.txt > > Hi Josh, > > Good observation; we may need to be clearer about the intended > usage scenarios for EAP-NOOB. > > In the home setting, the AAA server would typically be a > cloud-based service, where the consumer can register a user > account. This does require the 802.1X authentication (i.e. > WPA2-Enterprise) to be configured at the home NAS, so that > authentication for "@eap-noob.net" is forwarded to the cloud-based > AAA server. You only need to configure the NAS once, and all > future devices can be connected without touching the NAS. > > This is a change from the way home wireless routers are configured > today. We think that, as the number of IoT devices grows, > configuring them with a shared passphrase will be too > inconvenient. Obviously, the shared passphrase is also vulnerable > to a single untrusted IoT device that may leak the passphrase, and > using EAP helps to isolate the devices. > > Of course, the benefits of EAP-NOOB will be greater in > organizations which already use 802.1X authentication and which > have larger numbers of IoT devices than a single home. > > Anything else that we need to address? > > Tuomas > > > > -----Original Message----- > From: Josh Howlett [mailto:Josh.Howlett@jisc.ac.uk] > Sent: Thursday, 18 February, 2016 19:28 > To: Mohit Sethi > ; saag@ietf.org > ; emu@ietf.org > Cc: Aura Tuomas > Subject: RE: [saag] Fwd: New Version Notification for > draft-aura-eap-noob-00.txt > > Hi Mohit, > > This is an interesting draft, but I'm struggling to understand how > this would be deployed in the consumer settings that the document > alludes to. For example, who do you anticipate will be operating > the NAS (the consumer?), AAA server (the vendor?), and the AAA > fabric between these actors? > > Josh. > > > -----Original Message----- > > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Mohit Sethi > > Sent: 08 February 2016 15:34 > > To: saag@ietf.org ; emu@ietf.org > > > Cc: tuomas.aura@aalto.fi > > Subject: [saag] Fwd: New Version Notification for > > draft-aura-eap-noob-00.txt > > > > Dear all > > > > We have just submitted a new IETF Draft titled “Nimble out-of-band > > authentication for EAP (EAP-NOOB)”. > > > > The draft defines an EAP method where the authentication is > based on a > > user-assisted out-of-band (OOB) channel between the server and > peer. > > It is intended as a generic bootstrapping solution for > > Internet-of-Things devices which have no pre-configured > authentication > > credentials and which are not yet registered on the authentication > > server. Consider devices you just bought or borrowed. > > > > The EAP-NOOB method is more generic than most ad-hoc bootstrapping > > solutions in that it supports many types of OOB channels. We > specify > > the exact in-band messages but only the OOB message contents and > not > > the OOB channel details. Also, EAP-NOOB supports ubicomp devices > with > > only output (e.g. display) or only input (e.g. camera). > Moreover, it > > makes combined use of both secrecy and integrity of the OOB channel > > for more robust security than the ad-hoc solutions. We have put > a lot > > of effort into designing a robust security protocol. > > > > For one application example, we have used an earlier version of the > > protocol for bootstrapping security for ubiquitous displays: the > user > > can configure wireless network access, link the device to a cloud > > service, and register ownership of the device for a specific cloud > > user – all in one simple step of scanning a QR code with a smart > > phone. There seemed to more potential to this idea than just > using it > > for our own system, and thus we decided to write a generic EAP > method for out-of-band authentication. > > > > The draft is available here: > > https://tools.ietf.org/html/draft-aura-eap-noob-00 > > > > Please see if you can make use of it. We look forward to your > feedback > > and comments. > > > > Regards > > /--Mohit > > > > > > -------- Forwarded Message -------- > > Subject: New Version Notification for > draft-aura-eap-noob-00.txt > > Date: Mon, 08 Feb 2016 04:30:35 -0800 > > From: internet-drafts@ietf.org > > To: Tuomas Aura > , Mohit Sethi > > > > > > > > > > A new version of I-D, draft-aura-eap-noob-00.txt has been > successfully > > submitted by Tuomas Aura and posted to the IETF repository. > > > > Name: draft-aura-eap-noob > > Revision: 00 > > Title: Nimble out-of-band authentication for EAP > (EAP-NOOB) > > Document date: 2016-02-08 > > Group: Individual Submission > > Pages: 35 > > URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-00.txt > > Status:https://datatracker.ietf.org/doc/draft-aura-eap-noob/ > > Htmlized:https://tools.ietf.org/html/draft-aura-eap-noob-00 > > > > > > Abstract: > > Extensible Authentication Protocol (EAP) [RFC3748] provides > support > > for multiple authentication methods. This document defines > the EAP- > > NOOB authentication method for nimble out-of-band (OOB) > > authentication and key derivation. This EAP method is > intended for > > bootstrapping all kinds of Internet-of-Things (IoT) devices > that have > > a minimal user interface and no pre-configured authentication > > credentials. The method makes use of a user-assisted > one-directional > > OOB channel between the peer device and authentication server. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > Jisc is a registered charity (number 1149740) and a company > limited by guarantee which is registered in England under Company > No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: > One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. > > Jisc Services Limited is a wholly owned Jisc subsidiary and a > company limited by guarantee which is registered in England under > company number 2881024, VAT number GB 197 0632 86. The registered > office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 > 697 5800. > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > --------------090404060807010204020301 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Hi Josh

Thanks for the suggestion. It is a good idea to document the ecosystem assumptions. When writing about our own ideas it is easy to think that the design assumptions are obvious.

Regarding credentials for authentication, OOB authentication is an alternative to pre-established credentials. The secure channel created with OOB authentication could be used for setting up other credentials, such as a device certificate, but doing that is outside our protocol.

/--Mohit

On 03/03/2016 12:17 PM, Josh Howlett wrote:

Hi Tuomas,

 

I think it would be really helpful if you documented the intended deployment ecosystem at a high level (consumer, enterprise, vendor, AAA providers, etc.) and how these map to the protocol actors. I think the lack of a model results in ambiguity (at least in my own mind) as to how this could or should be deployed. You might want to do this in a separate document.

 

The Introduction also points to the need for establishment of “credentials for […] authentication-security”. The draft doesn’t appear to address this requirement. Is this intentional?

 

Josh.

 

From: Aura Tuomas [mailto:tuomas.aura@aalto.fi]
Sent: 03 March 2016 09:20
To: Josh Howlett <Josh.Howlett@jisc.ac.uk>; Mohit Sethi <mohit.m.sethi@ericsson.com>; saag@ietf.org
Subject: VS: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

 

Hi Josh,

 

I think I got your point. There are two questions here.

 

The first is about who will manage the AAA server for the devices. We have primarily thought it will be the user organization, which may outsource the authentication and authorization to a third party of their choice. You seem to be thinking that the device vendors will run the AAA server for their own devices. Both scenarios are certainly possible. The vendor-specific solution would not necessarily even need standard for the EAP method because it could be specified by the vendor alone. We have focused on the scenario where the AAA server is not necessarily the device vendor, and a standard for interoperability is needed.

 

The second question is whether all the devices in the same user organization should be handled by one AAA server, or if there should be multiple classes of devices that are handled by different AAA servers. Adding support for device classes, e.g. as subdomains “XXX.eap-noob.net”, is certainly possible. We’ll think about this. I’m not sure about the extra complexity that it will create.

 

Tuomas

 

 

 

Lähettäjä: Josh Howlett [mailto:Josh.Howlett@jisc.ac.uk]
Lähetetty: Monday, 29 February, 2016 23:29
Vastaanottaja: Mohit Sethi <mohit.m.sethi@ericsson.com>; Aura Tuomas <tuomas.aura@aalto.fi>; saag@ietf.org
Aihe: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

 

Hi Mohit,

 

Thanks, but I still don’t follow the use case. I thought the draft is trying to address the scenario where I have devices from multiple vendors wanting to register themselves against each vendors’ systems (e.g., my fridge registers with my fridge vendor’s AAA server; my washing machine with my washing machine vendor’s AAA server; etc.). How does my NAS know how to forward a request to the correct realm if each request is using the same realm?

 

Josh.

 

From: Mohit Sethi [mailto:mohit.m.sethi@ericsson.com]
Sent: 29 February 2016 17:10
To: Josh Howlett <Josh.Howlett@jisc.ac.uk>; Aura Tuomas <tuomas.aura@aalto.fi>; Mohit Sethi <mohit.m.sethi@ericsson.com>; saag@ietf.org
Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

 

Hi Josh

Thanks again for your useful questions.

1. The requests for "eap-noob.net" would either be served by a local AAA server or a remote AAA server for which a forwarding rule has been added. The request would not be forwarded to a global server based on DNS lookups. Hence, a DNS lookup for eap-noob.net is expected to respond with NXDOMAIN.

2. The need for the special purpose realm is to allow devices from any manufacturer to be directed to the AAA server of your choice. You only need setup the server or add the forwarding once for all the devices from any manufacturer. Not everyone wants to depend on the device vendor's AAA service for security.Besides, depending on a vendor service may not be always safe. As Stephen had pointed out in another mail thread (https://www.ietf.org/mail-archive/web/ace/current/msg01470.html), commercial devices will be end-of-lifed by vendors, and yet they still need to be functional for the owner.

/--Mohit

On 02/18/2016 09:05 PM, Josh Howlett wrote:

Sorry, ignore question 3, it makes no sense here.

 

From: Josh Howlett
Sent: 18 February 2016 18:47
To: Aura Tuomas; Mohit Sethi; saag@ietf.org; emu@ietf.org
Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

 

Hi Aura,

 

A couple of other questions on the deployment theme:

 

1.       How would requests towards the single special people realm get disambiguated among the multiple AAA servers?

2.       In fact, what’s the need for this special purpose realm at all – why not let the vendor burn one into the firmware, and use an intermediate AAA routing fabric do the AAA server discovery?

3.       Why this and not WPS (or something similar?)

 

Josh.

 

 

 

Sent from Outlook Mail for Windows 10 phone

 

From: Aura Tuomas
Sent: 18 February 2016 18:07
To: Josh Howlett; Mohit Sethi; saag@ietf.org; emu@ietf.org
Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

 

Hi Josh,

Good observation; we may need to be clearer about the intended usage scenarios for EAP-NOOB.

In the home setting, the AAA server would typically be a cloud-based service, where the consumer can register a user account. This does require the 802.1X authentication (i.e. WPA2-Enterprise) to be configured at the home NAS, so that authentication for "@eap-noob.net" is forwarded to the cloud-based AAA server. You only need to configure the NAS once, and all future devices can be connected without touching the NAS.

This is a change from the way home wireless routers are configured today. We think that, as the number of IoT devices grows, configuring them with a shared passphrase will be too inconvenient. Obviously, the shared passphrase is also vulnerable to a single untrusted IoT device that may leak the passphrase, and using EAP helps to isolate the devices.

Of course, the benefits of EAP-NOOB will be greater in organizations which already use 802.1X authentication and which have larger numbers of IoT devices than a single home.

Anything else that we need to address?

Tuomas



-----Original Message-----
From: Josh Howlett [mailto:Josh.Howlett@jisc.ac.uk]
Sent: Thursday, 18 February, 2016 19:28
To: Mohit Sethi <mohit.m.sethi@ericsson.com>; saag@ietf.org; emu@ietf.org
Cc: Aura Tuomas <tuomas.aura@aalto.fi>
Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

Hi Mohit,

This is an interesting draft, but I'm struggling to understand how this would be deployed in the consumer settings that the document alludes to. For example, who do you anticipate will be operating the NAS (the consumer?), AAA server (the vendor?), and the AAA fabric between these actors?

Josh.

> -----Original Message-----
> From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Mohit Sethi
> Sent: 08 February 2016 15:34
> To: saag@ietf.org; emu@ietf.org
> Cc: tuomas.aura@aalto.fi
> Subject: [saag] Fwd: New Version Notification for
> draft-aura-eap-noob-00.txt
>
> Dear all
>
> We have just submitted a new IETF Draft titled “Nimble out-of-band
> authentication for EAP (EAP-NOOB)”.
>
> The draft defines an EAP method where the authentication is based on a
> user-assisted out-of-band (OOB) channel between the server and peer.
> It is intended as a generic bootstrapping solution for
> Internet-of-Things devices which have no pre-configured authentication
> credentials and which are not yet registered on the authentication
> server. Consider devices you just bought or borrowed.
>
> The EAP-NOOB method is more generic than most ad-hoc bootstrapping
> solutions in that it supports many types of OOB channels. We specify
> the exact in-band messages but only the OOB message contents and not
> the OOB channel details. Also, EAP-NOOB supports ubicomp devices with
> only output (e.g. display) or only input (e.g. camera). Moreover, it
> makes combined use of both secrecy and integrity of the OOB channel
> for more robust security than the ad-hoc solutions. We have put a lot
> of effort into designing a robust security protocol.
>
> For one application example, we have used an earlier version of the
> protocol for bootstrapping security for ubiquitous displays: the user
> can configure wireless network access, link the device to a cloud
> service, and register ownership of the device for a specific cloud
> user – all in one simple step of scanning a QR code with a smart
> phone. There seemed to more potential to this idea than just using it
> for our own system, and thus we decided to write a generic EAP method for out-of-band authentication.
>
> The draft is available here:
> https://tools.ietf.org/html/draft-aura-eap-noob-00
>
> Please see if you can make use of it. We look forward to your feedback
> and comments.
>
> Regards
> /--Mohit
>
>
> -------- Forwarded Message --------
> Subject:       New Version Notification for draft-aura-eap-noob-00.txt
> Date:  Mon, 08 Feb 2016 04:30:35 -0800
> From:  internet-drafts@ietf.org
> To:    Tuomas Aura <tuomas.aura@aalto.fi>, Mohit Sethi
> <mohit@piuha.net>
>
>
>
> A new version of I-D, draft-aura-eap-noob-00.txt has been successfully
> submitted by Tuomas Aura and posted to the IETF repository.
>
> Name:         draft-aura-eap-noob
> Revision:     00
> Title:                Nimble out-of-band authentication for EAP (EAP-NOOB)
> Document date:        2016-02-08
> Group:                Individual Submission
> Pages:                35
> URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-00.txt
> Status:https://datatracker.ietf.org/doc/draft-aura-eap-noob/
> Htmlized:https://tools.ietf.org/html/draft-aura-eap-noob-00
>
>
> Abstract:
>     Extensible Authentication Protocol (EAP) [RFC3748] provides support
>     for multiple authentication methods.  This document defines the EAP-
>     NOOB authentication method for nimble out-of-band (OOB)
>     authentication and key derivation.  This EAP method is intended for
>     bootstrapping all kinds of Internet-of-Things (IoT) devices that have
>     a minimal user interface and no pre-configured authentication
>     credentials.  The method makes use of a user-assisted one-directional
>     OOB channel between the peer device and authentication server.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800. 

 

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

 


--------------090404060807010204020301-- From nobody Mon Mar 7 23:10:50 2016 Return-Path: X-Original-To: saag@ietfc.amsl.com Delivered-To: saag@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 950711CD88A for ; Mon, 7 Mar 2016 23:10:48 -0800 (PST) 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: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grtgMdP4N50h for ; Mon, 7 Mar 2016 23:10:48 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id B2E701CE137 for ; Mon, 7 Mar 2016 23:10:47 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id p65so137079739wmp.1 for ; Mon, 07 Mar 2016 23:10:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=Q1co5fRCTeBCusH0n6qZrjh1qu65q2Tn/KcW7YCgV3w=; b=aOFHyjbUjbWztiUnxOFDqc8GtWVaJkGdXX0Tfwt35nxKbTRaxrVz/B6WO3GKSjy8SO vmZRYAnKyr3qhnEdedeOkPnXj9hXopMOIZfEGWo5f7UDNMAdB+FWIH/J/0Qnv1FhZs45 /ZrxB83Bf9m++fI4530bsFGYh4zRHnqm/p7Oc0Qb9s2MZ+IsGkpHdhpeMyEh6rZutKkE 8eMOUR6bx0GBxeTm6Fbca7sBtv/pUDT56ybGrKvmS0rvZ+DiucL84WGFTH3Er9/q5wWg Y9Jov5cxMmt9DI9oGZWYH78/2fKNzmpfvVA51Xo2W4W6Je8AnTTXEsFkpDFdZP4B3Z/V AduQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=Q1co5fRCTeBCusH0n6qZrjh1qu65q2Tn/KcW7YCgV3w=; b=m5BCzzsQ8b0kT1SsuA0QLjZfycfwu6O6rqr89atbz4M1ROZXaaBVIsRAjU5CETEEN4 iaEw1tAAT2ZVHz55pIT1oyQ2/h8PHUUmzW8pC3EbR+8YHzlJmpXlxGJjcZyk3V8+N1wH MICc4HD9QIi9xGzeL28oJsOGoHhrQOrvoqC84KuRzbggBQsQ4pZdsSPwMptWq3RVR2yK qAcvEuEPT86tYbciryq4H/LkJOjByyJfcHqNptF6AVlGfbzSxjdn/IKPQcTnHnGZ9iWV CU7B1j2KcKT346X9naGpEkK020bRWX1XFenzWzwh8MJSe+wzS6R9p7sjvSlVvdFLVvdk Hpxg== X-Gm-Message-State: AD7BkJKTHf3my4JPNRGItBUa25KWj4lcnteGU+FOSPSxGWR56uj/TR/PLEhzBvAlh22Tgw== X-Received: by 10.194.95.73 with SMTP id di9mr29692789wjb.152.1457421046345; Mon, 07 Mar 2016 23:10:46 -0800 (PST) Received: from yoavs-mbp-2.mshome.net ([176.13.4.146]) by smtp.gmail.com with ESMTPSA id k125sm17124657wmb.14.2016.03.07.23.10.44 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 07 Mar 2016 23:10:45 -0800 (PST) From: Yoav Nir Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5B6E3BE2-3EF2-4262-AB34-54B54787009E@gmail.com> Date: Tue, 8 Mar 2016 09:10:22 +0200 To: Security Area Advisory Group Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [saag] MutualAuth: Looking for Volunteers 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: Tue, 08 Mar 2016 07:10:48 -0000 Note: Cross-posted to HTTPauth and HTTPbis. Apologies if you have = received this twice or thrice Hi all The HTTP-Auth working group has been working on a set of three documents = for a mutual authentication method for HTTP. These documents are: * draft-ietf-httpauth-mutual-06 * draft-ietf-httpauth-mutual-algo-04 * draft-ietf-httpauth-extension-05 =20 The documents are feature complete. However, neither the authors nor the=20= WG chairs are native English speakers, and we would like to have the=20 language of these documents improved before proceeding to WG and IETF = last calls.=20 =20 If anyone would like to volunteer to read one or more of these documents and help us improve grammar and readability, we would appreciate this = very much. As always in the IETF, substantive comments and nits are always welcome as well.=20 =20 So if you're interested and are able to perform a language review on one = or more of these documents please contact one of the chairs directly.=20 =20 Thanks in advance, =20 Yoav and Rifaat HTTP-Auth Chairs= From nobody Tue Mar 8 11:26:19 2016 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 8842912D830; Tue, 8 Mar 2016 11:26:17 -0800 (PST) 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kp8nl9MwgMhJ; Tue, 8 Mar 2016 11:26:16 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 F27DA12DA15; Tue, 8 Mar 2016 11:26:09 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id p65so41679304wmp.0; Tue, 08 Mar 2016 11:26:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3VVDG0zOhgkUNKY2Qyq8skUJy39wcByNaidYvvsrDMQ=; b=bIISrYE2AVvkZbNKPUSWN/nDDU2ZrKr2nrNbkOSmoqHej8AWNVHBCh8Vt7tBZnw43Z catH2XaG8ULs70ZGUvkyvYCJD1FB0J+Ew8UeEyiq4q0cVvn7yobmvQGhlg0LDH+UXwyx bDp8cXTMGdQkM90AEeeNp9tHpQDI3JbwRC91oaOPafzc0AImCSLRh0Pig/4uZhsnOyJc h8SfmgwaX8HSHbJI1juhdWzcpCrgyO/BCfZFP6EV5CQ66hOD+ASaKGIHgI8toe6ilNHE 2q8C+2zCwTPdeWcSeMeR2XRzH2QAK9t9vHA9HI0jAyqzKTk3ZE/7mpaGpSKxDXbhebcu /mhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3VVDG0zOhgkUNKY2Qyq8skUJy39wcByNaidYvvsrDMQ=; b=IFJoFFTInI5vmjyfzwJkc2XAPtO+fYBSZYOxXY1KDFGP0D8dGoQxSSunCS4i71omTR OrbHWNM+sVe9qcJe3MLwi4pFnUHKOZReBJSQ8NOkxMHgKYGt2Y0PACXfrlu0eZbyCW5T 6Q6X2P8FBOzXzuY34hqAMwL2+bQcuhx7BZprvfGvNZkgTblgxDUa+spMrk6ZoVRW+uug oPjqsuchfZ88S2rJ6zu8Y15G45T+LzUfvYzvn+2wJgunCi2bAi6NYgSpmvtoLAup/2VK aEC1SZY8aKi2t7dyxiXenpc6VjDeWcUlGr8DYMeoDKR6lue+S3p2NPs4K++ZOMAfZ2xg oxag== X-Gm-Message-State: AD7BkJKpT5cQzPxaV7JGOWdHxzk6BvM+oTW5hM8nLNE6D7o9ePNSgBD6zEoHPYUawh4O0w== X-Received: by 10.194.71.46 with SMTP id r14mr33850915wju.100.1457465168550; Tue, 08 Mar 2016 11:26:08 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id k125sm20110147wmb.14.2016.03.08.11.26.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Mar 2016 11:26:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <5B6E3BE2-3EF2-4262-AB34-54B54787009E@gmail.com> Date: Tue, 8 Mar 2016 21:26:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7D8A8D66-8259-4659-9BE2-E96C38B051BF@gmail.com> References: <5B6E3BE2-3EF2-4262-AB34-54B54787009E@gmail.com> To: Security Area Advisory Group , httpauth mailing list , HTTP Working Group X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Cory Benfield Subject: Re: [saag] MutualAuth: Looking for Volunteers 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: Tue, 08 Mar 2016 19:26:17 -0000 Note: This time it=E2=80=99s cross-posted for real, so please don=E2=80=99= t reply-all to this message. Thanks to all who volunteered. It=E2=80=99s always great to see how much = help you can get at the IETF just by asking. Peter, Melinda and Cory volunteered first, and they will be reviewing = our three documents. Other reviews are, as always, welcome Thanks again to everyone, and especially to Peter, Melinda and Cory. Yoav & Rifaat On 8 Mar 2016, at 9:10 AM, Yoav Nir wrote: > Hi all >=20 > The HTTP-Auth working group has been working on a set of three = documents for > a mutual authentication method for HTTP. These documents are: > * draft-ietf-httpauth-mutual-06 > * draft-ietf-httpauth-mutual-algo-04 > * draft-ietf-httpauth-extension-05 >=20 > The documents are feature complete. However, neither the authors nor = the=20 > WG chairs are native English speakers, and we would like to have the=20= > language of these documents improved before proceeding to WG and IETF = last > calls.=20 >=20 > If anyone would like to volunteer to read one or more of these = documents > and help us improve grammar and readability, we would appreciate this = very > much. As always in the IETF, substantive comments and nits are always > welcome as well.=20 >=20 > So if you're interested and are able to perform a language review on = one or > more of these documents please contact one of the chairs directly.=20 >=20 > Thanks in advance, >=20 > Yoav and Rifaat > HTTP-Auth Chairs From nobody Wed Mar 9 08:17:54 2016 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 E218312DF83 for ; Wed, 9 Mar 2016 08:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bblfish-net.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBfbTUG5mwZw for ; Wed, 9 Mar 2016 08:16:16 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c: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 A5B5F12D748 for ; Wed, 9 Mar 2016 08:11:20 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id p65so199228324wmp.1 for ; Wed, 09 Mar 2016 08:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bblfish-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=wZG5xkfjxLI+PhAFbs3Ij2jMIoOVhiPmYMLfTcTDv60=; b=v2D4aIiQWhgNNe9Kvdn06PQcH6+MgRP1Vrn0eldeN2zd4+2LKoDyaor7BNWVnxTot9 z7kBBA5+GL1CoP5Ue8grhUAqJ8zdpUGkSu5BKruYy4zXka5G92OsMtvbbOtyI19i8qBl a9I/KE9DD0BK3LIVRdGkHsP7xbqjsY0z5ZezCYVLTkD8XedZPuVLCoVk92CLDnmPGqtI lup2kWcwXpRnYr4jrsf3xlfpIFWXdnpAkGG3Rrt5RRNNIQXTcyG09b5YKxw6Rc5yp2AL MCyhZAxXO0OXh9jj7iqo5MyO2zCObtXLKiUAVmwgK17PK0DzDwdpREG4NOGoCR3e1NKm i34A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=wZG5xkfjxLI+PhAFbs3Ij2jMIoOVhiPmYMLfTcTDv60=; b=eoLIkOx9k1EMioi7kXLKYa57pxRh7oRN8Y037sDa1wfzL61L+Ne33n2PDcriXnCGtL Av8wE/2BVNN1VhBS+MQRmP+ftsJOagGSAucA3cv6LXeZm65r5NGaEw5pY3YFI+ZIb6tJ +72BCnHpINh0Ab21w+O66tuZqTJXBvcMmxTZkkY8qqvZDvGP1ZmObs1fzu0Z98IksHEk y1APrCeZdHZr0vR66bbGGgoDJNAQe1jfD7c5COgmddflUUu2ZZZfBVQM8J+NCddj3e0J Gnj9J6PIX6s/fLerZat8NUDbvVCILadmegEdENWsVhxE37ya7/ybhfRPjWUZAjBAUaV1 Y8Xg== X-Gm-Message-State: AD7BkJKX8weDQY5nUJDhHQ1/O68tEZ5nmEBz+MS7yBSNj+4bnu3a5j5uzP2g/thN+iOubg== X-Received: by 10.194.121.99 with SMTP id lj3mr40362643wjb.55.1457539879250; Wed, 09 Mar 2016 08:11:19 -0800 (PST) Received: from [192.168.0.6] (cpc2-popl3-2-0-cust563.13-2.cable.virginm.net. [86.21.242.52]) by smtp.gmail.com with ESMTPSA id t7sm8577533wjf.39.2016.03.09.08.11.18 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 09 Mar 2016 08:11:18 -0800 (PST) From: Henry Story Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <98DCC6F3-02D1-4092-A430-97114CED9532@bblfish.net> Date: Wed, 9 Mar 2016 16:11:41 +0000 To: saag@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [saag] X509 extension to specify use for only one origin? 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, 09 Mar 2016 16:16:18 -0000 Hi, The W3C TAG is working on a finding for Client Certificates that=20 people here should find very interesting [1].=20 One issue that comes up a lot in discussions is the use of certificates across origins [2], which some folks find problematic, even though it=20 clearly has its uses [3]. It seems that this could be solved neatly with an X509 extension limiting usage to a certain origin or set of origins. I would not be surprised if this already exists. With browser chrome support this would allow the full range of uses from FIDO to cross origin ones whilst putting the user in control. Henry [1] https://github.com/w3ctag/client-certificates [2] https://github.com/w3ctag/client-certificates/issues/1 [3] = https://github.com/w3ctag/client-certificates/issues/1#issuecomment-194318= 303= From nobody Thu Mar 10 08:52:27 2016 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 4D87F12DA5D for ; Thu, 10 Mar 2016 08:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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] 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 XmIEK1hatX2w for ; Thu, 10 Mar 2016 08:52:22 -0800 (PST) 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 B8FF912DA5C for ; Thu, 10 Mar 2016 08:52:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0E941BE2D for ; Thu, 10 Mar 2016 16:52:21 +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 yXrjyh62AlgM for ; Thu, 10 Mar 2016 16:52:19 +0000 (GMT) Received: from [10.87.48.75] (unknown [86.46.23.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F2505BE29 for ; Thu, 10 Mar 2016 16:52:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457628739; bh=IRbtbc6nIoldiSpSpPEm18l3njVQVRoW19qICeGoNCg=; h=Subject:References:To:From:Date:In-Reply-To:From; b=YLU8pXr3NmdRAUh//Dq6C9M7VUdiPrp3xAPniV3R17bb1FNTZiamRSHP8xhawg4EN kgv6umX0ls9kilokG6pPR9j3wI850Dusjx7R9AuA5SPNLbPxUL9VbNUs+feZap0yGe Lk7rG0fHuETyYTdGjfKzIFi8eHO3yTLyJxDsFUko= References: <492694C0-1033-41FB-A06B-63648F143E7E@netapp.com> To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <492694C0-1033-41FB-A06B-63648F143E7E@netapp.com> Message-ID: <56E1A632.4040905@cs.tcd.ie> Date: Thu, 10 Mar 2016 16:52:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <492694C0-1033-41FB-A06B-63648F143E7E@netapp.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="isE1DQPavvQXI3CuX4DapjfBgKp85xXvO" Archived-At: Subject: [saag] Fwd: ANRP presentations at IETF-95 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, 10 Mar 2016 16:52:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --isE1DQPavvQXI3CuX4DapjfBgKp85xXvO Content-Type: multipart/mixed; boundary="s6RjnPoLxCr6gg9JLfem16s4u17CmoO5x" From: Stephen Farrell To: "saag@ietf.org" Message-ID: <56E1A632.4040905@cs.tcd.ie> Subject: Fwd: ANRP presentations at IETF-95 References: <492694C0-1033-41FB-A06B-63648F143E7E@netapp.com> In-Reply-To: <492694C0-1033-41FB-A06B-63648F143E7E@netapp.com> --s6RjnPoLxCr6gg9JLfem16s4u17CmoO5x Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI, some relevant talk @ IETF-95 if you're there and not otherwise busy Cheers, S -------- Forwarded Message -------- Subject: ANRP presentations at IETF-95 Date: Thu, 10 Mar 2016 16:34:47 +0000 From: Eggert, Lars Reply-To: anrp@irtf.org To: irtf-announce@irtf.org , ietf@ietf.org , 95attendees@ietf.org <95attendees@ietf.org> Hi, we are extremely pleased to report that for the 2016 award period of the Applied Networking Research Prize (ANRP), 53 eligible nominations were received. Each submission was reviewed by several members of the selection committee selection committee according to a diverse set of criteria, including scientific excellence and substance, timeliness, relevance, and potential impact on the Internet. Based on this review, six submissions are awarded an Applied Networking Research Prize in 2016. Two prize winners will present their work at the IRTF Open Meeting during IETF-95 in Buenos Aires, Argentina. The ANRPs for IETF-95 go to: *** Roya Ensafi *** for examining how the Chinese "great firewall" discovers hidden circumvention servers: Roya Ensafi, David Fifield, Philipp Winter, Nick Feamster, Nicholas Weaver, and Vern Paxson. Examining How the Great Firewall Discovers Hidden Circumvention Servers. Proc. ACM Internet Measurement Conference (IMC), Tokyo, Japan, October 28-30, 2015. *** Zakir Durumeric *** for an empirical analysis of email delivery security: Zakir Durumeric, David Adrian, Ariana Mirian, James Kasten, Elie Bursztein, Nicolas Lidzborski, Kurt Thomas, Vijay Eranti, Michael Bailey, and J. Alex Halderman. Neither Snow Nor Rain Nor MITM=E2=80=A6= An Empirical Analysis of Email Delivery Security. Proc. ACM Internet Measurement Conference (IMC), Tokyo, Japan, October 28-30, 2015. Please subscribe to the IRTF-Announce mailing list in order to receive future calls for ANRP nominations and join ISOC to stay informed of other networking research initiatives: https://irtf.org/mailman/listinfo/irtf-announce https://isoc.org/join Regards, Lars Eggert, IRTF Chair https://irtf.org/anrp Mat Ford, Internet Society https://isoc.org/research/ 2016 ANRP Selection Committee Mark Allman, ICIR Marcelo Bagnulo, UC3M Lou Berger, LabN KC Claffy, CAIDA Mark Crovella, Boston University Lars Eggert, NetApp Stephen Farrell, Trinity College Dublin Nick Feamster, Princeton Mat Ford, ISOC Lisandro Granville, UFRGS Volker Hilt, Bell Labs Suresh Krishnan, Ericsson Al Morton, AT&T Laboratories J=C3=B6rg Ott, Aalto University Colin Perkins, University of Glasgow Aiko Pras, University of Twente J=C3=BCrgen Sch=C3=B6nw=C3=A4lder, Jacobs University Bremen Joe Touch, USC/ISI Rolf Winter, Hochschule Augsburg Lixia Zhang, UCLA --s6RjnPoLxCr6gg9JLfem16s4u17CmoO5x-- --isE1DQPavvQXI3CuX4DapjfBgKp85xXvO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW4aYyAAoJEC88hzaAX42i768H/A1c2pGxE9XVdqW0le5B+Ckq RBX3Ek+GTHBKt+DStO0RS3GZDuVF+Jak4/KJ3UrF5snUGcxTWCcgc3GFBNXw1yRX oxxwWArJXRmoV2QY1lNKpgNZygTtEtt6C2RCffPr21bUdbXgnMNzDbdVQMMxBD9R QNMfeE96EQ4hHTYkDQYmJdqx0IiGHxKEbitpp6wIH96JpEzVfGX2LYz6gKVNSJ1j pe8+0sqDemk1tWuXdUVsFjmWnw1px7hYmTSWB/OPhTZx3qhlIo5Z+pEL+5LC5kvT D3KJkcxJkDbjq3OweoZ0U2MgnfPVht1xQ8bwNv/aBP7x36SdGtJvGuKoaSmAtEM= =4QDV -----END PGP SIGNATURE----- --isE1DQPavvQXI3CuX4DapjfBgKp85xXvO-- From nobody Thu Mar 10 09:40:26 2016 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 2EF3212DAAC for ; Thu, 10 Mar 2016 09:40:26 -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, 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 F2XXZHQnpcbj for ; Thu, 10 Mar 2016 09:40:24 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 5611D12DAA4 for ; Thu, 10 Mar 2016 09:40:23 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id n186so40988534wmn.1 for ; Thu, 10 Mar 2016 09:40:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=cwvwlIAIKiCcEJWKTBoDv/6u5nu0pOU2ZRqThDp5rVM=; b=ilJ3f/aZLkdHpNCaDUG65lsEAap25Di0FC9EzY8XDl5f2Gqrdsi/pMX5YqFmuhBkLz R0hJlI7QLNWzmhtLWMjfOAvrIuQe5y7Bz59rMfMZJmGLWmxn/cRqrBamp0DbcNYUG1iX 8eeXupJQ3QDEZZkf4pRkEP4YPnLJ7qj7+74jcsyJfglDO5+zkdknP5vRETrIJZd0uS/s jDFKM7BiizUfkFvx75d1RlRE2SMHLgsANRzi/KzkJtJhR201pgDv/HUSFl5Cabzdpn4R M1xWvoYe2/XKWUXjlQ+i4i4NhGp+MPAbXqp6nsdDeA5r1Xly+KNqu+g+Z+J6dlJjIS7U Erzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=cwvwlIAIKiCcEJWKTBoDv/6u5nu0pOU2ZRqThDp5rVM=; b=LWZ7hj5fOr5VAX4ssbgn/hSQBrUrduQsV1IRba3XChvl+QKzoQOgXnf7r+c/zv7TKJ 4ucPZUZakcGIcGWugOn5atddziBGjygjVDiIF3V9lgn7S6HMiSRcQ2VwlMepYfAZQtf3 etIKpNrTJGjJgBv7Aby3/OgmzvZI8oKJ3kVd7rINAJLX4cRAmhMgLLNz1ISz1ak/A23W ZFBlRc2S2PswTmz3xvvjLZ7r4tOW8vUrtJHgVRxaRQLGWfTbwR+dfKoVfCYIB94ouJa2 zcclfABtxPyLGPPB2qVLfp+xZ+ljTCYIOTopwIQQOjhMu++iOHeb1+mcy2Ku8wYF94s0 P86A== X-Gm-Message-State: AD7BkJKTAMYD3CbBugnV3zGHwgKmLKgN10Vc5cIQxMT4tAFFJyc6NrwFjumW2MqlEZDw8Q== X-Received: by 10.28.218.145 with SMTP id r139mr5739957wmg.52.1457631621890; Thu, 10 Mar 2016 09:40:21 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id za6sm4556466wjc.18.2016.03.10.09.40.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Mar 2016 09:40:21 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_78B637E5-58E1-4F16-B23E-BB549A9AD8F1"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Yoav Nir In-Reply-To: <56E1A632.4040905@cs.tcd.ie> Date: Thu, 10 Mar 2016 19:40:18 +0200 Message-Id: References: <492694C0-1033-41FB-A06B-63648F143E7E@netapp.com> <56E1A632.4040905@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] ANRP presentations at IETF-95 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, 10 Mar 2016 17:40:26 -0000 --Apple-Mail=_78B637E5-58E1-4F16-B23E-BB549A9AD8F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Mar 2016, at 6:52 PM, Stephen Farrell = wrote: >=20 >=20 > FYI, some relevant talk @ IETF-95 if you're there and > not otherwise busy >=20 > Cheers, > S Yeah. Too bad it=E2=80=99s at the same time as TLS. Yoav --Apple-Mail=_78B637E5-58E1-4F16-B23E-BB549A9AD8F1 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----- iQEcBAEBCAAGBQJW4bGDAAoJECXR4BOacZZUI5kIALQXHSPCgnV0ykPY4Vj8wqT7 f5T/D5Vghs8wIXKahbwyI+n4PORQVGu86zfKoGUqEHmk5XE+LGUrwrJzGF4/3/nF WqYtJjJRFKPD+/N8D8tC3LrmsUWEQC8TmV+oBHUgHpZOTJab6cimwrcP8nnCM7CO V5OM3L1tq0lEDwm/kWx2f/2wzRfSsyn+W+uRBiDlzD3HYoyS3hz/qcFsqlvpR2mb uO5g108j5Adr54b6rQ5urq6QxEtyFghJa49P2rTUlY1tZ8oOQxLTPtkWn1dgfgPg hYge1Ab1I6JNZHBS6wLzErT+01NA41P9VJYiFKm627xP1UcE/tM5GYZU1hxPh/k= =+/6s -----END PGP SIGNATURE----- --Apple-Mail=_78B637E5-58E1-4F16-B23E-BB549A9AD8F1-- From nobody Thu Mar 10 10:41:41 2016 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 82CFD12DA63 for ; Thu, 10 Mar 2016 10:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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] 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 g6zIkQQ8RpuV for ; Thu, 10 Mar 2016 10:41:39 -0800 (PST) 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 1F7D312D9AA for ; Thu, 10 Mar 2016 10:41:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D1EEEBE4C; Thu, 10 Mar 2016 18:41:37 +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 BQEytkC0PXDb; Thu, 10 Mar 2016 18:41:36 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.46.23.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3A9C2BE3F; Thu, 10 Mar 2016 18:41:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457635296; bh=+RaXYWVrYRpX7jZKEEsPV06pdcADZLy81JI6XPlcp+k=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=G8DmpGiMcKdzKIXbWOptpfVWGjPdkZImec5b4b9gnspDbkx3E6WyLuu1oRkYTIffr PYX+Sw92DfJopkAYjnbFiyvRdCuB3RPsQB2SM1TZ3HDA4tsU42F1V9kLbGCSwunsv6 UPyxqMhIAvhTQ8+a53oLevFANg4MuSsnBWoXfvUE= To: Yoav Nir References: <492694C0-1033-41FB-A06B-63648F143E7E@netapp.com> <56E1A632.4040905@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56E1BFC6.8030102@cs.tcd.ie> Date: Thu, 10 Mar 2016 18:41:10 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="US4aUfSlDfB3t8F2pVwaljPXIIUXvRoUD" Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] ANRP presentations at IETF-95 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, 10 Mar 2016 18:41:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --US4aUfSlDfB3t8F2pVwaljPXIIUXvRoUD Content-Type: multipart/mixed; boundary="sfKbnXdxv4ojRo6cg3WB3P4msaXdMr6Cr" From: Stephen Farrell To: Yoav Nir Cc: Security Area Advisory Group Message-ID: <56E1BFC6.8030102@cs.tcd.ie> Subject: Re: [saag] ANRP presentations at IETF-95 References: <492694C0-1033-41FB-A06B-63648F143E7E@netapp.com> <56E1A632.4040905@cs.tcd.ie> In-Reply-To: --sfKbnXdxv4ojRo6cg3WB3P4msaXdMr6Cr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/03/16 17:40, Yoav Nir wrote: >=20 >> On 10 Mar 2016, at 6:52 PM, Stephen Farrell wrote: >> >> >> FYI, some relevant talk @ IETF-95 if you're there and >> not otherwise busy >> >> Cheers, >> S >=20 > Yeah. Too bad it=E2=80=99s at the same time as TLS. Indeed. For whatever reason we had many SEC area conflicts this time around and we've not been able to get rid of them all. Sorry for that, but it's not always doable Cheers, S. >=20 > Yoav >=20 --sfKbnXdxv4ojRo6cg3WB3P4msaXdMr6Cr-- --US4aUfSlDfB3t8F2pVwaljPXIIUXvRoUD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW4b/GAAoJEC88hzaAX42izwQH/318BJzn7FRb0m9VP1JXd7IS Ykof7IUp2wRTDQKaaYZyRTJVa0HdoPcsOoPOvNxA80Ul9tNSMZR1szAYia0tcUF/ vGPHYu3oBGl4qml7n8+oAX4NXyHzpOG8xBDT0Ip2bG4FuVbMYoCEiDE5/XAc+sTN PtAGIPS/hSlQkFw9Du9mGEnHZotvOBd874kWYUR2530Fbgx/csPtycmdcqdiy/mW tJtjI+bGVT/RRaZam3sGTy7oAvA9i5K/ouXJdNU+d5WjRX+D9Uu9/H0BQuMn8+3p wKpyZ9GXCbl8PbeuwzTqfqRukO+k28LT5vrCQItcyABq65U/rbmWtv6JXXdsVj4= =vM2f -----END PGP SIGNATURE----- --US4aUfSlDfB3t8F2pVwaljPXIIUXvRoUD-- From nobody Thu Mar 10 12:05:27 2016 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 715E812DC84 for ; Thu, 10 Mar 2016 12:05:25 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 GMHiELF-runy for ; Thu, 10 Mar 2016 12:05:23 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5190E12DC76 for ; Thu, 10 Mar 2016 12:05:23 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0D44D284F26; Thu, 10 Mar 2016 20:05:22 +0000 (UTC) Date: Thu, 10 Mar 2016 20:05:22 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20160310200521.GF10917@mournblade.imrryr.org> References: <492694C0-1033-41FB-A06B-63648F143E7E@netapp.com> <56E1A632.4040905@cs.tcd.ie> <56E1BFC6.8030102@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56E1BFC6.8030102@cs.tcd.ie> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [saag] ANRP presentations at IETF-95 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 20:05:25 -0000 On Thu, Mar 10, 2016 at 06:41:10PM +0000, Stephen Farrell wrote: > > Yeah. Too bad it’s at the same time as TLS. > > Indeed. For whatever reason we had many SEC area conflicts > this time around and we've not been able to get rid of them > all. Sorry for that, but it's not always doable There'll likely be presentations of revised/updated versions of some of the material in the future. The "Neither Snow Nor Rain Nor MITM" paper presents results from April 2015, but already significant changes have occurred. * In mid-February 2016 Google's transparency report is showing a significantly larger overall volume of inbound STARTTLS, from ~58% of all inbound mail to ~68% of all inbound email. This is likely largely the result of some large bulk senders enabling STARTTLS, but is nevertheless progress towards ubiquitous STARTTLS use. * Preferential use of RC4 in SMTP STARTTLS by large providers has ceased since the measurements reported from 2014/2015. RC4-only systems (Exchange 2003 and some old Email security appliances) have become significantly more rare. * Support for EXPORT ciphers started to diminish with LOGJAM, and will I expect drop substantially as MTA operators take steps to remediate DROWN. * Postfix 3.1.0 makes it much easier for O/S distributions to enable STARTTLS both inbound and outbound at installation time. http://www.postfix.org/postfix-tls.1.html * The "Let's Encrypt" CA is recently starting to get some traction. One data-point is that of the ~1460 MX hosts that support DANE TLS ~180 have LE certificates. Of the latter 1/6th are "mail in box" MTAs that make it easy to deploy a turn-key system with LE certs, DNSSEC, DANE, ... https://mailinabox.email/ So people looking for "trusted" certificates in peer SMTP servers should start to see a greater share of SMTP servers with "trusted" certificates. (Which CAs one should trust, and how well the domain control is verified by the CA remains a tricky question). * DANE support is still growing, and with luck will see greater adoption once OpenSSL 1.1.0 with built-in DANE support becomes available in "current" O/S distributions later this year. DANE SMTP moving from draft to RFC in October 2015 should also help. * In October of 2015 I had found 24 domains with DANE TLS records that were "large enough" to have been listed in Google's email transparency report at some point in the last ~2 years. That domain count is now 34. The gentoo.org and mail.com domains are the two most recent additions. The overall number of DANE domains I've found is now at 11.5k up from ~7k. [ Some of that increase is due to expansion of the set of domains scanned. ] So while DANE use is still very small, it continues to grow. Yes, STARTTLS in SMTP is still opportunistic, and active downgrade attacks cannot be avoided in many cases. However the landscape continues to evolve. -- Viktor. From nobody Fri Mar 11 07:26:22 2016 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 159F512D832 for ; Fri, 11 Mar 2016 07:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 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, 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 Vsa5ILlHHblQ for ; Fri, 11 Mar 2016 07:26:18 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::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 E04C512D7F2 for ; Fri, 11 Mar 2016 07:26:16 -0800 (PST) Received: by mail-lb0-x22d.google.com with SMTP id x1so160236995lbj.3 for ; Fri, 11 Mar 2016 07:26:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to; bh=AObm67vrpjXRteO06JoQK5BOfo/XNIEMTQ16OFG3peA=; b=cSMcjG0R/XGxjvkLroAC/Wu9mxO0CKKNfhCB14/X/iY2NeoOhWfSyW5M3cfDRYhfR4 HUqHEbkeBu674GGg73ZVOLCk9Ttce3sOLe46L3hQEActDdbRzV/CXxvr2JgRNEUd/H10 jjwiWg+JYBcyLrs0kidRtciWPLgX6WW90n9suXhXxCP1JBtSyI/L5IX6XlNJ9GoKYaoY 2yFmg4Buel9BQarQYet+VQVfd/IjdXZtKHyB+KzlN9YzTcRpgOKqOBpAyhA7kq/vZ+2K 9qwvz4o3Wd2hVKiFYHAkfSmJYaWbYM498yRd9biwpjrZeyjOe0uTaRirQzAfOjTmMT/G 1mSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=AObm67vrpjXRteO06JoQK5BOfo/XNIEMTQ16OFG3peA=; b=Lg7TJ2HlGebuszRj5n/gNx7am1vfpO/R5agukcdzwqMfh9kUbScfLwVGIJbPRSOpvV OxJIzl5pLJLj4kS0/yVH+HS6nog6tR/BASBuc1Z5GO3IemX9EPN6opeAkTNf8kE1Tack G4NvUZBCfyozlsODPWE7KcQSJhU/mnT1bIesFPO6ej5VXLiAsrcWpq7TiPY9RftDSpaA 6zydnO4wvMUF4gdfZr1qthDxktjmEFwlSS/4RqCGyNBGNMeVVl5bKLzZEabU8hiqcTQb +T6BAWe/+DTAvCy1nGR9LE/8QsVjohMYbr1LyPRXnuXBoog50hu3xlnmEgIzsunjzHsd TCcA== X-Gm-Message-State: AD7BkJJyKn0dVbe3Tthd51ltwAdWfXK6G/Vz9XhKJcFK21pu1KBRbpJp0STPaUvpITlPNmB4xGUEsu5Ih3Fprw== MIME-Version: 1.0 X-Received: by 10.25.90.21 with SMTP id o21mr2714441lfb.166.1457709974881; Fri, 11 Mar 2016 07:26:14 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.151.67 with HTTP; Fri, 11 Mar 2016 07:26:14 -0800 (PST) Date: Fri, 11 Mar 2016 10:26:14 -0500 X-Google-Sender-Auth: keMgpMS6-OArSYC67reS-Q22qZE Message-ID: From: Phillip Hallam-Baker To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] Bar BOF on making Computers (and crypto) easy to use 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, 11 Mar 2016 15:26:21 -0000 If people are interested in attending a Bar BOF at IETF 95 on this, please let me know so I can give numbers to Stephen. For years we have all agreed that the single biggest problem in security is making secure systems usable. Two years ago I demonstrated a scheme that made S/MIME mail as easy to use as regular mail. Then as I started to look at the deployment issues, I realized that 'as easy' isn't enough. To make the Internet secure, we have to make secure computers easier to use than they are today. I think I have a solution, if you excuse the marketing, 'The Mathematical Mesh'. But right now I am not fixated on that one solution. My goal is to solve the problem, not solve it in one particular way. Everything is on the table. Right now, the Mesh architecture is based on the following approach: * The user has ultimate control of their security * First priority is Availability, then Integrity, then Confidentiality [Do not lose the user's pictures of the kids at 3 years old] [Do not allow modification of system config files] [Protect secrets] * JSON over HTTP Web Service * JOSE Signature * End to end confidentiality and integrity * the Mesh itself is a Web Service but NOT a trusted service * Open standards, unencumbered technology * Reference code in C# Web Site: http://prismproof.org/ This is a completely general personal PKI that puts the user at the top of their personal trust hierarchy. So we can apply it to any cryptography enabled application. The YouTube demonstration shows S/MIME but that was chosen as end to end email security is the hardest application to support. For the Mesh to grow, it has to provide a compelling benefit to early adopters. So the two applications I am currently focused on are remembering Web Site Usernames and Passwords and managing SSH keys. Now these are both applications that people have done before. But as LastPass recently demonstrated, done before does not mean done right. I want solutions that are open, auditable and provide end-to-end security. Getting SSH key management right for me means making it easy to use a different key on each device. Right now I have to futz with every device I own each time I add one. Sure some folk have written scripts. But how much time can one person devote to writing a script and getting the implementation *really* right? Isn't an open standards based infrastructure the better way to approach this? At this point, I am only using traditional crypto that everyone is familiar with (public key encryption, signature, Merkle chain). Later on there are some additional security properties that are possible with some of the more cutting edge stuff that you have probably heard me talk about. Right now I don't want to confuse people so that is phase 2. Originally, I thought this would leverage PKIX for building a personal PKI. When I got into the various libraries I discovered this did not give me the leverage I expected. These have been used to support the WebPKI for 20 years and trying to repurpose them now creates more effort than it saves. From nobody Mon Mar 14 09:04:12 2016 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 7996D12DAF1 for ; Mon, 14 Mar 2016 09:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 w_YGFhIAXBGw for ; Mon, 14 Mar 2016 09:04:08 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id CF46D12DBC3 for ; Mon, 14 Mar 2016 09:02:51 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 85348F9C01C for ; Mon, 14 Mar 2016 12:02:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id U0-mQ0dcq2ei for ; Mon, 14 Mar 2016 11:49:46 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 040ADF9C019 for ; Mon, 14 Mar 2016 12:02:50 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary=Apple-Mail-295-775316555 Date: Mon, 14 Mar 2016 12:02:49 -0400 Message-Id: <8ED6241D-92AA-4667-B856-41B154B7376B@vigilsec.com> To: IETF SAAG Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: Subject: [saag] Request for Comments: NIST SP 800-175B, Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms 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, 14 Mar 2016 16:04:10 -0000 --Apple-Mail-295-775316555 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 NIST requests comments on SP 800-175B, Guideline for Using Cryptographic = Standards in the Federal Government: Cryptographic Mechanisms. The SP = 800-175 publications are intended to be a replacement for SP 800-21, = Guideline for Implementing Cryptography in the Federal Government, but = with a focus on using the cryptographic offerings currently available, = rather than building one=92s own implementation. SP 800-175B is intended = to provide guidance to the Federal government for using cryptography and = NIST=92s cryptographic standards to protect sensitive, but unclassified = digitized information during transmission and while in storage. The = cryptographic methods and services to be used are also discussed. The = first document in the series (i.e., SP 800-175A) will be available = shortly. Please provide comments on SP 800-175B by Friday, April 29, = 2016. =20 Comments may be sent to SP800-175@nist.gov, with =93Comments on SP = 800-175B=94 as the subject. If publication link does not work, please cut and paste into your = browser: = http://csrc.nist.gov/publications/drafts/800-175/sp800-175b_draft.pdf =20= --Apple-Mail-295-775316555 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

NIST requests comments on SP 800-175B, Guideline for Using Cryptographic Standards in the Federal = Government: Cryptographic Mechanisms. The SP 800-175 publications are intended to be a replacement for SP = 800-21, Guideline for Implementing Cryptography in the Federal Government, = but with a  focus on using the cryptographic offerings = currently available, rather than building one=92s own implementation. SP 800-175B is intended to provide guidance to the Federal = government for using cryptography and NIST=92s cryptographic standards = to protect sensitive, but unclassified digitized information during = transmission and while in storage. The cryptographic methods and services to be used are also discussed. The first document in the = series (i.e., SP 800-175A) will be available shortly. Please provide comments on SP 800-175B by Friday, April 29, = 2016.

 

Comments may be sent to SP800-175@nist.gov, with =93Comments on SP 800-175B=94 as the subject.


If publication link does not work, please cut and = paste into your browser: http://csrc.nist.gov/publications/drafts/800-175/sp800-175b_draft.pdf=

 

= --Apple-Mail-295-775316555-- From nobody Sat Mar 19 16:34:58 2016 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 65D7212D622 for ; Sat, 19 Mar 2016 16:34:55 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.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 uDc4IaxdmU9Q for ; Sat, 19 Mar 2016 16:34:52 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c: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 A2A6012D57F for ; Sat, 19 Mar 2016 16:34:52 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id q138so88248450vkb.3 for ; Sat, 19 Mar 2016 16:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=w+lRlIC2elqf7CMs7Rmyl/JI0R8o/LKZIGr237tTP0w=; b=nY9/aHI4PN8HEyHYieaQjwvJuP+RRS0YGQCrddqiEgOnimytfEVYTMKrOimttKUbw3 0mbadD1CwVk0B42/iSty/n+oEZvzN+SsuBmbpCs+qujWz7zGfznMlMf2j9o3yYVE3WS2 ofIogiTlO8uUsPqtAm4Gtwi7wbeRlZYwdkSJ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=w+lRlIC2elqf7CMs7Rmyl/JI0R8o/LKZIGr237tTP0w=; b=OMsDzfyJ0gpgUHpCJHWkbWf1L7xAMQVIYzPcOff5QPNmnKDi9krusMapKCHR7QhPGz djwZTMHql9yO6D+7o2ysnSNy26tt7P+dwfmGs7HeqwBch8JmbXYfQjxUTyT3sv6soTU3 /hGpD/nLl2IuKb8aqq6nv9YJ4XZ6MX+9Yqw5A4t3CcmSlMxGNeHu62ggrv5t56nCyiT3 yyubH6hNymt7bYSCnGM+4PjipIQWvWe2ybqGQnopLOKGxh5PDObdC9rb1dENMUZCkFRI hyvru9IIayezm4V/Sp8H3E1Yb+NfhL/c2tkaKQochcdjrgLApk3133txGghcokkwV1ZZ 8hPA== X-Gm-Message-State: AD7BkJJMp/kgBh1pKSSjCjLsmCiQs1yK8IAe4MmepgdKKLtJ8MGC6QHTFopCdRKSbUo39FNzbvoKvHHjOKEfMCBG X-Received: by 10.31.34.134 with SMTP id i128mr10052809vki.7.1458430491591; Sat, 19 Mar 2016 16:34:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.70.215 with HTTP; Sat, 19 Mar 2016 16:34:32 -0700 (PDT) From: Joseph Lorenzo Hall Date: Sat, 19 Mar 2016 19:34:32 -0400 Message-ID: To: saag@ietf.org, hrpc@irtf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Nick Feamster , Michael Aaron , Stephane Bortzmeyer , Giuseppe Aceto , Ben Jones , Antonio Pescape' Subject: [saag] new draft of draft-hall-censorship-tech 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: Sat, 19 Mar 2016 23:34:55 -0000 Greetings SAAG and HRPC, In SAAG at IETF 91, I presented our draft on "A Survey of Worldwide Censorship Techniques" [1]. We've since updated the draft, preparing for an -02 version, and have hopefully addressed a set of comments from Stephane Bortzmeyer and Martin Nilsson: * repo: https://github.com/josephlhall/rfc-censorship-tech * ID text: https://github.com/josephlhall/rfc-censorship-tech/blob/master/draft-hall-censorship-tech-latest.txt I'd love to get additional feedback before attempting to convince one of our overworked Security Area ADs to sponsor the draft and run it through the IETF process. You can send comments to draft-hall-censorship-tech@ietf.org, submit pull requests, or open github issues against the document to get feedback to us. Of course, if you're interested in contributing as a co-author, please let me know and give me an idea of what you'd like to add and we can go from there. best, Joe [1]: https://datatracker.ietf.org/doc/draft-hall-censorship-tech/ -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 CDT's annual dinner, Tech Prom, is April 6, 2016! https://cdt.org/annual-dinner From nobody Mon Mar 21 14:33:16 2016 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 2A68512D742 for ; Mon, 21 Mar 2016 14:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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] 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 aYe5pBlZjtdN for ; Mon, 21 Mar 2016 14:33:14 -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 DC16912D6A7 for ; Mon, 21 Mar 2016 14:33:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A191ABE32 for ; Mon, 21 Mar 2016 21:33:12 +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 Df6azbBUp0vt for ; Mon, 21 Mar 2016 21:33:11 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.46.21.5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E66D5BE2F for ; Mon, 21 Mar 2016 21:33:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458595991; bh=m0pNjzqdBXmLmrI0e3winzs6GROvz5hwydJEsIw7zqA=; h=To:From:Subject:Date:From; b=s4c7VT2ERBIHm4wsVyAFBi8VX7LFhaXmeRpsPNYRWCg/yT3GQQOQQcM5Lbbr4flBZ XdlXwrL/yxG60u0VaOhiMwAX35kzMq3W8wiMv6TulX/fP4jCCuTPCuA3GSYKOIjtmC DNsZwzq8FYaCbDepeZOz1dm6/A/RZhplt3ZFCvQg= To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56F06896.8030509@cs.tcd.ie> Date: Mon, 21 Mar 2016 21:33:10 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000106010901060100070106" Archived-At: Subject: [saag] Agenda slots for saag@IETF-95 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, 21 Mar 2016 21:33:15 -0000 This is a cryptographically signed message in MIME format. --------------ms000106010901060100070106 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =09 Hi all, I'm belatedly getting the agenda for the saag session at IETF-95 together. If you already asked us for a speaking slot, can you re-tx to Kathleen and I please? I will probably find it but no harm in a bit of duplication:-) If you didn't ask yet, you still can but we'll of course prioritise folks who asked earlier. I'll post a draft agenda later tonight but don't worry if think you should be, but are not on that - the final agenda won't be for a few more days yet. Thanks, S. --------------ms000106010901060100070106 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMjEy MTMzMTBaMC8GCSqGSIb3DQEJBDEiBCBMtv4Ylmt0DmLtWVz2FaQUj9cH6e4p/8bFGUw7nySm +jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCuTnqVBDhaAwPURBnCiZp18Aha2q/ejyn8AkPrRskunziEsFFjRfuB HURJk1hdek5mP3NHuUrU2wbMAiNwoYqblfCesvdHwJ2oLUTyw2yxJsdLNNkZz3SYRPCeyoZS UsxnQOgU1OQIWJ0yaboOVqRvWgOdbVfME0johU7i2g0E8s6Ww+PgHEskVGDN9eiJeBUtN44D kRWLgWqFWhTAAsyf2Ndg0uUOKXum61P5tPcRA2ZmTuhfZOBBv6CVObo0scfl/Wfxp8g2Fu5r TpcwRK7K0vyX26ld3d3t167HXlzAIIZQJpv5rNZ/H9EZgEm6fcVEA1BqsH40fdlNT2DenLJ+ AAAAAAAA --------------ms000106010901060100070106-- From nobody Mon Mar 21 18:03:51 2016 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 25AAD12D54B for ; Mon, 21 Mar 2016 18:03:50 -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 8Q1Zu8IeF9Wd for ; Mon, 21 Mar 2016 18:03:47 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E3612D168 for ; Mon, 21 Mar 2016 18:03:47 -0700 (PDT) Received: from [172.17.18.81] (net77-43-49-50.mclink.it [77.43.49.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 83C8B80161; Tue, 22 Mar 2016 02:03:42 +0100 (CET) To: Stephen Farrell , "saag@ietf.org" References: <56F06896.8030509@cs.tcd.ie> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56F092AF.3040904@si6networks.com> Date: Tue, 22 Mar 2016 01:32:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F06896.8030509@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: =?UTF-8?Q?Iv=c3=a1n_Arce?= Subject: Re: [saag] Agenda slots for saag@IETF-95 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: Tue, 22 Mar 2016 01:03:50 -0000 On 03/21/2016 10:33 PM, Stephen Farrell wrote: > > Hi all, > > I'm belatedly getting the agenda for the saag session at > IETF-95 together. > > If you already asked us for a speaking slot, can you > re-tx to Kathleen and I please? I will probably find it but > no harm in a bit of duplication:-) > > If you didn't ask yet, you still can but we'll of course > prioritise folks who asked earlier. If possible we'd like to present: Title: "Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols" Filename: draft-gont-predictable-numeric-ids-00 Speaker: Fernando Gont || Ivan Arce Slot: 20'? (but if more, even better) Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Mar 23 06:59:24 2016 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 6226012D53C for ; Wed, 23 Mar 2016 06:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 vfLLfZ2wVaOS for ; Wed, 23 Mar 2016 06:59:20 -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 135BE12DC29 for ; Wed, 23 Mar 2016 06:45:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 58A65BDF9 for ; Wed, 23 Mar 2016 13:45:12 +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 x7MkKXOCjzJk for ; Wed, 23 Mar 2016 13:45:10 +0000 (GMT) Received: from [192.150.181.133] (unknown [192.150.181.133]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6C9DFBDD0 for ; Wed, 23 Mar 2016 13:45:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458740710; bh=6XQ2OT/ehCcuGXXsZxq+zJ/piUufx4Nbjec/2ZqW94A=; h=To:From:Subject:Date:From; b=EqW/jWdr7oxbyLF5JZhgRvKyNlFVqpUZfknbfJmZtjTscTxmruQZDpWvI8MqmU6vn wWTxNLoMgydrJX4i8zmlH+fnbcOP0wUQYGmeUMaf5luTpf65sxdHfzzkC9yyUdc0DJ KDBFmDrL26kQIA238Wf0zY3hCI5irQhVPBBxwqh4= To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56F29DE6.50508@cs.tcd.ie> Date: Wed, 23 Mar 2016 13:45:10 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090107000002070306050306" Archived-At: Subject: [saag] possible BCP on public review being needed for standards-track crypto 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, 23 Mar 2016 13:59:23 -0000 This is a cryptographically signed message in MIME format. --------------ms090107000002070306050306 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Rich Salz has put together an initial stab at a draft of a BCP [1] that says "for IETF standards track, crypto algorithms need to have had public analysis." (Thanks Rich!) I think this'd be a good thing to progress but as you'll see the -00 submitted just at the cutoff needs a good bit of work. (Still great to have a starting point though, so thanks again Rich:-) So, please read and comment on saag@ietf.org. As well as getting detailed comments, I'd also be interested in whether or not folks think the basic premise is something it'd be good to have as a BCP, so thumbs-up/down messages are also useful at this point. (If "thumbs-down" please say why, if "thumbs-up" then later detailed wrangling over text will be fine.) We'll have a short 5-min slot for this in the saag session in B-A just to bring it to folks' attention. If there are issues that we don't resolve on the list (e.g. I'd expect that getting a good enough description of "public review" might be tricky) we can have a more extended discussion about this at saag in Berlin. Cheers, S. [1] https://tools.ietf.org/html/draft-rsalz-drbg-speck-wap-wep --------------ms090107000002070306050306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMjMx MzQ1MTBaMC8GCSqGSIb3DQEJBDEiBCAfX/qQFiOQWdqoi9guMKtKQUVLCD5p8T/i8/dhBTJW TzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQA0MzFcXP2P2TrqMmqe9CWb04q2PcBRCTE/Q77X1ZltLVofq8yBKvaI gcin125HwLmsKEvVrh2/p2FOUTSAWMjfPCZSqNIXjA9tQYetoLsaBsmv5LJi/r1hZP62jZE0 xUha5XP42t5K8LpI5N1XAQ1YvhWPHvpO6IbfQRW++VXe4WmtMVBilVlwUcLZAIXCc0t3ZL9Z yjgQGWRiGmMyWx/S0OUt/fFoWLi0zInXP92feet4tGed0PIgHTlzQljKEYcpnch2hahwa0+C Tidt/rSGQkFe0wcdTO8Ppaw22uSgR8XvgBjdL6SqfiAXFgnQLCp3xZj59CQAkC3vTGgAI9r8 AAAAAAAA --------------ms090107000002070306050306-- From nobody Wed Mar 23 10:26:58 2016 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 5017B12D14D for ; Wed, 23 Mar 2016 10:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 fLNUf9uY8GC4 for ; Wed, 23 Mar 2016 10:26:54 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 99CB712D12E for ; Wed, 23 Mar 2016 10:26:54 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 730D3423711; Wed, 23 Mar 2016 17:26:53 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 5D2EF42370E; Wed, 23 Mar 2016 17:26:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1458754013; bh=mHAr3maY97KWMNCQGopJkCTuWdqKyQVrlT8WcGxZd0g=; l=273; h=From:To:Date:References:In-Reply-To:From; b=eurDqXR5GoDbqVUdvcYGFKDShlKEi67MMhu6uLgdGSduLUZfzHMPlotoVS5ajh6x8 C+CUHwdaaAHkmJuzqlt2Zs920cdItQoJYs45/qeNOvLxpGJO2UuoFdNhljHMPBBlFT hBhuIRirSdfk1hWL6yLB1k4LYKsWUu/Zi/RergBs= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 5770F1FC88; Wed, 23 Mar 2016 17:26:53 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 23 Mar 2016 13:26:53 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 23 Mar 2016 13:26:52 -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.1130.005; Wed, 23 Mar 2016 13:26:52 -0400 From: "Salz, Rich" To: "cfrg@irtf.org" , "saag@ietf.org" Thread-Topic: [Cfrg] Fwd: [saag] possible BCP on public review being needed for standards-track crypto Thread-Index: AQHRhQ8HlpCAfKzKxEyzAMuZR1v71Z9nilmA//+9ZkA= Date: Wed, 23 Mar 2016 17:26:52 +0000 Message-ID: <30a931820a764cc081bcd91ac2fe4846@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56F29DE6.50508@cs.tcd.ie> <56F2A2D7.7020402@cs.tcd.ie> 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.33.143] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] [Cfrg] Fwd: possible BCP on public review being needed for standards-track crypto 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, 23 Mar 2016 17:26:57 -0000 For those playing along at home, my draft is maintained here: https://githu= b.com/richsalz/draft-rsalz-dbrg-speck-wap-wep and it's had some changes sin= ce the cut-off deadline. -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Wed Mar 23 12:10:09 2016 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 BFB1312D83D for ; Wed, 23 Mar 2016 12:10:07 -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 sDHFIij5jzdX for ; Wed, 23 Mar 2016 12:10:06 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c: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 2688812D834 for ; Wed, 23 Mar 2016 12:10:05 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id l68so36896128wml.1 for ; Wed, 23 Mar 2016 12:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=2whhR6NGBREBp1I5HvtpsmQ/T+N5Dou4jtg60SXvNHQ=; b=zmjF3UM5a5F2axItj2F34lb4/jtk0JktS8ANgdCWGGFccpDKAojUkce5OmaF4Wh7eN KCMiycS1Zjfl5cjjOB2vPLFXv7EWL3jCcDsf/Qo3maRd50q90I0nwgGhHR6aKpWQJhX2 4L38fN74yyHX+PIkdd+InRbZXb5CNo9NRqF+zl5bITpd6AE+d+TBePiNe3HF2w7uYqjD TxCZhZRETvE543W/qkPQe0li4XddOzOovqoMZZSLBeLXebgv6DW6uMS3Qo/6OE6+NWPY DZ6u52GUybfmgvOe4S475jakZsp5bZ36X+ZsqtfR9NA9/8W3lSAt/vOa+3LDqwCs3cEK Btxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2whhR6NGBREBp1I5HvtpsmQ/T+N5Dou4jtg60SXvNHQ=; b=KpiIOxbSN4Q4elZDe0HjpemuFrglXAGrevEyuRGlH8+wyFvnJ6DkrhU+KjCcYvhz8K xMzL+6hTQ15fcadOCVvy8IGroFJQHhwryB/QhySV9/+JfaGUZM04MXAlB2+rYdBgpng7 I+U6GQs6TsVpElgX5vmqSP/moEUlgQVti8M5oUkbPsTkoAlO1GEsrBjiDdqFcH9rR7QD M2uwkScdITq1rTHcx8UHp/IkIjim2Iv3LiDpkVguimjBSc+3ySi4CWMW5tRuGcXwSsK2 RAIFiNbrUPGCOIvgsE2HOwH6HPXW1wOY8XS4q+Y0F36Noq3IgJRxd7FdaxqO+/1JAwAp Mw3Q== X-Gm-Message-State: AD7BkJI8uwA013XYiBSxR2fz7+gsyCft7RShWv/DjF+j1m/jHh0BTY1AWC/PVj/gRrknug== X-Received: by 10.28.170.137 with SMTP id t131mr5932484wme.32.1458760203585; Wed, 23 Mar 2016 12:10:03 -0700 (PDT) Received: from [10.0.0.7] (bzq-79-178-150-60.red.bezeqint.net. [79.178.150.60]) by smtp.gmail.com with ESMTPSA id cb2sm3933781wjc.16.2016.03.23.12.10.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Mar 2016 12:10:02 -0700 (PDT) To: "Salz, Rich" , "saag@ietf.org" References: <56F29DE6.50508@cs.tcd.ie> <56F2A2D7.7020402@cs.tcd.ie> <30a931820a764cc081bcd91ac2fe4846@usma1ex-dag1mb1.msg.corp.akamai.com> From: Yaron Sheffer Message-ID: <56F2E9F6.3020303@gmail.com> Date: Wed, 23 Mar 2016 21:09:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <30a931820a764cc081bcd91ac2fe4846@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] [Cfrg] Fwd: possible BCP on public review being needed for standards-track crypto 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, 23 Mar 2016 19:10:08 -0000 So here are two possibly controversial comments (based on reading the GitHub version of the draft). - I think we need to say explicitly that publication as an RFC alone "does not count". The reason is, as far as I know most cryptographers do not review algorithms just because they were published as an informational RFC. - On the other hand, like it or not, NIST is still the leading reference for crypto algorithms. Yes, DUAL_EC_DRBG is a terrible example, but NIST is also the source of GCM and many other crypto mechanisms that are central to our work. As a result, mechanisms published by NIST are scrutinized heavily by the crypto community. And by the way, the title of this thread is misleading, in that it is much stronger than (the current version of) the draft. Thanks, Yaron On 03/23/2016 07:26 PM, Salz, Rich wrote: > For those playing along at home, my draft is maintained here: > https://github.com/richsalz/draft-rsalz-dbrg-speck-wap-wep and it's > had some changes since the cut-off deadline. > > -- Senior Architect, Akamai Technologies IM: richsalz@jabber.at > Twitter: RichSalz > > _______________________________________________ saag mailing list > saag@ietf.org https://www.ietf.org/mailman/listinfo/saag > From nobody Wed Mar 23 14:02:13 2016 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 9F2C712D743 for ; Wed, 23 Mar 2016 14:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 TnS0AsTkbsTq for ; Wed, 23 Mar 2016 14:02:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A24612D90A for ; Wed, 23 Mar 2016 14:02:09 -0700 (PDT) Received: from [192.168.10.140] ([94.79.182.6]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MRTiG-1aKkWj0jNY-00SjKi; Wed, 23 Mar 2016 22:02:05 +0100 To: Stephen Farrell , "saag@ietf.org" References: <56F29DE6.50508@cs.tcd.ie> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F3044D.6080905@gmx.net> Date: Wed, 23 Mar 2016 22:02:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F29DE6.50508@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ra3uC9jlsoUjgdPxSaW8qbglAW8VUvx8a" X-Provags-ID: V03:K0:U66n8QfJCwcIVTSnZLax5zGIl0PLOPstl7ssAvbdBhAgsrw4B4e 5+swYGaHXC79WezLKCNhpITyDzZxFXJaYH7Us3KkXu0WvqvCU3G13QSobyilA/gtpIdzcJJ Fu7bc4tkaLtFfne1uZFFXKN2iub5iAmKr6oFuWT6+vPp0s88z2RQNKoKU02fD4OQRFhKOV3 E2jTk+k8rVA7zAUaihRjw== X-UI-Out-Filterresults: notjunk:1;V01:K0:m6m+676bIMA=:rW7nZJTGAAH2p3B+N/xFyb gBaV2T1flZLjRrjkk3Xn7z+NK+L+xvQmRGqyh0Qka2zfVhjP4yrCDpOLmq57hnf4sq5dCeqGV Rptd8ZiG/4Pz+41JeGT5xRSUs/NnaZOmF3KWUbzhKYQNtWNZ+akZGPgqnCDNTrmt3jQntiyEe KVi613FbSrGVfAIsqxAk1owCNZjATLYxUdN9yFaUgCBfMkKfWXwbGcWkMRujHPN6eLxJwju2Z hyaK9KbcDKhdtwSVL75BTjPWd6sYlGaHC37zt+QW7GSzALo8EsYZH+LrrTTMRBHjllKMVQh9j seFPWB79bB1renTun5Rf/wQYCxPRZLf68IknVaaM6YHQvBwazQcreJjgcttObBQC1+vASDlM1 C+taf9Fz3gWhBbC2Vgzgtqnb1o0RzUDz+f2kWgWhg6LAN2mm+7my+RUMa2v8Mx2yDFSnYyquJ AqwHWQcs2mENiCGsy47OKc690a4ceHrb4koMWQkCqQ8mY0NSu+BXepvw2aHudzkpx0IvjE6Yl jSIUamC5ROzNS+c9G1BSjslJ/0Uz41iwzi2ibC+V/c6z8b+YoqklBvyZRbM/7b0EBbcdomOsS 3MFxDU8MJWBNtpneo7dJcq8jj3QM4WC9MEydmmDZH4D2303/ItAtNfUoLRMXNwwzq+kSA7yoX 6Xq4kEkIk0CglqOwy4sbnNuUyxJ6sRuvBvuyaPYAOdDdi0EaXdEKyVgSTWyy4WjYfDWlR3eH5 sFyIB4KKn9AkbBPNb6N/p3jIRKrOBlsQX4tPs2Cvmz79KCdjTccWviJXVOs= Archived-At: Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 23 Mar 2016 21:02:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ra3uC9jlsoUjgdPxSaW8qbglAW8VUvx8a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Stephen, the document Rich wrote says that "RFCs cannot specify an algorithm as mandatory-to-implement (MTI) unless that algorithm has had reasonable public review." Now, the question is what type of problem it this document really trying to solve. The mentioned examples, such as A5/1, A5/2, WEP and WPA, are not IETF RFCs and therefore we can hardly give guidance to other organizations. There are lots of closed organizations and the IAB work related to Open-Stand, see https://open-stand.org/, covers these issues already (although without a lot of impact). The Algebraic Eraser example is not much better since the authors came to the IETF with the intention to ask for review, which they actually received. IMHO the problem is that we have far too few people willing to do reviews and researchers have incentives to look at technologies when they are already deployed since the relevance of their investigations is much larger with widely deployed protocols. This is why the most secure protocols are those that never get beyond the paper-stage. An example of how bad our review can be was shown with MIKEY-IBAKE and MIKEY-SAKKE. Of course, you can argue that it did not receive reasonable public review but why should we care. Ciao Hannes On 03/23/2016 02:45 PM, Stephen Farrell wrote: >=20 > Hiya, >=20 > Rich Salz has put together an initial stab at a draft of a BCP [1] > that says "for IETF standards track, crypto algorithms need to > have had public analysis." (Thanks Rich!) >=20 > I think this'd be a good thing to progress but as you'll see the > -00 submitted just at the cutoff needs a good bit of work. (Still > great to have a starting point though, so thanks again Rich:-) >=20 > So, please read and comment on saag@ietf.org. As well as getting > detailed comments, I'd also be interested in whether or not > folks think the basic premise is something it'd be good to have > as a BCP, so thumbs-up/down messages are also useful at this > point. (If "thumbs-down" please say why, if "thumbs-up" then > later detailed wrangling over text will be fine.) >=20 > We'll have a short 5-min slot for this in the saag session in B-A > just to bring it to folks' attention. If there are issues that > we don't resolve on the list (e.g. I'd expect that getting a good > enough description of "public review" might be tricky) we can have > a more extended discussion about this at saag in Berlin. >=20 > Cheers, > S. >=20 > [1] https://tools.ietf.org/html/draft-rsalz-drbg-speck-wap-wep >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --Ra3uC9jlsoUjgdPxSaW8qbglAW8VUvx8a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW8wRNAAoJEGhJURNOOiAtjGsH/2g1cQa2ekprlZ4zwsanInLw y0B06duamg99BHTxIre+sI0FC25R6kkyHsp4F3UTBkfmmJTPreXsu/JEzTOHlaBm CyoaOzNS4Qj+cfGOpjERzXtxt32w8IysOEHla111/rB9AQaBkfrWlgrXU4D+JDHs qyuUANyMuFhDGk+Xc67HMus5P3k02vgDkERQ/RBTSFj0546f5or7iiRssfeoHleh zt8z6TuRf7y0f3am3Xn3oEW9mXp47402x4ZcaXIhOFibQU4wRE5VARdMrLupFyPL 9BMzRkTyiFD2NjvJeQt+G5WD1mUokLg2fiurAgbScv1QUZ86575ARSGLUXgXm2I= =KOMA -----END PGP SIGNATURE----- --Ra3uC9jlsoUjgdPxSaW8qbglAW8VUvx8a-- From nobody Wed Mar 23 18:28:19 2016 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 8981F12D581 for ; Wed, 23 Mar 2016 18:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 zndtvexWiBT6 for ; Wed, 23 Mar 2016 18:28:16 -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 CBC5F12D1BF for ; Wed, 23 Mar 2016 18:28:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C5B5DBE35; Thu, 24 Mar 2016 01:28:12 +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 DjMUOxZwweNi; Thu, 24 Mar 2016 01:28:11 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.46.21.5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C1D2FBE33; Thu, 24 Mar 2016 01:28:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458782891; bh=WkwC775d6xfDipc6HWFM7NvNGT4J3C7tcDrDyYXot6I=; h=Subject:To:References:From:Date:In-Reply-To:From; b=za9uNjd/gJ2fKfqeOWYDAqmpUaBFqtkqtAsgu6xgjQ9Mw7kDeZSe6C+GTxwCJ3d62 Hel9yW623u4Khizn2dkCInThk/uGxt1fFyjVJ7EQS4hrqUfToEfvKV+ZBAZtAax+7D 7BPbqGVK+0qjjh5yxePeB/rSE+f27yK3mq2YRsSU= To: Yaron Sheffer , "Salz, Rich" , "saag@ietf.org" References: <56F29DE6.50508@cs.tcd.ie> <56F2A2D7.7020402@cs.tcd.ie> <30a931820a764cc081bcd91ac2fe4846@usma1ex-dag1mb1.msg.corp.akamai.com> <56F2E9F6.3020303@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56F342AA.9080803@cs.tcd.ie> Date: Thu, 24 Mar 2016 01:28:10 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56F2E9F6.3020303@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060909090504070001040608" Archived-At: Subject: Re: [saag] [Cfrg] Fwd: possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 01:28:18 -0000 This is a cryptographically signed message in MIME format. --------------ms060909090504070001040608 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 23/03/16 19:09, Yaron Sheffer wrote: >=20 > And by the way, the title of this thread is misleading, in that it is > much stronger than (the current version of) the draft. Ah sorry, that's a fair point - I messed up and should've said "MTI in standards-track." Please read the draft and react to that and not to my badly chosen subject line. Mind you that subject probably does represent my unconscious asserting itself, as I do dislike the idea that we'd use vanity or national crypto even if that's not MTI. But I do accept that we'd not likely get consensus on what my unconscious thinks:-) Cheers, S. --------------ms060909090504070001040608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMjQw MTI4MTBaMC8GCSqGSIb3DQEJBDEiBCDWsVvcCjWB1wCeEcyIP0uYmMIdVXWhKyWNMMZzh2sx FTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCXafInhvCHzCl7wRVK4bklH1m5tUmcaMKsLFFk8fKsmbVOUHIg2ePg kMiRIxjtU5tIElNWWdg7Su80bJoUuwPrEmQIbzg7fZatkfzGG7nej5D4+VrtBWGwFW7wVJjw vbEXw94WtsS0h+yOj4ddz3aabCC5ti/SKY3bX5YXSKEzAEyoeuIa1kxQ7FVZZjZW8aJhttbO aBcRc68WByIOjw5XCymZ9LCwXMlrp3VHDxI9Fszq0jcQFaYJi9/2fmmoGA+9eO/pxpq2Bt9F RFJSYWxz/8JkyTB4e/IswXwBG26eU49GNvLf8Urha4Np3pmFTPFd9yJJUuNhEwX9a29kya5r AAAAAAAA --------------ms060909090504070001040608-- From nobody Wed Mar 23 18:45:40 2016 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 DE3B712D197 for ; Wed, 23 Mar 2016 18:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 LbjThyDFmMUd for ; Wed, 23 Mar 2016 18:45:37 -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 E0B5712D18E for ; Wed, 23 Mar 2016 18:45:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 55C4DBE35; Thu, 24 Mar 2016 01:45:35 +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 lrSjBJswnPbo; Thu, 24 Mar 2016 01:45:33 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.46.21.5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1104EBE33; Thu, 24 Mar 2016 01:45:30 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458783933; bh=ATE2qv1Vzz40MB3JwGCINyEl5nZ6upOZEywaJv5G/XU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=WwKYtXQVTOAnolrHP5pvYVeG2tUVtUpDLc24C7ED9dZaBvlo9nOjtPaChBNY73VWd xoEa89TjKdQaUHofZIBOXkNyTFWFBoI4ITznDh262u0HF/50IYOONy7BhsdWnhhjqU ak1xh/pi3cEV0RJGLYBlTwLXRDMXFRjK2HCj069w= To: Hannes Tschofenig , "saag@ietf.org" References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56F346B3.30600@cs.tcd.ie> Date: Thu, 24 Mar 2016 01:45:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56F3044D.6080905@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IDhOfhRLD8msn8IKoanvrRRETseuAobPw" Archived-At: Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 01:45:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IDhOfhRLD8msn8IKoanvrRRETseuAobPw Content-Type: multipart/mixed; boundary="WmH7QmS0VkKG4hFbwTFu7ePslNwRjgcKV" From: Stephen Farrell To: Hannes Tschofenig , "saag@ietf.org" Message-ID: <56F346B3.30600@cs.tcd.ie> Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> In-Reply-To: <56F3044D.6080905@gmx.net> --WmH7QmS0VkKG4hFbwTFu7ePslNwRjgcKV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 23/03/16 21:02, Hannes Tschofenig wrote: > Hi Stephen, >=20 > the document Rich wrote says that "RFCs cannot specify an algorithm as > mandatory-to-implement (MTI) unless that algorithm has had reasonable > public review." See my reply to Yaron. >=20 > Now, the question is what type of problem it this document really tryin= g > to solve. >=20 > The mentioned examples, such as A5/1, A5/2, WEP and WPA, are not IETF > RFCs and therefore we can hardly give guidance to other organizations. As it happens, I don't agree. That other SDOs have ended up using crap crypto is telling and tells us to not do that. This aims to help us avoid such pitfalls. > There are lots of closed organizations and the IAB work related to > Open-Stand, see https://open-stand.org/, covers these issues already > (although without a lot of impact). I don't believe open-stand is relevant here. For crypto algs we're more talking about having had publications at Crypto, RWC etc. >=20 > The Algebraic Eraser example is not much better since the authors came > to the IETF with the intention to ask for review, which they actually > received. Well, I'm not sure though that we can depend on there being a handy cryptographer in the room who happens to have a colleague who can find issues in a timely manner before we standardise stuff. We've so far done the right thing in that case I think, but I'd prefer we had a BCP t help us be more likely to do that without depending on such co-incidence. >=20 > IMHO the problem is that we have far too few people willing to do > reviews and researchers have incentives to look at technologies when > they are already deployed since the relevance of their investigations i= s > much larger with widely deployed protocols. This is why the most secure= > protocols are those that never get beyond the paper-stage. Again we're looking at crypto algorithms here and not security or privacy in general. CFRG have been making progress in getting better eyeballs on those in general and I think we can build on that via a BCP like this, if folks want a BCP like this. >=20 > An example of how bad our review can be was shown with MIKEY-IBAKE and > MIKEY-SAKKE. Of course, you can argue that it did not receive reasonabl= e > public review but why should we care. Yeah, those are a good example. I've just cleared a related DISCUSS [1] after a year+ on the basis that the authors agreed to experimental and not standards track for just this reason. (You can see the history there at [1].) I'd have been much more comfortable doing that if we had a BCP at which I could have pointed. Cheers, S. [1] https://datatracker.ietf.org/doc/draft-ietf-manet-ibs/history/ >=20 > Ciao > Hannes >=20 >=20 > On 03/23/2016 02:45 PM, Stephen Farrell wrote: >> >> Hiya, >> >> Rich Salz has put together an initial stab at a draft of a BCP [1] >> that says "for IETF standards track, crypto algorithms need to >> have had public analysis." (Thanks Rich!) >> >> I think this'd be a good thing to progress but as you'll see the >> -00 submitted just at the cutoff needs a good bit of work. (Still >> great to have a starting point though, so thanks again Rich:-) >> >> So, please read and comment on saag@ietf.org. As well as getting >> detailed comments, I'd also be interested in whether or not >> folks think the basic premise is something it'd be good to have >> as a BCP, so thumbs-up/down messages are also useful at this >> point. (If "thumbs-down" please say why, if "thumbs-up" then >> later detailed wrangling over text will be fine.) >> >> We'll have a short 5-min slot for this in the saag session in B-A >> just to bring it to folks' attention. If there are issues that >> we don't resolve on the list (e.g. I'd expect that getting a good >> enough description of "public review" might be tricky) we can have >> a more extended discussion about this at saag in Berlin. >> >> Cheers, >> S. >> >> [1] https://tools.ietf.org/html/draft-rsalz-drbg-speck-wap-wep >> >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> >=20 --WmH7QmS0VkKG4hFbwTFu7ePslNwRjgcKV-- --IDhOfhRLD8msn8IKoanvrRRETseuAobPw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW80a0AAoJEC88hzaAX42iHxYH/RLS+tiL3E1DlCmn3ci1Qiva TB3JSIZdDogms/ubWKgxjrMwhpVx0XfZLlkgzouYQfO0PiuCRVNjClyg3Nc4f6zR rr3m7RwzUl8nNhv+FtFiEtK9P51+ohm6t+D7wMN4c9RPDDCDrGpFaIIkSBbE5MT9 inxRBQ/snMfYkhdlStBOWo+0boBfIqKW4bq9urkhEtcw4/LhLrVmU9L5HInNET6p bUbpf8qz7opLDxU08WU8Hm/17l876aDibTQunUVVtWECG2OlOX8hw9dENo9+oDb+ ZP1cOP9LmSp4/o17ku/yTqXNBZVIk39OKW2k2dsTtAAUouRstxApjyByHS0L6ak= =eR4Q -----END PGP SIGNATURE----- --IDhOfhRLD8msn8IKoanvrRRETseuAobPw-- From nobody Wed Mar 23 20:33:17 2016 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 29C7C12D14B for ; Wed, 23 Mar 2016 20:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 sdYM7pq2-Qkv for ; Wed, 23 Mar 2016 20:33:15 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4606F12D0BC for ; Wed, 23 Mar 2016 20:33:15 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5DFB016C9E4; Thu, 24 Mar 2016 03:33:14 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 47EAF16C9BC; Thu, 24 Mar 2016 03:33:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1458790394; bh=6iK92S8lq+eD2Udw1mBCziKDi1UPtqHT+tvrThxTvQs=; l=1828; h=From:To:Date:References:In-Reply-To:From; b=o0P4M12Zx8iIAlChhiptiLv0Xp+lyuen65+goRsn68c5w33kOicPSPlELFYUU+tyl wP8HrPPaYvNT5GWfTruSIf9JoGm9WP90krSlHwC5p3Dyao/s1n9jaetO8CYLN6i8Q/ ER/y6UYZ5Q5zoPjGKjPIz67rO+xM9bxRJjUbe1EQ= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 2F93C98082; Thu, 24 Mar 2016 03:33:14 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 23 Mar 2016 23:33:13 -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.1130.005; Wed, 23 Mar 2016 23:33:13 -0400 From: "Salz, Rich" To: Stephen Farrell , Hannes Tschofenig , "saag@ietf.org" Thread-Topic: [saag] possible BCP on public review being needed for standards-track crypto Thread-Index: AQHRhUdJbeb1XQCXmUiUqV21h2EKpJ9oFiiA///WqJA= Date: Thu, 24 Mar 2016 03:33:12 +0000 Message-ID: <1167b205a7114ca4b5265a6a292a44ec@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> In-Reply-To: <56F346B3.30600@cs.tcd.ie> 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.32.157] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 03:33:17 -0000 U3RlcGhlbiBzYXlzOg0KPiAuLi4gVGhhdCBvdGhlciBTRE9zIGhhdmUgZW5kZWQgdXAgdXNpbmcg Y3JhcA0KPiBjcnlwdG8gaXMgdGVsbGluZyBhbmQgdGVsbHMgdXMgdG8gbm90IGRvIHRoYXQuIFRo aXMgYWltcyB0byBoZWxwIHVzIGF2b2lkIHN1Y2gNCj4gcGl0ZmFsbHMuDQoNCkluIHNvbWUgd2F5 cyB0aGlzIHByb3Bvc2VkIEJDUCBpcyB2ZXJ5IElFVEYtbGlrZSwgaW4gdGhhdCBpdCByZXF1aXJl cyBzb21ldGhpbmcgbWVhc3VyYWJsZSAocHVibGljIHJldmlldyksIGJ1dCBzdGlsbCBoYXMgYW4g YXNwZWN0IG9mIHJvdWdoIGNvbnNlbnN1cyAoZW5vdWdoIHB1YmxpYyByZXZpZXcpLg0KDQpIYW5u ZXM6DQo+ID4gVGhlIEFsZ2VicmFpYyBFcmFzZXIgZXhhbXBsZSBpcyBub3QgbXVjaCBiZXR0ZXIg c2luY2UgdGhlIGF1dGhvcnMgY2FtZQ0KPiA+IHRvIHRoZSBJRVRGIHdpdGggdGhlIGludGVudGlv biB0byBhc2sgZm9yIHJldmlldywgd2hpY2ggdGhleSBhY3R1YWxseQ0KPiA+IHJlY2VpdmVkLg0K DQpUaGF0J3Mgbm90IG15IHJlY29sbGVjdGlvbiAoSSB3YXMgaW4gdGhlIHJvb20pLiAgVGhleSBj YW1lIGxvb2tpbmcgdG8gaW1wcmVzcyB3aXRoIGhvdyBnb29kIGl0IHdhcywgYW5kIHNlZSBpZiB0 aGVyZSB3ZXJlIHBvc3NpYmlsaXRpZXMgb2YgdXNpbmcgaXQgaW4gSUVURiBkb2N1bWVudHMuDQoN Cj4gPiBJTUhPIHRoZSBwcm9ibGVtIGlzIHRoYXQgd2UgaGF2ZSBmYXIgdG9vIGZldyBwZW9wbGUg d2lsbGluZyB0byBkbw0KPiA+IHJldmlld3MgYW5kIHJlc2VhcmNoZXJzIGhhdmUgaW5jZW50aXZl cyB0byBsb29rIGF0IHRlY2hub2xvZ2llcyB3aGVuDQo+ID4gdGhleSBhcmUgYWxyZWFkeSBkZXBs b3llZCBzaW5jZSB0aGUgcmVsZXZhbmNlIG9mIHRoZWlyIGludmVzdGlnYXRpb25zDQo+ID4gaXMg bXVjaCBsYXJnZXIgd2l0aCB3aWRlbHkgZGVwbG95ZWQgcHJvdG9jb2xzLiBUaGlzIGlzIHdoeSB0 aGUgbW9zdA0KPiA+IHNlY3VyZSBwcm90b2NvbHMgYXJlIHRob3NlIHRoYXQgbmV2ZXIgZ2V0IGJl eW9uZCB0aGUgcGFwZXItc3RhZ2UuDQoNClRoZSBwb3N0LWN1dG9mZiB2ZXJzaW9uIGFkZHMgc29t ZSB0ZXh0IGFib3V0IHJlc2VhcmNoIGluY2VudGl2ZXMsIGFuZCB3aHkgTVRJIHNlZW1zIGxpa2Ug dGhlIGJlc3QgcGxhY2UgdG8gZG8gdGhpcy4gIFBsZWFzZSBsb29rIGF0IGh0dHBzOi8vcmF3Lmdp dGh1YnVzZXJjb250ZW50LmNvbS9yaWNoc2Fsei9kcmFmdC1yc2Fsei1kYnJnLXNwZWNrLXdhcC13 ZXAvbWFzdGVyL2RyYWZ0LXJzYWx6LWRyYmctc3BlY2std2FwLXdlcC5tZCBhbmQgc2VlICJXaHkg bGltaXQgdG8gTVRJIg0KDQogDQoNCg0K From nobody Thu Mar 24 07:17:19 2016 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 A0CD612DB2C for ; Thu, 24 Mar 2016 07:17:17 -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 rK-D6jl3OXOy for ; Thu, 24 Mar 2016 07:17:16 -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 6EB3A12DB75 for ; Thu, 24 Mar 2016 07:09:01 -0700 (PDT) Received: from [10.20.30.159] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u2OE8xXu065059 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Mar 2016 07:09:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [10.20.30.159] From: "Paul Hoffman" To: "saag@ietf.org" Date: Thu, 24 Mar 2016 07:08:57 -0700 Message-ID: <4C506F53-6128-4EAB-9E12-AA7096FCBD44@vpnc.org> In-Reply-To: <1167b205a7114ca4b5265a6a292a44ec@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> <1167b205a7114ca4b5265a6a292a44ec@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 14:17:17 -0000 On 23 Mar 2016, at 20:33, Salz, Rich wrote: > Stephen says: >> ... That other SDOs have ended up using crap >> crypto is telling and tells us to not do that. This aims to help us >> avoid such >> pitfalls. > > In some ways this proposed BCP is very IETF-like, in that it requires > something measurable (public review), but still has an aspect of rough > consensus (enough public review). Yes, exactly. Instead of us saying "we know exactly how much review we need", we can admit that the amount is variable, but way above "no one has written a paper questioning it". > Hannes: >>> The Algebraic Eraser example is not much better since the authors >>> came >>> to the IETF with the intention to ask for review, which they >>> actually >>> received. > > That's not my recollection (I was in the room). They came looking to > impress with how good it was, and see if there were possibilities of > using it in IETF documents. Rich's recollection matches mine. As much as I respect the messenger in this case, his response to people saying "problems have been found" was a quick "we have now fixed those", not "so we will slow down and make sure we have enough external review". --Paul Hoffman From nobody Thu Mar 24 07:56:18 2016 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 8D42E12DBD6 for ; Thu, 24 Mar 2016 07:56:16 -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=ihtfp.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 W7wAWWR5Hphk for ; Thu, 24 Mar 2016 07:56:14 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F336F12DD70 for ; Thu, 24 Mar 2016 07:43:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 2AADAE2030; Thu, 24 Mar 2016 10:43:38 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 25006-04; Thu, 24 Mar 2016 10:43:23 -0400 (EDT) Received: from securerf.ihtfp.org (IHTFP-DHCP-159.IHTFP.ORG [192.168.248.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 7AD38E200A; Thu, 24 Mar 2016 10:43:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1458830603; bh=gz46KHtoBtSuGOBmxCiWaaYN2H/3D11NRjrcbtQ2Y1c=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=W9yDbpKfl34lYShPiSOHPXqNPVPHpTZLJaXbzaeyjAH3sUz1w0IQpRKCsXe2bhrI5 nhP//xqDYHevZOrXFF88UES3lTevsdX8Ntdnv+SE6oWDVA9YTWBXqyTrFfgl/xWP5u 9bOVMxKt8KN1WE+u5N59lg5rVVEd10ZaHhsLJTG0= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u2OEhM0G007714; Thu, 24 Mar 2016 10:43:22 -0400 From: Derek Atkins To: Hannes Tschofenig References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> Date: Thu, 24 Mar 2016 10:43:22 -0400 In-Reply-To: <56F3044D.6080905@gmx.net> (Hannes Tschofenig's message of "Wed, 23 Mar 2016 22:02:05 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 14:56:16 -0000 Hi, Hannes Tschofenig writes: > The Algebraic Eraser example is not much better since the authors came > to the IETF with the intention to ask for review, which they actually > received. I agree with Hannes that this is a bad example specifically because, as Hannes said, the goal of coming to the IRTF (note IR, not IE) was to get more review, which did actually happen. It's also a bad example because, even though there was an I-D for AE in OpenPGP (which has since expired), it was never intended to be MTI. Moreover, Algebraic Eraser, while patented, HAS been published for over a decade now. So the fact that it is patented is orthogonal to getting good reviews. See below: > IMHO the problem is that we have far too few people willing to do > reviews and researchers have incentives to look at technologies when > they are already deployed since the relevance of their investigations is > much larger with widely deployed protocols. This is why the most secure > protocols are those that never get beyond the paper-stage. Agreed; this is the hard problem -- encouraging researchers to look at algorithms. I've been spending much of the past two years trying to get this to happen, with some (but still limited) success. Often, it's only once the algorithms look like they are going to get deployed that researchers start to look at them! >> [1] https://tools.ietf.org/html/draft-rsalz-drbg-speck-wap-wep -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Mar 24 07:58:03 2016 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 6717012DD50 for ; Thu, 24 Mar 2016 07:58:02 -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=ihtfp.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 gjzekZ_OiJgG for ; Thu, 24 Mar 2016 07:58:01 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13EC112DD7B for ; Thu, 24 Mar 2016 07:44:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 2DA14E203A; Thu, 24 Mar 2016 10:44:53 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 25006-05; Thu, 24 Mar 2016 10:44:45 -0400 (EDT) Received: from securerf.ihtfp.org (IHTFP-DHCP-159.IHTFP.ORG [192.168.248.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 5EC91E2039; Thu, 24 Mar 2016 10:44:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1458830685; bh=+yHoVcOS4zuGiYOBzX3MfheEjGfziyXXTTqb6wJHiYA=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=KHssiJAsfmdSGLmDssB9MuXbIpo62jSN7EAWgdlRA9QlVreGM+waKSWTrrC3T1DYk hpwjcXAKnSuxQJhJAYddQ3v6QE3kULzCMeJpRnBAUNQlV91wNSSnfBsYl/XWYWJq2r Z5OMkObLb8MAoIed+9u4e1sXDxTbDarRBgFEFRSs= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u2OEijct007791; Thu, 24 Mar 2016 10:44:45 -0400 From: Derek Atkins To: Stephen Farrell References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> Date: Thu, 24 Mar 2016 10:44:45 -0400 In-Reply-To: <56F346B3.30600@cs.tcd.ie> (Stephen Farrell's message of "Thu, 24 Mar 2016 01:45:23 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 14:58:02 -0000 Stephen Farrell writes: > Well, I'm not sure though that we can depend on there being a > handy cryptographer in the room who happens to have a colleague > who can find issues in a timely manner before we standardise > stuff. We've so far done the right thing in that case I think, > but I'd prefer we had a BCP t help us be more likely to do that > without depending on such co-incidence. I thought the whole point of CFRG *WAS* to connect to the cryptographers? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Mar 24 08:06:59 2016 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 D08A212DE33 for ; Thu, 24 Mar 2016 08:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 pQdzmkd1TavW for ; Thu, 24 Mar 2016 08:06:43 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4F24712DCB8 for ; Thu, 24 Mar 2016 07:52:05 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5382B433443; Thu, 24 Mar 2016 14:52:04 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 3C68C433409; Thu, 24 Mar 2016 14:52:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1458831124; bh=Z/yAPSJ0IC9AjzUOOwGE8jlVsmrVX8kMWrfAzDT6py4=; l=1025; h=From:To:CC:Date:References:In-Reply-To:From; b=v2Xk2uk7aOoTypUhjSUgdCEKdRbGfPSWQyWqp/5kGC8LPs1WMT/AQSZMKDZ8GDYhl wkMcU6MfltaAVlf08MOHFSdJAccJbpvonJOdpJCZ0JdPRpyCeppmUrm9gVQCc8B+mR VgeuCJEo/uVpPmqW0OJpFFsd3bxvb7KKkRdLACBA= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 34F371FC86; Thu, 24 Mar 2016 14:52:04 +0000 (GMT) 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.1130.7; Thu, 24 Mar 2016 10:52:03 -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.1130.005; Thu, 24 Mar 2016 10:52:03 -0400 From: "Salz, Rich" To: Derek Atkins , Hannes Tschofenig Thread-Topic: [saag] possible BCP on public review being needed for standards-track crypto Thread-Index: AQHRhUdJbeb1XQCXmUiUqV21h2EKpJ9orJz5gAAAwwA= Date: Thu, 24 Mar 2016 14:52:03 +0000 Message-ID: <9b8703e739344ea494aae73e6b5b9aad@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> 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.37.123] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 15:06:52 -0000 > Agreed; this is the hard problem -- encouraging researchers to look at > algorithms. I've been spending much of the past two years trying to get = this > to happen, with some (but still limited) success. >=20 > Often, it's only once the algorithms look like they are going to get depl= oyed > that researchers start to look at them! True, and I tried to add some text that addresses this in my current WIP, h= ttps://github.com/richsalz/draft-rsalz-dbrg-speck-wap-wep My thesis is that= being patented is *not* orthogonal to getting good reviews and in fact, it= is a barrier to it. My recollection of AE at CFRG might be wrong, but at least one other person= shares my view. We can fix/remove it if this moves forward. The fact tha= t it wasn't MTI-track at the time is not relevant; the fact that it's paten= ted crypto is, because it is harder to get reviews of such things, as this = email thread seems to make clear. Perhaps the text needs improvement. (Wel= l, that's probably a tautology :) From nobody Thu Mar 24 08:09:52 2016 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 DBF5012DD0D for ; Thu, 24 Mar 2016 08:09:50 -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, HEADER_FROM_DIFFERENT_DOMAINS=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 MS8k2flMWXcn for ; Thu, 24 Mar 2016 08:09:49 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 443F712DD16 for ; Thu, 24 Mar 2016 07:54:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 8A111E203A; Thu, 24 Mar 2016 10:54:45 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 25006-08; Thu, 24 Mar 2016 10:54:40 -0400 (EDT) Received: from securerf.ihtfp.org (IHTFP-DHCP-159.IHTFP.ORG [192.168.248.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 34719E2039; Thu, 24 Mar 2016 10:54:37 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u2OEsaa1008363; Thu, 24 Mar 2016 10:54:36 -0400 From: Derek Atkins To: "Salz\, Rich" References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> <1167b205a7114ca4b5265a6a292a44ec@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Thu, 24 Mar 2016 10:54:36 -0400 In-Reply-To: <1167b205a7114ca4b5265a6a292a44ec@usma1ex-dag1mb1.msg.corp.akamai.com> (Rich Salz's message of "Thu, 24 Mar 2016 03:33:12 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 15:09:51 -0000 Rich, "Salz, Rich" writes: > Hannes: >> > The Algebraic Eraser example is not much better since the authors came >> > to the IETF with the intention to ask for review, which they actually >> > received. > > That's not my recollection (I was in the room). They came looking to > impress with how good it was, and see if there were possibilities of > using it in IETF documents. Sure, the end goal was to see if there were possibilities of using it in IETF documents, but that's a very fine distinction. CFRG is IMHO the right place to start specifically because it's the place where cryptographers and IETF engineers overlap. It IS a research group, after all, and not an IETF Working Group. Besides, with only a 10 minute time slot to present a 10-year-old published algorithm, how would YOU have spent that time? I'll note that most of the time was spent on the math and the algoritm details, with only one or two slides (out of 9 or 10 -- I don't recall) on performance. The fact that you recall the 2 minutes going over performance numbers means that the numbers actually impressed you; the fact that you don't remember all the time spent on the math means...??? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Mar 24 08:17:53 2016 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 0D26712DD80 for ; Thu, 24 Mar 2016 08:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 fXO4pD6RCvgC for ; Thu, 24 Mar 2016 08:17:48 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id A6A1E12DB3F for ; Thu, 24 Mar 2016 08:02:47 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6886D433437; Thu, 24 Mar 2016 15:02:45 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 52137433404; Thu, 24 Mar 2016 15:02:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1458831765; bh=U/tjX8s3zK4bu59FD261dnMRjYV/H5uUgrkx8b3IZFM=; l=751; h=From:To:CC:Date:References:In-Reply-To:From; b=yksbzuUVpsC/zXYB/AU6CADvO4Yg9yQHiR5pgm8tgvEv4l+m19AHVG4+pmeuEUmq/ KbQOQy0nebclfzlMLcp1SawMYt4GGCpZzk31KYGPmCyP3cAIu4t7/OL5RivZKUtIJA PBCbiiYnRlK0VXrRKVYs7qFzgwArZ+4qtdk2xnEs= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 4F3161FC88; Thu, 24 Mar 2016 15:02:45 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 24 Mar 2016 11:02:44 -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.1130.005; Thu, 24 Mar 2016 11:02:44 -0400 From: "Salz, Rich" To: Derek Atkins Thread-Topic: [saag] possible BCP on public review being needed for standards-track crypto Thread-Index: AQHRhd0j0QUhVAeW3E2ouFLWLFNLL59orr9A Date: Thu, 24 Mar 2016 15:02:44 +0000 Message-ID: <83b3753318d84e1c91b5cef8de7fb42e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> <1167b205a7114ca4b5265a6a292a44ec@usma1ex-dag1mb1.msg.corp.akamai.com> 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.37.123] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 15:17:52 -0000 Derek, you're a pal and I am sorry if you're offended/upset by what I wrote= . This note is not going to help, sorry. > The fact that you recall > the 2 minutes going over performance numbers means that the numbers > actually impressed you; the fact that you don't remember all the time spe= nt > on the math means...??? My impression of the presentation was as follows: you presented an algorith= m with some interesting performance capabilities, some math (that is over m= y head, I'm not a cryptographer) and then near the end someone asked "isn't= this patented?" and you said yes. In a more impressionistic mode, as opposed to just reporting my recollectio= n, I would replace the last three words with "you admitted it was." From nobody Thu Mar 24 08:18:08 2016 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 E7C7712DD97 for ; Thu, 24 Mar 2016 08:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 8AxJHWxllV_3 for ; Thu, 24 Mar 2016 08:18:05 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4CB12D6BD for ; Thu, 24 Mar 2016 08:03:13 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CFE39496C26; Thu, 24 Mar 2016 15:03:12 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id B9B62496C02; Thu, 24 Mar 2016 15:03:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1458831792; bh=KhTqUVG54XeEvP8junUj+dQIcS5f6XWtm1+nXsM313Q=; l=154; h=From:To:CC:Date:References:In-Reply-To:From; b=ZEGZSJo9eWPklexpwLjn1KjTJvnpWd6iFcYIzMHv19g5qFKHUOOPkkVvmJgbD/8GP 0sDDDUJMKIfhlZB1CI1ccdiOJRRrtzS5Unn/Lg0D0Fgh9FOEEtx6P1spuTktLEWMhD FcTxYHSVb2t5A17aklUaAG6I4zQRLEBTf1yoB9SE= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id A0ECB98082; Thu, 24 Mar 2016 15:03:12 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 24 Mar 2016 11:03:11 -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.1130.005; Thu, 24 Mar 2016 11:03:11 -0400 From: "Salz, Rich" To: Derek Atkins , Stephen Farrell Thread-Topic: [saag] possible BCP on public review being needed for standards-track crypto Thread-Index: AQHRhUdJbeb1XQCXmUiUqV21h2EKpJ9oFiiAgACafvOAAAFHUA== Date: Thu, 24 Mar 2016 15:03:11 +0000 Message-ID: <4771d01542b74a00b1fa543e6ed6b852@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> 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.37.123] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 15:18:07 -0000 > I thought the whole point of CFRG *WAS* to connect to the cryptographers? And the point of my draft is that this is necessary but not sufficient. From nobody Thu Mar 24 08:24:27 2016 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 27DCC12DBDC for ; Thu, 24 Mar 2016 08:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ZW14v3U861Sq for ; Thu, 24 Mar 2016 08:24:13 -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 3128C12D8CA for ; Thu, 24 Mar 2016 08:08:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7FF64BE35; Thu, 24 Mar 2016 15:08:03 +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 pcC9g3ljJM1K; Thu, 24 Mar 2016 15:08:02 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.46.21.5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5895BBE33; Thu, 24 Mar 2016 15:08:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458832082; bh=IgB0T+1G7EvDo73Lhr4bWh3xXsK/Oe1y5G9Q/veaS7I=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=VZFRXOS9muTj0n5Pp5YaYhn7mrAHeYqCS9lhirQj/MPsoWQ4Cs7ctd9eavhGpxg47 8Y53Icme7vnvBCD0X7OYcu09F3x4lQPACFjGYzmxvvhA2Dxes4ru6dwWMUX5hGChKo sIOOMqY5AJfBdhPDq7ITH/hyxavYGNxurmFkWGYw= To: Derek Atkins References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56F402D1.9080508@cs.tcd.ie> Date: Thu, 24 Mar 2016 15:08:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060608090905070600060409" Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 15:24:26 -0000 This is a cryptographically signed message in MIME format. --------------ms060608090905070600060409 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 24/03/16 14:44, Derek Atkins wrote: > Stephen Farrell writes: >=20 >> Well, I'm not sure though that we can depend on there being a >> handy cryptographer in the room who happens to have a colleague >> who can find issues in a timely manner before we standardise >> stuff. We've so far done the right thing in that case I think, >> but I'd prefer we had a BCP t help us be more likely to do that >> without depending on such co-incidence. >=20 > I thought the whole point of CFRG *WAS* to connect to the cryptographer= s? Yes, but the fact that your talk ended up with someone doing specific work on that algorithm was serendipitous. It was a good thing. What I meant in the above was that had that not happened then there is a possibility we'd now be down the road to having incorporated AE into standards. The public review you did in the end trigger by presenting resulted in the right thing happening. And that I think bolsters the argument for public review of algorithms and hence the putative BCP. S. >=20 > -derek >=20 --------------ms060608090905070600060409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMjQx NTA4MDFaMC8GCSqGSIb3DQEJBDEiBCAAWhDACwS3SWQ41ieX1ea3GDpJHyR64bH+7aESXcAr QTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCSRH81g32DDHLo63Sqx2lJxbb+l51fhYkt+xr8AEb0XTwAtIzmfSTn 3mCBLEftmdLEsh8Gb75Owd3ODcRr4rXsK0EgMX1U9aq79dT2u0i+5IW4Sjcp2+G+vEQCrh8o LuZnw0lji9miPZ0/8RrmdwS8POWLft103fM40spaRrdHJCCPgD6ncraj2ODYJSBv2Hlu6DK/ gaSaToUCbJ1bqLakbhl3fmkSbPoNd3Tgr88JnNCPOaTcL0lqrneQ6ul9x5zwT0MBYZZMndMR /rBgxdgt14p1m8OSqmSlbNlYYAe3u2c9DJbZNt4l0jUwCfdzq8T0clxaVMCFI0rYQ4Cb/S6t AAAAAAAA --------------ms060608090905070600060409-- From nobody Thu Mar 24 08:26:58 2016 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 BC83412DCC1 for ; Thu, 24 Mar 2016 08:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ihtfp.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 W7sUwsqSCo3Z for ; Thu, 24 Mar 2016 08:26:56 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A77D12DD35 for ; Thu, 24 Mar 2016 08:10:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 6F6CBE203F; Thu, 24 Mar 2016 11:10:45 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 25296-08; Thu, 24 Mar 2016 11:10:39 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id B7C42E2039; Thu, 24 Mar 2016 11:10:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1458832237; bh=wFL9SKns37iafJMDOCpqZJv1fQBW8QJSgAexB64Vsy0=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=fi2vV1D2cbFYMGyqy0/hqP2egQNl+wmrS0P/ZgqjBeIutD3uQLIkYbOYpFEI3mkbk VOaqtj4Upf+tonzcIzYZ/KVbxJFxHSFsvvcIW/auWxiixX0V8FfmZ7vbTugSCeuG04 BH6R9EJ566fn25N01YV4m5uAIGCGPgOkwSiKaAKs= Received: from 192.168.248.159 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 24 Mar 2016 11:10:37 -0400 Message-ID: <4ed4c86ac0cca6e4f48cdc544375e364.squirrel@mail2.ihtfp.org> In-Reply-To: <83b3753318d84e1c91b5cef8de7fb42e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> <1167b205a7114ca4b5265a6a292a44ec@usma1ex-dag1mb1.msg.corp.akamai.com> <83b3753318d84e1c91b5cef8de7fb42e@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Thu, 24 Mar 2016 11:10:37 -0400 From: "Derek Atkins" To: "Salz, Rich" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 15:26:57 -0000 Rich, On Thu, March 24, 2016 11:02 am, Salz, Rich wrote: > Derek, you're a pal and I am sorry if you're offended/upset by what I > wrote. This note is not going to help, sorry. Thanks, Rich. I'm not at all offended by this email; I do, however, still believe that AE is a bad example. >> The fact that you recall >> the 2 minutes going over performance numbers means that the numbers >> actually impressed you; the fact that you don't remember all the time >> spent >> on the math means...??? > > My impression of the presentation was as follows: you presented an > algorithm with some interesting performance capabilities, some math (that > is over my head, I'm not a cryptographer) and then near the end someone > asked "isn't this patented?" and you said yes. > > In a more impressionistic mode, as opposed to just reporting my > recollection, I would replace the last three words with "you admitted it > was." So what? I still don't see the correlation between patents and peer reviews. RSA was patented and got many reviews. ECC was (and in some cases still is) patented, and got (and still gets) many reviews. So just being patented isn't (and should not IMHO be) a gating issue. Being patented might be a deterrent to being standardized and/or deployed. However I do not see that being the issue at hand or preventing access for reviews. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Mar 24 08:50:37 2016 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 E26E512D5D4 for ; Thu, 24 Mar 2016 08:50:34 -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=ihtfp.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 5G3AJmV70BHT for ; Thu, 24 Mar 2016 08:50:33 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E7DA12D7C4 for ; Thu, 24 Mar 2016 08:37:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 059FAE203A; Thu, 24 Mar 2016 11:34:49 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 25658-02; Thu, 24 Mar 2016 11:30:35 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id DF75BE2039; Thu, 24 Mar 2016 11:30:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1458833434; bh=rUZD3mdEeRasUl+NTnaXqPWLBNn5utAL2VsWfAJziaM=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=bi6bfYzWaaySNf/ke0XwA7V3YXYD6NEDPO5HmdVPaEMMGLIEZ5ATuyT1pdqI54pAT 5MItr3XLXWt/bId80b90HKyFeLmBn+8yz+DcEGVdcFxyJsCHddKrKRNArYzn6lSzOM 6uBs/sft0mjv3jsVglfTs/UYKwA76nQB8Z5l+iZs= Received: from 192.168.248.159 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 24 Mar 2016 11:30:34 -0400 Message-ID: <7297aa787d6ee76c3ed31d8319f717fc.squirrel@mail2.ihtfp.org> In-Reply-To: <4C506F53-6128-4EAB-9E12-AA7096FCBD44@vpnc.org> References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> <1167b205a7114ca4b5265a6a292a44ec@usma1ex-dag1mb1.msg.corp.akamai.com> <4C506F53-6128-4EAB-9E12-AA7096FCBD44@vpnc.org> Date: Thu, 24 Mar 2016 11:30:34 -0400 From: "Derek Atkins" To: "Paul Hoffman" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 15:50:35 -0000 Paul, On Thu, March 24, 2016 10:08 am, Paul Hoffman wrote: > On 23 Mar 2016, at 20:33, Salz, Rich wrote: > >> That's not my recollection (I was in the room). They came looking to >> impress with how good it was, and see if there were possibilities of >> using it in IETF documents. > > Rich's recollection matches mine. As much as I respect the messenger in > this case, his response to people saying "problems have been found" was > a quick "we have now fixed those", not "so we will slow down and make > sure we have enough external review". At the time of the CFRG presentation the last attack had been over 6 years prior. And yes, at the time of the presentation all previous attacks HAD long been fixed. In your opinion, how long must one go without an attack before you decide it's "good enough"? This is certainly a question of consensus and one that IMHO does not have a solid line. But sorry, six years without an attack seems like a decent metric to me. For example, there was recently a serious attack against ECC where one could recover an ECDSA signing key with just over 5000 trials. What do you suggest we do? BTW, since the more recent attack in November we HAVE slowed down, including letting my OpenPGP draft expire. So the right thing IS happening. My issue with the document isn't with any of that; it's singling out AE being an issue because it is patented. Besides, AE was never intended to be MTI so yet another reason to remove it as an example from the document. Thanks, > --Paul Hoffman -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Mar 24 09:01:26 2016 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 CB5C212DDD3 for ; Thu, 24 Mar 2016 09:01: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 SBib27ijSmgg for ; Thu, 24 Mar 2016 09:01:23 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c: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 2144112DDAF for ; Thu, 24 Mar 2016 08:50:44 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id e185so64395083vkb.1 for ; Thu, 24 Mar 2016 08:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=gvKrvWytJKV9MVTYzEzsYhOMFieHLKyLMVSHU6/kazw=; b=Y44dBKhdLk1ZaPEdjGimesEOwCV3SeHpdvZH42SF4Ssaz8ztL5X1f+9ndJFjPiU34S nyAj1u7v/TmkpxCl5Jtn0ZHM1vQL2Bz9tgHRsHY43axUPF2tHmzsqK1Hyn4wg9xhsmXZ oumfkX3m9TRME0izeIZe4uRBchU7h+LL0szUVlr+cgmNjjnCxbWwbBaRW/W2n3w20ewd WoWsaa+zaDizmKnq3x4kMa7X4+ZP704vl22Sv+ZP5odvnfxh6xS2X/yZbl3702RKDt+Y Apt1scsfJu100+3pSJ6lexyCGOBlmYlkWhoTfCv7sza7DL41/Zb1LJsW8hDtlWacXJo0 Oj1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=gvKrvWytJKV9MVTYzEzsYhOMFieHLKyLMVSHU6/kazw=; b=NPEfUf47aT4D+NMr4ulCF5n+tKsD4615QuRdST+hvSGBo9smTIevswLhLXvVPf/Ixs qe1EUTFxta5zC8sW+8Nm7wO/VcByaMzzkXY+opS5k7tkY87kpCCPUmlIwZchH2L9E/Xg wlFxxnUKD9DKBJtQrtFSFLRlLxV5UV9aulIUKMs7X9M4r0v3/qfgwoRqJxpXgvbmMVV9 6m7vKvJb3R9iFcZdxDr2cDVMQSJCQjR7HyMPXKFXXjl3Br2lbN94UoBIWAfAzfAyKaSC 7X9Z63p57Un6eOJWM2ZAJQA0pRMQJxPOAwAf0T/Ra6v44Hiv4mcwIAuDOQTofOo5p/rE YGgQ== X-Gm-Message-State: AD7BkJIn++kW2BQ43gOnhjYCPAOmUipv6lYm4x8KsWEMo9wKVjcXZjw/j7YRziIuNoW3R0ESe+hYdRx81pipOQ== MIME-Version: 1.0 X-Received: by 10.31.58.83 with SMTP id h80mr4945607vka.149.1458834642854; Thu, 24 Mar 2016 08:50:42 -0700 (PDT) Received: by 10.176.1.183 with HTTP; Thu, 24 Mar 2016 08:50:42 -0700 (PDT) In-Reply-To: <4771d01542b74a00b1fa543e6ed6b852@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> <4771d01542b74a00b1fa543e6ed6b852@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Thu, 24 Mar 2016 08:50:42 -0700 Message-ID: From: Watson Ladd To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 16:01:26 -0000 On Thu, Mar 24, 2016 at 8:03 AM, Salz, Rich wrote: > >> I thought the whole point of CFRG *WAS* to connect to the cryptographers? > > And the point of my draft is that this is necessary but not sufficient. Let me expand on that point. None of the algorithms in SSLv3 have failed in ways that make SSLv3 insecure (exception is MD5 in PKIX). if SSLv3 was being proposed today, CFRG wouldn't be involved. Instead we'd depend on the working group to which SSLv3 was presented to realize it had significant problems. This draft wouldn't help with that problem. It would help with circumstances where CFRG review is limited, and someone is very insistent on pushing the draft through. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu Mar 24 09:08:23 2016 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 6F6AB12D131 for ; Thu, 24 Mar 2016 09:08:21 -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 Ba4SKsdIEXAR for ; Thu, 24 Mar 2016 09:08:19 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c: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 E235C12D57F for ; Thu, 24 Mar 2016 08:56:26 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id z68so64797853vkg.3 for ; Thu, 24 Mar 2016 08:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=fTbOaFEDbbPd4ktF+Sv7+a5UBzYDy60AnUfV6gwEqd8=; b=MiveAy9tctvba7DaATDe6k2VS1BtKmFr5wvsosFxJo6D3gESxTbAYvtetle2u6/jjp xCbu4gKIfci/Q9ty07mxIbp0KqEJoSM37Z9p31waXuSDtpe48MSUasq793QJfizCNrEM GRRCZthhbv964/54JA7CRWM2KxYg5CEr4lQskca8ceqEy4IPeUuwfum32R5Y3tbkaJ+v z/mK7yyvQwL4kR+S73Bubx0BR6XNLdmQ4KcdihGX4spdGmJi3f8ml30F1RS3op01FhEu UyIk2FqUZ4JqcXZG9cCv9jPEuM0wAU3EGKT4yzdyckVYmYBGjHRNslCJmkUB1cljXVyx zNvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fTbOaFEDbbPd4ktF+Sv7+a5UBzYDy60AnUfV6gwEqd8=; b=S5KLesGzKiX3GF6ie6tZCS2rJnrSaQI6NUt1CgjGsw2W/rTaqVoTso83WSDQlVY5dZ kRRaK4ZoOn8JJsCpDW79ZtWusQKQgjmSWS1AH7kQy811HAVw3YLVpKzSXIJGTXLQfLG4 PAzkkfm16SRe3guKtemKaQUBabgpCVa+VnyVQBtinDbB2zQqdG3RB042/lPB3v0rxpR6 iQ7/UvrX/WK+ZTgXsqLkSQBBvc6n07Z1uwePZFUcvg3YHIjAyxmiJ36d7ObmKHMGUGHM jrZDaN7AvDTiX1F+auXVnaetXCKzE9LLAbTaj5fGw2S0HeDZ9AwLFjKQeo/IPlXOsmK0 gN6Q== X-Gm-Message-State: AD7BkJKB7wmW1DnRHPI+HReO6GavX5O/aN8HVUA0E+mtxcclMAwpUBz9MFhH9gDokL5taLUEQmLjzK1it9sVCg== MIME-Version: 1.0 X-Received: by 10.176.3.112 with SMTP id 103mr2535499uat.125.1458834985997; Thu, 24 Mar 2016 08:56:25 -0700 (PDT) Received: by 10.176.1.183 with HTTP; Thu, 24 Mar 2016 08:56:25 -0700 (PDT) In-Reply-To: <7297aa787d6ee76c3ed31d8319f717fc.squirrel@mail2.ihtfp.org> References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> <1167b205a7114ca4b5265a6a292a44ec@usma1ex-dag1mb1.msg.corp.akamai.com> <4C506F53-6128-4EAB-9E12-AA7096FCBD44@vpnc.org> <7297aa787d6ee76c3ed31d8319f717fc.squirrel@mail2.ihtfp.org> Date: Thu, 24 Mar 2016 08:56:25 -0700 Message-ID: From: Watson Ladd To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Paul Hoffman , "saag@ietf.org" Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 16:08:21 -0000 On Thu, Mar 24, 2016 at 8:30 AM, Derek Atkins wrote: > Paul, > > On Thu, March 24, 2016 10:08 am, Paul Hoffman wrote: >> On 23 Mar 2016, at 20:33, Salz, Rich wrote: >> >>> That's not my recollection (I was in the room). They came looking to >>> impress with how good it was, and see if there were possibilities of >>> using it in IETF documents. >> >> Rich's recollection matches mine. As much as I respect the messenger in >> this case, his response to people saying "problems have been found" was >> a quick "we have now fixed those", not "so we will slow down and make >> sure we have enough external review". > > At the time of the CFRG presentation the last attack had been over 6 years > prior. And yes, at the time of the presentation all previous attacks HAD > long been fixed. In your opinion, how long must one go without an attack > before you decide it's "good enough"? Were people actually looking at the protocol presented, or the algebraic problem claimed (incorrectly) to be equivalent? Were people looking at all. Not all 6 year spans are equivalent. > > This is certainly a question of consensus and one that IMHO does not have > a solid line. But sorry, six years without an attack seems like a decent > metric to me. For example, there was recently a serious attack against > ECC where one could recover an ECDSA signing key with just over 5000 > trials. What do you suggest we do? Sounds bad doesn't it? But what attack was actually being used by Tromer et al.? Bleichenbacher's partial nonce recovery and the side channel attacks of Koch, both from early 90's. > > BTW, since the more recent attack in November we HAVE slowed down, > including letting my OpenPGP draft expire. So the right thing IS > happening. > > My issue with the document isn't with any of that; it's singling out AE > being an issue because it is patented. Besides, AE was never intended to > be MTI so yet another reason to remove it as an example from the document. > > Thanks, > >> --Paul Hoffman > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu Mar 24 09:08:36 2016 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 2DF0112DCDC for ; Thu, 24 Mar 2016 09:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 QpS7nai1B5bp for ; Thu, 24 Mar 2016 09:08:24 -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 25D4812D541 for ; Thu, 24 Mar 2016 08:56:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EC14BBDCF; Thu, 24 Mar 2016 15:56:32 +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 6jC3pCvkowDw; Thu, 24 Mar 2016 15:56:30 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.46.19.213]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BAF1FBE2F; Thu, 24 Mar 2016 15:56:29 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458834990; bh=KjlYDBRAOY+FQUcoH+eiwTd7gslSF7dwva6W4R8dNag=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=nOXF+J/pQpm4UGQGQtj0D+luqNrEJkf/XYMsrsOULQnVXgkfseuMBAsLAMJ8bUY6b 2zMT3o6pXJ6pHHVmklOLb65Nsr1Zu60VfJQQZuhhHPNR6JfEdwTJSAphGNzQ6wGu7+ CzMwiElbnKKTTmopYb/WQ5YGOgH9SQ/RFG3/Rijk= To: Watson Ladd , "Salz, Rich" References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> <4771d01542b74a00b1fa543e6ed6b852@usma1ex-dag1mb1.msg.corp.akamai.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56F40E2B.7010900@cs.tcd.ie> Date: Thu, 24 Mar 2016 15:56:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050405070503020500070008" Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 16:08:36 -0000 This is a cryptographically signed message in MIME format. --------------ms050405070503020500070008 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 24/03/16 15:50, Watson Ladd wrote: > This draft wouldn't help with that problem. It would help with > circumstances where CFRG review is limited, and someone is very > insistent on pushing the draft through. We do also see cases where an algorithm has been standardised by some other organisation but without the kind of public review we'd like to see, and where there is then pressure to ensure that algorithm can be used in IETF protocols, and even sometimes that it become an MTI. S. --------------ms050405070503020500070008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMjQx NTU2MjdaMC8GCSqGSIb3DQEJBDEiBCClPNKK+ZbPVJ7xh3reb9lKnZq2POFLOXgheSErl8i5 mDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAP9d5xD0LU3eVzxRuJyq3iqvbZq2jiOnnRVxAqW6xl8FzfAEJSnJGl tis4AuaJ4EnMci+tdsQzqb8/QXaR547ZvWRANbok9DmeeDz6k96ve4It1gbDCY8qdnZrSDfI L1MUeXv6kPBH9+W2En228J0FDcXF5ExsY+gsw4RULXCRdpJUYeS16Y7C2/Bl4NNwKHsPt95O T605vU7TFdJXZ0250Cja97oZhwRX8jdywbaWqPtiUYvI9n5fJ1UmVdwQG7T0tTTbtRNKd5F2 YaWEVH73vKRFnYudjAL2WsCjXIpYZk/BIdBMTYbBwYUQDIxJCQgT1V/DTmdY8mRIXYJ4uTMd AAAAAAAA --------------ms050405070503020500070008-- From nobody Thu Mar 24 09:09:53 2016 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 5C65712D6F3 for ; Thu, 24 Mar 2016 09:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 vjkwIQUJFl3G for ; Thu, 24 Mar 2016 09:09:49 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id CBEA912DBC8 for ; Thu, 24 Mar 2016 08:58:19 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DAEA3433448; Thu, 24 Mar 2016 15:58:18 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id C4C4543343C; Thu, 24 Mar 2016 15:58:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1458835098; bh=Wl3LjtBlmyBHosMiibVvvOiAk6BUJpMLtq2m57Z4tzw=; l=559; h=From:To:CC:Date:References:In-Reply-To:From; b=FKaRDOgWIfCpuHL0IsVFxT+g2PZX1jwJ9hGhqTgZgSoqKkQ7RRzMtRwWBvk3xfJ6f aXizyKq6ZWFCNEmryy6vKSZcnqwJAyDb34L20tej9W5UuFyHGUqnoRwqUS0EXXJ5eW YbQilNbxtxWIzBEvXiQYmBEW0EqD0LjL5QYZH7CU= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id A00BF1FC94; Thu, 24 Mar 2016 15:58:18 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 24 Mar 2016 11:58:18 -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.1130.005; Thu, 24 Mar 2016 11:58:18 -0400 From: "Salz, Rich" To: Derek Atkins , Paul Hoffman Thread-Topic: [saag] possible BCP on public review being needed for standards-track crypto Thread-Index: AQHRhUdJbeb1XQCXmUiUqV21h2EKpJ9oFiiA///WqJCAAPkYgIAAFs4A///EI7A= Date: Thu, 24 Mar 2016 15:58:17 +0000 Message-ID: <56b61f06e5604e0c80945cf9f56258de@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> <1167b205a7114ca4b5265a6a292a44ec@usma1ex-dag1mb1.msg.corp.akamai.com> <4C506F53-6128-4EAB-9E12-AA7096FCBD44@vpnc.org> <7297aa787d6ee76c3ed31d8319f717fc.squirrel@mail2.ihtfp.org> In-Reply-To: <7297aa787d6ee76c3ed31d8319f717fc.squirrel@mail2.ihtfp.org> 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.37.123] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 16:09:52 -0000 > But sorry, six years without an attack seems like a decent metric to > me. For example, there was recently a serious attack against ECC where o= ne > could recover an ECDSA signing key with just over 5000 trials. What do y= ou > suggest we do? Again, I think this bolsters my point. Very few people are looking at AE a= nd many people are looking at ECDSA. Why? My hypothesis is that one major= reason is that the former is patented and has little public use while the = latter is not. In true scientific method, let's try to disprove that. :) From nobody Thu Mar 24 09:30:37 2016 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 2498112D544 for ; Thu, 24 Mar 2016 09:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ihtfp.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 3ez9_Ag18wBR for ; Thu, 24 Mar 2016 09:30:34 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00DC12D75A for ; Thu, 24 Mar 2016 09:27:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 350FAE200A; Thu, 24 Mar 2016 12:26:56 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 26014-03; Thu, 24 Mar 2016 12:26:51 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 35BE5E2030; Thu, 24 Mar 2016 12:26:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1458836811; bh=bksoMPzG7wiWUj+Q4vLlNr7xHChOBf4Y58QebQ71yNY=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=Vdr31j5ecn0uQD63wF1QMenIcjClpNMYyKTpVFdApfvbn+lHunUTV81mA4b33LQ7J Vl4rGl5dEp1VWdby/oWC5bg2TAuo2Oy4yeQTYXPsLvAQxbGM1vFmjpfppH3iyyJ8i4 5z5sy+6KmpX/j/mBBpSiiKS50LCAOlymT/1Edi6Y= Received: from 192.168.248.159 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 24 Mar 2016 12:26:51 -0400 Message-ID: <5629b89e643712669a7b21db35e23076.squirrel@mail2.ihtfp.org> In-Reply-To: <56b61f06e5604e0c80945cf9f56258de@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> <1167b205a7114ca4b5265a6a292a44ec@usma1ex-dag1mb1.msg.corp.akamai.com> <4C506F53-6128-4EAB-9E12-AA7096FCBD44@vpnc.org> <7297aa787d6ee76c3ed31d8319f717fc.squirrel@mail2.ihtfp.org> <56b61f06e5604e0c80945cf9f56258de@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Thu, 24 Mar 2016 12:26:51 -0400 From: "Derek Atkins" To: "Salz, Rich" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 16:30:35 -0000 Rich, On Thu, March 24, 2016 11:58 am, Salz, Rich wrote: >> But sorry, six years without an attack seems like a decent metric to >> me. For example, there was recently a serious attack against ECC where >> one >> could recover an ECDSA signing key with just over 5000 trials. What do >> you >> suggest we do? > > Again, I think this bolsters my point. Very few people are looking at AE > and many people are looking at ECDSA. Why? My hypothesis is that one > major reason is that the former is patented and has little public use > while the latter is not. In true scientific method, let's try to disprove > that. :) As my statistics professor used to say, "Correlation does not imply Causation". I would argue that it's the SECOND part of your statement that is the cause, and not the first. The fact that ECC is deployed and being actively used makes it a "more interesting" target for researchers. It also lowers the barrier of entry because there are lots of implementations available. I would argue that it's the number of available implementations and the amount of deployment (and not the patent status) that have a stronger correlation (and probably even causal) effect on the amount of research done. It's certainly the case that when I was a grad student I would prefer to bang on something that already existed versus having to implement it myself and then bang on it. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Mar 24 09:34:40 2016 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 43F2612D131 for ; Thu, 24 Mar 2016 09:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 PKR3ZcNh-cn3 for ; Thu, 24 Mar 2016 09:34:37 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4870B12D0FF for ; Thu, 24 Mar 2016 09:34:37 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A6A813F4028; Thu, 24 Mar 2016 16:34:36 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 899563F402D; Thu, 24 Mar 2016 16:34:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1458837276; bh=7PeTOCd9RrvxLbgHMTumB3FFqeMCPEAtbAd45D9/YB4=; l=452; h=From:To:CC:Date:References:In-Reply-To:From; b=usIAekjxZkzBDDgf7knytF9iHcl40eQj3O3sAWQKMuLIZwcy6KXTni9g7MXkMdbT5 zRBLm4yzBmrOGCKk+ieUcmkmGN68sA9ySuOdmYLZskbkkk9mNQW/PH8nqluYtcbYDM XNynsTDogyzL4DzlxvuKbw+hW1osBLvIAOA74RfA= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 7889D1FC88; Thu, 24 Mar 2016 16:34:36 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 24 Mar 2016 12:34:36 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 24 Mar 2016 12:34:35 -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.1130.005; Thu, 24 Mar 2016 12:34:35 -0400 From: "Salz, Rich" To: Derek Atkins Thread-Topic: [saag] possible BCP on public review being needed for standards-track crypto Thread-Index: AQHRhUdJbeb1XQCXmUiUqV21h2EKpJ9oFiiA///WqJCAAPkYgIAAFs4A///EI7CAAEuXgP//vtOg Date: Thu, 24 Mar 2016 16:34:35 +0000 Message-ID: <753840d92413467c90a829195845eb8e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> <1167b205a7114ca4b5265a6a292a44ec@usma1ex-dag1mb1.msg.corp.akamai.com> <4C506F53-6128-4EAB-9E12-AA7096FCBD44@vpnc.org> <7297aa787d6ee76c3ed31d8319f717fc.squirrel@mail2.ihtfp.org> <56b61f06e5604e0c80945cf9f56258de@usma1ex-dag1mb1.msg.corp.akamai.com> <5629b89e643712669a7b21db35e23076.squirrel@mail2.ihtfp.org> In-Reply-To: <5629b89e643712669a7b21db35e23076.squirrel@mail2.ihtfp.org> 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.37.123] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 16:34:39 -0000 PiBBcyBteSBzdGF0aXN0aWNzIHByb2Zlc3NvciB1c2VkIHRvIHNheSwgIkNvcnJlbGF0aW9uIGRv ZXMgbm90IGltcGx5DQo+IENhdXNhdGlvbiIuIA0KDQpJIGRpZCBub3QgZG8gd2VsbCBpbiA2LjA0 MSA6KSAgW2luc2lkZSBqb2tlXQ0KDQo+IEkgd291bGQgYXJndWUgdGhhdCBpdCdzIHRoZSBTRUNP TkQgcGFydCBvZiB5b3VyIHN0YXRlbWVudCB0aGF0IGlzDQo+IHRoZSBjYXVzZSwgYW5kIG5vdCB0 aGUgZmlyc3QuDQoNClNocnVnLiAgV2hlbi9pZiB0aGlzIG1vdmVzIGZvcndhcmQgSSdsbCBiZSBn bGFkIGNoYW5nZSBpdCBpZiBjb25zZW5zdXMgaW5kaWNhdGVzIHRoYXQuDQo= From nobody Thu Mar 24 10:29:41 2016 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 0AE4E12D698 for ; Thu, 24 Mar 2016 10:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 lG4sJ7Qc2p4M for ; Thu, 24 Mar 2016 10:29:38 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 07ABE12D5B5 for ; Thu, 24 Mar 2016 10:29:37 -0700 (PDT) Received: from [128.9.184.148] ([128.9.184.148]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u2OHT6RR002746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Mar 2016 10:29:07 -0700 (PDT) To: Hannes Tschofenig , Stephen Farrell , "saag@ietf.org" References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> From: Joe Touch Message-ID: <56F423E2.5000505@isi.edu> Date: Thu, 24 Mar 2016 10:29:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F3044D.6080905@gmx.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 17:29:40 -0000 On 3/23/2016 2:02 PM, Hannes Tschofenig wrote: > the document Rich wrote says that "RFCs cannot specify an algorithm as > mandatory-to-implement (MTI) unless that algorithm has had reasonable > public review." I completely agree that all BCPs and standards-track RFCs should require only algs and mechanisms that have had reasonable public review. I thought it was an assumed requirement of all BCPs and standards-track RFCs anyway. If it is not, a general statement to that effect seems reasonable. However, I disagree that this uniquely applies to crypto. Joe From nobody Thu Mar 24 11:19:11 2016 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 19EBC12D16C for ; Thu, 24 Mar 2016 11:19:09 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.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 SgcCA4rbV7YF for ; Thu, 24 Mar 2016 11:19:06 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0052.outbound.protection.outlook.com [104.47.0.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF3D12D6F0 for ; Thu, 24 Mar 2016 11:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZMej0xthobhoadYeanBl1yylOwW+CHccToCqe3Zzk4c=; b=2QzGzHEbkFJ66tIQ4poGEa1I4H2W1CigsLMpheJVLqJuVymJhotM3x/GG0PSHy7C1h9ruZWxeMDeQaSDm8+Bbi8cOzMlwqxCufLeZnlD5KzSpKga82AxA72n7MkF+e6giP2YTk5Q/gwHAz3UcIljBagFUFl6KFX2YUq3GmwZiCg= Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1824.eurprd03.prod.outlook.com (10.166.42.150) with Microsoft SMTP Server (TLS) id 15.1.447.15; Thu, 24 Mar 2016 18:19:03 +0000 Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0447.017; Thu, 24 Mar 2016 18:19:03 +0000 From: "Paterson, Kenny" To: Derek Atkins , "Salz, Rich" Thread-Topic: [saag] possible BCP on public review being needed for standards-track crypto Thread-Index: AQHRhUdNmMPwMqKelkWmPMyPqYGa7Z9n0xqAgAAeIACAAMNVKf///VIAgAACNICAADS7gA== Date: Thu, 24 Mar 2016 18:19:03 +0000 Message-ID: References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> <1167b205a7114ca4b5265a6a292a44ec@usma1ex-dag1mb1.msg.corp.akamai.com> <83b3753318d84e1c91b5cef8de7fb42e@usma1ex-dag1mb1.msg.corp.akamai.com> <4ed4c86ac0cca6e4f48cdc544375e364.squirrel@mail2.ihtfp.org> In-Reply-To: <4ed4c86ac0cca6e4f48cdc544375e364.squirrel@mail2.ihtfp.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 authentication-results: ihtfp.com; dkim=none (message not signed) header.d=none;ihtfp.com; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [134.219.148.47] x-ms-office365-filtering-correlation-id: c17a2b1b-259b-415a-7af3-08d35410c7bf x-microsoft-exchange-diagnostics: 1; VI1PR03MB1824; 5:Ej4yuV67/Vu/zf3ShAOeLxVCxlHXJPPQ0BubEAh7BXcr7YMEqVqNyOwxWURZZIznFhlwN8ATY734PYpkk3smC59sOimfHA1U9fLiMypJjUuahvh9wlQMBjNoiFppYCiHKGaNUVQVTiDpahp0CvzIZQ==; 24:TnHBKyGLTzy5YcWR8ZnUYHfChwxid0Ga9x1jetYvSJ277x1/Fcx2LlSKLMGRAJFHUeAaQLaxt8Mma9v+ORX9rK6jD8djy6C32rh5akFGtVk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1824; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:VI1PR03MB1824; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1824; x-forefront-prvs: 0891BC3F3D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(19580405001)(1096002)(77096005)(11100500001)(87936001)(5004730100002)(122556002)(5008740100001)(19580395003)(50986999)(92566002)(561944003)(54356999)(76176999)(86362001)(15975445007)(93886004)(83506001)(5001770100001)(4001350100001)(36756003)(2906002)(4326007)(106116001)(586003)(66066001)(5002640100001)(10400500002)(74482002)(6116002)(1220700001)(189998001)(3660700001)(2950100001)(15974865002)(102836003)(3280700002)(2900100001)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1824; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <09D6248250FF10449EFC6E904203A1D1@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2016 18:19:03.5859 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1824 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 18:19:09 -0000 SGkgRGVyZWssDQoNCk9uIDI0LzAzLzIwMTYgMTU6MTAsICJzYWFnIG9uIGJlaGFsZiBvZiBEZXJl ayBBdGtpbnMiDQo8c2FhZy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBkZXJla0BpaHRm cC5jb20+IHdyb3RlOg0KPg0KPkJlaW5nIHBhdGVudGVkIG1pZ2h0IGJlIGEgZGV0ZXJyZW50IHRv IGJlaW5nIHN0YW5kYXJkaXplZCBhbmQvb3IgZGVwbG95ZWQuDQo+IEhvd2V2ZXIgSSBkbyBub3Qg c2VlIHRoYXQgYmVpbmcgdGhlIGlzc3VlIGF0IGhhbmQgb3IgcHJldmVudGluZyBhY2Nlc3MNCj5m b3IgcmV2aWV3cy4NCg0KT25lIHZlcnkgc3Ryb25nIGZhY3RvciB0aGF0IHByZXZlbnRzIHByb3Bl ciByZXZpZXcgb2YgbmV3IGNyeXB0byBwcm9wb3NhbHMNCmlzIHRoZSBjb21tdW5pdHkgaGF2aW5n IGFjY2VzcyB0byBhIGNvbXBsZXRlIHNwZWNpZmljYXRpb24gb2YgdGhlIHByb3Bvc2FsDQpiZWlu ZyBwcm9tb3RlZC4NCg0KRm9yIGV4YW1wbGUsIGRvZXMgU2VjdXJlUkYgaGF2ZSBwbGFucyB0byBw dWJsaXNoIGEgZnVsbCBzcGVjaWZpY2F0aW9uIG9mDQppdHMgQWxnZWJyYWljIEVyYXNlciBzY2hl bWUsIGluY2x1ZGluZyB0aGUgdml0YWwgZGV0YWlscyBvZiBob3cga2V5DQpnZW5lcmF0aW9uIGlz IGRvbmUgc28gYXMgdG8gYXZvaWQgdGhlIHJlY2VudCBhdHRhY2tzPyBPciBoYXZlIHlvdSBhbHJl YWR5DQpkb25lIHNvLCBhbmQgSSBqdXN0IG1pc3NlZCBpdD8gT3IgaXMgdGhlcmUgc29tZSBzb3Vy Y2UgY29kZSB0aGF0DQpyZXNlYXJjaGVycyBjYW4gdXNlIHRvIGV4cGVyaW1lbnQgd2l0aCB0aGUg YWN0dWFsIGtleSBnZW5lcmF0aW9uIHByb2Nlc3MNCnlvdSBhcmUgY3VycmVudGx5IHByb3Bvc2lu Zz8NCg0KV2l0aG91dCB0aGF0IGtpbmQgb2YgZGV0YWlsLCBJJ20gYWZyYWlkIFNlY3VyZVJGIHdv dWxkIHJlbWFpbiB2dWxuZXJhYmxlDQp0byAocG9zc2libHkgYmFzZWxlc3MpIGFjY3VzYXRpb25z IG9mIGJlaW5nIGluIHRoZSBidXNpbmVzcyBvZiBzZWxsaW5nDQpoZXJwZXRvbG9naWNhbCBwcm9k dWN0cy4NCg0KQ2hlZXJzLA0KDQpLZW5ueQ0KDQoNCj4NCj4tZGVyZWsNCj4NCj4tLSANCj4gICAg ICAgRGVyZWsgQXRraW5zICAgICAgICAgICAgICAgICA2MTctNjIzLTM3NDUNCj4gICAgICAgZGVy ZWtAaWh0ZnAuY29tICAgICAgICAgICAgIHd3dy5paHRmcC5jb20NCj4gICAgICAgQ29tcHV0ZXIg YW5kIEludGVybmV0IFNlY3VyaXR5IENvbnN1bHRhbnQNCj4NCj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNhYWcgbWFpbGluZyBsaXN0DQo+c2FhZ0Bp ZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZw0KDQo= From nobody Thu Mar 24 11:26:57 2016 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 3404412D51E for ; Thu, 24 Mar 2016 11:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 I4bPKgQae0Jf for ; Thu, 24 Mar 2016 11:26:44 -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 82F8D12DAB7 for ; Thu, 24 Mar 2016 11:26:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 50B66BE3F; Thu, 24 Mar 2016 18:26:15 +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 3dUrbSbO1Aw3; Thu, 24 Mar 2016 18:26:14 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.46.19.213]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0AB30BE2F; Thu, 24 Mar 2016 18:26:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458843974; bh=uhbK5SIf7GNh9yFAlZ57PXi8cVk+7mkNIpBlNUIw1/E=; h=Subject:To:References:From:Date:In-Reply-To:From; b=vV+seWPnWGEd7m40ylyDArNtp45I9ans/7YtDR3A5eUQI8XVHyPuhdUqCQE3QOrOy puvBFD3BQe4d0LU+WFnZlAOI95r+v3zaEhdc+N58A5YjCnubakcbiTblLtUOMZQI0h qAJ4WkOdbQmUiBYv5lcFu7A63JftQUF/YjdbGKb0= To: Joe Touch , Hannes Tschofenig , "saag@ietf.org" References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F423E2.5000505@isi.edu> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56F43144.6030803@cs.tcd.ie> Date: Thu, 24 Mar 2016 18:26:12 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56F423E2.5000505@isi.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080001080508050703080002" Archived-At: Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 18:26:56 -0000 This is a cryptographically signed message in MIME format. --------------ms080001080508050703080002 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 24/03/16 17:29, Joe Touch wrote: >=20 >=20 > On 3/23/2016 2:02 PM, Hannes Tschofenig wrote: >> the document Rich wrote says that "RFCs cannot specify an algorithm as= >> mandatory-to-implement (MTI) unless that algorithm has had reasonable >> public review." >=20 > I completely agree that all BCPs and standards-track RFCs should requir= e > only algs and mechanisms that have had reasonable public review. >=20 > I thought it was an assumed requirement of all BCPs and standards-track= > RFCs anyway. If it is not, a general statement to that effect seems > reasonable. However, I disagree that this uniquely applies to crypto. Sure, there are other things that would require equivalent review. I think a reason crypto makes sense as a target for this BCP is that in the IETF we do have a good few people who are qualified to judge when the level of public review seems good, but who aren't the ones who'd be doing the review. Put another way, we (IETF sec area folks) know the set of venues for good publications here but aren't the ones who'd write those. It's not clear to me how to generalise a BCP beyond crypto and preserve that property. S >=20 > Joe >=20 --------------ms080001080508050703080002 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMjQx ODI2MTJaMC8GCSqGSIb3DQEJBDEiBCALrG5q8417Nc/hFhqAh/rDxGvXs9CuidSlmcs/5qY+ KjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCf4UnMJCVkEcl6Tfays3eZ/OUVTT2O9VCbZ314hNAkqxeyIM+msJf6 VA7vRU3l+bRle8z/X1fduiPzg3BM/4/JCnm7/VZzzeA3f8bPnB1+WMpsX5P5BHA61HPFe+IH wNSIs6xJIy89Ez0YCAI/TzI58dFIpf8l5MU8xf3kufXdYOUUNgWD0Dfk/Uq8EHWJYEuhvnCx xEuAHNqxXjYJ4EhWvG2RIkYBuIjc/MAHwtiCEbWJTl0RRLEEjt3IUZ5HQUB9Z/cdT6mgoFMl Yg19bV4lZi2Lurtis8JI8xTIBXzBb5r+/A/OBWw6b+djnB4hLJu3vuTv7g8wRrYoaM/3g1KY AAAAAAAA --------------ms080001080508050703080002-- From nobody Thu Mar 24 11:28:13 2016 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 A755B12D74D for ; Thu, 24 Mar 2016 11:28:12 -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 9l2hjyE4wKL4 for ; Thu, 24 Mar 2016 11:28:10 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 C8AFE12D71F for ; Thu, 24 Mar 2016 11:28:10 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id v187so62873770ioe.2 for ; Thu, 24 Mar 2016 11:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=jDyIyxV7Ee8gmEtX3HyQXI5fijJAbpU8revhlxVsgac=; b=EghVBIwAwoEd5leWzPerfU/iiALWXrCBGSWQ6sZjzkdj5TKeU+vrMPwVFYCOg7NK9Y dkXoevcT+H+nnsDuFyCIJ3eTO9a7o5tIyVuMYaJK1AHr+TQT5z8Rb//GpWxCEfW+oHwD Fwv8BS9QJM/9yo16ybqGpQl0aWHHQJyBIIEX2KMrgVvwnncI5+wGjwBvpcGDkJj5WNL/ o56d+k5ixZqcU4C1Uw3GiKayPR6AktivlhAQyfCzmtHQrM8Hy2NobtySRm5+4Xm28MfK Rg8PJYZ29rx8lLpuB9jzaMhbxb1zZKj/Pvaa3vbJjXZPFZsIKKhZb3+8qxnWuUZusbHp KfLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jDyIyxV7Ee8gmEtX3HyQXI5fijJAbpU8revhlxVsgac=; b=Az+PhR7Qp5InTswBRFN/IOvUA9TLYU4gwsVOAQn6rI8sbbMJQUJNOKYWlZPnanO+L6 fPJD3PdxwN5H7nruhJEIEeQm5nvfVWXi9C1bMoVQSzBYRtObO8ipymU6fweWB257OR1O 8Ho0oNy95s7MyZAivSH+4FA1lZun3qr67MEXNxCT4j+I8SH6GW8YbgV2HE/i/LZ73bB1 WCaekE4I94YdAASmXlwOSUB+w6YAMmgRCq3d7TRgfcyzTgPp64bm81gLbPfHj2BQkbUX oFy4ZiQnB5h0ddgr06ghPI0a6SSVukT23TbvhLgVOJpoxAehHXvPTBHvg3nxWSZ3HQYU 8+aw== X-Gm-Message-State: AD7BkJKIch++S1tsZjWaaHXwsYBJyeN5+pYpREgm2aD7rPWRZdVpccw9S40Lc9LupkfWZQ== X-Received: by 10.107.33.7 with SMTP id h7mr10385448ioh.30.1458844090188; Thu, 24 Mar 2016 11:28:10 -0700 (PDT) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by smtp.gmail.com with ESMTPSA id hv3sm11718554igb.13.2016.03.24.11.28.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Mar 2016 11:28:09 -0700 (PDT) To: Joe Touch , Hannes Tschofenig , Stephen Farrell , "saag@ietf.org" References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F423E2.5000505@isi.edu> From: Rene Struik Message-ID: <56F431AF.6080109@gmail.com> Date: Thu, 24 Mar 2016 14:27:59 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F423E2.5000505@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] (on the uselessness on legislating the obvious) Re: possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 18:28:12 -0000 Dear colleagues: I would like to echo Joe Touch's remark: indeed, one would assume that RFCs describe relatively mature technology, no matter the area. Personally, I have trouble seeing what value the draft provides, since it states the obvious: it has been long common practice to require some (read: solid) rationale supporting suggested engineering approaches. Aren't we all (well, most of us) engineers and scientists who should all do our own due diligence? In case we have collectively forgotten, adding this BCP to the shelf does not help and we have to look into the mirror, get back on our feet again, or hand in our degrees. Or, is there perhaps a subliminal message in the draft that we now have to depend on nods of program committee members only? If so, this seems to provide a bad incentive for offloading our own responsibilities. Let our acts be guided by time-tested engineering principles instead. Best regards, Rene On 3/24/2016 1:29 PM, Joe Touch wrote: > > On 3/23/2016 2:02 PM, Hannes Tschofenig wrote: >> the document Rich wrote says that "RFCs cannot specify an algorithm as >> mandatory-to-implement (MTI) unless that algorithm has had reasonable >> public review." > I completely agree that all BCPs and standards-track RFCs should require > only algs and mechanisms that have had reasonable public review. > > I thought it was an assumed requirement of all BCPs and standards-track > RFCs anyway. If it is not, a general statement to that effect seems > reasonable. However, I disagree that this uniquely applies to crypto. > > Joe > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Thu Mar 24 12:21:35 2016 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 4485B12D681 for ; Thu, 24 Mar 2016 12:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 wh6P6-RLa2B5 for ; Thu, 24 Mar 2016 12:21:31 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 A672F12D597 for ; Thu, 24 Mar 2016 12:21:31 -0700 (PDT) Received: from [10.123.83.109] (usc-secure-wireless-207-109.usc.edu [68.181.207.109]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u2OJKxft028992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Mar 2016 12:21:14 -0700 (PDT) To: Stephen Farrell , Hannes Tschofenig , "saag@ietf.org" References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F423E2.5000505@isi.edu> <56F43144.6030803@cs.tcd.ie> From: Joe Touch Message-ID: <56F43E1A.1000407@isi.edu> Date: Thu, 24 Mar 2016 12:20:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F43144.6030803@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 24 Mar 2016 19:21:33 -0000 On 3/24/2016 11:26 AM, Stephen Farrell wrote: > I think a reason crypto makes sense as a target for this BCP is that > in the IETF we do have a good few people who are qualified to judge > when the level of public review seems good, but who aren't the ones > who'd be doing the review. Put another way, we (IETF sec area folks) > know the set of venues for good publications here but aren't the ones > who'd write those. > > It's not clear to me how to generalise a BCP beyond crypto and preserve > that property. Every interaction with a link layer has this property (usually because the specs are limited access through the IEEE) as do many interactions with upper layer protocols and services (not all of which are IETF). IMO, if we have people here who want to do reviews, they should do so - in the venues where that's relevant. I don't think the IETF is the only place where that can or should occur, and I don't think we need to call out review of crypto as a special case. Joe From nobody Thu Mar 24 21:47:13 2016 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 C3D0512D14C for ; Thu, 24 Mar 2016 21:47:12 -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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tc26.ru 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 WL5KDTuf51V5 for ; Thu, 24 Mar 2016 21:47:10 -0700 (PDT) Received: from mail.tc26.ru (mail.tc26.ru [188.40.163.82]) by ietfa.amsl.com (Postfix) with ESMTP id DD78112D12A for ; Thu, 24 Mar 2016 21:47:09 -0700 (PDT) Received: from mail.tc26.ru (localhost [127.0.0.1]) by mail.tc26.ru (Postfix) with ESMTPSA id BE35E300168; Fri, 25 Mar 2016 07:47:06 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.tc26.ru BE35E300168 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tc26.ru; s=mx; t=1458881228; bh=UztSl5We56HB1wc07045RmRfAdchOsyLMKAcyun95p0=; h=Date:From:Subject:To:Cc:In-Reply-To:References:From; b=nlTwtPgueMqWK7l1rL+6Zl42GeHOJ+FdLOPF5gYQslK8T2nqjvPaPFKajIVG7OOHF xzO8brrN8s/zCsEyQOr7GCC6jXphoLtF+R00mn8rhoeF3gAToefZFtftFQdpszzf9z Yhr5zZhnTiosFXwD5OZ5qfM82drNyb97peQghY6s= Mime-Version: 1.0 Date: Fri, 25 Mar 2016 04:47:06 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: <1a687f67071f874cec787e1e9b5a9d32@mail.tc26.ru> X-Mailer: RainLoop/1.9.3.365 From: "Grigory Marshalko" To: "Kenny" , "Derek Atkins" , "Rich" In-Reply-To: References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> <1167b205a7114ca4b5265a6a292a44ec@usma1ex-dag1mb1.msg.corp.akamai.com> <83b3753318d84e1c91b5cef8de7fb42e@usma1ex-dag1mb1.msg.corp.akamai.com> <4ed4c86ac0cca6e4f48cdc544375e364.squirrel@mail2.ihtfp.org> X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 93560 [Mar 25 2016] X-KLMS-AntiSpam-Version: 5.5.9.33 X-KLMS-AntiSpam-Envelope-From: marshalko_gb@tc26.ru X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 4032967, 4032980, 4032512 X-KLMS-AntiSpam-Info: LuaCore: 415 415 56d27afa4611b5fc17406ce7708f83a66d615280, 127.0.0.200:7.1.3; mail.tc26.ru:7.1.1; www.ietf.org:7.1.1; d41d8cd98f00b204e9800998ecf8427e.com:7.1.1; 127.0.0.199:7.1.2; tc26.ru:7.1.1, Auth:dkim=none X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: Clean, 2016/03/24 15:12:18 X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, bases: 2016/03/24 23:18:00 #7326653 X-KLMS-AntiVirus-Status: Clean, skipped Archived-At: Cc: saag@ietf.org Subject: Re: [saag] [MASSMAIL] Re: possible BCP on public review being needed for standards-track crypto 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, 25 Mar 2016 04:47:13 -0000 Several comments to the draft=0A=0AComments=0A=0AAbstract, second paragra= ph. Change =C2=ABhis document specifies a proposed best practice for any = protocol (or data format) that uses cryptography.=C2=BB to =C2=ABhis docu= ment specifies a proposed best practice for any mechanism (or data format= ) that uses cryptography.=C2=BB The reason is that RFC specifies data for= mats, algorithms and protocols, so mechanism is more appropriate term.=0A= =0A3. Why is Cryptography Hard?=0A=0AThis part is not sound since it deal= s with a problem of correct implementation but concludes that a good cryp= to should be used. This problems drustically differs from a problem of us= ing weak or flawed crypto mechanisms. These are two different problems, w= hich should be treated consequently: first, select a good crypto, then im= plement it in a right way. And also, of cause, the final step -- is to us= e crypto correctly. So, I would suggets that these issues should be treat= ed consequently, as a sequential parts of design of a sound crypto applic= ation.=0A=0AAs for the draft it,as far as I understood, is supposed to be= focused on the first issue: the choice of good crypto mechanisms.=0A=0A4= . Things to avoid.=0A=0AFrankly speaking, every crypto is developed in pr= ivate:), in developer's mind. The question, whether it has received enoug= h public review irrespective of its origin: independent proposal, standar= tised mechanism or commercial. =0A=0AIt should be noted, that patended cr= ypto could receive public review if it publicly availiable(though it coul= d have problems with implemetations due to patent restrictions). The key = question here is public availiability: if mechanism is publicly availiabl= e it could receive public review. There are a lot of examples of such sit= uations.=0A=0ACryptographic agility is a must, not probably a must. The s= ecurity strength of crypto is always decreasing so there should be a way = for transition to another crypto, or to use another algo which is more ap= propriate for implementation purposes.=0A=0AWhat constitutes sufficient p= ublic review? It is, actually, easy to say. First of all cryptoalgorithm = should be in public domain unchanged for several years (crypto competitio= ns show that 3 years is a good time), in order to receive sufficent publi= c review. Public review is actually is independent cryptanalysis: there s= hould be publications on cryptanalytic results on the discussed crypto. T= hese publications should be in peer reviewed conferences and journals in = order to avoid flawed cryptanalysis (there are a lot examples of such fla= wed public review -- see the rate of eprint.iacr.org withdrawals).=0A=0AP= roof of contest could be useful if it is resulted in a number of such pub= lications.=0A=0A=0ARegards,=0AGrigory Marshalko,=0Aexpert,=0ATechnical co= mmittee for standardisation "Cryptography and security mechanisms" (TC 26= )=0Awww.tc26.ru=0A24 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2016 =D0=B3., 21:19, = "Paterson, Kenny" =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0=D0=BB:=0A> Hi Derek,=0A> =0A> On 24/03/2016 15:10, "saag on beh= alf of Derek Atkins"=0A> wrote:=0A> =0A>> Being patented might be a deterrent to being standa= rdized and/or deployed.=0A>> However I do not see that being the issue at= hand or preventing access=0A>> for reviews.=0A> =0A> One very strong fac= tor that prevents proper review of new crypto proposals=0A> is the commun= ity having access to a complete specification of the proposal=0A> being p= romoted.=0A> =0A> For example, does SecureRF have plans to publish a full= specification of=0A> its Algebraic Eraser scheme, including the vital de= tails of how key=0A> generation is done so as to avoid the recent attacks= ? Or have you already=0A> done so, and I just missed it? Or is there some= source code that=0A> researchers can use to experiment with the actual k= ey generation process=0A> you are currently proposing?=0A> =0A> Without t= hat kind of detail, I'm afraid SecureRF would remain vulnerable=0A> to (p= ossibly baseless) accusations of being in the business of selling=0A> her= petological products.=0A> =0A> Cheers,=0A> =0A> Kenny=0A> =0A>> -derek=0A= >> =0A>> --=0A>> Derek Atkins 617-623-3745=0A>> derek@ihtfp.com www.ihtfp= .com=0A>> Computer and Internet Security Consultant=0A>> =0A>> __________= _____________________________________=0A>> saag mailing list=0A>> saag@ie= tf.org=0A>> https://www.ietf.org/mailman/listinfo/saag=0A> =0A> _________= ______________________________________=0A> saag mailing list=0A> saag@iet= f.org=0A> https://www.ietf.org/mailman/listinfo/saag From nobody Fri Mar 25 06:28:58 2016 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 974D912D7F3 for ; Fri, 25 Mar 2016 06:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 N31Oocc2vqe9 for ; Fri, 25 Mar 2016 06:28:55 -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 4452C12D77B for ; Fri, 25 Mar 2016 06:28:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6E4C6BE2F for ; Fri, 25 Mar 2016 13:28:53 +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 wAR4HOvMI1BP for ; Fri, 25 Mar 2016 13:28:52 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.46.19.213]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 74DA8BE29 for ; Fri, 25 Mar 2016 13:28:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458912532; bh=RKQWkSfALKZHGu6auCmChMExT7LZ4Ca2jmf8GEIYb9c=; h=To:From:Subject:Date:From; b=kv3pC3UsduPI7EuCxm2byHGDdRnDSKWh5/6R06RIibzNBWFVbIwHEmWuoXiXnhPqG ktCjVmanm65s84Y7E6OT37Zi8HoGmq9KLnlj1ojcbgobFOrqiScJFck4PDtEkkxuds o4oEuluBbTKbNjsSwcND28Pdnx5QThpC+glI/dHc= To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56F53D12.8090600@cs.tcd.ie> Date: Fri, 25 Mar 2016 13:28:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030505000501060701040605" Archived-At: Subject: [saag] Liaison from ITU-T SG17 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, 25 Mar 2016 13:28:57 -0000 This is a cryptographically signed message in MIME format. --------------ms030505000501060701040605 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, We got a liaison from ITU-T [1] study group 17 on being buddies, which seems on the face of it to be a reasonable thing. I figure Kathleen and I can handle this without much input but if some of you are involved or interested in ITU-T SG17 it'd be good to know that, so if you could send us an email offlist that'd be great. If any concrete stuff arises we'll of course get back. Thanks, S. [1] https://datatracker.ietf.org/liaison/1466/ --------------ms030505000501060701040605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMjUx MzI4NTBaMC8GCSqGSIb3DQEJBDEiBCABqryl1AQUgVM3/3I24iTeldj992r4kjE4sRA6ErRz +jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCwXCT/PhUY+9nkeuFDApqiPhq8HpnPYbqICb24Oo6Zsbb1hfJ7Lzs8 Za/DrUTeEw796Vf8zYW3+lxldTkI1F4ztPhtXJN8TwkEjF+aoGDavmKht7ZoBRIvLB+7gNtA mC9zsCvXtQd5fiAhRdpE9/PcJM3SSsXiQcLhrVNVlLz/y24xshsQvz0UZ3Pk/5U7vBubo+jC xd+fvvKboZ7hYOmQ3luwflsBGWZ+i8/OL5nvTlPYNmKd3YU+ZJ2r/xNMvieTCQfkBqZSmYpH FuXi+6Ah766z+PXG4xBdLUQzsN55I1vEIaMcIaHU1ysAahppmw8QWYQdFIjY3qlNypOrl/t3 AAAAAAAA --------------ms030505000501060701040605-- From nobody Fri Mar 25 09:43:35 2016 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 EBC2112D7C7 for ; Fri, 25 Mar 2016 09:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 UB1ba19_l0h7 for ; Fri, 25 Mar 2016 09:43:32 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c: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 5E95B12D15F for ; Fri, 25 Mar 2016 09:43:32 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id e6so96395450vkh.2 for ; Fri, 25 Mar 2016 09:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=u1hQ3qZkXBTTCHCe+W9UAkQV4UUhxK10DYRCQ3yJOF0=; b=vB9ehtenRQWWndWkpclR6Gfhnt8rJRtKERSV67BsoKVVTqdDePLP5CKmKJE5JtKZQ7 /Y9d/LDxdaFnjarywzRXFjTam7VUtQhLOlNgC/KgyvBIAqJn94Tu9FZ9JoT1Aq2LYQ+P K9+DX0n9ujVvyFI6ElPaMp6BugGoynrmKD8tcX9wOAMD+j09qAXGJLOQcPQHUXJhrKd5 1xaoB+hmTZji2BzvaspX4L1iVsE+7oRR5hKOszwmwhq9pb9OozIlddFIGKvSFLdeof8o cQHeQZbTG60p4ZJ3X/m1UkHG2q2UtyRn2xgbgb9yVI5DQ8DZN5RQg4ZK5skpnJDDPik/ 3uuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=u1hQ3qZkXBTTCHCe+W9UAkQV4UUhxK10DYRCQ3yJOF0=; b=OV3xXuqjLgoXn94efGRNT+zzZJFmzI7aQ42DSZJRyCLqvYvScxW/jwOlJBHTog3JZD /WdnAi76kGam1hwWCEqgSeJ7ptu+cHcy5SYBlKowbi4/7ezPxGlBJo9EGtdKsc+H7fHO nU2y5qcLfyGkIzsU02AGFS9Ibwqse6C9jHLHC0ISfpJDauSWdaUv8QrXzlk27cPcsiWC NB4JHinxQUokpyHnUGcy3cEI3uPd8YUPaVOZzR/S2k0oYMCAYVV66r0GKN1UAulQ4kdi xdvmU95mUOnMx99CdABY3gFeMkbyDfyQxaN50Zh2bKsGX2BxVrmsSUXy2xIbHAaVPWsg CuuA== X-Gm-Message-State: AD7BkJK3P1CByGP+tpDQdQlAk0ykK89MMSZ7RsTMsTgd4U5vY0PsWCZpXWN+ohvy8mNevUdW/0SjMUkcHLN+iw== MIME-Version: 1.0 X-Received: by 10.176.1.109 with SMTP id 100mr1095127uak.90.1458924211410; Fri, 25 Mar 2016 09:43:31 -0700 (PDT) Received: by 10.176.1.183 with HTTP; Fri, 25 Mar 2016 09:43:31 -0700 (PDT) In-Reply-To: <56F431AF.6080109@gmail.com> References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F423E2.5000505@isi.edu> <56F431AF.6080109@gmail.com> Date: Fri, 25 Mar 2016 09:43:31 -0700 Message-ID: From: Watson Ladd To: Rene Struik Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] (on the uselessness on legislating the obvious) Re: possible BCP on public review being needed for standards-track crypto 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, 25 Mar 2016 16:43:34 -0000 On Thu, Mar 24, 2016 at 11:27 AM, Rene Struik wrote: > Dear colleagues: > > I would like to echo Joe Touch's remark: indeed, one would assume that RFCs > describe relatively mature technology, no matter the area. > > Personally, I have trouble seeing what value the draft provides, since it > states the obvious: it has been long common practice to require some (read: > solid) rationale supporting suggested engineering approaches. > > Aren't we all (well, most of us) engineers and scientists who should all do > our own due diligence? In case we have collectively forgotten, adding this > BCP to the shelf does not help and we have to look into the mirror, get back > on our feet again, or hand in our degrees. Real engineers don't use materials known to fail in catastrophic ways. Software engineers use C. Real engineers know the relevant science. Software engineers continue to insist that MD5 is ok, endorse MtE over EtM, etc for years after they shouldn't. > > Or, is there perhaps a subliminal message in the draft that we now have to > depend on nods of program committee members only? If so, this seems to > provide a bad incentive for offloading our own responsibilities. No, it's pointing out that cryptographic algorithms need specialized knowledge to examine, which there is no reason the BGP master will know. > > Let our acts be guided by time-tested engineering principles instead. Like knowing the limits of one's knowledge and deferring to experts? > > Best regards, Rene > > On 3/24/2016 1:29 PM, Joe Touch wrote: >> >> >> On 3/23/2016 2:02 PM, Hannes Tschofenig wrote: >>> >>> the document Rich wrote says that "RFCs cannot specify an algorithm as >>> mandatory-to-implement (MTI) unless that algorithm has had reasonable >>> public review." >> >> I completely agree that all BCPs and standards-track RFCs should require >> only algs and mechanisms that have had reasonable public review. >> >> I thought it was an assumed requirement of all BCPs and standards-track >> RFCs anyway. If it is not, a general statement to that effect seems >> reasonable. However, I disagree that this uniquely applies to crypto. >> >> Joe >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Mar 25 11:10:35 2016 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 CB99912D5A5 for ; Fri, 25 Mar 2016 11:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 MDgWEoSTQbRc for ; Fri, 25 Mar 2016 11:10:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A43B12D0DC for ; Fri, 25 Mar 2016 11:10:29 -0700 (PDT) Received: from [192.168.10.140] ([80.92.114.73]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LoE4f-1a7xNY2Mor-00gDkK; Fri, 25 Mar 2016 19:10:25 +0100 To: Stephen Farrell , "saag@ietf.org" References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F57F12.5030003@gmx.net> Date: Fri, 25 Mar 2016 19:10:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F346B3.30600@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aBacNrfUwTmAdxlCLfdIL3IJDnM8ga7m8" X-Provags-ID: V03:K0:KVkJymc7wQKXChCfsZyifyf1kooTQk8vMzUKl8Yl9DJFbKH6hPS XxLWjFPPXo4/8zQPFCJ2d1JGuAprdrjm/KohZ5hcAwerepTQFObIkM2/vlUx/4bmhmoCvi+ DjmJVEwCY6kD25xWb2+fSGH31TiGr/VTGE593zETZL++CxLY1ytqitRcBJGLFqMiYJkV7k4 ZhPBjz7OZVtDEyqJtt1Sg== X-UI-Out-Filterresults: notjunk:1;V01:K0:O8sm3JSLZdo=:8WwSQHJAJkJ1NsY5yqsuU1 Xslin3eF8MBz5lN9dDxS8iv2h+etOH3RMV5VzuiKq+Gu2osT2RUJlYbAeHfzpX6n3je11x4kZ PYpmx1WQH2wC1rbGlb8E0oGuBj2oVkWWpRzqWoYL4rE0Mh55TOYxuIB76YsYrhxJVUfDJbiGr qEkr3BFz686hkgcNl9Px/jUQ7VDVrEFFLE2i319EUDqPSU2iGaD+kPKTgFxOV5NqzPX03ajvi T5ZlqC4LSAT+LLdAoKTI1/xdG6h1hLwm7tm1qY5wJdQ6EWz+j6CgicDoAZWL+spv4T27JwOkP U9sxe4idfX0ftVnZyullFWvnQmOYYscotRDwfIYCGPXskZIlLN1w6Emczw4pIzxW00MgAPLVW 2Hkqd03mgb0dDCh3Lo3JsRtcB2ObQQAPnybKFi57Fs3iC0q8af1KWrIaztRMOLEP3Q50mSwnw imWPbc13bFQEb7ngY2yI+D271ykDfA8iRipSK2pDPiW8PgihFvt/FPTq4BDa0pE5CYd0hOaHa /Qjc0JwYdwoEbMq4GPU5O73CTUUPM3pay0lNkwuqc7AQnm/JYUoPIjrivJ3SdeRrHYtYusJW9 cVTGLzk8goWPK8EuY0+lyuAAyDtnmR/03Jny0BeCsD36JEaGyunF+wuXbgtUspObCdQIhSe5m Rr9fhOEgqGLZg+wccdtqv+yEfwTx2DRjwyKvub3PHYzwc8MQXZAJBBgi0HUDyrRuTAQPLp0Jy mE/Yw9Nv0hr4eibLrnopYonie3JETRAU1w8cy+c3nULN37wTL6zXIZxJEww= Archived-At: Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 25 Mar 2016 18:10:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aBacNrfUwTmAdxlCLfdIL3IJDnM8ga7m8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think I am now getting the idea. Let me try to summarize. 1) You don't want to publish RFCs that contain cryptographic algorithms that have not gone through substantial public review *elsewhere*. While we have a "good" review process it does hot really cover the hard-core crypto stuff. 2) We don't have the time, interest and expertise in the IETF to do a review of cryptographic algorithms. Therefore we have to delegate it to others. 3) You want to send a message to document authors to not even try to come along with a document that includes crypto that nobody in the IETF is likely to analyse. 4) You are not trying to send a message to other organizations that develop crypto being closed doors. Most likely (I am guessing) the reason that triggered your interest to have such a document is the Algebraic Eraser. With this BCP you would essentially tell someone coming along with, for example, a new password-based authenticated key exchange, identity-based crypto, threshold key exchange algorithm, etc. to first have that substantial public review outside the IETF (most likely in the academic community) before they should even try to approach the IETF. Is that a fair summary? If that's the idea then I believe I can agree with you that such a BCP would be useful. I think it is also a "safeguard" for the security ADs and for the IESG in general who have a hard time judging stuff that comes along where nobody really knows whether it is secure. Ciao Hannes PS: The examples provided in the document, namely A5/1, A5/2, WEP and WPA, are misleading since nobody (to my knowledge) ever wanted to use them in IETF specifications anyway. --aBacNrfUwTmAdxlCLfdIL3IJDnM8ga7m8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW9X8SAAoJEGhJURNOOiAtHE0H/irQlOZ9mgAFyg40gf5q7DXv IKi9+CZfYx2f1fXP/Rp4G5g0GRjWa07K2OKRKZyv7fUT0HLGkLPhTvnwG5DjVRbq 45jLfuxy3mWHb9WGr9xVSwP8LLgENLgC4QpO/OzhzKp7xZ9aM7aixMA1XLy/ZGws ZDFyB+sslIo6BXoOojvV2/W9y6QHHx4f7u73hoDD/tot1YoMqK1MdK032Cgzwggz 8ntHt+VrDZCI5gHRMgbkY5DZqzc3qpBTXjYp0nw7b8OD6k7fS/wgguZzsZIzOR6F KnMdHYpaYsdAIu5EEB6CfOZZx0/IpaN0AWAjVFZhHtg/qCeJZ3egJHvnAWpYgTU= =3AKP -----END PGP SIGNATURE----- --aBacNrfUwTmAdxlCLfdIL3IJDnM8ga7m8-- From nobody Fri Mar 25 11:13:48 2016 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 C878D12D5AA for ; Fri, 25 Mar 2016 11:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 44VILHngOuXY for ; Fri, 25 Mar 2016 11:13:45 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC90C12D0DC for ; Fri, 25 Mar 2016 11:13:44 -0700 (PDT) Received: from [192.168.10.140] ([80.92.114.73]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MJFBe-1amG3f2GzK-002mZy; Fri, 25 Mar 2016 19:13:29 +0100 To: Derek Atkins , Stephen Farrell References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56F57FC7.70203@gmx.net> Date: Fri, 25 Mar 2016 19:13:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aPQFhX8sIBdcAXFVhdRFpEb3mJh7PKrpw" X-Provags-ID: V03:K0:wEKaweBzyr9dAk9NeyZ4E2lcwWnyAQVnu6bogbtQ9K3rIyav6tO k/hD2rJTvsQ2rlSraATQsd8b0ApL2dacjkRC4tNS35TzgnAA/Drqy0xyf9lndRC9cSK29Ku gqF/vvMxFw6uLh9OSf9nHwAln5wYshmX8DQ4Xsf3v/rpITIxa4L+gvEXax17U+y+JLB7eR4 PsFZmmFuHaODma95Xwu3Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:gMe64tdNvRI=:YyRvBDdKLYnfF2Yq9Umg60 8XDebIe35B41kGakeWF5gtd6AX1kqnJV/v4xMMDStkBCM5s7fCkHheZKn/bRkxJYE9yGXmzv3 8ab1uH56/b5pTyO75CSsbRrwbUNJvoShJh6NKPomEDLmE0MNEIuRz63M6FPeTDrdPcLlw6I+o Yk63Lj/57dl+MWCSiuQImUUJQh3nF2RIQmZbsE0ok9G3y+o2V/mkhACmcPVuDgItTgQz4ElxC BpZr3fbZKF4sWbNCBwNIo3wAwiIamig7GVrou2TrKodfwlhYylMrOJHpVr70IQGaW73XQY9KB 2XPFUS1BFrbdYEnMc1bBZxplFkzSzl2Av4H/XZwH0YDJgRsdLuEfA5QIczS4yVR6G6Y9l7IZD WJ9MA3kdHZOto8EhFGkngI5/FkY24f9OpcjI4PbNjHzhvaqxbbwO0pYXs20l0cQ0dgHWNg98U YkR1I4j+rpdfN4naH1BT2NL6gUUJ0R5az1tTlArW9LxG/QTGyQQk9DchfGzsUCh1hzkjTf5h9 /uL2DIB7X0epBPUFMwARW4+j5qnNP4feFUGvROnMZEaD2XtFahQW08YA8mAGPacAulM2b9Vj7 mnUZsWusWwNWoj6q2qWNnOogO6c4DVZLC7IljkiGVaFly5tda2ZteAZIBt+gwGqnVZ+u1voa5 VwQKAGMPkV7slKwrcFyRSlRbx6O4DGq97kGb4LDQ8ccIxQJou+hSKP0ILwS3zSjKgusxQtt2n f3SegA7tf+EW7V0rP3x9eCHSqU1ifUvZppQB+wOgTMzFNu3Ptnqyax5Q2BE= Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 25 Mar 2016 18:13:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aPQFhX8sIBdcAXFVhdRFpEb3mJh7PKrpw Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree with Derek that this also needs to be clarified. The BCP is specially aiming at the IETF and the IRTF in fact has a slightly different mission where we specially tried to get cryptographers to share their views. If this is not clearly indicated in the BCP I fear that researchers could easily get confused. Ciao Hannes On 03/24/2016 03:44 PM, Derek Atkins wrote: > Stephen Farrell writes: >=20 >> Well, I'm not sure though that we can depend on there being a >> handy cryptographer in the room who happens to have a colleague >> who can find issues in a timely manner before we standardise >> stuff. We've so far done the right thing in that case I think, >> but I'd prefer we had a BCP t help us be more likely to do that >> without depending on such co-incidence. >=20 > I thought the whole point of CFRG *WAS* to connect to the cryptographer= s? >=20 > -derek >=20 --aPQFhX8sIBdcAXFVhdRFpEb3mJh7PKrpw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW9X/HAAoJEGhJURNOOiAthvsH/iXLXw11FE+Is/raCHJDScXl Id5ylwu+NoCZOdda2EoA58ORbxQ7ay4LZ10rvmM58YW8FMX3z1/WF8P5bde6PRiS QAkKe7RfSnsPEz5BKtKoLvFbp0m76HIEaBBJAT8PGOl9VBkrt9f2RCnxoK5AViV4 8yx12xVvOCQfk3ezDigRG6XK4/c8S6d3xKYVexJwNjeA1FbF3stSsydMbr7ZnpND jLd/Fw7jzAg/MMyhC8M/w81fk0Z31Ry6cLnzaOU82+2Ul52eB2vg6n70mdeyE4XS iYogbQbRwf6Xad/GrrEWWNUt6A+wA9fmpVV4QI/spl0NSEXYA+aKpiHoqoiGhPQ= =eUgI -----END PGP SIGNATURE----- --aPQFhX8sIBdcAXFVhdRFpEb3mJh7PKrpw-- From nobody Fri Mar 25 11:24:03 2016 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 A030512D622 for ; Fri, 25 Mar 2016 11:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 7B479Md1FGo9 for ; Fri, 25 Mar 2016 11:24:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C1512D5EE for ; Fri, 25 Mar 2016 11:23:46 -0700 (PDT) Received: from [192.168.10.140] ([80.92.114.73]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MJXEd-1am0IP1aV1-0033U2; Fri, 25 Mar 2016 19:23:26 +0100 To: Stephen Farrell , Joe Touch , "saag@ietf.org" References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F423E2.5000505@isi.edu> <56F43144.6030803@cs.tcd.ie> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F5821E.3070401@gmx.net> Date: Fri, 25 Mar 2016 19:23:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F43144.6030803@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XNeKDO5VEWs5sUl7hPAHuHFqIiw2X0uIH" X-Provags-ID: V03:K0:aOPAm84uOpM7ghboL/Cb8JzELeNCl5CoB7aQXDZSDCWWiaCxdC0 jf/e9d6DeVJWxF1fHQ2iD5MNdmC+ITsp9MEfrCLR9WEgHnrJTCPc5UiYWKAgat8aPkvb7xq ZuGVbFm3JsNrQrNZvd3krv8w8Or5kSQqFKEt7XWbizmJvgnrvPmsT3CgpyflbiTv3c6JfKu 1mzKu14OqDKJtuDlHXbJA== X-UI-Out-Filterresults: notjunk:1;V01:K0:MEc4s2LwRk8=:5Gr7jG6k6ZJ4JA8/z/eCBO gb+PJbi8fsbrW2jsjiJeJge06CkkDqGZFxQxinX04nWj9HvnLclbsE/gMHMFHsdKWUH5W0T0u cAe4ww4Slei1G54Q0iinFRxzUAbggkw20I3u/KJtNBurSb2jfx2yG/h5r0a8oMCaxdnUMeRqJ 8elSVJYyxy+XFpVy5aZ7lYjfJh3T8WCYHTRFm60Lqzo5IIJPPdFuWqgFFuAT+MvBdDCjAGW6C CmqY1U6//h053FUvagi2VnhJ3zb6hW4cb1ANNcXe7zNdjEFboqZ9VzPlhmDdFRyUq+B+ONAiC 6mYIt/2LMnHqbgg1J1ON4M65dQey4hgqUKVv4JdpcHo8i0rpXyiy6uWB1JiUYHF75XijyU2i+ SEqMlEg0auwfErIr152+xh8mKjTSReDQbrVC/oOQNi3pWion4oXoxRGlFoH39Gr93kA9f9zIb Lz7lAjtQ1g/uTz6Oqv1LK9rNXu3pKN4lMvZmLkZRTeJustUjdsSUxFEP6Gq8sL+SVQYpgIe+4 GbiNI7kNrzArZlgWOdsB97qqFvKYZtriUquglT92atAm0cCV8SLqohwckhtEMEvxe26mrAxPZ aFZYH/q5kUKPwJa3eScT7g7gDDlJRvOjjXnjUXLF2FHpz3kOzjjxG6Ez2KsLOUvZJ4iJQgnQo 8gbSvoDIa8AQZr7iYUiUxQTWx3l+Os1mG3ll9PUVk7lZzmHm8GLbrHH+22MjKS4ndcfzCJVWF YdiJ6NzbCgbeGvce7sdnOaGRGiVC+Musw1iRstvIByWyU8RZug7w+uHUurc= Archived-At: Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 25 Mar 2016 18:24:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XNeKDO5VEWs5sUl7hPAHuHFqIiw2X0uIH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stephen, Rich, I think we need to have an honest discussion what problem we are really trying to solve here. Examples are useful but we have often had problems with talking about mistakes we made (since someone will be unhappy). Unless there aren't a handful of examples I prefer not to publish a "best current practice" document. I personally would rather like to solve the MIKEY-IBAKE and MIKEY-SAKKE type problems first, particularly since they have been caused by the IESG and our review process. Ciao Hannes --XNeKDO5VEWs5sUl7hPAHuHFqIiw2X0uIH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW9YIeAAoJEGhJURNOOiAtiQ8H/0mOzkEmo5GRWMDorIKr7WTw fgWDBu/toryLbvOdWfJNHoT8btc3GLze0OKgDNdNOAHpnTFq3jGBb7np23Uzzsyz q+5NEqR1sFDxmSP4hqdWNrrsJ3eXPEJ+fdlVFiwyY5r5EWx3t3YSZzPxuGsBXz/t rcHGqPQy1h6Ll+snUwlvmivNTFhMD982hIRP/NdK+6sz/EH+WgPbyBomw28CGV9x mSXZ6s0YCDxo3khBhmOu2md5Yy/gJ7Z2xiMqHi2lBewoib/TqQ2VXl0NLyEy1QQk 12WrYEkJoLN9RK/WDiwx8u0iR8NugVM3Yvf0fw0besOufE/lKN9zKO5LbabT24c= =JEFi -----END PGP SIGNATURE----- --XNeKDO5VEWs5sUl7hPAHuHFqIiw2X0uIH-- From nobody Fri Mar 25 12:45:55 2016 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 5C96012D6A5 for ; Fri, 25 Mar 2016 12:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 b4h0sinBmnSd for ; Fri, 25 Mar 2016 12:45:53 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0B89F12D6B7 for ; Fri, 25 Mar 2016 12:45:52 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4BE343F4075; Fri, 25 Mar 2016 19:45:52 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 358AB3F405A; Fri, 25 Mar 2016 19:45:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1458935152; bh=hU3akiHxKqzhMWvWKqgpUq4WJJ9NhdukZRs9tPwgbfU=; l=318; h=From:To:Date:References:In-Reply-To:From; b=bGjKtKH3FX3bMdHb4SHimX4XfXdKyjxu7GcWaABMrK2l4cGWW7wkLNdVlDmRav+jN R9wwZPy/ah14O2qt1jGbFHZa+GkvWK6fr0SE/9ljz8KUE016SFt7rAP99tJ/clqzqp FfiQ7sgQb6VK2k1R24otq6cPcyqKiEqNDBmzEma8= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 31C781FC86; Fri, 25 Mar 2016 19:45:52 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 25 Mar 2016 15:45:51 -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.1130.005; Fri, 25 Mar 2016 15:45:51 -0400 From: "Salz, Rich" To: Hannes Tschofenig , Stephen Farrell , Joe Touch , "saag@ietf.org" Thread-Topic: [saag] possible BCP on public review being needed for standards-track crypto Thread-Index: AQHRhUdJbeb1XQCXmUiUqV21h2EKpJ9pHdQAgAAP9ACAAZGPAP//0+jA Date: Fri, 25 Mar 2016 19:45:51 +0000 Message-ID: <15aa6d9e36b44df08c010c67202fe5d8@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F423E2.5000505@isi.edu> <56F43144.6030803@cs.tcd.ie> <56F5821E.3070401@gmx.net> In-Reply-To: <56F5821E.3070401@gmx.net> 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.33.108] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 25 Mar 2016 19:45:54 -0000 DQo+IEkgcGVyc29uYWxseSB3b3VsZCByYXRoZXIgbGlrZSB0byBzb2x2ZSB0aGUgTUlLRVktSUJB S0UgYW5kIE1JS0VZLVNBS0tFDQo+IHR5cGUgcHJvYmxlbXMgZmlyc3QsIHBhcnRpY3VsYXJseSBz aW5jZSB0aGV5IGhhdmUgYmVlbiBjYXVzZWQgYnkgdGhlIElFU0cgYW5kDQo+IG91ciByZXZpZXcg cHJvY2Vzcy4NCg0KV2hlcmUgY2FuIEkgc2VlIHRoaWUgaGlzdG9yeSBvZiB0aGVzZSBpc3N1ZXM/ DQo= From nobody Fri Mar 25 12:57:59 2016 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 B928012D10C for ; Fri, 25 Mar 2016 12:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 O4jOoa-L2yQy for ; Fri, 25 Mar 2016 12:57:56 -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 6C3CB12D104 for ; Fri, 25 Mar 2016 12:57:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 712D5BF45; Fri, 25 Mar 2016 19:57:54 +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 vlKaETrgH26t; Fri, 25 Mar 2016 19:57:53 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.46.19.213]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A483ABDD0; Fri, 25 Mar 2016 19:57:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458935873; bh=aA6S+8ipKQ8ROhRMVnLQ+rLjMP0n7ewHJlHFItb0L4o=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Xi28yznMKQAayYOvbbk/pWwZPwf9FZ1EIZvHoTQX3tuy2Ar3p7DN0BBG/br9/igzw kbenfeJgBtiP1eaZ5VVyPMApyrhb9dGJRQXg4Y5Y1EWf9ywiYhypS+9pZIaKxDTM7F zKHNrrZTI9LXGGoUJ/bOkLAC/FsQtgKG+Y5KYXbw= To: Hannes Tschofenig , "saag@ietf.org" References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> <56F57F12.5030003@gmx.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56F5983F.8030204@cs.tcd.ie> Date: Fri, 25 Mar 2016 19:57:51 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56F57F12.5030003@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IIub8LL78M4gi7sNWGxWUjrj7mxgqML22" Archived-At: Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 25 Mar 2016 19:57:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IIub8LL78M4gi7sNWGxWUjrj7mxgqML22 Content-Type: multipart/mixed; boundary="C2eVpg9jMeD6RHGTrK3q3aeHmVacIhhFb" From: Stephen Farrell To: Hannes Tschofenig , "saag@ietf.org" Message-ID: <56F5983F.8030204@cs.tcd.ie> Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> <56F57F12.5030003@gmx.net> In-Reply-To: <56F57F12.5030003@gmx.net> --C2eVpg9jMeD6RHGTrK3q3aeHmVacIhhFb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 25/03/16 18:10, Hannes Tschofenig wrote: > Is that a fair summary? Yep. AE wasn't the direct motivation for me as it happens but that's by the by. [1] was more of a deal for me - that was originally proposed for PS and with an algorithm that has had basically no public scrutiny that we could find. S. [1] https://datatracker.ietf.org/doc/draft-ietf-manet-ibs/ --C2eVpg9jMeD6RHGTrK3q3aeHmVacIhhFb-- --IIub8LL78M4gi7sNWGxWUjrj7mxgqML22 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW9ZhAAAoJEC88hzaAX42i4uMH/3zacizrwqyItTEQ8w6DuwZg GKkOOGdl53PolifAunKKb6s7hK7tp34lK0832HsCYXIf8l4hO87rfnuNZ/ZGoHiS LuSmj8EvtHauBs3eBxCwp2p87d66JWvwhP1WO9y9IiK4FvvPbxMvryykC7hr9Pes vW9SlQd1dcW4eOuB+3CKb9fWQZXxL69H+JXEmuYu/nOKqyU1meO29UHKa52zRVo9 N7i7wJAk6F/GqMD1IRpuCFmXGONIwHQ1L9ifJc+ojEKSlXLBYPw/+jHf4n1bLGtU S10J6HGS5Wfc7Sz+OtOhksAKioG/k/SKgqpIjKrlU7LZwIFjl+bvI3SCcERylFQ= =u4g9 -----END PGP SIGNATURE----- --IIub8LL78M4gi7sNWGxWUjrj7mxgqML22-- From nobody Fri Mar 25 13:11:23 2016 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 D9A1012D6F3 for ; Fri, 25 Mar 2016 13:11:22 -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=ihtfp.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 IOFqBe35M4-K for ; Fri, 25 Mar 2016 13:11:21 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C3612D6F6 for ; Fri, 25 Mar 2016 13:11:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id C72E8E2030; Fri, 25 Mar 2016 16:11:16 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 04968-05; Fri, 25 Mar 2016 16:11:13 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 6162DE2039; Fri, 25 Mar 2016 16:11:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1458936673; bh=I3GMR/eNdXeG1kk9Kpu8s6TMWtUPKStG+z3QVKNg9lg=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=N0rYrnovwYbPl7qEoZmeM3ECPGAm/HIyVxZT2DVAHQq8UaoQvGdUcP1CK3TRKrgio 44g3pzwF4Xl3ccICavzMKNRY9zSLf/e5Z7TWHULReSE3FX7oA4+S+ZP1n20OaycdVQ ceOPOr+6WqnNr72xTviU8iqGztylfazjfhO3bW0w= Received: from 192.168.248.159 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Fri, 25 Mar 2016 16:11:12 -0400 Message-ID: <4101d883d7ab9c1bf0a7880dff790a51.squirrel@mail2.ihtfp.org> In-Reply-To: <56F5983F.8030204@cs.tcd.ie> References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F346B3.30600@cs.tcd.ie> <56F57F12.5030003@gmx.net> <56F5983F.8030204@cs.tcd.ie> Date: Fri, 25 Mar 2016 16:11:12 -0400 From: "Derek Atkins" To: "Stephen Farrell" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto 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, 25 Mar 2016 20:11:23 -0000 On Fri, March 25, 2016 3:57 pm, Stephen Farrell wrote: > > > On 25/03/16 18:10, Hannes Tschofenig wrote: >> Is that a fair summary? > > Yep. AE wasn't the direct motivation for me as it happens > but that's by the by. [1] was more of a deal for me - that > was originally proposed for PS and with an algorithm that > has had basically no public scrutiny that we could find. > > S. > > [1] https://datatracker.ietf.org/doc/draft-ietf-manet-ibs/ Honestly, I would hope that AE was *NOT* the motivation, considering progress on all AE documents has slowed down (or stopped) since November. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Mar 25 19:07:04 2016 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 0744112D0C7 for ; Fri, 25 Mar 2016 19:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 SzHDcJuiCHXU for ; Fri, 25 Mar 2016 19:07:01 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D393E12D096 for ; Fri, 25 Mar 2016 19:07:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ajdcx-0003fI-Sw; Sat, 26 Mar 2016 02:07:00 +0000 Date: Sat, 26 Mar 2016 11:06:57 +0900 Message-ID: From: Randy Bush To: Watson Ladd In-Reply-To: References: <56F29DE6.50508@cs.tcd.ie> <56F3044D.6080905@gmx.net> <56F423E2.5000505@isi.edu> <56F431AF.6080109@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] (on the uselessness on legislating the obvious) Re: possible BCP on public review being needed for standards-track crypto 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: Sat, 26 Mar 2016 02:07:03 -0000 >> Let our acts be guided by time-tested engineering principles instead. > Like knowing the limits of one's knowledge and deferring to experts? or begging the experts and implementors for usable, safe, and boring (thanks djb) algorithms and code. e.g. to use the example in this thread, bgp ops have been told that they want/need something better than md5 for over a decade. what are they given? AO. simple? no. safe? how the hell do they know? boring? yes, because no vendor implemented it. feh. randy From nobody Tue Mar 29 16:39:13 2016 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 13FD612D512 for ; Tue, 29 Mar 2016 16:39:12 -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, 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=sn3rd.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 aCOI3u3H5qzB for ; Tue, 29 Mar 2016 16:39:10 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 17E0512D0BE for ; Tue, 29 Mar 2016 16:39:09 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id i4so13061577qkc.3 for ; Tue, 29 Mar 2016 16:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DER1fqGLVKE8OQT4aQuxBiFcOiDCtr5WkpHV7BD4i3U=; b=QmfyV2633R/hbIredzM1qk3U6a/GZvCSML4/qhGRJHkB75Ud2O4aKO6ARdj5tY5ESt W05vUoxpIPFMDoUB1aRpGJi80rrXiLiTKpqHp4m0pgPU4LuUOWTt7VO6ucj72X0XW270 RreFn2hXyN8UprDLW0vQyA8J4Y/bnxGx/G+QQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DER1fqGLVKE8OQT4aQuxBiFcOiDCtr5WkpHV7BD4i3U=; b=KVr7y23PQ/uBmHiCUbcok9a9ZtRDdyi44TFZaXEiCa4wD9vqYfDDJ6bSSoNBJ6b+0N JexMCHSiD0bfDIObX0FvF8LW7JU/hN2iFwjEd+DEohy0gwJfi/1P5FtB/ofCkEfDu6do vICWmPiGUpC2zthKeBP1saXnSe0l9QQH2rV9qTzF9l2eC8mCgFr2vSaf+Ja4QtqN+AZO YrQevzHkhLF1xrxoDgqgkZQyI954XzrJ7/TeDzEBbXqnE4A5atIXs8tpYTAuf/IpqYri wqZDOv/SXoDBASyrY2SQxJ+J9LbW0Vl6CcosYwVCDhKAPtTMr2osOJoNdXZSiU700bpB 27dA== X-Gm-Message-State: AD7BkJJgBttp2IvQINkV+NSnpWiEFfSWHjoFrglpMJ7aQP9nAd8HH5jiLikTxlyWyzBUtw== X-Received: by 10.55.81.2 with SMTP id f2mr6210306qkb.87.1459294748963; Tue, 29 Mar 2016 16:39:08 -0700 (PDT) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id l188sm548054qhc.10.2016.03.29.16.39.07 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2016 16:39:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <56F53D12.8090600@cs.tcd.ie> Date: Tue, 29 Mar 2016 19:39:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7B59D8C1-1A08-44BF-98AE-AB44410B4E71@sn3rd.com> References: <56F53D12.8090600@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Liaison from ITU-T SG17 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: Tue, 29 Mar 2016 23:39:12 -0000 Maybe ask them to use the "new work=E2=80=9D list (again) ;) spt > On Mar 25, 2016, at 09:28, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > We got a liaison from ITU-T [1] study group 17 on being > buddies, which seems on the face of it to be a reasonable > thing. I figure Kathleen and I can handle this without > much input but if some of you are involved or interested > in ITU-T SG17 it'd be good to know that, so if you could > send us an email offlist that'd be great. >=20 > If any concrete stuff arises we'll of course get back. >=20 > Thanks, > S. >=20 > [1] https://datatracker.ietf.org/liaison/1466/ >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Thu Mar 31 05:30:16 2016 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 2387C12D5B5 for ; Thu, 31 Mar 2016 05:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Ozh0QdXUTILV for ; Thu, 31 Mar 2016 05:30:11 -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 6362112D170 for ; Thu, 31 Mar 2016 05:30:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 37A78BE58 for ; Thu, 31 Mar 2016 13:30:09 +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 kdI8Tq88fCKD for ; Thu, 31 Mar 2016 13:30:06 +0100 (IST) Received: from [10.87.49.100] (unknown [86.46.30.32]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 27A66BE57 for ; Thu, 31 Mar 2016 13:30:06 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1459427406; bh=sDjvPaGdU+WFM8aTi/UUo9iYqmThYqqpHaqVTvPeMq8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=x+tW5IKblAdD/g3CoBBOB2HXtVBk/Mv30+NdsNEgNJXoUIAuVV8ifcJ23kw5Rt2Uq C56xX0yjXso3jIQ8DGG9R3b9879snp3WcmwtFCPOkgKsc+njA9IWZLQsJAPcZh6/nt T9wWY9CTS/o7/w1PaMyda7jTh5TgbkKFjyI+Vneo= To: "saag@ietf.org" References: <56F06896.8030509@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56FD184D.2090603@cs.tcd.ie> Date: Thu, 31 Mar 2016 13:30:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F06896.8030509@cs.tcd.ie> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050907020402070701020404" Archived-At: Subject: Re: [saag] Agenda slots for saag@IETF-95 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, 31 Mar 2016 12:30:14 -0000 This is a cryptographically signed message in MIME format. --------------ms050907020402070701020404 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I've updated the saag agenda for next week. [1] I think we've included all the requests we got this time as plan to get some local guest speakers didn't work out. Please yell if I've mucked up. Cheers, S. [1] https://www.ietf.org/proceedings/95/agenda/agenda-95-saag --------------ms050907020402070701020404 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMzEx MjMwMDVaMC8GCSqGSIb3DQEJBDEiBCBoi4MBjNfifGKUEt5qWGl42ytuisdmxpWHg3YKZV12 vTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQALPFc9Ki6n3z6Zje/WXozFMaxq8LFZkl+kmOPL8GD3Vw3VCJfKkH/N 2F/sO3Sq6pgplNdv4TF+yusJ6c80fMGu61sLgutjAX8wLxVbP7sq+Q72QQVEa/TldMus2dFy WU+Xw84eU52zU1g/EL1hOKQ2NvmOTtJcuv0Kl58S0oeqytTyLYlXnfyloSW/X5IVoT6+A4Wf gxKXujx7uyIzut+CpHe0OeaEoN73vCpgxkc+LGa4oKLlv77h1BVOvV5d4V3MqZ9tWYVZRfsm QqafQzNmQMeogMOX0uKyVLrvkhb8vwMATmBBxFK23xhPLjVAb9yHrvF+oK709Asa1bT9wO/g AAAAAAAA --------------ms050907020402070701020404--