From nobody Sat Nov 1 09:23:32 2014 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 9C0D91A897D; Sat, 1 Nov 2014 09:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 Q6WZUgiJVLkk; Sat, 1 Nov 2014 09:23:24 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 00F5B1A896D; Sat, 1 Nov 2014 09:23:24 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 750C79A446D; Sat, 1 Nov 2014 12:23:13 -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 jYqZDlK1tlXJ; Sat, 1 Nov 2014 12:22:52 -0400 (EDT) Received: from [192.168.2.108] (pool-96-255-26-251.washdc.fios.verizon.net [96.255.26.251]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 39DB09A4461; Sat, 1 Nov 2014 12:22:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <544D14C8.4070604@seantek.com> Date: Sat, 1 Nov 2014 12:22:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <02E8A627-3147-40DB-9C50-E0CE9E536909@vigilsec.com> References: <540E0A56.7060301@seantek.com> <544D14C8.4070604@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/lO8oPVmYDSB9lo6cusdPWIlOzYE Cc: pkix@ietf.org, saag@ietf.org Subject: Re: [saag] [pkix] New Version Notification for draft-seantek-certfrag-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: Sat, 01 Nov 2014 16:23:26 -0000 I took a look at the draft, and is seems like a reasonable way to = address the stated problem. Russ On Oct 26, 2014, at 11:35 AM, Sean Leonard wrote: > Just wanted to follow up on this request for feedback/review for = draft-seantek-certfrag, which defines fragment identifiers for = certificates. >=20 > This is a short draft (just four pages--and the fourth page is just = the author info). If you read it and don't find any issues, please let = me know as well. >=20 > Thanks, >=20 > Sean >=20 > On 9/8/2014 12:58 PM, Sean Leonard wrote: >=20 > Hello PKIX and SAAG lists: >=20 > Based on discussions had at IETF 90, I have written up a new = Internet-Draft to define URI fragment identifiers for certificates. The = proposal is very simple, as there are only a limited number of = well-defined PKIX certificate parts. >=20 > This text is a spinoff of draft-seantek-certspec, since the fragment = definitions depend on the media type (application/pkix-cert), not on the = URI scheme or other parts. >=20 > Feedback is appreciated. >=20 > Sean >=20 > ************************* >=20 > A new version of I-D, draft-seantek-certfrag-00.txt > has been successfully submitted by Sean Leonard and posted to the > IETF repository. >=20 > Name: draft-seantek-certfrag > Revision: 00 > Title: URI Fragment Identifiers for the application/pkix-cert = Media Type > Document date: 2014-09-08 > Group: Individual Submission > Pages: 4 > URL: http://www.ietf.org/internet-drafts/draft-seantek-certfrag-00.txt > Status: https://datatracker.ietf.org/doc/draft-seantek-certfrag/ > Htmlized: http://tools.ietf.org/html/draft-seantek-certfrag-00 >=20 >=20 > Abstract: > This memo describes Uniform Resource Identifier (URI) fragment > identifiers for PKIX certificates, which are identified with the > Internet media type application/pkix-cert. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From nobody Sun Nov 2 13:56:12 2014 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 5B5C41A1A60 for ; Sun, 2 Nov 2014 13:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 P4tVUApmEW7J for ; Sun, 2 Nov 2014 13:56:10 -0800 (PST) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B961A0410 for ; Sun, 2 Nov 2014 13:56:09 -0800 (PST) Received: by mail-yh0-f50.google.com with SMTP id b6so4273218yha.9 for ; Sun, 02 Nov 2014 13:56:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=p5zgfrZ9bsIu7a1CaREiy3a4jaQl44nq7HYAs4D59/o=; b=SZiGlkV/qi6rt2lJAquJFkTRf6OAil8hkKGqD3ODg5XrZ0XLtLmsr3Eb9B4hbnBlgY YGUCQb3Q4AjAj4Vyy37ZLCSYlwo784x21fjiHLq8JNxk1tEw7K63eh32vu9VmkJl2Txg fS21jSWU/mtNzCey8Vu9KuKw+5R8FatruTmeBIMivDZMS3B1oA/NKaF16Rr249EKDbsR DMJX1xs7SoTrEyTf1tJ/gYuSf2KbP6/yiCW4BRGytl4SlqMsLUMnzO+nE+jxBhCmP+f4 wQlwG+OgsaLXzBY2Yp8GRe37J4VsGQn6/GsLzgkRGYuoWp/Bus7Tp7pQjz3zbapV30ME PTnQ== MIME-Version: 1.0 X-Received: by 10.170.223.84 with SMTP id p81mr1159443ykf.110.1414965369212; Sun, 02 Nov 2014 13:56:09 -0800 (PST) Received: by 10.170.195.203 with HTTP; Sun, 2 Nov 2014 13:56:09 -0800 (PST) Date: Sun, 2 Nov 2014 13:56:09 -0800 Message-ID: From: Watson Ladd To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HgtspO-q77ngz92K6t38KfOUt5Q Subject: [saag] NTP security, and thoughts on Hawaii 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: Sun, 02 Nov 2014 21:56:11 -0000 Dear all, NTP needs to be secure, ergo we have NTP Autokey. Problem solved? Of course not, otherwise I wouldn't be writing this email. Most NTP servers and clients can't use autokey. Many servers are run as part of pools, making it difficult to secure NTP effectively with autokey because of a mismatch in trust models. Most clients can't use autokey, because autokey fails in the presence of NATs. Many client implementations don't want to embed reams of code from OpenSSL, and RFC 5906 defines several important data structures in terms of this code, as well as relying on X509. Many of the choices in Autokey were designed to help attain microsecond precision. However most users of secure NTP don't need that level of precision: they want to get an authentic time within minutes, not an inauthentic time to within microseconds, and they want to do it with pools and from behind NATs. As usual this was known when the standard was being written. We have a hard enough time deploying crypto that works: it's even worse when the only solution to a problem is DOA, because it solves the wrong problem. The impact of insecure time is hard to understate. Every single expiration time, be it on zone keys in DNSSEC, OCSP stapling responses, X509 certificates, or even DNS responses, can be evaded by an attacker who manipulates the network by faking NTP packets at boot time. On most (all?) operating systems this is sufficient to change the clock to whatever time is desired, and thus evade all the checks depending on synchronized clocks. Luckily the NTP working group is considering drafts that address some of these issues. However, it still is not addressing pool security. I'm at my limit of effective participation, but I hope that this problem is solved sooner, rather than later. Without secure time, a lot of security mechanisms do not work. In the course of writing this email, I discovered that this is on the SAAG agenda for Hawaii, and I hope that these issues get raised in that discussion. I also hope that in Hawaii SAAG carefully examine the role of IETF working groups in promoting security, the lack of effective depreciation of old protocols, the relations between implementors, standards bodies, and administrators, and how we are going to get to a world in which every packet is encrypted with security protocols that work. I don't think that the current agenda or drafts advance this goal. Sincerely, Watson Ladd From nobody Sun Nov 2 18:50:51 2014 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 5B0601A6EE8 for ; Sun, 2 Nov 2014 18:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.003 X-Spam-Level: *** X-Spam-Status: No, score=3.003 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_03_06=1.592, HELO_MISMATCH_ORG=0.611] 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 WtxonxNULDDh for ; Sun, 2 Nov 2014 18:50:48 -0800 (PST) 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 26C241A6EF0 for ; Sun, 2 Nov 2014 18:50:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B6FD8E2034; Sun, 2 Nov 2014 21:50:46 -0500 (EST) 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 23348-04; Sun, 2 Nov 2014 21:50:44 -0500 (EST) Received: from securerf.ihtfp.org (unknown [12.180.137.251]) (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 DE7CFE2031; Sun, 2 Nov 2014 21:50:43 -0500 (EST) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id sA2NfeWF020303; Sun, 2 Nov 2014 18:41:40 -0500 From: Derek Atkins To: Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C739B9DD3AD@uxcn10-5.UoA.auckland.ac.nz> Date: Sun, 02 Nov 2014 18:41:40 -0500 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DD3AD@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Fri, 31 Oct 2014 21:47:36 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/saag/vnq5FAFtbTcuWdZbXH_hrSEpl9U Cc: "saag@ietf.org" Subject: Re: [saag] getting rid of fairly old stuff 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, 03 Nov 2014 02:50:50 -0000 Peter Gutmann writes: > Derek Atkins writes: >>ianG writes: >>> Back to the subject line: How about taking away? ;-) Here's a strawman >>> proposal: >>> >>> TLS 1.5 will deprecate all but 1 suite from the TLS 1.4 set. >> >>So we'll standardize on that in about 2020, and deployment will finally get >>out around 2030 or so. Not too bad! :) > > I think that's being optimistic. I don't think it'll actually be possible to > form a committee big enough to standardise TLS 1.5. Eh, I like being optimistic. The alternative is pessimism, which isn't good. I suppose realism is the best alternative. Considering we're still talking about TLS 1.3, waiting for 1.5 is a LONG way off. > Peter. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Nov 3 01:31:27 2014 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 5EA601A0020 for ; Mon, 3 Nov 2014 01:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.394 X-Spam-Level: X-Spam-Status: No, score=-3.394 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 pZDBBVcqz7uO for ; Mon, 3 Nov 2014 01:31:22 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A161A0032 for ; Mon, 3 Nov 2014 01:31:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1415007082; x=1446543082; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=HroR+LPamPSeDMwmv4rTuCqY2sRewcb6WQTYvkej18o=; b=iGrlZOsksUDMcG+Pqh3ywZ5gZgpv+Q3Vlj1OHvAsVHAgdxxriZ6DaePn SP9QcfzEOZmROpKnAIDM6nnxCiDhXgqiAn0p6VO0QGJx5U608icHz3Tnf DudASt5274AtnVx/k4Qi5UHoG5QewUOkWsMidBkMEDNXzdwfr9Ksbpony g=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="287401823" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 03 Nov 2014 22:31:19 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Mon, 3 Nov 2014 22:31:19 +1300 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] getting rid of fairly old stuff Thread-Index: Ac/3SOvrPORosZ98SCqVCFDv/nofdw== Date: Mon, 3 Nov 2014 09:31:18 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DEA3A@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Ov5_gjiIC-4eom0RB7OiWQ5vrLs Subject: Re: [saag] getting rid of fairly old stuff 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, 03 Nov 2014 09:31:25 -0000 Derek Atkins writes:=0A= =0A= >Eh, I like being optimistic. The alternative is pessimism, which isn't go= od.=0A= >I suppose realism is the best alternative. Considering we're still talkin= g=0A= >about TLS 1.3, waiting for 1.5 is a LONG way off.=0A= =0A= My comment was in regard to the current TLS 1.3 process, which started out = as=0A= a slight update on 1.2 but has since turned into a complete protocol redesi= gn=0A= incorporating every cool new feature everyone on the standards committee ca= n=0A= think of. Or at least every proposed feature, they haven't even been able = to=0A= agree on which ECC fashion statement to follow yet.=0A= =0A= So my comment about what TLS 1.5 would be is just an extrapolation on what = TLS=0A= 1.3 seems to be doing now.=0A= =0A= Peter.= From nobody Mon Nov 3 03:13:51 2014 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 D62D91A007F for ; Mon, 3 Nov 2014 03:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 acT0CkxJXIYI for ; Mon, 3 Nov 2014 03:13:46 -0800 (PST) Received: from ppsw-40.csi.cam.ac.uk (ppsw-40.csi.cam.ac.uk [131.111.8.140]) (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 76DB61A0076 for ; Mon, 3 Nov 2014 03:13:46 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:49655) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1XlFZw-0008He-kL (Exim 4.82_3-c0e5623) (return-path ); Mon, 03 Nov 2014 11:13:44 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1XlFZw-0004v6-9j (Exim 4.72) (return-path ); Mon, 03 Nov 2014 11:13:44 +0000 Date: Mon, 3 Nov 2014 11:13:44 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Watson Ladd In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/saag/m55oFADddrEUkO_kXhW_MwhVPq8 Cc: "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 03 Nov 2014 11:13:49 -0000 I did some experiments last year on secure time, based on the principle of getting the time from multiple marginally-trusted third parties and determining what time they agree on. I have not been following the NTP WG. http://fanf.livejournal.com/128861.html http://fanf.livejournal.com/129371.html I have a proposal for DNSSEC root trust anchor bootstrap and rollover based on similar ideas: http://tools.ietf.org/html/draft-fanf-dnsop-trust-anchor-witnesses Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. From nobody Mon Nov 3 07:42:08 2014 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 2BA351A038A for ; Mon, 3 Nov 2014 07:42:06 -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 cjCXan4sGrV0 for ; Mon, 3 Nov 2014 07:42:04 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9781A03A6 for ; Mon, 3 Nov 2014 07:42:03 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id hs14so9902517lab.33 for ; Mon, 03 Nov 2014 07:42:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+bFUpksie6aeq0DKhGxkXNdVhrbFSq/r3b4IS0wxUu4=; b=PKzkYAAkBXHsG55I2Hhiyp9GFoDQlLp0fMoGhJDQRcICn/IR7u13/CEQqXAktCxm+6 xgvG49LRtvtwTXmuf8WMpmfwUOGONhQhItmaS00rWH/nrwD7Hd3AhF7mU0KS5fhCYrM8 +Stuy9KVkzBHJTcU0Dq4oIiGFBgBfepLRxlSE1t/+H2XkrjKzQFcRxL4fku6bhj5JM2I a+EMRTRMAwXziuimsBLfxawORAnaZayez7u8ajoOLfXynJ3+vmDND+BHdLZrMGCFPftU /tiZvs63tUJDp4PGozQiZKMcU8nZPzBSC0HOIgU8BqMmnHKL6c44Z75JyzAj7n9VvC7X /eLA== MIME-Version: 1.0 X-Received: by 10.112.135.229 with SMTP id pv5mr51678346lbb.52.1415029321736; Mon, 03 Nov 2014 07:42:01 -0800 (PST) Received: by 10.112.95.17 with HTTP; Mon, 3 Nov 2014 07:42:01 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Nov 2014 10:42:01 -0500 Message-ID: From: Kathleen Moriarty To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/DUDP_YHZvhk0uqt5xWUES-XyQHw Cc: "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 03 Nov 2014 15:42:06 -0000 Hello, Thanks for sharing your thoughts. On Sun, Nov 2, 2014 at 4:56 PM, Watson Ladd wrote: > Dear all, > NTP needs to be secure, ergo we have NTP Autokey. Problem solved? Of > course not, otherwise I wouldn't be writing this email. > > Most NTP servers and clients can't use autokey. Many servers are run > as part of pools, making it difficult to secure NTP effectively with > autokey because of a mismatch in trust models. Most clients can't use > autokey, because autokey fails in the presence of NATs. Many client > implementations don't want to embed reams of code from OpenSSL, and > RFC 5906 defines several important data structures in terms of this > code, as well as relying on X509. > > Many of the choices in Autokey were designed to help attain > microsecond precision. However most users of secure NTP don't need > that level of precision: they want to get an authentic time within > minutes, not an inauthentic time to within microseconds, and they want > to do it with pools and from behind NATs. > > As usual this was known when the standard was being written. We have a > hard enough time deploying crypto that works: it's even worse when the > only solution to a problem is DOA, because it solves the wrong > problem. > > The impact of insecure time is hard to understate. Every single > expiration time, be it on zone keys in DNSSEC, OCSP stapling > responses, X509 certificates, or even DNS responses, can be evaded by > an attacker who manipulates the network by faking NTP packets at boot > time. On most (all?) operating systems this is sufficient to change > the clock to whatever time is desired, and thus evade all the checks > depending on synchronized clocks. > > Luckily the NTP working group is considering drafts that address some > of these issues. However, it still is not addressing pool security. > I'm at my limit of effective participation, but I hope that this > problem is solved sooner, rather than later. Without secure time, a > lot of security mechanisms do not work. In the course of writing this > email, I discovered that this is on the SAAG agenda for Hawaii, and I > hope that these issues get raised in that discussion. We will have open mic time after the talks that are planned and can see what develops, then bring it to the appropriate lists for discussion. If there are additional drafts needed, getting volunteers would be good. Let's see how the discussion goes in Hawaii and thanks for raising these points. > > I also hope that in Hawaii SAAG carefully examine the role of IETF > working groups in promoting security, the lack of effective > depreciation of old protocols, the relations between implementors, > standards bodies, and administrators, and how we are going to get to a > world in which every packet is encrypted with security protocols that > work. I don't think that the current agenda or drafts advance this > goal. We've started a little bit of discussion on this topic between a few of the ADs, but have not taken it far enough yet. It's a bit tricky to figure out what the right approach will be and more discussion is needed. I'll see if there is time to add this on the agenda, but would encourage more suggestions to be discussed on the SAAG list in the meantime. I don't like the idea of waiting for something to break before fixing it as what happened with POODLE. It's also hard to get everyone to make the switch or enough to have the impact. This particular topic does require more consideration and I think anything we do would need to be coupled with marketing (even twitter in a positive way - praising those who have made updates) to motivate change. Thanks, Kathleen > > Sincerely, > Watson Ladd > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- Best regards, Kathleen From nobody Mon Nov 3 08:14:48 2014 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 B922F1A03A8 for ; Mon, 3 Nov 2014 08:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 CDyJYkcfTVEy for ; Mon, 3 Nov 2014 08:14:46 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E2DFD1A03A4 for ; Mon, 3 Nov 2014 08:14:46 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id C861467C06B; Mon, 3 Nov 2014 08:14:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Z7/SxIkP0XlgQ0 yHF29/n9FLCEQ=; b=PmZ3gvqMhjFOuTkxFHWursVqLLOtFHgSC7flFOoWf6yfes 6vUTCyzcEPEm3ONVPAPu9fMB5XVrGgnfnx6/haBNJdlPtD4w1W/2wiOXeZ0C2Y5C tG9kMG4eHl4Yea5Q0YJF1+dAt1tQnqzGMuPxLWv7LF3ac0lf53YGr46uSK0oE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPA id BC76D67C069; Mon, 3 Nov 2014 08:14:45 -0800 (PST) Date: Mon, 3 Nov 2014 10:14:44 -0600 From: Nico Williams To: Tony Finch Message-ID: <20141103161441.GF7913@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/6CqRWZtvAlCtugLssTdmwPtXpUA Cc: "saag@ietf.org" Subject: [saag] DNSSEC witnessing (Re: NTP security, and thoughts on Hawaii) 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, 03 Nov 2014 16:14:47 -0000 On Mon, Nov 03, 2014 at 11:13:44AM +0000, Tony Finch wrote: > I have a proposal for DNSSEC root trust anchor bootstrap and rollover > based on similar ideas: > > http://tools.ietf.org/html/draft-fanf-dnsop-trust-anchor-witnesses +1 This is, in my mind, related to gossip protocols, which DNSSEC does need. (Can witnesses gang up on the zone (here the root) they witness for to DoS it? But of course that's unlikely; still, it should be mentioned in the Security Considerations.) Nico -- From nobody Mon Nov 3 08:49:24 2014 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 26AF91A1A05 for ; Mon, 3 Nov 2014 08:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 UUd-__7IDtwK for ; Mon, 3 Nov 2014 08:49:18 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) (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 DF30C1A0A6B for ; Mon, 3 Nov 2014 08:49:17 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:46173) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1XlKod-0004sL-YK (Exim 4.82_3-c0e5623) (return-path ); Mon, 03 Nov 2014 16:49:15 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1XlKod-0001Sq-Iz (Exim 4.72) (return-path ); Mon, 03 Nov 2014 16:49:15 +0000 Date: Mon, 3 Nov 2014 16:49:15 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Nico Williams In-Reply-To: <20141103161441.GF7913@localhost> Message-ID: References: <20141103161441.GF7913@localhost> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/saag/oiDYNnFqaIZaTxzLmBOyE2CRO3w Cc: "saag@ietf.org" Subject: Re: [saag] DNSSEC witnessing (Re: NTP security, and thoughts on Hawaii) 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, 03 Nov 2014 16:49:20 -0000 Nico Williams wrote: > > (Can witnesses gang up on the zone (here the root) they witness for to > DoS it? But of course that's unlikely; still, it should be mentioned in > the Security Considerations.) Yes in all respects. The really tricky aspect of this idea is being sure that you are talking to several *different* sources of information. If they share some common infrastructure then it is likely that you are trusting that infrastructure more than you intended to. (There's more discussion about this in my second post on Temporum http://fanf.livejournal.com/129371.html) My current thinking is that this is easiest to deal with if you have a carefully chosen statically configured list of witnesses, aiming for quality rather than quantity. But perhaps gossip protocols are a better (more widely applicable) way to solve the problem. Tony. -- f.anthony.n.finch http://dotat.at/ Fisher: Southerly or southwesterly 5 to 7, occasionally gale 8 in east, veering westerly 4 or 5. Moderate or rough, becoming slight or moderate later. Rain or squally showers. Good, occasionally moderate. From nobody Mon Nov 3 08:59:57 2014 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 7F0551A1A1F for ; Mon, 3 Nov 2014 08:59:53 -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 LnVkFtHW6EEo for ; Mon, 3 Nov 2014 08:59:51 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7DC51A0A6B for ; Mon, 3 Nov 2014 08:59:50 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id p9so3989702lbv.0 for ; Mon, 03 Nov 2014 08:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pMz383YxnWBULUoktMUwr0F6bDtH/Q7/JcGzyFezufw=; b=Pg+EA9L87hyRjzaffFHKwmwDeKnaKXukxHDc3CxqHLm8NXyK9ckJlcuEjbP5UJhUX8 GW3XJTwduzYvEtR8LcTttVIvBRb5iKXadqE7U9s7x8Ctx9Cwd98areaU+AyBA4nUIJdV iotmHYgp5y0JvSbupCZ/Y2gSwc8GoYpkE63bdXbJcKiVVsSiQE1e29zGRQUcH+A6KojW eZNBI6wS4oFtnjIkpvOwBweSefMOzR1qjv7GlZ5DzMMNzfl+mo5XzY+3u0qhKc42NS/M Shcw5cQRmXy3alkUYLo6g58xN2YXzgHeR7Emj/7TxmJUKM5LxOGOXmOMLlCazdyWZGIX /o8Q== MIME-Version: 1.0 X-Received: by 10.112.11.133 with SMTP id q5mr52098039lbb.77.1415033988870; Mon, 03 Nov 2014 08:59:48 -0800 (PST) Received: by 10.112.95.17 with HTTP; Mon, 3 Nov 2014 08:59:48 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Nov 2014 11:59:48 -0500 Message-ID: From: Kathleen Moriarty To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/eEpM9mNVkWfej4TglZAqpiVrRsI Cc: "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 03 Nov 2014 16:59:53 -0000 On Mon, Nov 3, 2014 at 10:42 AM, Kathleen Moriarty wrote: > Hello, > > Thanks for sharing your thoughts. > > On Sun, Nov 2, 2014 at 4:56 PM, Watson Ladd wrote: >> Dear all, >> NTP needs to be secure, ergo we have NTP Autokey. Problem solved? Of >> course not, otherwise I wouldn't be writing this email. >> >> Most NTP servers and clients can't use autokey. Many servers are run >> as part of pools, making it difficult to secure NTP effectively with >> autokey because of a mismatch in trust models. Most clients can't use >> autokey, because autokey fails in the presence of NATs. Many client >> implementations don't want to embed reams of code from OpenSSL, and >> RFC 5906 defines several important data structures in terms of this >> code, as well as relying on X509. >> >> Many of the choices in Autokey were designed to help attain >> microsecond precision. However most users of secure NTP don't need >> that level of precision: they want to get an authentic time within >> minutes, not an inauthentic time to within microseconds, and they want >> to do it with pools and from behind NATs. >> >> As usual this was known when the standard was being written. We have a >> hard enough time deploying crypto that works: it's even worse when the >> only solution to a problem is DOA, because it solves the wrong >> problem. >> >> The impact of insecure time is hard to understate. Every single >> expiration time, be it on zone keys in DNSSEC, OCSP stapling >> responses, X509 certificates, or even DNS responses, can be evaded by >> an attacker who manipulates the network by faking NTP packets at boot >> time. On most (all?) operating systems this is sufficient to change >> the clock to whatever time is desired, and thus evade all the checks >> depending on synchronized clocks. >> >> Luckily the NTP working group is considering drafts that address some >> of these issues. However, it still is not addressing pool security. >> I'm at my limit of effective participation, but I hope that this >> problem is solved sooner, rather than later. Without secure time, a >> lot of security mechanisms do not work. In the course of writing this >> email, I discovered that this is on the SAAG agenda for Hawaii, and I >> hope that these issues get raised in that discussion. > > We will have open mic time after the talks that are planned and can > see what develops, then bring it to the appropriate lists for > discussion. If there are additional drafts needed, getting volunteers > would be good. Let's see how the discussion goes in Hawaii and thanks > for raising these points. >> >> I also hope that in Hawaii SAAG carefully examine the role of IETF >> working groups in promoting security, the lack of effective >> depreciation of old protocols, the relations between implementors, >> standards bodies, and administrators, and how we are going to get to a >> world in which every packet is encrypted with security protocols that >> work. I don't think that the current agenda or drafts advance this >> goal. > > We've started a little bit of discussion on this topic between a few > of the ADs, but have not taken it far enough yet. It's a bit tricky > to figure out what the right approach will be and more discussion is > needed. I'll see if there is time to add this on the agenda, but > would encourage more suggestions to be discussed on the SAAG list in > the meantime. I don't like the idea of waiting for something to break > before fixing it as what happened with POODLE. It's also hard to get > everyone to make the switch or enough to have the impact. This > particular topic does require more consideration and I think anything > we do would need to be coupled with marketing (even twitter in a > positive way - praising those who have made updates) to motivate > change. > I should have mentioned phasing out SSL 3 here as the example. Some of the difficulties we'll have to consider in how the IETF can influence change and phasing out older protocols, algorithms, etc. is the way vulnerability disclosure is handled between companies. For good reason, it is a very private process between those effected with strict disclosure rules prior to any announcements. Often, vendors will want to be ready with the actions they plan to take prior to announcements to mitigate the effect (ability to exploit) the vulnerability could have once announced. > Thanks, > Kathleen > >> >> Sincerely, >> Watson Ladd >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > > > -- > > Best regards, > Kathleen -- Best regards, Kathleen From nobody Mon Nov 3 09:42:59 2014 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 E1EC91A1BE4 for ; Mon, 3 Nov 2014 09:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 Bh3caGRaZshp for ; Mon, 3 Nov 2014 09:42:52 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590921A1B9C for ; Mon, 3 Nov 2014 09:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1415036573; x=1446572573; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=b6rfyZPm2Pum6u2C+8xU86H7p7fyXS9RUHFBPqa37kE=; b=Dg8JMs9VttsAAaq+yu/Z1jwHjx+gyDkAx/GowzUG7yLRuUS/LPwQDoDr O7Ke+c7FSB5m9Ozj+9QOwHBkvKWIfPuDaY7A4I6v2ObEHPWDM29G3kVxF QuTXHdVO9r/YNJN7zChmvA1eUii4sXq+kNhD/5AhLER/SB6v+QfBimNza 4=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="287433776" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 04 Nov 2014 06:42:51 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Tue, 4 Nov 2014 06:42:50 +1300 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] NTP security, and thoughts on Hawaii Thread-Index: Ac/3jZWFS3tDHMnsSHCkiAUV/HFvFQ== Date: Mon, 3 Nov 2014 17:42:48 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DEDB8@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/r-1Pni36hXpLQhMhxJep3bkX_fs Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 03 Nov 2014 17:42:58 -0000 Tony Finch writes:=0A= =0A= >I did some experiments last year on secure time, based on the principle of= =0A= >getting the time from multiple marginally-trusted third parties and=0A= >determining what time they agree on. I have not been following the NTP WG.= =0A= >=0A= >http://fanf.livejournal.com/128861.html=0A= >http://fanf.livejournal.com/129371.html=0A= =0A= tlsdate is quite risky because it relies on a feature that some servers=0A= already don't support (telling a potentially hostile client what your idea = of=0A= the current time is isn't a good idea) and that definitely won't be present= in=0A= TLS 1.3.=0A= =0A= If you're really worried about the validity of your time, why not hook a GP= S=0A= to a Raspberry Pi and run that as an NTP server, or get a prebuilt one like= =0A= this:=0A= =0A= https://www.tindie.com/products/gxti/laureline-gps-ntp-server/=0A= =0A= That can still be spoofed, but getting in close proximity to where you're= =0A= running the server and spoofing GPS signals is a lot trickier than spoofing= =0A= NTP over a network.=0A= =0A= Peter.= From nobody Mon Nov 3 09:48:02 2014 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 E41B41A1A76 for ; Mon, 3 Nov 2014 09:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 fTRBBT6Qdlrd for ; Mon, 3 Nov 2014 09:47:58 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029261A1B6D for ; Mon, 3 Nov 2014 09:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1645; q=dns/txt; s=iport; t=1415036878; x=1416246478; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=7dRFVDBCRE8SPWGfrDDZIaJubBQoE3lf1VefR2rt/kw=; b=mvPJvvV2UGlO776uBpJcYKrCdLAPmtnhsP2r1n43G2LSsY4hyr7FiaW8 k4BebBrww/39SxMg/njew9f9V89Ce2IzgmIuuUFvl4cyYzT5f0fMZGXpm 2n5GEXfnDaAg5cqZW6Vv5p4r1rDCC9/A1xubkw0TY3Oj+3AhUhP41gd7O c=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0EAC2/V1StJssW/2dsb2JhbABcDoNUg17LBIdNAoE5AQEBAQF9hAMBAQQjVRELDgoJFgsCAgkDAgECAUUGAQwIAQGIPQ2zaJQTAQEBAQEBAQEBAQEBAQEBAQEBFgSRF4J3gVQBBIt2iDmBUogAgTGGRIpShAmDOGEcgnoBAQE X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="asc'?scan'208";a="234302593" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 03 Nov 2014 17:47:56 +0000 Received: from [10.154.176.54] ([10.154.176.54]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sA3HltU9009199; Mon, 3 Nov 2014 17:47:55 GMT Message-ID: <5457BFC9.8010703@cisco.com> Date: Mon, 03 Nov 2014 09:47:53 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Peter Gutmann , "saag@ietf.org" References: <9A043F3CF02CD34C8E74AC1594475C739B9DEDB8@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DEDB8@uxcn10-5.UoA.auckland.ac.nz> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2tg1LkFLke8E4HIwCUIhXOh6Hhns6Hq6e" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/6Wh4w3dh5oczP5heTeyE9Ij0h3s Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 03 Nov 2014 17:48:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2tg1LkFLke8E4HIwCUIhXOh6Hhns6Hq6e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Peter, I won't comment on the rest of this, but... On 11/3/14, 9:42 AM, Peter Gutmann wrote: > If you're really worried about the validity of your time, why not hook = a GPS > to a Raspberry Pi and run that as an NTP server, or get a prebuilt one = like > this: > > https://www.tindie.com/products/gxti/laureline-gps-ntp-server/ > > That can still be spoofed, but getting in close proximity to where you'= re > running the server and spoofing GPS signals is a lot trickier than spoo= fing > NTP over a network. > In particular it requires access to the sky, which in any number of cases is not possible. Perhaps that's beyond the general case, but worth thinking about. Eliot --2tg1LkFLke8E4HIwCUIhXOh6Hhns6Hq6e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUV7/KAAoJEIe2a0bZ0nozJjYIANqM8Wf6bJjRh95TiJcw1b+q kacXlmMwWMm4fRHRooXCDgsGARdjyn8iqZEPcZamJEfEDXIqgU0BFVDt3i+C/hGg oc1U8aYnLtlpp0lByChss76y2Dw0gC93ecA0Hh86WtTg1bVHYcFS8hRsRXmKpY6T kz1ejJePaIbAWn9HR/tXFD13n5XIbiJC34OGyq46a+0w72IeUPZcvJqlH2VoaOjs 4gUx8WdO0EFUp1qV5rMyJKnTMYLhVNqwC8odBVOAN0w2bfts7jwsn2sRvaXnKXYI HU5+CiE38aqJC6IeDUsItx/4Bvqaw1PWZvfWoRmy3NcVcuSVlKKZAalqHJmAT/M= =8gZ1 -----END PGP SIGNATURE----- --2tg1LkFLke8E4HIwCUIhXOh6Hhns6Hq6e-- From nobody Mon Nov 3 09:53:27 2014 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 E427F1A6F0A for ; Mon, 3 Nov 2014 09:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 gwikDIBmBFti for ; Mon, 3 Nov 2014 09:53:22 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4291A3BA7 for ; Mon, 3 Nov 2014 09:53:22 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 1F1EC598057 for ; Mon, 3 Nov 2014 09:53:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=XdR/bTojeCyvJDlrxgt1 +iydg4w=; b=ViKhm6DltON23jpYy5uJTt5B/mIT0ZolwpA5kg+ion1IInjDrWAo xYYSUtOhyorjZOXOwy7Hbow7ggvKhPmMVMu77wI1oG0JAOYVsLxj6RdDVyoTZ6MS oFvVdnJww+JIpbDnAdGJsTA9GNIXleZOuo22UMJSbtHvHdo2oe9c4uc= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id BDDE0598058 for ; Mon, 3 Nov 2014 09:53:21 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id bs8so7221656wib.5 for ; Mon, 03 Nov 2014 09:53:20 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.239.104 with SMTP id vr8mr23128315wjc.18.1415037200159; Mon, 03 Nov 2014 09:53:20 -0800 (PST) Received: by 10.216.32.135 with HTTP; Mon, 3 Nov 2014 09:53:20 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DEDB8@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C739B9DEDB8@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 3 Nov 2014 11:53:20 -0600 Message-ID: From: Nico Williams To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/zVbZYM-P3MyvalMxebkPMQuHMS4 Cc: "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 03 Nov 2014 17:53:25 -0000 Mobile devices typically have a GPS receiver too... Still, it'd be nice to have a secure NTP that scales. Do we have an analysis of NTP autokey? What's wrong with it? Is it just a matter of lack of deployment? (I imagine that signing every NTP multicast could be problematic, but what about including a signature of the previous multicast in every new one?) Nico -- From nobody Mon Nov 3 10:06:40 2014 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 CA6F61A6EE7 for ; Mon, 3 Nov 2014 10:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 OOTt0oiPNmnM for ; Mon, 3 Nov 2014 10:06:38 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA231A6F8F for ; Mon, 3 Nov 2014 10:06:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1415037999; x=1446573999; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=KGEecS1l5Igsmvo2e7iE/UbpP4s7K1QcD6ZoIL8d4+Q=; b=hkr3C3kt4lj4CulYPbVPC7gCFU8V9W0JHB26LQSXWQaSHGGDZsbqBxzD sCeGBxK5JgSIEqQgvWVaS/+OzstJsrW7/+uoxChUThReR5qMsDNAlf8fY +89kNabXTlU4Q5pouDviWMA1GFzyuo2js+QvccTtMPXlOAlidJH/v6sD/ I=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="287435500" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 04 Nov 2014 07:06:37 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Tue, 4 Nov 2014 07:06:35 +1300 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] NTP security, and thoughts on Hawaii Thread-Index: Ac/3kOeLlzVRAFrATIGrjWMhC1Wzvg== Date: Mon, 3 Nov 2014 18:06:34 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/K2q3d0BE8tY8mtRCCoIAT65GYVI Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 03 Nov 2014 18:06:39 -0000 Eliot Lear writes:=0A= =0A= >In particular it requires access to the sky, which in any number of cases = is=0A= >not possible. Perhaps that's beyond the general case, but worth thinking= =0A= >about.=0A= =0A= It actually requires a lot less access to the sky than that, you don't need= a=0A= 3D or even 2D lock, just a single satellite will do. I run my GPS-based NT= P=0A= server in a room under a metal roof and it has no problems getting a time-= =0A= source lock (although I've never had a 3D lock, and 2D is quite intermitten= t).=0A= As long as you can get a ceramic patch antenna somewhere near a window you= =0A= should be fine.=0A= =0A= (Even if your servers are located in, say, an underground bunker, there's n= o=0A= reason why your NTP server also needs to be there. Or if you're that worri= ed,=0A= buy a rubidium clock-based one and run your own time reference).=0A= =0A= Peter.= From nobody Mon Nov 3 10:09:17 2014 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 DF0351A6FB8 for ; Mon, 3 Nov 2014 10:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 x7r36hXmWB25 for ; Mon, 3 Nov 2014 10:09:11 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C0561A0235 for ; Mon, 3 Nov 2014 10:09:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1590; q=dns/txt; s=iport; t=1415038150; x=1416247750; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=tGAnhneR3/sxVrFf2WuhMUQmwt1MINSOnIbHs7pdRNU=; b=PjNWN/6WXcBTlfh9i+Oy00pfN8gQJgZR7qTpZLGKY4k/8KorfUpBHOWM 3isoWijAr077Jhbfz2vp8E+tWDHGV5Jh0++D+vgkjNvpWnaMYsPo0d9ld VFs5knGhRjNrcwTzA3OsZ9obPhm8vKlKfHVkxs0sLc6KeRZjCjcO5AhPj M=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAOLDV1StJssW/2dsb2JhbABcDoQsgwbSUQKBOgEBAQEBfYQDAQEEI1URCw4KCRYLAgIJAwIBAgFFBgEMBgIBAYg9tACUFAEBAQEBAQEDAQEBAQEBAQEakReCd4FUAQSLdog5gVKIAId1jluDOGEcL4JLAQEB X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="asc'?scan'208";a="234956568" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 03 Nov 2014 18:09:08 +0000 Received: from [10.154.176.54] ([10.154.176.54]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sA3I97L1015289; Mon, 3 Nov 2014 18:09:07 GMT Message-ID: <5457C4C2.6010407@cisco.com> Date: Mon, 03 Nov 2014 10:09:06 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Peter Gutmann , "saag@ietf.org" References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A2ehJshC6EMLDCxg2fiWk0DVNv4fKfIxS" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/nxBlcUQGdSlZjI_dAyMH7G1Gdts Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 03 Nov 2014 18:09:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A2ehJshC6EMLDCxg2fiWk0DVNv4fKfIxS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/3/14, 10:06 AM, Peter Gutmann wrote: > Eliot Lear writes: > >> In particular it requires access to the sky, which in any number of ca= ses is >> not possible. Perhaps that's beyond the general case, but worth think= ing >> about. > It actually requires a lot less access to the sky than that, you don't = need a > 3D or even 2D lock, just a single satellite will do. I understand. Even that access is not always available in a number of environments. In the cases I'm aware of, there is at least one wire out to an antenna from a strat1 clock. But you can't expect hundreds of devices to do that... Eliot --A2ehJshC6EMLDCxg2fiWk0DVNv4fKfIxS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUV8TCAAoJEIe2a0bZ0nozpSQIAJK+zUeTyuTNVibmnpdLTyOa iAFcuyx51pPZYqVVjHpmDrjORkuaeu1lkfipPOFyRx83DcoC1gzS3DbFBWZvquKN LGa7qXS7NnuI1KCwer3Z2SjDHtbhQ80puB1G8Nrs3Cxg7QQ0TL6tv7vIrrSDnb+Q EY7eg+cNRSnLJhKSFStCFNVNYpSEIDFXBQIbtxa4D7CRRlQjC3SYKaIY9M96retM 8B0NwbDXNfgozxW2xmJdYKtYdKrDfHMY5o9jwCLmxGeV9FG9bRMa4/sMkA6Mjfwd nrrfPHCueuZ5xroitP/IKyDCFqtcULZfgpiHqZRcHwacoon5ixPFzhOBI8EaSF0= =piFW -----END PGP SIGNATURE----- --A2ehJshC6EMLDCxg2fiWk0DVNv4fKfIxS-- From nobody Mon Nov 3 10:09:44 2014 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 F1D8D1A6FB2 for ; Mon, 3 Nov 2014 10:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] 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 r1XGVoi4HanG for ; Mon, 3 Nov 2014 10:09:35 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id D9F2F1A6F8D for ; Mon, 3 Nov 2014 10:09:27 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id EC89A4759C; Mon, 3 Nov 2014 18:09:26 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id DFCD64759A; Mon, 3 Nov 2014 18:09:26 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id D93CC2029; Mon, 3 Nov 2014 18:09:26 +0000 (GMT) Received: from usma1ex-cashub5.kendall.corp.akamai.com (172.27.105.21) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 3 Nov 2014 13:09:19 -0500 Received: from USMBX1.msg.corp.akamai.com ([169.254.1.216]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Mon, 3 Nov 2014 13:09:19 -0500 From: "Salz, Rich" To: Peter Gutmann , "saag@ietf.org" Date: Mon, 3 Nov 2014 13:09:19 -0500 Thread-Topic: [saag] NTP security, and thoughts on Hawaii Thread-Index: Ac/3kOeLlzVRAFrATIGrjWMhC1WzvgAAE+jw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D4F1CAA5B@USMBX1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/GRCPbpD9MTBFmDF1huGOKTprBNY Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 03 Nov 2014 18:09:41 -0000 I want one of these: http://www.npr.org/2014/11/03/361069820/new-clock-may-end-time-as-we-kn= ow-it Move it 1 inch and it reacts to the relativistic effects=20 -- =20 Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Mon Nov 3 12:02:29 2014 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 76B641A0360 for ; Mon, 3 Nov 2014 12:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 O5AvRUJJT53B for ; Mon, 3 Nov 2014 12:02:24 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 945B61A00B5 for ; Mon, 3 Nov 2014 12:02:23 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 17F2020028; Mon, 3 Nov 2014 15:03:59 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 74419637F4; Mon, 3 Nov 2014 15:02:22 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6330863740; Mon, 3 Nov 2014 15:02:22 -0500 (EST) From: Michael Richardson To: Peter Gutmann In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/gTap3cv39-aSieoNxdpap1B3y0s Cc: "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 03 Nov 2014 20:02:26 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Peter Gutmann wrote: > It actually requires a lot less access to the sky than that, you don't > need a 3D or even 2D lock, just a single satellite will do. I run my > GPS-based NTP From=20my office desk, I can't get any of the USB based GPS receivers to wo= rk: The windows have the reflective EM coating, and seem to reflect it all. I think we have 3G now only because there is a tower literally outside the windows at UQO. > (Even if your servers are located in, say, an underground bunker, > there's no reason why your NTP server also needs to be there. Or if > you're that worried, buy a rubidium clock-based one and run your own > time reference). We tried taping pasting the USB device to the window :-) {In this case, I was testing the devices for installation at sbrac.org, where we have no network at all... while we have a 18M dish up there, the inside of the turret turns out to also be a really good faraday cage.} =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVFffS4CLcPvd0N1lAQK/agf+JEBG97EwBOw0bWmoGHFt1hIutDPdPaOG Mvi7/oGQCzIKhFoGTl7i+Z3qm9AGJYPoVXvB7Ai3+8PLuXlZmVCilTUopRwTnsF3 FNglo9kjb6aIOBMghS9CaTOCRaX187Bt1A0nfaqNOQPKfGY4u6VVbD7uP58vCRmb TaKGgPG8th+v2Su31niBrJS8zX0AHzuXA6N1Ui10C9UC2ymproRL51ADVZRIvy1G HEA+8q6dz2WLtrDdnuVzkZtvirnG4MRtJVeU02U8koZO8KyPQVPNcOGurTYdIQSq tjt7BoADRvM+rX1fP/y+hDF+aGAYXzR9l/akVsNMXFIZgfkfnnyWtA== =XyKm -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 3 22:29:07 2014 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 E313A1A88C2 for ; Mon, 3 Nov 2014 22:29:05 -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 vm1bVXHApRYq for ; Mon, 3 Nov 2014 22:29:04 -0800 (PST) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF781A038C for ; Mon, 3 Nov 2014 22:29:04 -0800 (PST) Received: by mail-yh0-f52.google.com with SMTP id v1so1903259yhn.11 for ; Mon, 03 Nov 2014 22:29:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Y7Lvb/FrBjiYIJWreLaDb/caDdk1b+4FZK9z1mCXdng=; b=afjhkKUNJKxI8v6SX91ixqha63h63RVLQUV3odIzu3wBmV1MQ9VGq+N6mmRBLmBgIA NVgGt4+P87umz3zSWXdy9/mosQ842IRlhE0dOIF0GQdzrWLIs7ftwnO3F8Y9uPLKJnTV tCD/hOcLxt/RffsfBn3ZT4VLVTvQY5SW4JqPxgCr/1hD9pFFCCaHHlpGp39Ib4iglx/t SCL8YZRYxAi/uN5A4PjkiAWFKS7fQD2DNzS9zZF5xpJC007h18peziHFUjN8sgZNn0CW gQjS8zWN6dtIp3mIlNDm64EILam8ZxArvLzyLDP795XAw+KZN5ZAIU/KD8KVL0gELp5x 5iKw== MIME-Version: 1.0 X-Received: by 10.236.7.52 with SMTP id 40mr5470586yho.172.1415082543358; Mon, 03 Nov 2014 22:29:03 -0800 (PST) Received: by 10.170.195.203 with HTTP; Mon, 3 Nov 2014 22:29:03 -0800 (PST) Date: Mon, 3 Nov 2014 22:29:03 -0800 Message-ID: From: Watson Ladd To: Kathleen Moriarty Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/1u0rrfJTJBLI4X4oaXECgnSYa20 Cc: "saag@ietf.org" Subject: [saag] POODLE in detail (was Re: NTP security, and thoughts on Hawaii) 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, 04 Nov 2014 06:29:06 -0000 On Mon, Nov 3, 2014 at 8:59 AM, Kathleen Moriarty wrote: > On Mon, Nov 3, 2014 at 10:42 AM, Kathleen Moriarty > wrote: >> Hello, >> >> Thanks for sharing your thoughts. >> >> On Sun, Nov 2, 2014 at 4:56 PM, Watson Ladd wrote: >>> Dear all, >>> >>> I also hope that in Hawaii SAAG carefully examine the role of IETF >>> working groups in promoting security, the lack of effective >>> depreciation of old protocols, the relations between implementors, >>> standards bodies, and administrators, and how we are going to get to a >>> world in which every packet is encrypted with security protocols that >>> work. I don't think that the current agenda or drafts advance this >>> goal. >> >> We've started a little bit of discussion on this topic between a few >> of the ADs, but have not taken it far enough yet. It's a bit tricky >> to figure out what the right approach will be and more discussion is >> needed. I'll see if there is time to add this on the agenda, but >> would encourage more suggestions to be discussed on the SAAG list in >> the meantime. I don't like the idea of waiting for something to break >> before fixing it as what happened with POODLE. It's also hard to get >> everyone to make the switch or enough to have the impact. This >> particular topic does require more consideration and I think anything >> we do would need to be coupled with marketing (even twitter in a >> positive way - praising those who have made updates) to motivate >> change. >> > > I should have mentioned phasing out SSL 3 here as the example. Some > of the difficulties we'll have to consider in how the IETF can > influence change and phasing out older protocols, algorithms, etc. is > the way vulnerability disclosure is handled between companies. For > good reason, it is a very private process between those effected with > strict disclosure rules prior to any announcements. Often, vendors > will want to be ready with the actions they plan to take prior to > announcements to mitigate the effect (ability to exploit) the > vulnerability could have once announced. Let's look at the SSLv3 situation in detail. SSLv3 only websites were a vanishingly small fraction of the Internet, and SSLv3 only browsers a vanishingly small percentage of the population. SSLv3 was depreciated successfully, if we look at how often it was used. But that depreciation meant nothing so long as a man in the middle could cause both sides to fallback. The solution was extremely simple, but we're only deploying it now, after knowing for years fallback could be a problem, and how to solve that problem. This wasn't because of the closed nature of vuln disclosure (which didn't help/has changed over the years), or because of compatibility issues. It was because the TLS WG ignored the reality of fallback logic, and the need to protect it. This work didn't need to wait until POODLE and BEAST, which themselves were anticipated by well-publicized but not well understood attacks on the record layer. Likewise, the decision not to flip the MAC and encryption was made, and made again, and now we've finally fixed it. Similarly, the failure of autokey to protect pool.ntp.org was apparent from the begining of the design effort, as was the reality that CAs can be broken and that we have no defense. We should consider what can go wrong, and prepare for it to go wrong, so when it goes wrong, nothing happens. I don't see how "responsible" disclosure to some plays into being proactive, or affects the depreciation of protocols with well-known flaws. (I am amused to see an IPv4 sunsetting WG. Someone is being extraordinarily optimistic about our depreciation abilities) Sincerely, Watson Ladd > > >> Thanks, >> Kathleen >> >>> >>> Sincerely, >>> Watson Ladd >>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >> >> >> >> -- >> >> Best regards, >> Kathleen > > > > -- > > Best regards, > Kathleen -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue Nov 4 00:10:00 2014 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 5C7141A88F9 for ; Tue, 4 Nov 2014 00:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 1cUZuJK3bHre for ; Tue, 4 Nov 2014 00:09:49 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 734A11A8906 for ; Tue, 4 Nov 2014 00:09:49 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id d1so8519101wiv.3 for ; Tue, 04 Nov 2014 00:09:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=udcc3dRlz/hnKIUM1coey/iiklNEVl4PMCiim31yN1I=; b=ndtXXiMP61/QjALgdgocpiWpEj/J+m8gILCa71P0vP181sKqw2VgxCnaj4HoM/gfoq atjnY7AuvgH113sXs9DCFoz5y7b9sOA1l2ASpP6Do8DzMTOLyq1yykP0MTbwUdAJMlJ7 sISoIPoMxQSMGM0H1ErdomesJhEOZEO6GwBOVPYxKI+tALNVMmJLzFvPkaTEZMmkgPOS ka6jf/L3B8HAhsFAPTRtAC102jaHZsCyr4o6+1TEWmcN9pxFKDpDkt3DKH54Z+lYB1gt PXO7V6J/RZZE3VuKuCiJBfmxEOmU1WFUmhN7hPAklO+/hLPVx6twg6W3y+51KWtZxU+b FSYg== MIME-Version: 1.0 X-Received: by 10.180.75.116 with SMTP id b20mr21670415wiw.49.1415088588046; Tue, 04 Nov 2014 00:09:48 -0800 (PST) Received: by 10.194.220.104 with HTTP; Tue, 4 Nov 2014 00:09:48 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Nov 2014 10:09:48 +0200 Message-ID: From: Yoav Nir To: Watson Ladd Content-Type: multipart/alternative; boundary=f46d0438914f9dc885050703fcab Archived-At: http://mailarchive.ietf.org/arch/msg/saag/3HpJHKjrX5BaKL_zg4c01lA2yY8 Cc: "saag@ietf.org" Subject: Re: [saag] POODLE in detail (was Re: NTP security, and thoughts on Hawaii) 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, 04 Nov 2014 08:09:53 -0000 --f46d0438914f9dc885050703fcab Content-Type: text/plain; charset=UTF-8 On Tue, Nov 4, 2014 at 8:29 AM, Watson Ladd wrote: > > Let's look at the SSLv3 situation in detail. SSLv3 only websites were > a vanishingly small fraction of the Internet, and SSLv3 only browsers > a vanishingly small percentage of the population. SSLv3 was > depreciated successfully, if we look at how often it was used. But > that depreciation meant nothing so long as a man in the middle could > cause both sides to fallback. The solution was extremely simple, but > we're only deploying it now, after knowing for years fallback could be > a problem, and how to solve that problem. > > This wasn't because of the closed nature of vuln disclosure (which > didn't help/has changed over the years), or because of compatibility > issues. It was because the TLS WG ignored the reality of fallback > logic, and the need to protect it. I think this has little to do with the TLS working group. Fallback logic is a relatively new phenomenon. Microsoft chose to make TLS disabled by default when IE was 95% of browsers. Websites weren't punished for not tolerating TLS, so the "small" browsers like Firefox and Opera had to implement fallback logic or have a bunch of sites that don't work on their browser. As for protecting fallback, this was suggested as far back as 2006: https://tools.ietf.org/html/draft-pettersen-tls-interop-experience-00 It's a shame that it took so long to act upon this. > This work didn't need to wait until > POODLE and BEAST, which themselves were anticipated by well-publicized > but not well understood attacks on the record layer. Likewise, the > decision not to flip the MAC and encryption was made, and made again, > and now we've finally fixed it. > Not quite. There is an RFC that's hardly implemented. TLS 1.3 will fix this, but that's a long way off. (I am amused to see an IPv4 sunsetting WG. Someone is being > extraordinarily optimistic about our depreciation abilities) > The IETF doesn't get to tell the market what to do. The idea is that IPv4 is being deprecated anyway (by countries like China and Romania who were late to the party and didn't get to grab a lot of the IPv4 space), and that the IETF needs to build transition mechanisms. Whether the market will use them is up to the market, not us. That is why we would like to have more operators participate. Similarly, if we had more people who manage websites, it would be a good thing for TLS and HTTPBIS. Yoav --f46d0438914f9dc885050703fcab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 4, 2014 at 8:29 AM, Watson Ladd <watsonbladd@gmail.com= > wrote:

Let's look at the SSLv3 situation in detail. SSLv3 only websites were a vanishingly small fraction of the Internet, and SSLv3 only browsers
a vanishingly small percentage of the population. SSLv3 was
depreciated successfully, if we look at how often it was used. But
that depreciation meant nothing so long as a man in the middle could
cause both sides to fallback. The solution was extremely simple, but
we're only deploying it now, after knowing for years fallback could be<= br> a problem, and how to solve that problem.

This wasn't because of the closed nature of vuln disclosure (which
didn't help/has changed over the years), or because of compatibility issues. It was because the TLS WG ignored the reality of fallback
logic, and the need to protect it.

I think= this has little to do with the TLS working group. Fallback logic is a rela= tively new phenomenon. Microsoft chose to make TLS disabled by default when= IE was 95% of browsers. Websites weren't punished for not tolerating T= LS, so the "small" browsers like Firefox and Opera had to impleme= nt fallback logic or have a bunch of sites that don't work on their bro= wser.

As for protecting fallback, this was suggested as f= ar back as 2006: https://tools.ietf.org/html/draft-pettersen-tls-int= erop-experience-00
It's a shame that it took so long = to act upon this.
=C2=A0
This work didn't need to wait until
POODLE and BEAST, which themselves were anticipated by well-publicized
but not well understood attacks on the record layer. Likewise, the
decision not to flip the MAC and encryption was made, and made again,
and now we've finally fixed it.

Not= quite. There is an RFC that's hardly implemented. TLS 1.3 will fix thi= s, but that's a long way off.

(I am amused to see an IPv4 sunsetting WG. Someone is being
extraordinarily optimistic about our depreciation abilities)

The IETF doesn't get to tell the market what to d= o. The idea is that IPv4 is being deprecated anyway (by countries like Chin= a and Romania who were late to the party and didn't get to grab a lot o= f the IPv4 space), and that the IETF needs to build transition mechanisms. = Whether the market will use them is up to the market, not us. That is why w= e would like to have more operators participate. Similarly, if we had more = people who manage websites, it would be a good thing for TLS and HTTPBIS.
Yoav
--f46d0438914f9dc885050703fcab-- From nobody Tue Nov 4 01:38:59 2014 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 1E1821A03E3 for ; Tue, 4 Nov 2014 01:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 uKFaTceMNo7B for ; Tue, 4 Nov 2014 01:38:55 -0800 (PST) Received: from ppsw-40.csi.cam.ac.uk (ppsw-40.csi.cam.ac.uk [131.111.8.140]) (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 BF1721A0030 for ; Tue, 4 Nov 2014 01:38:55 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:53934) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1XlaZi-0007sT-jK (Exim 4.82_3-c0e5623) (return-path ); Tue, 04 Nov 2014 09:38:54 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1XlaZh-0003hT-Vy (Exim 4.72) (return-path ); Tue, 04 Nov 2014 09:38:53 +0000 Date: Tue, 4 Nov 2014 09:38:53 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Peter Gutmann In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DEDB8@uxcn10-5.UoA.auckland.ac.nz> Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C739B9DEDB8@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/saag/SnwfEhkoOLlp1Kr9dfjiMpcP8fA Cc: "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 04 Nov 2014 09:38:58 -0000 Peter Gutmann wrote: > > tlsdate is quite risky because it relies on a feature that some servers > already don't support (telling a potentially hostile client what your idea of > the current time is isn't a good idea) and that definitely won't be present in > TLS 1.3. Sort of: it can alternatively use the HTTP Date: header. I prefer to get the time from servers that are provisioned for that purpose rather than doing it parasitically, but tlsdate was useful for an experimental proof of concept. > If you're really worried about the validity of your time, why not hook a GPS > to a Raspberry Pi and run that as an NTP server, or get a prebuilt one like > this: The point is not to help experts get the time securely in a managed environment: NTPsec already suffices. My aim is something that can bootstrap time securely on a consumer device without a battery backed clock or user interface more complicated than a few LEDs. Tony. -- f.anthony.n.finch http://dotat.at/ Fisher, Northwest German Bight: Westerly 4 or 5, occasionally 6 in north Fisher, becoming variable 3 or 4 later. Slight or moderate, becoming moderate or rough later. Showers. Good, occasionally moderate. From nobody Tue Nov 4 01:42:23 2014 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 B97F21A892B for ; Tue, 4 Nov 2014 01:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 WkUScQ1S6Lnv for ; Tue, 4 Nov 2014 01:42:20 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) (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 3D1811A0022 for ; Tue, 4 Nov 2014 01:42:20 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:36382) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Xlacw-0007bn-WX (Exim 4.82_3-c0e5623) (return-path ); Tue, 04 Nov 2014 09:42:14 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Xlacw-00041g-0M (Exim 4.72) (return-path ); Tue, 04 Nov 2014 09:42:14 +0000 Date: Tue, 4 Nov 2014 09:42:14 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Nico Williams In-Reply-To: Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C739B9DEDB8@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/saag/G6Wbq_oicAsyd4ah_RB0o9Pl36E Cc: "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 04 Nov 2014 09:42:21 -0000 Nico Williams wrote: > > Still, it'd be nice to have a secure NTP that scales. Do we have an > analysis of NTP autokey? What's wrong with it? It is crippled by NAT, because the peer IP addresses are part of the authentication key. Also, I could not work out how to configure it to support the usual anonymous client / authenticated server setup that you would need for something like the NTP pool. Tony. -- f.anthony.n.finch http://dotat.at/ Portland: Northwest 5 or 6. Moderate or rough. Thundery showers. Good, occasionally moderate. From nobody Tue Nov 4 03:47:08 2014 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 9EE101A0861 for ; Tue, 4 Nov 2014 03:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 yWLo61iuPxcS for ; Tue, 4 Nov 2014 03:47:01 -0800 (PST) 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 AE1581A1AAB for ; Tue, 4 Nov 2014 03:47:01 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1XlcZf-00033c-Ua for saag@ietf.org; Tue, 04 Nov 2014 11:47:00 +0000 Date: Tue, 04 Nov 2014 11:47:07 +0000 Message-ID: From: Randy Bush To: saag References: <61DC333A-CB55-4A3E-93A1-F5274F238223@apnic.net> 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: http://mailarchive.ietf.org/arch/msg/saag/sZuVDhi8bAMB50HrBJMljSIIhtQ Subject: [saag] dnssec with ecdsa in the wild, very wild 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, 04 Nov 2014 11:47:03 -0000 moving to newer protocols is such a simple and rigorous experience < with permission > From: Geoff Huston http://www.potaroo.net/presentations/2014-11-01-ecc.pdf randy From nobody Tue Nov 4 04:31:05 2014 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 5B91D1A00AE for ; Tue, 4 Nov 2014 04:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 zmia9o7MxbVl for ; Tue, 4 Nov 2014 04:31:01 -0800 (PST) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA371A00B7 for ; Tue, 4 Nov 2014 04:31:01 -0800 (PST) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id D74176D803; Tue, 4 Nov 2014 07:30:58 -0500 (EST) Message-ID: <5458C701.4070604@iang.org> Date: Tue, 04 Nov 2014 12:30:57 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/coDXyUbiLShKg_O0R0SE-CjUOHU Subject: Re: [saag] POODLE in detail (was Re: NTP security, and thoughts on Hawaii) 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, 04 Nov 2014 12:31:03 -0000 On 4/11/2014 08:09 am, Yoav Nir wrote: > I think this has little to do with the TLS working group. ... > Whether the market will use them is up to the market, not us. That may be the way IETF thinks. Meanwhile, there are great swathes of industry that think this way: "OK, you're right. Security is screwed. But we can't do anything about it because we only implement standards. Go speak to the IETF!" The best bit about this deadly embrace of insecurity is that both sides are perfectly right, logical, just, consistent. Meanwhile the users get screwed. > That is why we would > like to have more operators participate. Similarly, if we had more > people who manage websites, it would be a good thing for TLS and HTTPBIS. Yeah, that's the other thing I noticed in my lost decade of trying to get someone anyone to do something. No users are represented on any committees. Sometimes for understandable reasons, like committees are boring and repetitive and filled with argumentative curmudgeons like myself. Other times because the charter or group is explicitly set up to exclude them. (In the SSL business, that was the norm.) I'm on a group of users called BetterCrypto.org. Here's their current recommendation: SSLProtocol All -SSLv2 -SSLv3 SSLCipherSuite 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:\ EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:\ +SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:\ !ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA' They worked like dervishes and got it down to that, last was about double! A big thank you to the TLS WG for making the lives of the poor sysadm darn near impossible, sisyphean. iang From nobody Tue Nov 4 05:03:35 2014 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 CBB701A00F4 for ; Tue, 4 Nov 2014 05:03:32 -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] 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 iUmNsJNd21qL for ; Tue, 4 Nov 2014 05:03:31 -0800 (PST) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270D41A1B03 for ; Tue, 4 Nov 2014 05:03:31 -0800 (PST) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 421C56D7E9; Tue, 4 Nov 2014 08:03:27 -0500 (EST) Message-ID: <5458CE9D.9070603@iang.org> Date: Tue, 04 Nov 2014 13:03:25 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <61DC333A-CB55-4A3E-93A1-F5274F238223@apnic.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ez4_mesiEGNPcw8Niceepn5R01o Subject: Re: [saag] dnssec with ecdsa in the wild, very wild 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, 04 Nov 2014 13:03:33 -0000 On 4/11/2014 11:47 am, Randy Bush wrote: > moving to newer protocols is such a simple and rigorous experience > > < with permission > > From: Geoff Huston > http://www.potaroo.net/presentations/2014-11-01-ecc.pdf If I read it right, which I probably don't, they measured a 23.6% ECDSA validation failure rate, apparently due to IPR issues. What I lack is the relevant starting point for ECDSA in DNS so we can estimate the circumference of the OODA loop. When did the RFC start work? When did it get out the gate? iang From nobody Tue Nov 4 06:42:43 2014 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 E1B991A8944 for ; Tue, 4 Nov 2014 06:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 loJMyhUzo82K for ; Tue, 4 Nov 2014 06:42:38 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) (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 94BF31A8928 for ; Tue, 4 Nov 2014 06:42:38 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:49023) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1XlfJb-0002rf-Yk (Exim 4.82_3-c0e5623) (return-path ); Tue, 04 Nov 2014 14:42:35 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1XlfJb-0000E1-NK (Exim 4.72) (return-path ); Tue, 04 Nov 2014 14:42:35 +0000 Date: Tue, 4 Nov 2014 14:42:35 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ianG In-Reply-To: <5458CE9D.9070603@iang.org> Message-ID: References: <61DC333A-CB55-4A3E-93A1-F5274F238223@apnic.net> <5458CE9D.9070603@iang.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/saag/s03ghh0lh4i3eGYOAhhM9wzbh-0 Cc: saag@ietf.org Subject: Re: [saag] dnssec with ecdsa in the wild, very wild 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, 04 Nov 2014 14:42:41 -0000 ianG wrote: > On 4/11/2014 11:47 am, Randy Bush wrote: > > > > < with permission > > > From: Geoff Huston > > http://www.potaroo.net/presentations/2014-11-01-ecc.pdf > > If I read it right, which I probably don't, they measured a 23.6% ECDSA > validation failure rate, apparently due to IPR issues. Most of that is correctly working lack of support for ECDSA, which is sad for us though not disruptive for the users. More worrying is the 1.6% of users whose resolvers apparently treated the domain as bogus. Tony. -- f.anthony.n.finch http://dotat.at/ Viking: Northeast 7 to severe gale 9 decreasing 5 or 6 later. Rough or very rough. Showers. Good. From nobody Tue Nov 4 07:55:20 2014 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 405621A8AB9 for ; Tue, 4 Nov 2014 07:55:18 -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] 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 u3-qrQeT6mNj for ; Tue, 4 Nov 2014 07:55:12 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935CC1A8ABB for ; Tue, 4 Nov 2014 07:55:12 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7D3C82AB04A; Tue, 4 Nov 2014 15:55:10 +0000 (UTC) Date: Tue, 4 Nov 2014 15:55:10 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20141104155510.GE23599@mournblade.imrryr.org> References: <61DC333A-CB55-4A3E-93A1-F5274F238223@apnic.net> <5458CE9D.9070603@iang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/z8kmS2FIQ1iJMRYG4_EDRic49-k Subject: Re: [saag] dnssec with ecdsa in the wild, very wild X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 04 Nov 2014 15:55:18 -0000 On Tue, Nov 04, 2014 at 02:42:35PM +0000, Tony Finch wrote: > ianG wrote: > > On 4/11/2014 11:47 am, Randy Bush wrote: > > > > > > < with permission > > > > From: Geoff Huston > > > http://www.potaroo.net/presentations/2014-11-01-ecc.pdf > > > > If I read it right, which I probably don't, they measured a 23.6% ECDSA > > validation failure rate, apparently due to IPR issues. > > Most of that is correctly working lack of support for ECDSA, which is sad > for us though not disruptive for the users. More worrying is the 1.6% of > users whose resolvers apparently treated the domain as bogus. FWIW, "unbound" versions without ECDSA support correctly treats such domains as unsigned. Also, for example, the DS RRs below are signed by .net and thus validated by Google's public resolver: $ dig +noall +comment +ans +ad -t ds .net @8.8.8.8 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39125 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; ANSWER SECTION: .net. 21571 IN DS 45769 14 2 69B3EB826977CEE1254AAC16A5EBA8F7703AE07FFA64975F8216374F E206FD59 .net. 21571 IN DS 51069 14 2 2B0D14AB811961026F12F0F469BBDFE6C5B19B20CEB13FC711D045A9 E8AAFD02 While the associated DNSKEY RR's are ECDSA signed, and not validated by Google's resolver. $ dig +noall +comment +ans +ad -t dnskey .net @8.8.8.8 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 216 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; ANSWER SECTION: .net. 3599 IN DNSKEY 256 3 14 eA6gtaxCmBSiMnvms3ikMHg2VzEFhc2sMWBPeEasBma71LE+JJEaWKts 3aidPjBiGrzwJxkS7PKhiUrI0v3OnSHq6WEr6QIaX/puxolbS56nrNGZ VTV7Mez3LxdCKtoR .net. 3599 IN DNSKEY 257 3 14 /MgAOGYW1xmzImUc72xPxBJoKXoya3RExpljghgSYtS/XlfRohY+xECL bEHtIil6FkdJvhzXeAkNVp6Lu4lxnDlOIIz8sLlxpkUHaDuWEQI0tEjn YjG7qgwElpbi4qc1 .net. 3599 IN DNSKEY 257 3 14 zOmrgji5nLGZ11t+p2tQVPDiHqybpIw6UsGWeRIHmcJjtIVEnaPrJbZA N1Nkup3tlLM05DUwnSRp35NTZUS4LnSa8wvQmdgOUjfpxJd9gq3l11vx SgPp3F6ocEXRxBH3 .net. 3599 IN DNSKEY 256 3 14 LPa2EbmvyTe3dxXPL4p6j+deQBG27yeN7w35lGIQkASzDXx9FLH+z5ML l2Wh+zAESkHOOeZxgGDRBEiksx7yJSQH9vZQ0xLYh4OSenOT2wj1q0tE OkLjgn73Avhw1E8F Bleeding edge deployments should also publish RSA/SHA1 or RSA/SHA256 keys along with the less widely implemented algorithm of their choice. Because DNSSEC key are published unilaterally, and not subject to interactive negotiation, the set of algorithms that are not yet deprecated needs to be kept relatively short at any given time, with clear guidance on which set "MUST" be supported by resolvers, and which are aspirational future "MUST"s as well as a set that are aspirational future "SHOULD NOT"s. Thus it seems we presently have a few algorithms too many, and should stop adding new ones until some of the older ones are retired. -- Viktor. From nobody Tue Nov 4 08:06:57 2014 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 7A0B41A8ADF for ; Tue, 4 Nov 2014 08:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 urVj0lgqT4JG for ; Tue, 4 Nov 2014 08:06:47 -0800 (PST) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B321A8AE3 for ; Tue, 4 Nov 2014 08:06:47 -0800 (PST) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 1640D6D87D; Tue, 4 Nov 2014 11:06:44 -0500 (EST) Message-ID: <5458F993.9050501@iang.org> Date: Tue, 04 Nov 2014 16:06:43 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <61DC333A-CB55-4A3E-93A1-F5274F238223@apnic.net> <5458CE9D.9070603@iang.org> <8357C889-E902-4A17-B3D7-3D1E1533EE23@apnic.net> In-Reply-To: <8357C889-E902-4A17-B3D7-3D1E1533EE23@apnic.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/KA133oWOvQoaKxfExrunnW1zliY Subject: [saag] OODA loops and why they are important to IETF security area 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, 04 Nov 2014 16:06:50 -0000 > I'm not familiar with the terminology you are using here so I cannot parse > "estimate the circumference of the OODA loop". Ah Apologies. Let me explain. The OODA loop is from Col. Boyd [0]: Observe, Orient, Decide, Act. Boyd was a post-WWII American military thinker who proposed that battle went through a response loop. His claim was that the fighter with the tighter loop could out turn the other, and win the day. His explanation resonated broadly, and his own work fed into the F16, being the smaller, lighter and tighter plane fielded in those days against heavier slower adversaries. The OODA loop turns out to apply broadly to many competitive and attack situations [1]. In Internet security, we can look at the way attackers evolve their attacks, and the hint seems to be that they can turn in the order of a month. In contrast, if the defender is stuck on standards-based, library-deployed responses, his OODA loop can be measured in years... Recently, we saw the renegotiation bug which I guessed at about a 3.5 year response to 80% deployment of fixes, whereas an exploit were demonstrated (not used) against Twitter within 2 months [2]. (I should also measure the response to Heartbleed and Poodle, but there aren't that many hours in the day, and winter is coming.) The IETF standards effort can be considered as responding to some of these threats to Internet security, and is part and parcel of why we have such a long OODA response loop. iang [0] http://financialcryptography.com/mt/archives/000991.html [1] https://en.wikipedia.org/wiki/OODA_loop [2] http://financialcryptography.com/mt/archives/001210.html From nobody Tue Nov 4 08:15:49 2014 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 1497A1A8FD7 for ; Tue, 4 Nov 2014 08:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] 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 UlkWxXFd1AqQ for ; Tue, 4 Nov 2014 08:15:44 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC041A8FD5 for ; Tue, 4 Nov 2014 08:15:44 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8E46D47570; Tue, 4 Nov 2014 16:15:43 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 74FB947562; Tue, 4 Nov 2014 16:15:43 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 709978004A; Tue, 4 Nov 2014 16:15:43 +0000 (GMT) Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 4 Nov 2014 11:15:42 -0500 Received: from USMBX1.msg.corp.akamai.com ([169.254.1.216]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Tue, 4 Nov 2014 11:15:42 -0500 From: "Salz, Rich" To: ianG , "saag@ietf.org" Date: Tue, 4 Nov 2014 11:15:41 -0500 Thread-Topic: [saag] POODLE in detail (was Re: NTP security, and thoughts on Hawaii) Thread-Index: Ac/4KznksFae6/HGQtabEpd/HAIF+AAHOOlg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D4F1CAD65@USMBX1.msg.corp.akamai.com> References: <5458C701.4070604@iang.org> In-Reply-To: <5458C701.4070604@iang.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Ko-C_Y-eKggFxmoG4Ixa-se3u6c Subject: Re: [saag] POODLE in detail (was Re: NTP security, and thoughts on Hawaii) 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, 04 Nov 2014 16:15:46 -0000 > I'm on a group of users called BetterCrypto.org. Here's their current > recommendation: First, I don't think you can blame the TLS WG for adding national ciphers t= o the protocol. It's a constant battle, apparently, but SEED GOST CAMELLIA,= etc., aren't the TLS group's fault. Once national politics got into it, th= ere's not much the IETF can do. Second, that cipher suite is, well, gross complicated and confusing. Also = not the TLS WG fault. Blame it on poor use of OpenSSL (and where you then d= ivide that blame isn't clear) if you must. I ran the list through 'openssl ciphers.' The ordering is strange, intermi= xing AES-GCM with AES and Camellia. I'd put AES-GCM first, and then drop C= amellia for simplicity. And then only list the algorithms I do want. Avoid= OpenSSL magic keywords that change meaning over time (like EXPORT or HIGH)= . Prefer ECDHE over DHE and perhaps allow RSA for legacy interop. That giv= es the following cipher list: ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256: \ ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256: \ ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA: \ DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256: \ DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256: \ DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA: \ AES256-SHA:AES128-SHA: Which is easy to understand and reason about. And yes, it requires explici= t reconfiguration to add new ciphers if and when desired. Given your oft-stated feelings on protocol flexibility, I am surprised you = didn't strongly argue against Camellia. Or did you just lose that fight? /r$ From nobody Tue Nov 4 09:12:26 2014 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 348A81A9240 for ; Tue, 4 Nov 2014 09:12:24 -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] 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 CyRbsSgt46zL for ; Tue, 4 Nov 2014 09:12:21 -0800 (PST) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C9B1A8ABF for ; Tue, 4 Nov 2014 09:12:21 -0800 (PST) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id F04B96D8DF; Tue, 4 Nov 2014 12:12:18 -0500 (EST) Message-ID: <545908F1.3050304@iang.org> Date: Tue, 04 Nov 2014 17:12:17 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Salz, Rich" , "saag@ietf.org" References: <5458C701.4070604@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D4F1CAD65@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D4F1CAD65@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/NT8oYsvQH_VuEeqRFmJvGITh1IY Cc: "ach@lists.cert.at List Mailing" Subject: Re: [saag] POODLE in detail (was Re: NTP security, and thoughts on Hawaii) 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, 04 Nov 2014 17:12:24 -0000 On 4/11/2014 16:15 pm, Salz, Rich wrote: >> I'm on a group of users called BetterCrypto.org. Here's their current >> recommendation: > > First, I don't think you can blame the TLS WG for adding national ciphers to the protocol. Yeah, but! No offense, picking up the devil's advocacy, here, but: This is exactly the sort of not-my-faultism that created the mess in the first place. It's always someone else's problem, someone else's fault. It's not us, it's the OpenSSL dullards / naive browser fools / criminal CAs / NSA devils / evil vendors / stupid effing users... > It's a constant battle, apparently, but SEED GOST CAMELLIA, etc., aren't the TLS group's fault. WG inherited the SSL system they got, so yes, algorithm vanity was in there before the group existed. But, they've shown no desire to remove this system. Indeed, they've shown the reverse: we all know that complexity in general and multiple algorithms in particular [0] are a crock, yet the WG promotes the ability to add in more insecurity. > Once national politics got into it, there's not much the IETF can do. Where in the IETF charter or the WG charter does it say, "and we pander to national politics?" Surely, the role of the IETF security area is to deliver protocols *that secure the users*. Correct me if I'm wrong, but surely the role of the IETF is *NOT* to fall to one or other of the various interest groups that might claim a special status? Or is it? Correct me if I'm wrong? Who does the IETF serve? Why am I here? Why are you here? > Second, that cipher suite is, well, gross complicated and confusing. That is the point: that's an expert group of users, as good as it gets. It's turtles down from there. > Also not the TLS WG fault. Blame it on poor use of OpenSSL (and where you then divide that blame isn't clear) if you must. TLS WG can solve that with a single decision in its next release: there is one cipher suite, and it is numbered Number 1. Can you really shift the blame to OpenSSL and others when the WG walks blindfolded & backwards in security history and hands them a system that isn't possible to secure? > I ran the list through 'openssl ciphers.' The ordering is strange, intermixing AES-GCM with AES and Camellia. I'd put AES-GCM first, and then drop Camellia for simplicity. And then only list the algorithms I do want. Avoid OpenSSL magic keywords that change meaning over time (like EXPORT or HIGH). Prefer ECDHE over DHE and perhaps allow RSA for legacy interop. That gives the following cipher list: > ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256: \ > ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256: \ > ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA: \ > DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256: \ > DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256: \ > DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA: \ > AES256-SHA:AES128-SHA: > Which is easy to understand and reason about. And yes, it requires explicit reconfiguration to add new ciphers if and when desired. I've cc'd the ach group, so they can look at your proposal. > Given your oft-stated feelings on protocol flexibility, I am surprised you didn't strongly argue against Camellia. Or did you just lose that fight? :) I lost that fight, big time. But rest assured, I won't forget ... iang [0] If you disagree that multiple algorithms are the worst possible idea, then read it this way: "other algorithms than my favourite..." From nobody Tue Nov 4 10:28:24 2014 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 6A4F01A1A14 for ; Tue, 4 Nov 2014 10:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 IAaGoxazKmOP for ; Tue, 4 Nov 2014 10:28:21 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFEA11A1B9B for ; Tue, 4 Nov 2014 10:28:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1415125701; x=1446661701; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=aM4StlX99tMZ2mDMHkJiwGzNQxrmnswFxn4/tWP17j4=; b=qXo7esQDc0gZFWftUP9wY9vbVwqSj37wjoQGcIX1eX/gf9EcZLAuuFe8 KC5q8q8AKrnO1whnFO1Itk/+LvNWaAeP41q79+ZaI3u+X1cVmATGpMXce UNzwLrVMxzi0iR5D2bQCJgNZnApB6xAQq2i8UpsfOqd6ouea6AzI88KXe Q=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="287662628" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 05 Nov 2014 07:28:18 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 5 Nov 2014 07:28:18 +1300 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] NTP security, and thoughts on Hawaii Thread-Index: Ac/4XRpJxYglJJsTTBmEC/ZUkd4Yaw== Date: Tue, 4 Nov 2014 18:28:17 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DFC54@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/JMNuAaobReece3lCv5vMJHHVbOY Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 04 Nov 2014 18:28:23 -0000 Tony Finch writes:=0A= =0A= >The point is not to help experts get the time securely in a managed=0A= >environment: NTPsec already suffices. =0A= =0A= Oh don't be such a wimp, tell them to get a surplus 5680 rubidium clock off= =0A= eBay for $150, discipline it with a GPS signal, and run their own reference= =0A= clock. Users expect far too much handholding these days.=0A= =0A= (Just remember to have them turn it upside down if they're in the antipodes= or=0A= it won't start).=0A= =0A= Peter :-).= From nobody Tue Nov 4 10:33:47 2014 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 21BDD1A1A17 for ; Tue, 4 Nov 2014 10:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 sjwAgKgo8Qtj for ; Tue, 4 Nov 2014 10:33:45 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857FD1A1B61 for ; Tue, 4 Nov 2014 10:33:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1415126025; x=1446662025; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=f/EelM59QXzJkNdLCWL60/DYameW9DjeA4jRmkTGR8A=; b=akaIvJ+khAi3eHt6JNtabC3FPtRpkDx3ZUwFW/szCVCjj8N+RG8SQ6dc HHvN22wR2v5DcDBZCUK465N5Aj6DYxylCUCOPFXonTXr1NNcou8DuIiWq VEuTa/3QiSxJ0tB7I1uEmj03CigSEOVxglqaSNgY3VzqsMjhjge3BiIPd 4=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="287663188" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 05 Nov 2014 07:33:43 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Wed, 5 Nov 2014 07:33:42 +1300 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] POODLE in detail (was Re: NTP security, and thoughts on Hawaii) Thread-Index: Ac/4Xdr0cDpwfClyTK2HF+n+2xRC9g== Date: Tue, 4 Nov 2014 18:33:40 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DFC69@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/g1qyjKtrYgrqeSEEpn_c9-aJMGw Subject: Re: [saag] POODLE in detail (was Re: NTP security, and thoughts on Hawaii) 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, 04 Nov 2014 18:33:46 -0000 ianG writes:=0A= >On 4/11/2014 08:09 am, Yoav Nir wrote:=0A= >> I think this has little to do with the TLS working group. ...=0A= >> Whether the market will use them is up to the market, not us.=0A= >=0A= >That may be the way IETF thinks. Meanwhile, there are great swathes of=0A= >industry that think this way:=0A= >[...]=0A= =0A= Not all of industry thinks this way, see e.g.=0A= http://techblog.netflix.com/2014/10/message-security-layer-modern-take-on.h= tml.=0A= =0A= (While I agree with their reasoning, they then go off into the weeds and=0A= decide to invent their own security protocol rather than just taking TLS an= d=0A= throwing out the PKI stuff that's causing them all the pain).=0A= =0A= Interesting challenge for the TLS WG: What would you say to these guys to g= et=0A= them to go with TLS 1.3 rather than inventing their own protocol? These ar= e=0A= serious, major scale users who aren't brower vendors or Google, what's in i= t=0A= for them? Sell me this pen^H^H^Hprotocol.=0A= =0A= Peter.= From nobody Tue Nov 4 11:58:02 2014 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 561B31ACE3C for ; Tue, 4 Nov 2014 11:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 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, GB_I_LETTER=-2, 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 lFra6oySNfx8 for ; Tue, 4 Nov 2014 11:57:55 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6771A7013 for ; Tue, 4 Nov 2014 11:57:54 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id b13so14148305wgh.26 for ; Tue, 04 Nov 2014 11:57:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M5+iGERWC3kDgKJxzMAbq9jvj38FTGZKU0Jy8Elmm9k=; b=yuUdIj5eN550pmial/CfDHtBq9jZlqcxTddfT4kTf1dmDE2UDNpedBdEByIghTWdAX /Nf02dZmLbybsCJe35UjMPcf1on6BUAINHTLKcMHiOv8bvjUuGFAz44/nGW1p7vd0OJC cWMBze5HUqFZDnpiAoGv7fg16cNVWkTdcAFoqTixTOtNg280NcME3GYGfgJR96g6xRuX Z0wudO1CiHqVlOOlcLbLK6B8FXHLQ8LGwg44Bg1RUyME/Rqb99dw0UiPgErYpk2VAUrw GqfjiTuJjXEBZN1xiqFYYc3QISK+f0y+VOn00HVV+Hu0JLa3qusU96i79WlOGSRk0OJw KU2Q== X-Received: by 10.194.240.68 with SMTP id vy4mr59837086wjc.36.1415131073114; Tue, 04 Nov 2014 11:57:53 -0800 (PST) Received: from [192.168.1.103] (IGLD-84-228-87-161.inter.net.il. [84.228.87.161]) by mx.google.com with ESMTPSA id pn4sm1611915wjc.38.2014.11.04.11.57.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Nov 2014 11:57:52 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: <545908F1.3050304@iang.org> Date: Tue, 4 Nov 2014 21:57:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7976425F-FC0E-4E33-9D01-F0D94B4E0A9E@gmail.com> References: <5458C701.4070604@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D4F1CAD65@USMBX1.msg.corp.akamai.com> <545908F1.3050304@iang.org> To: ianG X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/7fEGjJqkRWlkD887lqfB371zcQw Cc: "saag@ietf.org" Subject: Re: [saag] POODLE in detail (was Re: NTP security, and thoughts on Hawaii) 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, 04 Nov 2014 19:57:58 -0000 > On Nov 4, 2014, at 7:12 PM, ianG wrote: >=20 >> It's a constant battle, apparently, but SEED GOST CAMELLIA, etc., = aren't the TLS group's fault. I don=E2=80=99t think it=E2=80=99s a fault at all. > WG inherited the SSL system they got, so yes, algorithm vanity was in > there before the group existed. >=20 > But, they've shown no desire to remove this system. Indeed, they've > shown the reverse: we all know that complexity in general and = multiple > algorithms in particular [0] are a crock, yet the WG promotes the > ability to add in more insecurity. Complexity is bad, but having a bunch of extra ciphersuites that you are = not required to support is not the kind of complexity that causes pain. >> Once national politics got into it, there's not much the IETF can do. >=20 >=20 > Where in the IETF charter or the WG charter does it say, "and we = pander > to national politics?=E2=80=9D It=E2=80=99s in the second letter - Engineering. Engineers build things = to meet requirements. Russian Internet users are required to use GOST = for certain things. A TLS or IPsec that didn=E2=80=99t allow the use of = GOST would not meet their requirements. It doesn=E2=80=99t matter what = we think about the requirements. Fortunately, it=E2=80=99s fairly easy = to not support GOST or Camelia or whatever. . > Surely, the role of the IETF security area is to deliver protocols = *that > secure the users*. >=20 > Correct me if I'm wrong, but surely the role of the IETF is *NOT* to > fall to one or other of the various interest groups that might claim a > special status? >=20 > Or is it? Correct me if I'm wrong? Who does the IETF serve? Why am = I > here? Why are you here? To make protocols that are useful to all Internet users? >> Second, that cipher suite is, well, gross complicated and confusing. >=20 >=20 > That is the point: that's an expert group of users, as good as it = gets. > It's turtles down from there. >=20 >=20 >> Also not the TLS WG fault. Blame it on poor use of OpenSSL (and where = you then divide that blame isn't clear) if you must. >=20 >=20 > TLS WG can solve that with a single decision in its next release: >=20 > there is one cipher suite, and it is numbered Number 1. There are different needs and different environments. Do you really want = the lowest common denominator as the one and only ciphersuite? You know = that it=E2=80=99s going to be defined by the weakest smartobject.=20 > Can you really shift the blame to OpenSSL and others when the WG walks > blindfolded & backwards in security history and hands them a system = that > isn't possible to secure? What do you mean =E2=80=9Cimpossible to secure=E2=80=9D ? Banks, = government agencies, and vendors make trillions of dollars in = transactions protected by TLS and IPsec. They lose no money in attacks = that have anything to do with breaking the crypto. That is by far the = most solid link in the chain of securing both privacy and commerce. From nobody Tue Nov 4 12:47:15 2014 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 4C1321ACEDD for ; Tue, 4 Nov 2014 12:47:12 -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, 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 EiiJp7RHiema for ; Tue, 4 Nov 2014 12:47:09 -0800 (PST) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5936B1A7025 for ; Tue, 4 Nov 2014 12:47:09 -0800 (PST) Received: by mail-qg0-f53.google.com with SMTP id z107so11032143qgd.40 for ; Tue, 04 Nov 2014 12:47:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=n82PaRmXAQx+N1kLJjRZNj9ydAOrMwr4D8wx19tDb5s=; b=xpWjnfsiApIryZHBD3lJ3tTkN1OJo3ZG+xbqr98CWkT++dc6biI6mkJugZd8DPKlaI XXorOAttJIEyHQ0nPbHyffc7SXS4+cPmG/5EfflZR9wco/zu8PDf6VPWk9Qu9GVBcclV ViDCQPJ1FXhixravyL4XYdEIWNOdkHHKn60f8hg7lk9Lg0SbGysf9rV1PkZXF1jRJO0d /rV6MhHGiJu39iC3PhfpVvuIMY9Mds0jKydbGdXFUD4eHXot+h3WFeFgGKAetbhFuVwa XZUO2IVNAGbW0bQrf8TlkmKScK3r/7NnAeDN8wgEmAOGSSI9PoYS5HgZWqe9XxC4JSfK tSow== X-Received: by 10.224.34.73 with SMTP id k9mr2947395qad.33.1415134028452; Tue, 04 Nov 2014 12:47:08 -0800 (PST) Received: from nomad.local (ip-94-112-138-148.net.upcbroadband.cz. [94.112.138.148]) by mx.google.com with ESMTPSA id w8sm1328714qag.2.2014.11.04.12.47.07 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 04 Nov 2014 12:47:07 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <1415134025.22936.5.camel@nomad.lan> From: Nikos Mavrogiannopoulos To: "Salz, Rich" Date: Tue, 04 Nov 2014 21:47:05 +0100 In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D4F1CAD65@USMBX1.msg.corp.akamai.com> References: <5458C701.4070604@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D4F1CAD65@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.2-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/12M0hFltE97aUbYKVknC_xkyxI8 Cc: "saag@ietf.org" Subject: Re: [saag] POODLE in detail (was Re: NTP security, and thoughts on Hawaii) 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, 04 Nov 2014 20:47:12 -0000 On Tue, 2014-11-04 at 11:15 -0500, Salz, Rich wrote: > > I'm on a group of users called BetterCrypto.org. Here's their current > > recommendation: > > First, I don't think you can blame the TLS WG for adding national ciphers to the protocol. It's a constant battle, apparently, but SEED GOST CAMELLIA, etc., aren't the TLS group's fault. Once national politics got into it, there's not much the IETF can do. On the contrary. National ciphers are all we got so far, because crypto competitions are expensive and only big nations can organize it (AES was US NIST's competition, Camellia was EU ECRYPT's competition, GOST was USSR's cipher). Why should they US national ciphers (AES+3DES) monopolize IETF, and disallow other national ciphers? Having Camellia defined for TLS was a very good thing. regards, Nikos From nobody Tue Nov 4 12:52:10 2014 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 8BE2B1ACEEB for ; Tue, 4 Nov 2014 12:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 N4dQTNODgoFv for ; Tue, 4 Nov 2014 12:52:02 -0800 (PST) Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3A11ACEF3 for ; Tue, 4 Nov 2014 12:52:02 -0800 (PST) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id E319220047B89 for ; Tue, 4 Nov 2014 12:52:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=85FioJsx4DJsggTSHEXd 3Drfo3g=; b=mV5vVE6bL79u4gTxVbFRV60rAR3xwuZXBh2Pg6/GDtdMW5J/ImgD t2dC1hQBUcDWKM2X+ZowaNxacnKw3yYYqJ8AEg1FPIkIZSLBFLluxyn+aGFoQI2n 9mIq/BtBXxru5e4HFjGq5E+Kcykfe6LsPeHwLKd43MoBnGzenN6tBoE= Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPSA id 988E820047B87 for ; Tue, 4 Nov 2014 12:52:01 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id q5so9752246wiv.3 for ; Tue, 04 Nov 2014 12:52:00 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.100.129 with SMTP id ey1mr510113wib.28.1415134320347; Tue, 04 Nov 2014 12:52:00 -0800 (PST) Received: by 10.216.32.135 with HTTP; Tue, 4 Nov 2014 12:52:00 -0800 (PST) In-Reply-To: <1415134025.22936.5.camel@nomad.lan> References: <5458C701.4070604@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D4F1CAD65@USMBX1.msg.corp.akamai.com> <1415134025.22936.5.camel@nomad.lan> Date: Tue, 4 Nov 2014 14:52:00 -0600 Message-ID: From: Nico Williams To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Sp5DmlHHxpoERPQgR_XDYKNhUpM Cc: "saag@ietf.org" Subject: Re: [saag] POODLE in detail (was Re: NTP security, and thoughts on Hawaii) 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, 04 Nov 2014 20:52:02 -0000 The argument about national ciphers seems OT to me. The IETF does not keep out non-U.S. ciphers. The IETF insists on a small required-to-implement profile. That's all. Nico -- From nobody Tue Nov 4 13:07:25 2014 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 4D54E1A0004 for ; Tue, 4 Nov 2014 13:07:23 -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, 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 5_nKY6ti32Fi for ; Tue, 4 Nov 2014 13:07:21 -0800 (PST) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339AF1ACEE3 for ; Tue, 4 Nov 2014 13:07:21 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id u7so10283171qaz.25 for ; Tue, 04 Nov 2014 13:07:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:subject:from:to:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=cOi8+rUSOU+cpBAr9q5PLmaiAwYcK+OCQ5qXbIMrPpM=; b=bKKGntw1PUJ9KkXzPumoSFskBgfg2zJzbLUkAzdE7Ttj0nhOMzeekJTe6GOJNRyx9X zVvlUxbSxhs5AJ3Bs0a56K4u/WNPQXWi201DPZhT3gfWuoTLlirNFFUOTwV5xPXtAQCy b7nwCPIoDk0PxopHucQJ7zaUG3u4zODWn73h2dlZhxgPG2IujeK7wL4mL5vL2lYKrje6 9q99YXDfhjus5eB0FtgCoJvJE+ekznjA0KvpYxrbjssEPgNL5gdmFwmWZ8Sel/zWNz2d VOqIhQZPo0JTEAtGYFw9deOkCFI84hH77nZo+gGhO4h3GNtlNeII59ugoHCABXvOdlyb DDGQ== X-Received: by 10.140.48.233 with SMTP id o96mr64327053qga.47.1415135240373; Tue, 04 Nov 2014 13:07:20 -0800 (PST) Received: from nomad.local (ip-94-112-138-148.net.upcbroadband.cz. [94.112.138.148]) by mx.google.com with ESMTPSA id w66sm1337475qgw.44.2014.11.04.13.07.19 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 04 Nov 2014 13:07:19 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <1415135237.22936.12.camel@nomad.lan> From: Nikos Mavrogiannopoulos To: "saag@ietf.org" Date: Tue, 04 Nov 2014 22:07:17 +0100 In-Reply-To: <1415134025.22936.5.camel@nomad.lan> References: <5458C701.4070604@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D4F1CAD65@USMBX1.msg.corp.akamai.com> <1415134025.22936.5.camel@nomad.lan> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.2-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/6MDekJ7aYrffwLg1K5rxTo8kO0s Subject: Re: [saag] POODLE in detail (was Re: NTP security, and thoughts on Hawaii) 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, 04 Nov 2014 21:07:23 -0000 On Tue, 2014-11-04 at 21:47 +0100, Nikos Mavrogiannopoulos wrote: > On Tue, 2014-11-04 at 11:15 -0500, Salz, Rich wrote: > > > I'm on a group of users called BetterCrypto.org. Here's their current > > > recommendation: > > > > First, I don't think you can blame the TLS WG for adding national ciphers to the protocol. It's a constant battle, apparently, but SEED GOST CAMELLIA, etc., aren't the TLS group's fault. Once national politics got into it, there's not much the IETF can do. > > On the contrary. National ciphers are all we got so far, because crypto > competitions are expensive and only big nations can organize it (AES was > US NIST's competition, Camellia was EU ECRYPT's competition, To correct myself. Camellia was a winner of the EU's Nessie [0] competition and Japan's cryptrec. Not ECRYPT (thanks to Kenny Paterson for noticing). regards, Nikos [0]. https://en.wikipedia.org/wiki/NESSIE [1]. https://en.wikipedia.org/wiki/CRYPTREC From nobody Wed Nov 5 04:35:09 2014 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 BD69B1A887A for ; Wed, 5 Nov 2014 04:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, LOTS_OF_MONEY=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 v1WJfkY5O2PE for ; Wed, 5 Nov 2014 04:35:04 -0800 (PST) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5F11A8879 for ; Wed, 5 Nov 2014 04:35:03 -0800 (PST) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 81E136D8B9; Wed, 5 Nov 2014 07:35:00 -0500 (EST) Message-ID: <545A1973.1060704@iang.org> Date: Wed, 05 Nov 2014 12:34:59 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yoav Nir References: <5458C701.4070604@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D4F1CAD65@USMBX1.msg.corp.akamai.com> <545908F1.3050304@iang.org> <7976425F-FC0E-4E33-9D01-F0D94B4E0A9E@gmail.com> In-Reply-To: <7976425F-FC0E-4E33-9D01-F0D94B4E0A9E@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/YNP4erQQyi26Nf6skLMnqHgUFE0 Cc: "saag@ietf.org" Subject: Re: [saag] POODLE in detail (was Re: NTP security, and thoughts on Hawaii) 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, 05 Nov 2014 12:35:07 -0000 On 4/11/2014 19:57 pm, Yoav Nir wrote: > >> On Nov 4, 2014, at 7:12 PM, ianG wrote: >> >>> It's a constant battle, apparently, but SEED GOST CAMELLIA, etc., aren't the TLS group's fault. > > I don’t think it’s a fault at all. I also don't think it helps to "allocate blame." Far better to think about what we can do fix the situation. >> WG inherited the SSL system they got, so yes, algorithm vanity was in >> there before the group existed. >> >> But, they've shown no desire to remove this system. Indeed, they've >> shown the reverse: we all know that complexity in general and multiple >> algorithms in particular [0] are a crock, yet the WG promotes the >> ability to add in more insecurity. > > Complexity is bad, but having a bunch of extra ciphersuites that you are not required to support is not the kind of complexity that causes pain. What a browser needs to support and what a server needs to support is the crux of this argument. Have a look at that very tight apache config in prior posts which Rich critiqued, evidence that browsers and servers *are required to serve those things* even though they have no benefit. What legitimate benefit is gained from any of them other than the first (or last)? Yet, I can faithfully claim that the creation of that BetterCrypto apache config ran into order of man-months over the last 2 years. Huh? Just the string? That's complexity. Equals loss. Just configuring the string represents utter loss for no benefit to users. >>> Once national politics got into it, there's not much the IETF can do. >> >> >> Where in the IETF charter or the WG charter does it say, "and we pander >> to national politics?†> > It’s in the second letter - Engineering. Engineers build things to meet requirements. Russian Internet users are required to use GOST for certain things. A TLS or IPsec that didn’t allow the use of GOST would not meet their requirements. It doesn’t matter what we think about the requirements. Fortunately, it’s fairly easy to not support GOST or Camelia or whatever. . The NSA requires backdoors. GCHQ demand them [0]. So by extension, it doesn't matter what we think, American and British engineers are required to insert them into IETF protocols. Or? >> Surely, the role of the IETF security area is to deliver protocols *that >> secure the users*. >> >> Correct me if I'm wrong, but surely the role of the IETF is *NOT* to >> fall to one or other of the various interest groups that might claim a >> special status? >> >> Or is it? Correct me if I'm wrong? Who does the IETF serve? Why am I >> here? Why are you here? > > To make protocols that are useful to all Internet users? Yes. >>> Second, that cipher suite is, well, gross complicated and confusing. >> >> >> That is the point: that's an expert group of users, as good as it gets. >> It's turtles down from there. >> >> >>> Also not the TLS WG fault. Blame it on poor use of OpenSSL (and where you then divide that blame isn't clear) if you must. >> >> >> TLS WG can solve that with a single decision in its next release: >> >> there is one cipher suite, and it is numbered Number 1. > > There are different needs and different environments. Do you really want the lowest common denominator as the one and only ciphersuite? You know that it’s going to be defined by the weakest smartobject. I think the problem here is that nobody's ever been asked to pick one generally good ciphersuite. BTW, what are these different needs and environments? What wouldn't say chacha20/poly1305 whip, which is the informal, consensual standard of the day? >> Can you really shift the blame to OpenSSL and others when the WG walks >> blindfolded & backwards in security history and hands them a system that >> isn't possible to secure? > > What do you mean “impossible to secure†? There are probably a million sysadms out there that install SSL on an "install, copy a config from a mate, move on" basis. They probably have to manage o(100) packages. They have no time for anything that requires detailed knowledge and configuration. As the vast majority of them are likely to make basic mistakes, it is therefore approximately impossible to secure, in the aggregate. You might be thinking that "impossible to secure" can be easily shown in lab conditions to be wrong; but lab conditions aren't the benchmark. What the average sysadm does, is. > Banks, government agencies, and vendors make trillions of dollars in transactions protected by TLS and IPsec. Nah. Banks, government agencies, vendors make trillions of dollars by using transaction systems that are *reversible*. Bitcoin OTOH moves money without reversibility, and it's currently in the process of removing openssl, because it's ... impossible to use securely. Indeed, it was directly implicated in a lost money situation, albeit the PRNG not the encryption. > They lose no money in attacks that have anything to do with breaking the crypto. Indeed. But that's because they have easier ways to lose money. Security is a relative game, the crypto is by far the strongest thing we have. > That is by far the most solid link in the chain of securing both privacy and commerce. Right. Agreed. Except, the recent Heartbleed event was by one count a cost of $500m. Since 2011, the attack profile has shifted up a notch, and software is under attack more pervasively. Which is not to say that any one particular product is bad, but it is to say that the easy game over the last 2 decades is over. Every time here is a big breach, we'll likely find it is because we're using software that is at least a decade old, probably deprecated and probably with known bugs in it. What part does the IETF play in this question? None, as of right now. It's still in throw-it-over-the-wall mode. Time to tear the wall down? iang [0] "The web is a terrorist’s command-and-control network of choice" Robert Hannigan GCHQ and its sister agencies, MI5 and the Secret Intelligence Service, cannot tackle these challenges at scale without greater support from the private sector, including the largest US technology companies which dominate the web. I understand why they have an uneasy relationship with governments. They aspire to be neutral conduits of data and to sit outside or above politics. But increasingly their services not only host the material of violent extremism or child exploitation, but are the routes for the facilitation of crime and terrorism. However much they may dislike it, they have become the command-and-control networks of choice for terrorists and criminals, who find their services as transformational as the rest of us. If they are to meet this challenge, it means coming up with better arrangements for facilitating lawful investigation by security and law enforcement agencies than we have now. http://www.ft.com/cms/s/2/c89b6c58-6342-11e4-8a63-00144feabdc0.html From nobody Wed Nov 5 16:29:18 2014 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 363821A1A3F for ; Wed, 5 Nov 2014 16:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 FRAykEunX5Vi for ; Wed, 5 Nov 2014 16:29:16 -0800 (PST) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [67.18.62.18]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBCE21A1A3E for ; Wed, 5 Nov 2014 16:29:15 -0800 (PST) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 591852D0AEE0F; Wed, 5 Nov 2014 18:29:15 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 495A02D0AEDCB for ; Wed, 5 Nov 2014 18:29:15 -0600 (CST) Received: from [173.73.121.234] (port=53946 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XmAws-0004sF-IU; Wed, 05 Nov 2014 18:29:14 -0600 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <544D14C8.4070604@seantek.com> Date: Wed, 5 Nov 2014 19:29:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1557541F-A60F-430B-8C6C-BA5474538C79@ieca.com> References: <540E0A56.7060301@seantek.com> <544D14C8.4070604@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.121.234 X-Exim-ID: 1XmAws-0004sF-IU X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [173.73.121.234]:53946 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/saag/VsffnwiXYCd0-2B7D-OWiOzkgE0 Cc: pkix@ietf.org, saag@ietf.org Subject: Re: [saag] [pkix] New Version Notification for draft-seantek-certfrag-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, 06 Nov 2014 00:29:17 -0000 Seems like a reasonable way to do what you=92re trying to do, but I=92ve = got two questions: 1) Do you really, really need the MUST? If an implementation doesn=92t = follow the rules and instead uses =93sN=94 for the serial number = fragment it=92s still going to work right because they=92re = case-insensitive? If that=92s the case then maybe you could just drop = that bit. 2) The second part of the text in the security considerations gave me = pause: A certificate displaying application might zoom in on that aspect of the certificate, while a public key-processing application might use a fragment identifier like "#spki" to extract the "SubjectPublicKeyInfo" structure for further processing.=20 Are you saying the spki would be extracted for processing from the = identifier or from the certificate? I=92m hoping the later. spt On Oct 26, 2014, at 11:35, Sean Leonard wrote: > Just wanted to follow up on this request for feedback/review for = draft-seantek-certfrag, which defines fragment identifiers for = certificates. >=20 > This is a short draft (just four pages--and the fourth page is just = the author info). If you read it and don't find any issues, please let = me know as well. >=20 > Thanks, >=20 > Sean >=20 > On 9/8/2014 12:58 PM, Sean Leonard wrote: >=20 > Hello PKIX and SAAG lists: >=20 > Based on discussions had at IETF 90, I have written up a new = Internet-Draft to define URI fragment identifiers for certificates. The = proposal is very simple, as there are only a limited number of = well-defined PKIX certificate parts. >=20 > This text is a spinoff of draft-seantek-certspec, since the fragment = definitions depend on the media type (application/pkix-cert), not on the = URI scheme or other parts. >=20 > Feedback is appreciated. >=20 > Sean >=20 > ************************* >=20 > A new version of I-D, draft-seantek-certfrag-00.txt > has been successfully submitted by Sean Leonard and posted to the > IETF repository. >=20 > Name: draft-seantek-certfrag > Revision: 00 > Title: URI Fragment Identifiers for the application/pkix-cert = Media Type > Document date: 2014-09-08 > Group: Individual Submission > Pages: 4 > URL: http://www.ietf.org/internet-drafts/draft-seantek-certfrag-00.txt > Status: https://datatracker.ietf.org/doc/draft-seantek-certfrag/ > Htmlized: http://tools.ietf.org/html/draft-seantek-certfrag-00 >=20 >=20 > Abstract: > This memo describes Uniform Resource Identifier (URI) fragment > identifiers for PKIX certificates, which are identified with the > Internet media type application/pkix-cert. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From nobody Thu Nov 6 00:15:21 2014 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 4ACAE1A1A94; Thu, 6 Nov 2014 00:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 odWTwR4nsUPK; Thu, 6 Nov 2014 00:14:59 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F36A1A1A64; Thu, 6 Nov 2014 00:14:57 -0800 (PST) Received: from [192.168.123.119] (unknown [23.240.242.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 41E50509B6; Thu, 6 Nov 2014 03:14:54 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_233C98B8-5DBC-45A4-B89E-5585AE401805"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <1557541F-A60F-430B-8C6C-BA5474538C79@ieca.com> Date: Thu, 6 Nov 2014 00:13:50 -0800 Message-Id: References: <540E0A56.7060301@seantek.com> <544D14C8.4070604@seantek.com> <1557541F-A60F-430B-8C6C-BA5474538C79@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4pdULipXX6636W5XtvEznAL1V6M Cc: pkix@ietf.org, saag@ietf.org Subject: Re: [saag] [pkix] New Version Notification for draft-seantek-certfrag-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, 06 Nov 2014 08:15:20 -0000 --Apple-Mail=_233C98B8-5DBC-45A4-B89E-5585AE401805 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 5, 2014, at 4:29 PM, Sean Turner wrote: > Seems like a reasonable way to do what you=92re trying to do, but I=92ve= got two questions: >=20 > 1) Do you really, really need the MUST? If an implementation doesn=92t = follow the rules and instead uses =93sN=94 for the serial number = fragment it=92s still going to work right because they=92re = case-insensitive? If that=92s the case then maybe you could just drop = that bit. Okay, maybe =93MUST=94 is unduly harsh. However, I like to have = consistent casing, even though it is case-insensitive. Is =93SHOULD=94 = appropriate? If not, I can drop the RFC 2119 key word and simply say = =93The fragments defined in the table above are case-insensitive; = nevertheless for consistency, a generator is supposed to produce the = fragment identifiers with the same casing as provided in this memo.=94 >=20 > 2) The second part of the text in the security considerations gave me = pause: >=20 > A certificate displaying > application might zoom in on that aspect of the certificate, while a > public key-processing application might use a fragment identifier > like "#spki" to extract the "SubjectPublicKeyInfo" structure for > further processing.=20 >=20 > Are you saying the spki would be extracted for processing from the = identifier or from the certificate? I=92m hoping the later. It=92s the certificate. Proposed revised text: A certificate displaying application might zoom in on that aspect of the certificate, while a public key-processing application might use a fragment identifier like "#spki" to extract the "SubjectPublicKeyInfo=94 structure from the certificate for further processing. Sean --Apple-Mail=_233C98B8-5DBC-45A4-B89E-5585AE401805 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO7TCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqT PDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTMxMTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J 9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2g uKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G 53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia33JN+ oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50 ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMf WE2/5myX518DB+kTa5iQDbKYRuJp3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmI H4kfI4LWrY8XrPhlX3JmHjD6hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3 jx9VF/gA3vqYpL+jNumInz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d 9ljRDEiAts5OopkeeFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYID rjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MTEwNjA4MTQ1M1owIwYJKoZIhvcNAQkEMRYEFIrWlzjyT4F9nUmmZlhF0Anx VqaoMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQDKkzwxu6lupsyQvhKSvQd8MIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEBBQAE ggEAsWnLtV7WOnjoXM+FO0jzc9GPUl3gss+RLIzb9xwwzEXxgicjsFsanSGvR3dNoI7sHUZoioiv YVAA7/uAMmbzyk56VLtnk3UXZLmxXYLq8tdMZEsGe1H6h5G5fQ1VGJ56ODJndngJA61cyj/D2z7l y+iCx7tHE51CTJTLqvonrEhoNiCg1Qu+kaQoAJsN6v3RkN4EtuaVGnuTUwSk7kSLazr0lLty/9Wp JHhsnbhNdt9MZ0I64k/R9f/ffA/875ZJPPrYoG+sday2nttWNrqNwtJhnbNcjhVOzYwkamHZzaYp SnEJWPnOIVdDffm9GaaAvmSLKtiHZgTjtw/VZAdrEAAAAAAAAA== --Apple-Mail=_233C98B8-5DBC-45A4-B89E-5585AE401805-- From nobody Thu Nov 6 10:36:35 2014 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 3E3A21A89FC for ; Thu, 6 Nov 2014 10:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 U7DjA5EYmQ5u for ; Thu, 6 Nov 2014 10:36:33 -0800 (PST) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [69.56.148.5]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC711A89F9 for ; Thu, 6 Nov 2014 10:36:32 -0800 (PST) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 4CE6FEB075B6; Thu, 6 Nov 2014 12:36:32 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 270BDEB0750D for ; Thu, 6 Nov 2014 12:36:32 -0600 (CST) Received: from [173.73.121.234] (port=52186 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XmRv5-0001Jx-8r; Thu, 06 Nov 2014 12:36:31 -0600 Content-Type: multipart/signed; boundary="Apple-Mail=_330984D1-6328-4D56-84C6-62CFEB8691B6"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Thu, 6 Nov 2014 13:36:32 -0500 Message-Id: <0A4F75A3-59E3-4953-AE0F-E77758B21ED6@ieca.com> References: <540E0A56.7060301@seantek.com> <544D14C8.4070604@seantek.com> <1557541F-A60F-430B-8C6C-BA5474538C79@ieca.com> To: Sean Leonard X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.121.234 X-Exim-ID: 1XmRv5-0001Jx-8r X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [173.73.121.234]:52186 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/saag/uRtnOtz6EvE4O9zj1GvHYnF5LwM Cc: pkix@ietf.org, saag@ietf.org Subject: Re: [saag] [pkix] New Version Notification for draft-seantek-certfrag-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, 06 Nov 2014 18:36:34 -0000 --Apple-Mail=_330984D1-6328-4D56-84C6-62CFEB8691B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 06, 2014, at 03:13, Sean Leonard wrote: >=20 > On Nov 5, 2014, at 4:29 PM, Sean Turner wrote: >=20 >> Seems like a reasonable way to do what you=92re trying to do, but = I=92ve got two questions: >>=20 >> 1) Do you really, really need the MUST? If an implementation doesn=92t= follow the rules and instead uses =93sN=94 for the serial number = fragment it=92s still going to work right because they=92re = case-insensitive? If that=92s the case then maybe you could just drop = that bit. >=20 > Okay, maybe =93MUST=94 is unduly harsh. However, I like to have = consistent casing, even though it is case-insensitive. Is =93SHOULD=94 = appropriate? If not, I can drop the RFC 2119 key word and simply say = =93The fragments defined in the table above are case-insensitive; = nevertheless for consistency, a generator is supposed to produce the = fragment identifiers with the same casing as provided in this memo.=94 I=92d just drop the 2119 language entirely and not try to use language = based on RFC6919. I really like to lock things down when you can but in = this case if there=92s clearly no interop issue, I=92d go for less = characters in the draft ;) >> 2) The second part of the text in the security considerations gave me = pause: >>=20 >> A certificate displaying >> application might zoom in on that aspect of the certificate, while a >> public key-processing application might use a fragment identifier >> like "#spki" to extract the "SubjectPublicKeyInfo" structure for >> further processing.=20 >>=20 >> Are you saying the spki would be extracted for processing from the = identifier or from the certificate? I=92m hoping the later. >=20 > It=92s the certificate. Proposed revised text: >=20 > A certificate displaying > application might zoom in on that aspect of the certificate, while a > public key-processing application might use a fragment identifier > like "#spki" to extract the "SubjectPublicKeyInfo=94 structure > from the certificate for further processing. How about: =85 , while a public key-processing application might use a fragment = identifier like "#spki" to chose which certificate from which to extract = the "SubjectPublicKeyInfo=94 structure for further processing. It might also be worth adding a security consideration that the values = in the fragment identifier shouldn=92t be used in lieu of the values = they=92re supposed to be identifying because they=92re not part of the = actual certificate - or something like that. Then, I think you=92re done. spt= --Apple-Mail=_330984D1-6328-4D56-84C6-62CFEB8691B6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFQTCCBT0w ggMloAMCAQICCQCdWMxKNutUfDANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE ChMKSUVDQSwgSW5jLjAeFw0xNDA0MDIxNDU0MjBaFw0xNTA0MDIxNDU0MjBaMDgxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAKaIbxySgDxs/xq2w7+C9AGF8hT65ppo9bKXmJ9iOmR/M2DC x9T38oMuPGctVavcxXWYWxCMRCOHuDQKZiIlA8tD5VYGAzBid+4t6hrqAuis9WbWwtHfGVqOnZtP q3iNM+KqYOOz5OQ0OzlubgRrq3LuKirytxojE1WShnNwocouUwv8KDtbfbiKXcXKBgEqaz4qCuMJ YK4owwz2cH37OoWM9b5gWQ4EP/S94J5t2CwtfYM+f0n+Lk3LvL+kZUxIcQNUmpT8RM8D0M/sYbSm RtSLrAc0drV8K7OGBv20vpXewKvom56PHpRRsXK8tclSjY3ogqUjNfShpD98psV3OBcCAwEAAaOC AV4wggFaMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgXgMFIGA1UdIwRLMEmAFAB0bEnlyVJhcU1W OKthyfLh5fsNoSakJDAiMQswCQYDVQQGEwJVUzETMBEGA1UEChMKSUVDQSwgSW5jLoIJAMQtcFwx NPDPMB0GA1UdDgQWBBSrm8x24iKtr6Lnns5BPgGKRM1OMjAtBgNVHREEJjAkgRBUdXJuZXJTQGll Y2EuY29tgRB0dXJuZXJzQGllY2EuY29tMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly93d3cuaWVj YS5jb20vcGtpL2llY2Etcm9vdC1jcmwuY3JsMBcGA1UdIAQQMA4wDAYKKwYBBAGB1wAAADBGBggr BgEFBQcBAQQ6MDgwNgYIKwYBBQUHMAKGKmh0dHA6Ly93d3cuaWVjYS5jb20vcGtpL2llY2Etcm9v dC1jZXJ0LmRlcjANBgkqhkiG9w0BAQsFAAOCAgEAYOZQp8Xa4UYvDJWBlrNidIjp0IbKF6FsPb9S FJynTMNiZU42UvsF3MXJEB48OIZKCO15aM+pqjp4Qk5KFlprdOAvlK44B/DQh1F2XU9d9H8WiVfg o0d7Zl+ynDPsEr+yBN5X3AcHo636wPLt6IZPrxzecLgm837HygDIeh0ShesqTg6VlfQ1D94KYBPs 7xBmoZqqCVqbOySakgjdOxxPWV23bTTEsbQ6diwVb370t0xTfuMGcTRrn2iN6tXLY0FtXKXhNlXy a2Rsclenx+rUFlAtVIxWCUYNe969c+F4T/WTV1TtRS3nRLYTM7iDFTiD1qiY+qvAiMxGv7uDPSsK PdoenKz68KNLElo9993AzxdrU8S6pwwfi6gFGeYF8eInidKaWKqBqniKSEzza1YgVfdXhJn+YxCX WtYL+8aowiXkeLa0qFhN7qTcqSfaG5Fsz4BbuLo/Hr1dLi0pl+APvcQt7YA58zgovMYV5b5mSUAt s9ecIdIlcirYYjQmC9zif4FdCT+ee5DJMRjvibfdG8dAUrkkmFkOiecwi0Db9PHgfjr2+3S/Izf3 k06uRnlZhcnfAsOO/4dUDsfc9Xr4uta0wt1dZHVP/XzTI7w/mXwBfZPnIZvlhv5olpeXFuXom819 I10cyxToXnRcgPuTrXqscLpuKZeHSoO88252FP4xggI4MIICNAIBATAvMCIxCzAJBgNVBAYTAlVT MRMwEQYDVQQKEwpJRUNBLCBJbmMuAgkAnVjMSjbrVHwwCQYFKw4DAhoFAKCB3zAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDExMDYxODM2MzNaMCMGCSqGSIb3DQEJ BDEWBBTEe0HNjUHIac0GSz8f0EzbK8HhYzA+BgkrBgEEAYI3EAQxMTAvMCIxCzAJBgNVBAYTAlVT MRMwEQYDVQQKEwpJRUNBLCBJbmMuAgkAnVjMSjbrVHwwQAYLKoZIhvcNAQkQAgsxMaAvMCIxCzAJ BgNVBAYTAlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuAgkAnVjMSjbrVHwwDQYJKoZIhvcNAQEBBQAE ggEAHdA/h1eO42ZDQuC9Pze26gNK/MEWyOxVFOIWItpYx0DxhJRTtTF9bqQw48StwVkph8LFP9Ko uAnXi3xmTGnTKlFiKirmc3GeOKO4UJHwmBvq7iR+hfVh15KXl6rfTdodfUQWPC8g7Dxvrhs2ZGbd o45BhHesdsmpml/dQmhPYmHnfJ0p6+j03OBuOcbTuw9Wj7uAFDbZJKiE2f1D0Y4TIloukVtjOT8N I/tpeoxTVCYHHKdIjQxM7y7+o5ITIcHZKoF6qtvlcXccrFtyA/aQ/Cs8XwMmt315vnE3QCusQFti 0MOFqF/wXyZJEbIhGfdheCSM/TiTkKPVaFCDmJwnmAAAAAAAAA== --Apple-Mail=_330984D1-6328-4D56-84C6-62CFEB8691B6-- From nobody Fri Nov 7 11:00:43 2014 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 30B4A1A0058 for ; Fri, 7 Nov 2014 11:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.443 X-Spam-Level: ** X-Spam-Status: No, score=2.443 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MISSING_HEADERS=1.021, 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 hEFcNdys7Pll for ; Fri, 7 Nov 2014 11:00:41 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 941BA1A0027 for ; Fri, 7 Nov 2014 11:00:40 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id gd6so4992148lab.34 for ; Fri, 07 Nov 2014 11:00:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:cc:content-type; bh=nnpQgrvnVNnk7g8DQIXT9lSeVpwKNps9dUZcuzu+0gU=; b=r0dkkYT0j2nafENViVt42sbIDdQzBB+tmhAR0HRfJuCgcspqAa86UbvoXaOC4YO6l7 cgHL3nrZKf3aod3eHYoEjRuF7dk9Tc0oW9+W7YEz/H427nqonGRXmEPpk/OLO1VZ3Vih nTD0h9qgaIt1wBY1z7ZMakXHEziHmUyWGuviDnVYA14G4RQzRn6UzDRXlC3LjxrZHPyz qUy+/9X6m+VyhoAGcF24di0hw2N6rJ8TvLo6g/u/fLQYIKYkB5eOEfUVAUnaIXtFflX6 ErIU1fpAVc2vbdygGo1OxRCiYtwoDp75u9jPtUZYbW8DXNMuBjPjLH8Le+L9Vgf0bBrU WYDA== MIME-Version: 1.0 X-Received: by 10.112.199.40 with SMTP id jh8mr13060457lbc.5.1415386839129; Fri, 07 Nov 2014 11:00:39 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.34.212 with HTTP; Fri, 7 Nov 2014 11:00:39 -0800 (PST) In-Reply-To: <27873.1415044942@sandelman.ca> References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> Date: Fri, 7 Nov 2014 14:00:39 -0500 X-Google-Sender-Auth: z7tn1eb6T6Vt9s-eaqDYvvHMTQg Message-ID: From: Phillip Hallam-Baker Cc: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rIcPbM7XTYxpA4ECLW6MqY6NqFw Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 07 Nov 2014 19:00:42 -0000 There are really two separate time problems: 1) Accurate time synchronization for lab work, database sync, transactions, etc. 2) Current time to bound replay attacks, stale PKI data etc. for security The first requires a very high degree of accuracy, frequently to 100ms or better. If I have more than one clock in a room with a second hand then I want them all to march in time. The second requires a high degree of trust but not a high degree of accuracy. The WebPKI as deployed has to tolerate clock skews of hours. It would be good if we could reduce the skew to a minute but we don't need to worry about seconds in a general purpose protocol. If we need tighter synchronization then we should be using a different approach. This has important consequences for the secure time protocol design. It is not a case of slapping security onto NTP. NTP is designed to solve the lab time problem, not provide a trustworthy input to a security infrastructure. It is easy to write a passive protocol that provides proof that we are past a certain time. NIST and its Iranian cousin both sign time at 60 second intervals. We collect the time from both and can be pretty sure that the earliest time cited by either has passed. If we have a TRANS like notary infrastructure, we can obtain a proof that a certain time has elapsed. We choose a random value, create an entry in a notary log and then wait to collect the signed registration. If all the notaries are interconnected, defection requires defection of a quorum. I see TRANS and DPRIVE as opening up an opportunity to address this problem. The folk who want DNS Privacy and the folk who care about trustworthy time are mostly the same people. One of the core requirements for DNS Privacy is that you have to decide to take your DNS service from a trusted source (or sources) rather than accept service from random providers you don't know. Which means that you will need a mechanism for authenticating their responses. Having worked on that problem for 4 years now, I know that 95% of the DNS privacy problem is in working out how you connect to the service and manage that trust relationship. The actual encryption part is a trivial bit of packaging and the only thing to make sure about is that the encrypt/MAC get done in the right order. Since a DNS resolver service is trusted, why not allow the same provider to provide trusted time as well? t would be a separate protocol/service of course. But it should fit into the same framework so that instead of having to configure separately for each trusted service it should be possible to plug a device into one trust provider and not have to configure each service separately unless you had a reason to. From nobody Fri Nov 7 15:48:36 2014 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 BF42C1A0049 for ; Fri, 7 Nov 2014 15:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 cFcnudBY0JS8 for ; Fri, 7 Nov 2014 15:48:34 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF761A000B for ; Fri, 7 Nov 2014 15:48:34 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CE3B920012; Fri, 7 Nov 2014 18:50:24 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id D7CFD637F4; Fri, 7 Nov 2014 18:48:33 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BF671637F2; Fri, 7 Nov 2014 18:48:33 -0500 (EST) From: Michael Richardson To: Phillip Hallam-Baker In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/EHNx23TGwfT3tXbOmT03G-03L8I Cc: "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 07 Nov 2014 23:48:35 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Phillip Hallam-Baker wrote: > Having worked on that problem for 4 years now, I know that 95% of the > DNS privacy problem is in working out how you connect to the service > and manage that trust relationship. The actual encryption part is a > trivial bit of packaging and the only thing to make sure about is that > the encrypt/MAC get done in the right order. > Since a DNS resolver service is trusted, why not allow the same > provider to provide trusted time as well? > t would be a separate protocol/service of course. But it should fit > into the same framework so that instead of having to configure > separately for each trusted service it should be possible to plug a > device into one trust provider and not have to configure each service > separately unless you had a reason to. Well, DNSSEC RRSIG has a signature inception date. If a DPRIVE provider simply signs a RR every minute or hour, and you have a pre-existing trust path to that RR, then doesn't that solve the problem? And pseudo-randomly/regularly asking for the RR over the private channel, doesn't that naturally provide for some defeat of traffic analysis for the DPRIVE? =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVF1aToCLcPvd0N1lAQJUTwf/aoEB0JrvRP86KwYP9q3bqq+nYoPa4FQn VBEXfMC1tjFlNVgzkz38vHH0qZjFsAGcyaStwDcwDV4apVmJvn7tE8MLaozVrWA5 zoZRSthxRKeeGxqLpPVZ/FGp+BuiMb9KXeSF4xrSoofnE6K+LhStO37nIcI1T+tG J/Gj6UrSarasDvyLL3nCsQf5Pf3WaD80BuJGajrmWdZ8eFOdQUsROOqOe+az7I2G TocAkM66MFDtvCbzjSJh3sf/ESEMTqwOyn+s9LXmKCZJLRbeVgBlrl3tO9Ba0651 WliHnOcKq/I/LwjYvvvLFmLVF93NE/FqAMiPEj+y80pdwoiQdSC74A== =LRAx -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 7 18:37:59 2014 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 BF6701A0145 for ; Fri, 7 Nov 2014 18:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 pk0LpcHZF5kf for ; Fri, 7 Nov 2014 18:37:54 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C10D1A0143 for ; Fri, 7 Nov 2014 18:37:54 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id pv20so5428613lab.11 for ; Fri, 07 Nov 2014 18:37:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cWUJhjFR/T1T0oa2pPdBPOIF3GkabuI2QKgv3u1O/zA=; b=e5akPHBYjlS3grWJjko/lcbwD3W94T8u4SPsP4f/NCLScg30es/Jk0aXiHyBs8Wz0U EkvKzIkFv6VSTJwDigOX6H2/EWWYT4JTC9671OKh7dfLSTm61hC96H5ABr6UFUaofxiS Z4TOsql1dFt89aD4aPUfjYwIUcZAIHMei0z0DRm4RUoS3Y1L/kn1tW6TUTKeUpM5B+ph HNW4vx4hlyxrGm7gjWfm41/pe7ys4my2oLPecTidXB/F1IcQ7YKte7J6Eb4aivffejYN FR5H1qRmnoIBLo+aKi1ve3+Kc7wopMI+DJe04qu3S8vlW2zWUXpQ4brTaStFdx2tPpHk dRTQ== MIME-Version: 1.0 X-Received: by 10.152.30.9 with SMTP id o9mr14795043lah.8.1415414272451; Fri, 07 Nov 2014 18:37:52 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.34.212 with HTTP; Fri, 7 Nov 2014 18:37:52 -0800 (PST) In-Reply-To: <8258.1415404113@sandelman.ca> References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> Date: Fri, 7 Nov 2014 21:37:52 -0500 X-Google-Sender-Auth: tYr1Bx2kx6cMpFS4eI7T1-Xj3f0 Message-ID: From: Phillip Hallam-Baker To: Michael Richardson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/M_NY6QSCZihearECyZSVeb97kA0 Cc: "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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: Sat, 08 Nov 2014 02:37:56 -0000 On Fri, Nov 7, 2014 at 6:48 PM, Michael Richardson wrote: > > Phillip Hallam-Baker wrote: > > Having worked on that problem for 4 years now, I know that 95% of the > > DNS privacy problem is in working out how you connect to the service > > and manage that trust relationship. The actual encryption part is a > > trivial bit of packaging and the only thing to make sure about is that > > the encrypt/MAC get done in the right order. > > > Since a DNS resolver service is trusted, why not allow the same > > provider to provide trusted time as well? > > > t would be a separate protocol/service of course. But it should fit > > into the same framework so that instead of having to configure > > separately for each trusted service it should be possible to plug a > > device into one trust provider and not have to configure each service > > separately unless you had a reason to. > > Well, DNSSEC RRSIG has a signature inception date. If a DPRIVE provider > simply signs a RR every minute or hour, and you have a pre-existing trust > path to that RR, then doesn't that solve the problem? If the client has a prenegotiated shared secret with the resolution service, the client can ask the service what the time is and get an encrypted/authenticated response. It doesn't need to be signed. Can just use a MAC with a shared secret and a protocol with a very simple signature: Transaction GetTime GetTimeRequest GetTimeResponse Message GetTimeRequest Message GetTimeResponse DateTime Now My preference would be to do a completely separate protocol. But we could easily add in a pseudo RR for it. Could even use a DNS class for Time! Signed time doesn't really do much for security I can see. Time attacks are almost always winding time back into the past. Singing time tells me that the time I am given has definitely passed but not that that I was given the current time. So it doesn't help with a post dating attack anyway unless I get it from a trusted source. > And pseudo-randomly/regularly asking for the RR over the private channel, > doesn't that naturally provide for some defeat of traffic analysis for > the DPRIVE? Might help. But I would rather hide in a larger quantity of natural traffic like VOIP or whatever. From nobody Sat Nov 8 07:25:42 2014 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 07C4C1A1BF9; Sat, 8 Nov 2014 07:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 HDR7RGkr5vh8; Sat, 8 Nov 2014 07:25:39 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8FB1A1BF1; Sat, 8 Nov 2014 07:25:39 -0800 (PST) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 02D3D509B5; Sat, 8 Nov 2014 10:25:37 -0500 (EST) Message-ID: <545E358C.9010405@seantek.com> Date: Sat, 08 Nov 2014 07:23:56 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "pkix@ietf.org" , saag@ietf.org References: <20141026225606.23674.92818.idtracker@ietfa.amsl.com> In-Reply-To: <20141026225606.23674.92818.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080209070606010404000906" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/m5g3KfVMJapPv_Txwss5Hp2murE Subject: [saag] PKCS #9 LDAP Registrations New Version Notification for draft-seantek-ldap-pkcs9-01.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: Sat, 08 Nov 2014 15:25:41 -0000 This is a cryptographically signed message in MIME format. --------------ms080209070606010404000906 Content-Type: multipart/alternative; boundary="------------090904030206030501020600" This is a multi-part message in MIME format. --------------090904030206030501020600 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hello pkix/saag: In September I published an initial Internet-Draft on registering PKCS=20 #9 values (such as dateOfBirth and userPKCS12) in the IANA LDAP=20 Parameters registry. I got a few comments from the ldap list, so I revised it to -01 last=20 month. Since IETF 91 is coming up, I thought I would at least inform=20 these lists of the work. A lot of security software (such as OpenSSL)=20 uses LDAP Parameters with varying degrees of (in)formality, so the=20 purpose of this short 7-page draft is just to finish off what PKCS #9=20 started. Comments welcome. Thanks, Sean Begin forwarded message: > *From: *internet-drafts@ietf.org > *Subject: **New Version Notification for draft-seantek-ldap-pkcs9-01.tx= t* > *Date: *October 26, 2014 at 3:56:06 PM PDT > *To: *Sean Leonard >, "Sean Leonard" > > > > A new version of I-D, draft-seantek-ldap-pkcs9-01.txt > has been successfully submitted by Sean Leonard and posted to the > IETF repository. > > Name:draft-seantek-ldap-pkcs9 > Revision:01 > Title:Lightweight Directory Access Protocol (LDAP) Registrations for=20 > PKCS #9 > Document date:2014-10-26 > Group:Individual Submission > Pages:7 > URL: http://www.ietf.org/internet-drafts/draft-seantek-ldap-pkcs9-01.tx= t > Status: https://datatracker.ietf.org/doc/draft-seantek-ldap-pkcs9/ > Htmlized: http://tools.ietf.org/html/draft-seantek-ldap-pkcs9-01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-seantek-ldap-pkcs9-01 > > Abstract: > PKCS #9 includes several useful definitions that are not yet > reflected in the LDAP IANA registry. This document adds those > definitions to the IANA registry. > > The IETF Secretariat > --------------090904030206030501020600 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello pkix/saag:

In September I published an initial Internet-Draft on registering PKCS #9 values (such as dateOfBirth and userPKCS12) in the IANA LDAP Parameters registry.

I got a few comments from the ldap list, so I revised it to -01 last month. Since IETF 91 is coming up, I thought I would at least inform these lists of the work. A lot of security software (such as OpenSSL) uses LDAP Parameters with varying degrees of (in)formality, so the purpose of this short 7-page draft is just to finish off what PKCS #9 started.

Comments welcome. Thanks,

Sean

Begin forwarded message:

New Version Notification for draft-seantek-ldap-pkcs9-01.txt<= /b>
October= 26, 2014 at 3:56:06 PM PDT
Sean Leonard <dev+iet= f@seantek.com>, "Sean Leonard" <= dev+ietf@seantek.com>


A new version of I-D, draft-seantek-ldap-pkcs9-01.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name: = draft-seantek-ldap-pkcs9
Revision: 01
Title: Lightweight Directory Access Protocol (LDAP) Registrations for PKCS #9
Document date: 2014-10-26
Group: Individual Submission
Pages: 7
URL: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0http://www.ietf.org/internet-drafts/draft-seantek-ldap-pkcs9-01.txt
Status: =A0=A0=A0=A0=A0=A0=A0=A0https://datatracker.ietf.org/doc/draft-seantek-ldap-pkcs9/ Htmlized: =A0=A0=A0=A0=A0=A0http://tools.ietf.org/html/draft-seantek-ldap-pkcs9-01
Diff: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0http://www.ietf.org/rfcdiff?url2=3Ddraft-seantek-ldap-pkcs9-= 01

Abstract:
=A0=A0PKCS #9 includes several useful definitions that are no= t yet
=A0=A0reflected in the LDAP IANA registry. This document adds= those
=A0=A0definitions to the IANA registry.

The IETF Secretariat


--------------090904030206030501020600-- --------------ms080209070606010404000906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKTDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMx MTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRkZXYraWV0ZkBz ZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J9tKgDs1LQtaD c+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2guKi2R5xr f/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G53zv awQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia3 3JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaA FHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQ ME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcw AoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25h bmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMfWE2/5myX518DB+kTa5iQDbKYRuJp 3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmIH4kfI4LWrY8XrPhlX3JmHjD6 hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3jx9VF/gA3vqYpL+jNumI nz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d9ljRDEiAts5Oopke eFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYIEHDCCBBgCAQEw gakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE0MTEwODE1MjM1NlowIwYJKoZIhvcNAQkEMRYEFEdLTYiWTWWgkRNI 8b2IY85DEc8yMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09N T0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwgbwGCyqGSIb3DQEJEAIL MYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMw Q09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAypM8 MbupbqbMkL4Skr0HfDANBgkqhkiG9w0BAQEFAASCAQARbhQOlZE8Fk5fJYWpah9eFhIdeo5P xpVjJq0F8KO8INhup9dvTz8ZbZqs1ww7V5e1OKECJWgyxai4slb2R8NUP4eGM379v258xpTv JK57nJ/9onorzHtIu03cPiwg3f85S3WrNbPeVE4+GF5Ioo5dbm7vK12Gtbr9ycR2nsjPOYTg cAtw1/GrZZ22w3HCSstuT5bWMTeKqGdIUoeh09zeSzG0OlIfBZOFV3YEvXCRVGNpXFWaKCEA hLzTlCCZl9lVBdqJgwexHtm77Ejn9VUqTembypeGROjvvDyemZhYJgBXjWhG40XV40ousHXU gK0kYF2R1kQm78UT5fmVDNOnAAAAAAAA --------------ms080209070606010404000906-- From nobody Sun Nov 9 09:53:53 2014 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 68A971A3B9E for ; Sun, 9 Nov 2014 09:53:52 -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] 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 B6Sg1vTSO0Ly for ; Sun, 9 Nov 2014 09:53:51 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id EB3DF1A212D for ; Sun, 9 Nov 2014 09:53:50 -0800 (PST) Received: from fifthhorseman.net (unknown [199.68.254.218]) by che.mayfirst.org (Postfix) with ESMTPSA id E4A0BF989; Sun, 9 Nov 2014 12:53:46 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id A7E8E1FEC1; Sun, 9 Nov 2014 07:53:46 -1000 (HST) From: Daniel Kahn Gillmor To: Phillip Hallam-Baker , Michael Richardson In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Sun, 09 Nov 2014 07:53:43 -1000 Message-ID: <87y4rkxntk.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_KhDme2wbhohHmbJqvbMucyTFIc Cc: "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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: Sun, 09 Nov 2014 17:53:52 -0000 --=-=-= Content-Type: text/plain On Fri 2014-11-07 16:37:52 -1000, Phillip Hallam-Baker wrote: > If the client has a prenegotiated shared secret with the resolution > service, the client can ask the service what the time is and get an > encrypted/authenticated response. > > It doesn't need to be signed. Can just use a MAC with a shared secret > and a protocol with a very simple signature: > > Transaction GetTime GetTimeRequest GetTimeResponse > Message GetTimeRequest > Message GetTimeResponse > DateTime Now Without a nonce, isn't this vulnerable to replay attacks? If i ever see you request the time (and see your server's response) at time T, i shouldn't be allowed to wind time back to T for you just because i control the network. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJUX6onXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpclTkP/16Mf6Cb1g+UguNBk+mzWk81 uvO+AeEYiNp33u08AH/EI7msIMlwktGTHvagZegRP/bflzuOU4EDqBxtuyiW45bC nBl2LSr5Ane9Ms33V94rrERx4BuuXM8Yk7DDb/mxiTaimC2PLRBMohhGx2R8/iCi rveqhlCKLnEugHsCNHXdyw2HrUV0XT1MCxRkQ5tQGbK54OxngQbuBtnT5n40nSUg zDyrwVBLmQC4TgkimSKG2ry0TD3ClWgeijKXWdy1B8NK7kPZAsrdS1YXs79thqMX WKQJE+cJoGcfXKcbexHBX5DrJMSEFzc2BL/sweT1gLJgsZfUuPVP9Oh37Uv/Ogrj szCjFyAWn4RGm1HCyjf0gppx5Vi26NBgIH9zqYsTv8xjttfOJinoRiB8ScBzW2ob IdqYlB4VCxnCKCtAfEU+rVdaRLnj3UjXwRBMsW2hUltiXIHDsmLQcAZx/hEGn4dK rjksRFpLN+CWjH2ZMOwCSi1kibpDsWUIBQwTIVVxI2aRgTvhbFaFjz3ywD1UYeiR s4fo5y12VWNsgLwWnNfA5fY6Kf44LEzNWteC4uibpVjZ9RIgKQ6iCEfA19/QW2Na qgShZpOGmOaaORLJKTxGROHYxBUW3Zk9HYybNPggxUZI+RRHhDhVaBaqjQZzoyUL h0FnUFvjpXjTZc1SfXaM =KobO -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 9 11:01:11 2014 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 128151A6F14 for ; Sun, 9 Nov 2014 11:01:10 -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 SPGujJ9A6fId for ; Sun, 9 Nov 2014 11:01:08 -0800 (PST) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE2A1A6F2A for ; Sun, 9 Nov 2014 11:01:08 -0800 (PST) Received: by mail-yh0-f53.google.com with SMTP id a41so1469462yho.12 for ; Sun, 09 Nov 2014 11:01:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+/CVwXq9lR6iI4EuHRsu/EAH2ql5uP0QAr3e22IDAT8=; b=JkoK3BGQR6eNIUNVg2leWzIyc9jMp+l5z9COnDnt7C2RjCUEcTKG5gfRd4GFXjbLQB RdgCGljnUiMBsfgqCXoE0Tkr2MPkvRHHvMyq/RW7nZqMzIhD2rIEd4fHGkuUVQSuRTbf 9w0blcdbOEEsUnlzbBxahXGv7lFc5NxRigexN03870hPtn1m/1ZOqWk/fb4Z2+LA/YlU x7kfJ3rZDmtmvve7sf+D9n5zrMIB0a7Cio5WAryQoBZD8cfv+19ZXf0WSTz3IXX8AAEz SGVQvLdi/1xaaXxTk4ZnFu5Enn8b8oAYzRuU840ajZiMr/I6sSKYz387gHbTFnCTo7zy F0IQ== MIME-Version: 1.0 X-Received: by 10.236.22.36 with SMTP id s24mr25784331yhs.138.1415559667859; Sun, 09 Nov 2014 11:01:07 -0800 (PST) Received: by 10.170.195.203 with HTTP; Sun, 9 Nov 2014 11:01:07 -0800 (PST) In-Reply-To: <87y4rkxntk.fsf@alice.fifthhorseman.net> References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> <87y4rkxntk.fsf@alice.fifthhorseman.net> Date: Sun, 9 Nov 2014 11:01:07 -0800 Message-ID: From: Watson Ladd To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/kCBI31dNC0T5QQvWfWBb_uyw7IE Cc: Michael Richardson , "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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: Sun, 09 Nov 2014 19:01:10 -0000 On Sun, Nov 9, 2014 at 9:53 AM, Daniel Kahn Gillmor wrote: > On Fri 2014-11-07 16:37:52 -1000, Phillip Hallam-Baker wrote: >> If the client has a prenegotiated shared secret with the resolution >> service, the client can ask the service what the time is and get an >> encrypted/authenticated response. >> >> It doesn't need to be signed. Can just use a MAC with a shared secret >> and a protocol with a very simple signature: >> >> Transaction GetTime GetTimeRequest GetTimeResponse >> Message GetTimeRequest >> Message GetTimeResponse >> DateTime Now > > Without a nonce, isn't this vulnerable to replay attacks? If i ever see > you request the time (and see your server's response) at time T, i > shouldn't be allowed to wind time back to T for you just because i > control the network. All motherboards contain a RTC. There is a standard, host-based, security measure for NTP that prevents running the clock backwards. This measure is not used. Yes, it really is as simple as removing an argument from a boot script. Sincerely, Watson Ladd > > --dkg > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Nov 9 13:19:59 2014 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 7324E1A8729 for ; Sun, 9 Nov 2014 13:19:57 -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 vwquMmfn9R-B for ; Sun, 9 Nov 2014 13:19:56 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13251A8703 for ; Sun, 9 Nov 2014 13:19:55 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id f15so5483406lbj.13 for ; Sun, 09 Nov 2014 13:19:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tc42FRL65x6iC35dqErJYD/I4USBJ88SeNdPedbKEw4=; b=q+A+3wiXazHLcXGJ1CkYufwqDOR4OzFA2jAej4wLo7psnrzzbjVk4H1LiLCAyZVcYe hm4Jah1b4q+axipWgoRFBJot3G+mvQ8Ej42KGktt2LYJyavYQk9r5X5JjaLv9SdFd27y 7nSZgG1cT9D5J/rfVsP6MB2w8q66TKDvS2bIu1azAe5ytnOn9QwJmm59cUl360qDCyXA 5Lkvo8Kd2G8BmbhcphpP4DSPm/qphfuHjoRO4N3lSTKoyBBiwfQwf75ILRWp4Gx60rDX JXhB3akROHNoKD2+56sNcleBD3aFzxEkmMNhCYlHdHpI6tytXf1JtiTq1OPDa9MKjPUr XaLg== MIME-Version: 1.0 X-Received: by 10.112.14.69 with SMTP id n5mr25515838lbc.34.1415567994124; Sun, 09 Nov 2014 13:19:54 -0800 (PST) Received: by 10.112.95.17 with HTTP; Sun, 9 Nov 2014 13:19:54 -0800 (PST) Date: Sun, 9 Nov 2014 16:19:54 -0500 Message-ID: From: Kathleen Moriarty To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/d-q4pNOkqK-2tysj1IH8T-oadYc Subject: [saag] Slides for SAAG 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: Sun, 09 Nov 2014 21:19:57 -0000 Hello, If you are presenting at SAAG, please send slides to sec-ads@tools.ietf.org as soon as possible so we can get them posted. Thanks, Kathleen & Stephen From nobody Mon Nov 10 01:59:10 2014 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 5B2B71A89A7 for ; Mon, 10 Nov 2014 01:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.394 X-Spam-Level: X-Spam-Status: No, score=-3.394 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 Cquugp3AVWyP for ; Mon, 10 Nov 2014 01:59:00 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) (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 3750A1A89A2 for ; Mon, 10 Nov 2014 01:59:00 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58954) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1XnlkO-0004X9-rJ (Exim 4.82_3-c0e5623) (return-path ); Mon, 10 Nov 2014 09:58:56 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1XnlkO-0007hu-FX (Exim 4.72) (return-path ); Mon, 10 Nov 2014 09:58:56 +0000 Date: Mon, 10 Nov 2014 09:58:56 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Watson Ladd In-Reply-To: Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> <87y4rkxntk.fsf@alice.fifthhorseman.net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/saag/8o5d8oCBS1n53Pv-aP9rzEywCOY Cc: Michael Richardson , "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 10 Nov 2014 09:59:03 -0000 Watson Ladd wrote: > > All motherboards contain a RTC. You should look at the Raspberry Pi or some Internet of Things devices. Tony. -- f.anthony.n.finch http://dotat.at/ Portland, Plymouth, Biscay: Southwesterly 4 or 5, backing southeasterly 6 to gale 8, perhaps severe gale 9 later in Plymouth, then becoming variable 4 later in Plymouth and northwest Biscay. Rough or very rough, but moderate at first in Portland. Rain or thundery showers. Moderate or good, occasionally poor. From nobody Mon Nov 10 07:56:43 2014 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 223061A0006 for ; Mon, 10 Nov 2014 07:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 Qs17vcm2BgZ5 for ; Mon, 10 Nov 2014 07:56:37 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAC401A0004 for ; Mon, 10 Nov 2014 07:56:36 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id f15so6780615lbj.9 for ; Mon, 10 Nov 2014 07:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Fv+RQd1I6jmuaPs/VMRIZh/6kaVGYhg2yk68RGFIXQs=; b=UkbwCl4nxgVBNCXtpVwqMw+Rq4v8xRwtRs1JChhlvzhyWGllAjGY9bSnNqCP8ay+XA leIVjKydQ+oOKEwtOuxFJMQoFUGVwk1ZupjAZvWMknmbSsN68ZcUnvCwYzQKViHVnIlZ Oju3oW8v1AAu4m2MYkWZi913XtVZ14RWQaixCxoAF3xW21igfE/hUoIsAlTRqJy8b92U BxH7cnQivKp20Q94gKHCrNl4nnsGIS208k7VxJvrOfcxeAZaUMP0YiG/5Z0tYfMD4i+s uDQ2PPKTzOxX7xPXJaby6K9WYTP13SMfZBQclcjJNkRoH7v45jOGlrDqQ1fqMvjfJlgx uKCQ== MIME-Version: 1.0 X-Received: by 10.112.77.233 with SMTP id v9mr21397244lbw.45.1415634995273; Mon, 10 Nov 2014 07:56:35 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.34.212 with HTTP; Mon, 10 Nov 2014 07:56:35 -0800 (PST) In-Reply-To: <87y4rkxntk.fsf@alice.fifthhorseman.net> References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> <87y4rkxntk.fsf@alice.fifthhorseman.net> Date: Mon, 10 Nov 2014 10:56:35 -0500 X-Google-Sender-Auth: vaFdAP1fjsVsiP_G8LiDW-w8fWM Message-ID: From: Phillip Hallam-Baker To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/sHIdwyywPDiRxjpF-MNYtkCTS2Q Cc: Michael Richardson , "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 10 Nov 2014 15:56:42 -0000 On Sun, Nov 9, 2014 at 12:53 PM, Daniel Kahn Gillmor wrote: > On Fri 2014-11-07 16:37:52 -1000, Phillip Hallam-Baker wrote: >> If the client has a prenegotiated shared secret with the resolution >> service, the client can ask the service what the time is and get an >> encrypted/authenticated response. >> >> It doesn't need to be signed. Can just use a MAC with a shared secret >> and a protocol with a very simple signature: >> >> Transaction GetTime GetTimeRequest GetTimeResponse >> Message GetTimeRequest >> Message GetTimeResponse >> DateTime Now > > Without a nonce, isn't this vulnerable to replay attacks? If i ever see > you request the time (and see your server's response) at time T, i > shouldn't be allowed to wind time back to T for you just because i > control the network. Sorry, yes you do need a nonce, and that gets added in automatically in my presentation layer. Forgot to mention it. From nobody Mon Nov 10 07:59:57 2014 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 A1A7A1A0029 for ; Mon, 10 Nov 2014 07:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 810_9VlQcQy6 for ; Mon, 10 Nov 2014 07:59:55 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD4061A002C for ; Mon, 10 Nov 2014 07:59:48 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id 10so6126042lbg.35 for ; Mon, 10 Nov 2014 07:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=308B5vU0vhItj9dI4PEqmigWfpPemtRYBoKK9g9705Q=; b=L8+y6pdIpBnbae4of3gn6hE2MbQyV5JS1WQu5il18Hzq6kOXTiWfrAGtOcceStf3dN bz3VXQM2axU/I9p+o8vmxmytRHRrCBpkQODx6gBxCa3HdX00tDV3CaZEuRblZdhDVoKQ x4V5FRsEet93H+iOVjRWhsazowRnBV4yz6bL8+wwVbZ2aK8qjrVVv8tYF5g0QZv73DkZ PocfX8UXoIz8SoyqQJo223AulTj+F6xXYzp1INOdX5y8fJXAVcKgs8wq5oYfLlcRosIu k7ba0P88cZnd+gjFDLyq/YT256g7nlNmEYsv+pMziWs/qf5O0tIyYAR7V+1A1PRT5ncT O6yg== MIME-Version: 1.0 X-Received: by 10.112.200.34 with SMTP id jp2mr30277325lbc.1.1415635186831; Mon, 10 Nov 2014 07:59:46 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.34.212 with HTTP; Mon, 10 Nov 2014 07:59:46 -0800 (PST) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> <87y4rkxntk.fsf@alice.fifthhorseman.net> Date: Mon, 10 Nov 2014 10:59:46 -0500 X-Google-Sender-Auth: dkl3FoMsSEIWzqdqZzgtfde3m3c Message-ID: From: Phillip Hallam-Baker To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/cn29KQE329v73AgQsS4_ysOmsvA Cc: Michael Richardson , "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 10 Nov 2014 15:59:55 -0000 On Sun, Nov 9, 2014 at 2:01 PM, Watson Ladd wrote: > All motherboards contain a RTC. There is a standard, host-based, > security measure for NTP that prevents running the clock backwards. > This measure is not used. Yes, it really is as simple as removing an > argument from a boot script. No, they don't. Where is the real time clock on an Arduino? How about a Smothieboard or a TinyG? And those are quite high spec boards costing over $50. Raspberry Pis don't have an RTC either. The last is pretty important given that Raspberry Pi is a likely candidate for any security involving disposable one time use machines. From nobody Mon Nov 10 08:13:54 2014 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 C35821A006E for ; Mon, 10 Nov 2014 08:13: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 5TZwlM2GvcOA for ; Mon, 10 Nov 2014 08:13:50 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396941A006B for ; Mon, 10 Nov 2014 08:13:50 -0800 (PST) Received: by mail-yk0-f177.google.com with SMTP id 142so4088294ykq.8 for ; Mon, 10 Nov 2014 08:13:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NQ4nwV6FjUJnR4FiucQphTgdVVTX8pXlW2Qu5LqD/ZM=; b=zcFA/1gJ+iuoLxjs5roSkx4HWy2/4a/gpIegr4+8ZsgPsPLC1do2KCDsSQ3XALZhNN cHzbAx1zzArQqq/W/RJz4JbSjKVFI7XXzdOknVvSFVz5LPZs9aHseZ4ub+yaxBWS/wAM fhpM52rtaE8z4eYi0UKkYlVgtPBBhmiQG9Z01ix9ZdnY61IgbFq4gkeyfKdootDOAHkV 2QNsNeDWetez2cN/YcZHzeA48eJ/UWU4avZsnbea9592ZSnRNDK4w6Kxy4yLrmUx+qM7 uuocH1250/xaYcYrQllqkg7LOLHF85gfE5kn4POgoMhiKo7dGnAYvm75PtHsZ2JJrFFF EkHA== MIME-Version: 1.0 X-Received: by 10.170.159.70 with SMTP id a67mr35129299ykd.20.1415636029523; Mon, 10 Nov 2014 08:13:49 -0800 (PST) Received: by 10.170.195.203 with HTTP; Mon, 10 Nov 2014 08:13:49 -0800 (PST) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> <87y4rkxntk.fsf@alice.fifthhorseman.net> Date: Mon, 10 Nov 2014 08:13:49 -0800 Message-ID: From: Watson Ladd To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ztB05yOltD--6PUXBLMYTX3355o Cc: Michael Richardson , "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 10 Nov 2014 16:13:52 -0000 On Mon, Nov 10, 2014 at 7:59 AM, Phillip Hallam-Baker wrote: > On Sun, Nov 9, 2014 at 2:01 PM, Watson Ladd wrote: > >> All motherboards contain a RTC. There is a standard, host-based, >> security measure for NTP that prevents running the clock backwards. >> This measure is not used. Yes, it really is as simple as removing an >> argument from a boot script. > > No, they don't. The vulnerable machines include laptops and desktops which do have an RTC. We can't even solve the easy problem. Embedded devices will need a secure time protocol that works. But if you don't understand why Autokey doesn't work, you'll make proposals that don't work either. Anyone can join pool.ntp.org: you cannot have a single key for all pool.ntp.org servers. Saying we should use ISP provided servers leaves out the question of finding those servers. It's trivial to design a protocol that can work through NAT. It's not trivial to make one suitable for the current situation, where almost everyone uses a pool of servers anyone can join for the correct time because this avoids all sorts of discovery and longevity problems. Sincerely, Watson Ladd -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Nov 10 08:41:48 2014 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 A34E81A0119 for ; Mon, 10 Nov 2014 08:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 fSAGijzOwmQv for ; Mon, 10 Nov 2014 08:41:46 -0800 (PST) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 680211A0115 for ; Mon, 10 Nov 2014 08:41:45 -0800 (PST) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 35B24200B9997 for ; Mon, 10 Nov 2014 08:41:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=MP37d4h1QzP22DGYQp5S XTfAwKE=; b=ZC+3apZBnLQ1keMeliJM/yftjQtLePBPmdlxWOs61/b6DLNA8XeJ Sz35HsnzxsucQ0zcKUn94FowIPhhrqOR4buz6n4ZCANCRWO5Sdtwm48qIkVd7vuA ZjBTbC51BJX6wSP/AswKz39dc/2IKsIcPDGBgUmlYKrskRX7Z0KzVFY= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 0A783200B9996 for ; Mon, 10 Nov 2014 08:41:45 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id h11so11062347wiw.15 for ; Mon, 10 Nov 2014 08:41:43 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.19.234 with SMTP id i10mr32733161wie.28.1415637703478; Mon, 10 Nov 2014 08:41:43 -0800 (PST) Received: by 10.216.32.135 with HTTP; Mon, 10 Nov 2014 08:41:43 -0800 (PST) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> <87y4rkxntk.fsf@alice.fifthhorseman.net> Date: Mon, 10 Nov 2014 10:41:43 -0600 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/A44rxbjerBmQiFSCD30Fv5u6hbM Cc: Michael Richardson , "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 10 Nov 2014 16:41:47 -0000 I agree: stepping the RTC backwards should never be taken lightly (prompt the user if you can; do not step back if you can't prompt). For devices without an RTC but with stable storage, they should periodically write the last known time and never step backwards over it. But of course, without an RTC there's no real good way to prevent stepping backwards if the device was powered off for a long time coincident with a compromise of time distribution keys (or the trust infrastructure for them). For the internet of things it might be nice if homes could have a local trusted time source, but that involves joining those devices to a home network, so that's a no-go. Perhaps we should be reaching this conclusion: the time infrastructure is as critical as a PKI's roots. Nico -- From nobody Mon Nov 10 09:58:45 2014 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 82D041A1A15 for ; Mon, 10 Nov 2014 09:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 ss3rMHuBcTU5 for ; Mon, 10 Nov 2014 09:58:41 -0800 (PST) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E1A1A1AB7 for ; Mon, 10 Nov 2014 09:58:40 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id hq12so1735272vcb.37 for ; Mon, 10 Nov 2014 09:58:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=q4xE+Ybn0kSStM6biXxazbSa2gVtlY+lAdgZBKYwKgQ=; b=TEHbC38NL9SjspHld4EVi2rnqr7BMf9IbhHrOsP6UJylmSjjz8BLv+DAAnUdydUro0 W4D54mpo4Iaw6JCtTKOEDDQA9bTCd4wn1aoB6r6uCY5bktiHA0yURI6jaEXEzqhv5hk+ dkzweq3J8pxg2IcZLpi2p1onsVlnxmQLu4E+pL7OR9XDiIs8Gaa+ek0SxPacXcToGjD/ 9JHzJTS1ScJMHEEQFfjx3bbuAom9yuLjyiJW1w+bY/ulKmM4XGtL4CKlunQfKBsbA+O+ GPwqF/59h7lqrpHWRo+SJbNQrrQhYd6wyjXQa1qQO5+CffjZL5oRLPVuecQtkvyBT/Zf 4KOA== MIME-Version: 1.0 X-Received: by 10.53.1.12 with SMTP id bc12mr920572vdd.87.1415642319757; Mon, 10 Nov 2014 09:58:39 -0800 (PST) Sender: nygren@gmail.com Received: by 10.221.11.148 with HTTP; Mon, 10 Nov 2014 09:58:39 -0800 (PST) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> <87y4rkxntk.fsf@alice.fifthhorseman.net> Date: Mon, 10 Nov 2014 07:58:39 -1000 X-Google-Sender-Auth: lZI7b_KNm5gU3FB9CzHdQN411bc Message-ID: From: Erik Nygren To: Nico Williams Content-Type: multipart/alternative; boundary=001a1133f7da992cb3050784e92d Archived-At: http://mailarchive.ietf.org/arch/msg/saag/eQ_-4IYzMouBAgcshPs-8jcxrVw Cc: "saag@ietf.org" , Michael Richardson Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 10 Nov 2014 17:58:43 -0000 --001a1133f7da992cb3050784e92d Content-Type: text/plain; charset=UTF-8 While there may be no solution for devices powered off for a long time with neither RTC nor long-term storage, we should explore leveraging existing PKI roots to ensure monotonic coarse-grained time. For example, if some intermediary of the PKI roots and DNSSEC TLD roots periodically signed "current time" and made it available somewhere, clients could fetch some number of these and update a time floor (minimum allowable time) if over some number of trusted roots agreed. This time floor could be stored in local storage. Fine-grained synchronization could still use less trusted NTP as long as it couldn't go below the floor. If the signed current time is updated daily or every few days, this could at least help with the sort of time roll-back attacks that started this thread (although by itself might not help against replay attacks with shorter time bounds). Threat-wise, we also need to protect against accidents or attacks that might trick clients into thinking that the time floor is in the future as that might be very hard to recover from. As such, clients would presumably not want to rely on a single trust root for advancing this. Erik On Mon, Nov 10, 2014 at 6:41 AM, Nico Williams wrote: > I agree: stepping the RTC backwards should never be taken lightly > (prompt the user if you can; do not step back if you can't prompt). > For devices without an RTC but with stable storage, they should > periodically write the last known time and never step backwards over > it. But of course, without an RTC there's no real good way to prevent > stepping backwards if the device was powered off for a long time > coincident with a compromise of time distribution keys (or the trust > infrastructure for them). > > For the internet of things it might be nice if homes could have a > local trusted time source, but that involves joining those devices to > a home network, so that's a no-go. > > Perhaps we should be reaching this conclusion: the time infrastructure > is as critical as a PKI's roots. > > Nico > -- > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a1133f7da992cb3050784e92d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
While there may be no solution for devices powered of= f for a long time
with neither RTC nor long-term storage, we should exp= lore leveraging
existing PKI roots to ensure monotonic coarse-grained t= ime.
For example, if some intermediary of the PKI roots and D= NSSEC TLD roots
periodically signed "current time" = and made it available somewhere,
clients could fetch some number of thes= e and update a time floor
(minimum allowable time) if over so= me number of trusted roots agreed.
This time floor could be s= tored in local storage.=C2=A0 Fine-grained synchronization
could still u= se less trusted NTP as long as it couldn't go below the floor.
If the signed current time is updated daily or every few days, this c= ould
at least help with the sort of time roll-back attacks th= at started this thread
(although by itself might not help aga= inst replay attacks with shorter time bounds).

Threat-wise, we also need to protect against accidents or attacks that mig= ht
trick clients into thinking that the time floor is in the future as t= hat might
be very hard to recover from.=C2=A0 As such, clients would pre= sumably not want
to rely on a single trust root for advancing this.
<= /div>

=C2=A0=C2=A0=C2=A0 Erik


On Mon, Nov 1= 0, 2014 at 6:41 AM, Nico Williams <nico@cryptonector.com> wrote:
I agree: stepping the RTC backwa= rds should never be taken lightly
(prompt the user if you can; do not step back if you can't prompt).
For devices without an RTC but with stable storage, they should
periodically write the last known time and never step backwards over
it.=C2=A0 But of course, without an RTC there's no real good way to pre= vent
stepping backwards if the device was powered off for a long time
coincident with a compromise of time distribution keys (or the trust
infrastructure for them).

For the internet of things it might be nice if homes could have a
local trusted time source, but that involves joining those devices to
a home network, so that's a no-go.

Perhaps we should be reaching this conclusion: the time infrastructure
is as critical as a PKI's roots.

Nico
--

_______________________________________________
saag mailing list
saag@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/saag

--001a1133f7da992cb3050784e92d-- From nobody Mon Nov 10 10:09:58 2014 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 EDCAA1A1BFA for ; Mon, 10 Nov 2014 10:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 P8TW41OwZ1sz for ; Mon, 10 Nov 2014 10:09:55 -0800 (PST) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id BFFE11A1F20 for ; Mon, 10 Nov 2014 10:09:53 -0800 (PST) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 9308BB806D for ; Mon, 10 Nov 2014 10:09:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=0VIHkt6ACReMen1D0gHNG03 dJuE=; b=TVuPSwYv9UzpaaClggrQNJOeLXIgFep/4w5fHZd+WQrgcrHgzzuSMAG u0lIuPeXYOIcdogZLtug06R3+VZoo44nPO3tkJP9wjgLv71YkDlQ8USBy/ZV0gDA RHhtoPF1SFjGrMgnqTkXT4JJ2SnH43g13oknr8zgSMFy6BbJAe+M= Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 6BDB6B806B for ; Mon, 10 Nov 2014 10:09:53 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so9522971wgh.15 for ; Mon, 10 Nov 2014 10:09:50 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.20.173 with SMTP id o13mr5987799wie.70.1415642990533; Mon, 10 Nov 2014 10:09:50 -0800 (PST) Received: by 10.216.32.135 with HTTP; Mon, 10 Nov 2014 10:09:50 -0800 (PST) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> <87y4rkxntk.fsf@alice.fifthhorseman.net> Date: Mon, 10 Nov 2014 12:09:50 -0600 Message-ID: From: Nico Williams To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/7Qb8U_CkJmBzAjNyVzdfm32bnYM Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 10 Nov 2014 18:09:56 -0000 Another point is that devices with no writable stable storage cannot receive updates, not even of trust anchors in the event of PKI root compromises. Such devices had better have trivial roles with no significant security considerations! For devices with significant security considerations we should expect at least a modicum of writable stable storage for things like "last known time" and trust anchors. Nico -- From nobody Mon Nov 10 10:43:43 2014 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 CF1261A7028 for ; Mon, 10 Nov 2014 10:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 HcFBH84FuX3B for ; Mon, 10 Nov 2014 10:43:41 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 474B71A700E for ; Mon, 10 Nov 2014 10:43:41 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 05D6E594061 for ; Mon, 10 Nov 2014 10:43:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=O05xamijeiYuOMq7qW3F cQYrVW8=; b=JoafZ6zkLD8sCK8o6Mk//rUHj9BlYy2Zg4NsBoaSfrbXxvFus4EM iThZ6UQLfk9NGQNXzUH1/oSqn75ogDnpUx1X5QdggzgjqWoPnYqSzALLRyKZFCh+ 1OyFNXZYrF3/ihm0EcT3ANbBCKvdVz+4VcUy6KWmtGX7X8bJuCxLWYI= Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id C7D1D594058 for ; Mon, 10 Nov 2014 10:43:40 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id x12so9685145wgg.32 for ; Mon, 10 Nov 2014 10:43:39 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.98.233 with SMTP id el9mr32276737wib.3.1415643123047; Mon, 10 Nov 2014 10:12:03 -0800 (PST) Received: by 10.216.32.135 with HTTP; Mon, 10 Nov 2014 10:12:02 -0800 (PST) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> <87y4rkxntk.fsf@alice.fifthhorseman.net> Date: Mon, 10 Nov 2014 12:12:02 -0600 Message-ID: From: Nico Williams To: Erik Nygren Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4CoQ8Py_xdeus0reJ2lU0UgU-X8 Cc: "saag@ietf.org" , Michael Richardson Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 10 Nov 2014 18:43:42 -0000 On Mon, Nov 10, 2014 at 11:58 AM, Erik Nygren wrote: > [...] This strikes me as a good idea. Attacks involving moving the time into the far future are always going to be a problem on RTC-less devices, and that means that a UI will be needed (even if it's just a hard reset button). Nico -- From nobody Mon Nov 10 12:17:41 2014 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 AC1041ACD61 for ; Mon, 10 Nov 2014 12:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] 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 desCY8FDbLLl for ; Mon, 10 Nov 2014 12:17:38 -0800 (PST) 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 882B11A6F98 for ; Mon, 10 Nov 2014 12:17:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 3E092E2031; Mon, 10 Nov 2014 15:17:37 -0500 (EST) 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 16481-04; Mon, 10 Nov 2014 15:17:34 -0500 (EST) Received: from securerf.ihtfp.org (s2001067c03700176ea2aeafffe7d0235.wireless-a.v6.meeting.ietf.org [IPv6:2001:67c:370:176:ea2a:eaff:fe7d:235]) (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 5E213E200A; Mon, 10 Nov 2014 15:17:34 -0500 (EST) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id sAAKHV2M026622; Mon, 10 Nov 2014 15:17:31 -0500 From: Derek Atkins To: Watson Ladd References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> <87y4rkxntk.fsf@alice.fifthhorseman.net> Date: Mon, 10 Nov 2014 15:17:30 -0500 In-Reply-To: (Watson Ladd's message of "Sun, 9 Nov 2014 11:01:07 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/saag/h--hxoDS6cNRVy70EAh7ownShSI Cc: Michael Richardson , "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 10 Nov 2014 20:17:39 -0000 Watson, Watson Ladd writes: > All motherboards contain a RTC. There is a standard, host-based, > security measure for NTP that prevents running the clock backwards. > This measure is not used. Yes, it really is as simple as removing an > argument from a boot script. You're thinking too big. Perhaps all x86_64-level motherboards contain an RTC. But not all *systems* contain an RTC, and they most definitely don't always have a battery to maintain it across reboots. You don't even have to get very small to get into this level of system; many ARM SoC systems fall into this category. Moreover, once you get into even smaller systems you're more likely to hit this situation. For example, when my Wandboard (ARM SoC running Linux) boots up it comes up at January 1, 1970, until it contacts the network and obtains a time (usually about 10-30 seconds after power-up). So it behooves us to have a way to securely obtain a current time reference, because these levels are systems are the major growing category. > Sincerely, > Watson Ladd -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Nov 10 12:21:26 2014 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 182AF1ACE1A for ; Mon, 10 Nov 2014 12:21:24 -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] 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 bn8wnxpowojb for ; Mon, 10 Nov 2014 12:21:21 -0800 (PST) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4031A9077 for ; Mon, 10 Nov 2014 12:21:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 4311DE2036; Mon, 10 Nov 2014 15:21:18 -0500 (EST) 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 16481-07; Mon, 10 Nov 2014 15:21:16 -0500 (EST) Received: from securerf.ihtfp.org (s2001067c03700176ea2aeafffe7d0235.wireless-a.v6.meeting.ietf.org [IPv6:2001:67c:370:176:ea2a:eaff:fe7d:235]) (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 CDAD5E2035; Mon, 10 Nov 2014 15:21:15 -0500 (EST) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id sAAKLDAN026725; Mon, 10 Nov 2014 15:21:13 -0500 From: Derek Atkins To: Nico Williams References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> <87y4rkxntk.fsf@alice.fifthhorseman.net> Date: Mon, 10 Nov 2014 15:21:12 -0500 In-Reply-To: (Nico Williams's message of "Mon, 10 Nov 2014 10:41:43 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_qbhIHZtxu7WcYAgob41kb-AhlU Cc: "saag@ietf.org" , Michael Richardson Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 10 Nov 2014 20:21:25 -0000 Nico Williams writes: > I agree: stepping the RTC backwards should never be taken lightly > (prompt the user if you can; do not step back if you can't prompt). So you've never had a system whose clock ran fast? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Nov 10 12:28:47 2014 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 F0D271ACE6F for ; Mon, 10 Nov 2014 12:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 nc1OGKo80UFB for ; Mon, 10 Nov 2014 12:28:45 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DA8191ACE18 for ; Mon, 10 Nov 2014 12:27:52 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 9464F26406C for ; Mon, 10 Nov 2014 12:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=RORVnE+5Xm94IbpLz7CL O5DT2ZQ=; b=UK/VnDhhjCaeWwhlQYM7wL4ubkAFstfH8Pdp7Wm8fV/U4vrkvjDB J4z6v9LHksG/wdAeBhOvn6x0uwG/yq7qm8SHIrSJZpoBmIeY2P8kYzuup3YnPtDF 0gwO5mSKVdvL3sFI/SUzOkHRoP8suVfe+wXgSvf6F/16xjw8DobXuns= Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 6B43426406B for ; Mon, 10 Nov 2014 12:27:52 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id n12so10247056wgh.41 for ; Mon, 10 Nov 2014 12:27:50 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.19.234 with SMTP id i10mr34645920wie.28.1415651270744; Mon, 10 Nov 2014 12:27:50 -0800 (PST) Received: by 10.216.32.135 with HTTP; Mon, 10 Nov 2014 12:27:50 -0800 (PST) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> <87y4rkxntk.fsf@alice.fifthhorseman.net> Date: Mon, 10 Nov 2014 14:27:50 -0600 Message-ID: From: Nico Williams To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/W0HJ65c7sRTGIu-ghcG9J0lLlIM Cc: "saag@ietf.org" , Michael Richardson Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 10 Nov 2014 20:28:46 -0000 On Mon, Nov 10, 2014 at 2:21 PM, Derek Atkins wrote: > Nico Williams writes: > >> I agree: stepping the RTC backwards should never be taken lightly >> (prompt the user if you can; do not step back if you can't prompt). > > So you've never had a system whose clock ran fast? I have. There needs to be some tolerance (what Kerberos calls max skew). Beyond that tolerance you need user input. If an RTC runs way too fast then the user can change the tolerance on that system, or else return the busted system and get a new one. From nobody Mon Nov 10 13:24:27 2014 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 E946F1A1B2F; Mon, 10 Nov 2014 13:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 J1vAyimSKsZ6; Mon, 10 Nov 2014 13:24:21 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFC1A1A1B58; Mon, 10 Nov 2014 13:24:19 -0800 (PST) Received: from dhcp-b3ac.meeting.ietf.org (unknown [31.133.179.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B997222E1F4; Mon, 10 Nov 2014 16:24:12 -0500 (EST) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_45218A70-4565-4D45-B2F2-0048C6C8F1A0"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 10 Nov 2014 11:23:10 -1000 References: <20141110212038.12978.55746.idtracker@ietfa.amsl.com> To: pkix@ietf.org, saag@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/SiPGnbPoGE-q21fl6RrqTOSfZKQ Subject: [saag] New Version Notification for draft-seantek-certfrag-01.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, 10 Nov 2014 21:24:24 -0000 --Apple-Mail=_45218A70-4565-4D45-B2F2-0048C6C8F1A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 draft-seantek-certfrag-01 has been posted. It incorporates feedback = received thus far (namely from Sean Turner). Should be close to done=85 Sean Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-seantek-certfrag-01.txt > Date: November 10, 2014 at 11:20:38 AM HST >=20 > A new version of I-D, draft-seantek-certfrag-01.txt > has been successfully submitted by Sean Leonard and posted to the > IETF repository. >=20 > Name: draft-seantek-certfrag > Revision: 01 > Title: URI Fragment Identifiers for the = application/pkix-cert Media Type > Document date: 2014-11-10 > Group: Individual Submission > Pages: 4 > URL: = http://www.ietf.org/internet-drafts/draft-seantek-certfrag-01.txt > Status: = https://datatracker.ietf.org/doc/draft-seantek-certfrag/ > Htmlized: http://tools.ietf.org/html/draft-seantek-certfrag-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-seantek-certfrag-01 >=20 > Abstract: > This memo describes Uniform Resource Identifier (URI) fragment > identifiers for PKIX certificates, which are identified with the > Internet media type application/pkix-cert. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 --Apple-Mail=_45218A70-4565-4D45-B2F2-0048C6C8F1A0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO7TCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqT PDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTMxMTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J 9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2g uKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G 53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia33JN+ oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50 ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMf WE2/5myX518DB+kTa5iQDbKYRuJp3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmI H4kfI4LWrY8XrPhlX3JmHjD6hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3 jx9VF/gA3vqYpL+jNumInz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d 9ljRDEiAts5OopkeeFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYID rjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MTExMDIxMjQxMFowIwYJKoZIhvcNAQkEMRYEFNazJMH04YQ6JzC/3RKNwSPi VTJUMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQDKkzwxu6lupsyQvhKSvQd8MIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEBBQAE ggEAfCi93+ySUBVHWq8kIqNqYkWh9KgIvh+8l8KQsSv+Tu4CDKCJrGmJA1i+29tDA/xZRTcY7iro QAxrSfLA23U75OEHs62YL+SeAq5tGleoQV9onr5SvEEPlxnAXAzE0eUmAHt9Y2RHMM6VxuQhgfBc 1LmflWWeQO22lPdUWLLycVHFLSGZr63AeyoM2gqvcwfKjt4g3QRu9Y6aUoxw65SxEIoUz2oMSbyl KnhUd0snr1FbF0yjQSNOocNyLYr0fVb/2wzdS7ZEtfNLJWRsOMA8e9HqDCjpqEWSAwW7puWFgdvW 2MkTjA49o4PAp+ADi/jVcYVeBuH4AMDNdFUUJpg90QAAAAAAAA== --Apple-Mail=_45218A70-4565-4D45-B2F2-0048C6C8F1A0-- From nobody Mon Nov 10 13:29:34 2014 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 80CF21A1BFC for ; Mon, 10 Nov 2014 13:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 PFDgUxnVH97v for ; Mon, 10 Nov 2014 13:29:28 -0800 (PST) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.14.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA2441A1BF8 for ; Mon, 10 Nov 2014 13:29:28 -0800 (PST) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id EFDFC3F8B4A46; Mon, 10 Nov 2014 15:29:27 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway05.websitewelcome.com (Postfix) with ESMTP id DE6F13F8B49B3 for ; Mon, 10 Nov 2014 15:29:27 -0600 (CST) Received: from [31.133.163.154] (port=49169 helo=dhcp-a39a.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XnwWd-0005MZ-5k; Mon, 10 Nov 2014 15:29:27 -0600 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Mon, 10 Nov 2014 11:29:26 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <08B07129-0714-463D-BF4B-20305F0B5902@ieca.com> References: <20141110212038.12978.55746.idtracker@ietfa.amsl.com> To: Sean Leonard X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 31.133.163.154 X-Exim-ID: 1XnwWd-0005MZ-5k X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-a39a.meeting.ietf.org) [31.133.163.154]:49169 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/saag/6uZxwXxyvJpe0z6PrAyfIW1mm7c Cc: pkix@ietf.org, saag@ietf.org Subject: Re: [saag] New Version Notification for draft-seantek-certfrag-01.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, 10 Nov 2014 21:29:30 -0000 Yep this version addresses my comments. spt On Nov 10, 2014, at 11:23, Sean Leonard wrote: > draft-seantek-certfrag-01 has been posted. It incorporates feedback = received thus far (namely from Sean Turner). >=20 > Should be close to done=85 >=20 > Sean >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-seantek-certfrag-01.txt >> Date: November 10, 2014 at 11:20:38 AM HST >>=20 >> A new version of I-D, draft-seantek-certfrag-01.txt >> has been successfully submitted by Sean Leonard and posted to the >> IETF repository. >>=20 >> Name: draft-seantek-certfrag >> Revision: 01 >> Title: URI Fragment Identifiers for the = application/pkix-cert Media Type >> Document date: 2014-11-10 >> Group: Individual Submission >> Pages: 4 >> URL: = http://www.ietf.org/internet-drafts/draft-seantek-certfrag-01.txt >> Status: = https://datatracker.ietf.org/doc/draft-seantek-certfrag/ >> Htmlized: http://tools.ietf.org/html/draft-seantek-certfrag-01 >> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-seantek-certfrag-01 >>=20 >> Abstract: >> This memo describes Uniform Resource Identifier (URI) fragment >> identifiers for PKIX certificates, which are identified with the >> Internet media type application/pkix-cert. >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Mon Nov 10 15:06:19 2014 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 434441A86F6 for ; Mon, 10 Nov 2014 15:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.733 X-Spam-Level: X-Spam-Status: No, score=0.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 wCr7SW-N_Joa for ; Mon, 10 Nov 2014 15:06:13 -0800 (PST) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [67.18.22.82]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D401ACDF3 for ; Mon, 10 Nov 2014 15:06:11 -0800 (PST) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 67C9FC9247C49; Mon, 10 Nov 2014 17:06:10 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway14.websitewelcome.com (Postfix) with ESMTP id E5EFEC9247B7A for ; Mon, 10 Nov 2014 17:06:09 -0600 (CST) Received: from [31.133.163.154] (port=49395 helo=dhcp-a39a.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xny2C-0007ZR-7x; Mon, 10 Nov 2014 17:06:08 -0600 Content-Type: multipart/signed; boundary="Apple-Mail=_54F1270D-CD98-44B5-BC33-440B2A8535A4"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <545E358C.9010405@seantek.com> Date: Mon, 10 Nov 2014 13:06:04 -1000 Message-Id: <6913EDA6-738F-4824-A307-331AFED8FAD4@ieca.com> References: <20141026225606.23674.92818.idtracker@ietfa.amsl.com> <545E358C.9010405@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 31.133.163.154 X-Exim-ID: 1Xny2C-0007ZR-7x X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-a39a.meeting.ietf.org) [31.133.163.154]:49395 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Jkw5NuI7lBxE4bdgUCVqPY6VBh4 Cc: "pkix@ietf.org" , saag@ietf.org Subject: Re: [saag] PKCS #9 LDAP Registrations New Version Notification for draft-seantek-ldap-pkcs9-01.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, 10 Nov 2014 23:06:14 -0000 --Apple-Mail=_54F1270D-CD98-44B5-BC33-440B2A8535A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 RFC 4510 is kind of a lame LDAP security reference because it just says = this: LDAP security considerations are discussed in each document comprising the technical specification. Maybe 4512 is better because it at least mentions privacy. Because I=92m = sure you=92re going to get hit with a =93where=92s your privacy = considerations=94 maybe you should have a look at the SCIM draft: = http://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/?include_text=3D= 1 At a minimum you=92re going to note which of these elements are privacy = sensitive. You may end up saying those identified elements must be = returned over a protected channel. spt On Nov 08, 2014, at 05:23, Sean Leonard wrote: > Hello pkix/saag: >=20 > In September I published an initial Internet-Draft on registering PKCS = #9 values (such as dateOfBirth and userPKCS12) in the IANA LDAP = Parameters registry. >=20 > I got a few comments from the ldap list, so I revised it to -01 last = month. Since IETF 91 is coming up, I thought I would at least inform = these lists of the work. A lot of security software (such as OpenSSL) = uses LDAP Parameters with varying degrees of (in)formality, so the = purpose of this short 7-page draft is just to finish off what PKCS #9 = started. >=20 > Comments welcome. Thanks, >=20 > Sean >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-seantek-ldap-pkcs9-01.txt >> Date: October 26, 2014 at 3:56:06 PM PDT >> To: Sean Leonard , "Sean Leonard" = >>=20 >>=20 >> A new version of I-D, draft-seantek-ldap-pkcs9-01.txt >> has been successfully submitted by Sean Leonard and posted to the >> IETF repository. >>=20 >> Name: draft-seantek-ldap-pkcs9 >> Revision: 01 >> Title: >>=20 >> =20 >>=20 >> =20 >> Lightweight Directory Access Protocol (LDAP) Registrations for PKCS = #9 >> Document date: 2014-10-26 >> Group: >>=20 >> =20 >>=20 >> =20 >> Individual Submission >> Pages: >>=20 >> =20 >>=20 >> =20 >> 7 >> URL: = http://www.ietf.org/internet-drafts/draft-seantek-ldap-pkcs9-01.txt >> Status: = https://datatracker.ietf.org/doc/draft-seantek-ldap-pkcs9/ >> Htmlized: = http://tools.ietf.org/html/draft-seantek-ldap-pkcs9-01 >> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-seantek-ldap-pkcs9-01 >>=20 >> Abstract: >> PKCS #9 includes several useful definitions that are not yet >> reflected in the LDAP IANA registry. This document adds those >> definitions to the IANA registry. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail=_54F1270D-CD98-44B5-BC33-440B2A8535A4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFQTCCBT0w ggMloAMCAQICCQCdWMxKNutUfDANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE ChMKSUVDQSwgSW5jLjAeFw0xNDA0MDIxNDU0MjBaFw0xNTA0MDIxNDU0MjBaMDgxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAKaIbxySgDxs/xq2w7+C9AGF8hT65ppo9bKXmJ9iOmR/M2DC x9T38oMuPGctVavcxXWYWxCMRCOHuDQKZiIlA8tD5VYGAzBid+4t6hrqAuis9WbWwtHfGVqOnZtP q3iNM+KqYOOz5OQ0OzlubgRrq3LuKirytxojE1WShnNwocouUwv8KDtbfbiKXcXKBgEqaz4qCuMJ YK4owwz2cH37OoWM9b5gWQ4EP/S94J5t2CwtfYM+f0n+Lk3LvL+kZUxIcQNUmpT8RM8D0M/sYbSm RtSLrAc0drV8K7OGBv20vpXewKvom56PHpRRsXK8tclSjY3ogqUjNfShpD98psV3OBcCAwEAAaOC AV4wggFaMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgXgMFIGA1UdIwRLMEmAFAB0bEnlyVJhcU1W OKthyfLh5fsNoSakJDAiMQswCQYDVQQGEwJVUzETMBEGA1UEChMKSUVDQSwgSW5jLoIJAMQtcFwx NPDPMB0GA1UdDgQWBBSrm8x24iKtr6Lnns5BPgGKRM1OMjAtBgNVHREEJjAkgRBUdXJuZXJTQGll Y2EuY29tgRB0dXJuZXJzQGllY2EuY29tMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly93d3cuaWVj YS5jb20vcGtpL2llY2Etcm9vdC1jcmwuY3JsMBcGA1UdIAQQMA4wDAYKKwYBBAGB1wAAADBGBggr BgEFBQcBAQQ6MDgwNgYIKwYBBQUHMAKGKmh0dHA6Ly93d3cuaWVjYS5jb20vcGtpL2llY2Etcm9v dC1jZXJ0LmRlcjANBgkqhkiG9w0BAQsFAAOCAgEAYOZQp8Xa4UYvDJWBlrNidIjp0IbKF6FsPb9S FJynTMNiZU42UvsF3MXJEB48OIZKCO15aM+pqjp4Qk5KFlprdOAvlK44B/DQh1F2XU9d9H8WiVfg o0d7Zl+ynDPsEr+yBN5X3AcHo636wPLt6IZPrxzecLgm837HygDIeh0ShesqTg6VlfQ1D94KYBPs 7xBmoZqqCVqbOySakgjdOxxPWV23bTTEsbQ6diwVb370t0xTfuMGcTRrn2iN6tXLY0FtXKXhNlXy a2Rsclenx+rUFlAtVIxWCUYNe969c+F4T/WTV1TtRS3nRLYTM7iDFTiD1qiY+qvAiMxGv7uDPSsK PdoenKz68KNLElo9993AzxdrU8S6pwwfi6gFGeYF8eInidKaWKqBqniKSEzza1YgVfdXhJn+YxCX WtYL+8aowiXkeLa0qFhN7qTcqSfaG5Fsz4BbuLo/Hr1dLi0pl+APvcQt7YA58zgovMYV5b5mSUAt s9ecIdIlcirYYjQmC9zif4FdCT+ee5DJMRjvibfdG8dAUrkkmFkOiecwi0Db9PHgfjr2+3S/Izf3 k06uRnlZhcnfAsOO/4dUDsfc9Xr4uta0wt1dZHVP/XzTI7w/mXwBfZPnIZvlhv5olpeXFuXom819 I10cyxToXnRcgPuTrXqscLpuKZeHSoO88252FP4xggI4MIICNAIBATAvMCIxCzAJBgNVBAYTAlVT MRMwEQYDVQQKEwpJRUNBLCBJbmMuAgkAnVjMSjbrVHwwCQYFKw4DAhoFAKCB3zAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDExMTAyMzA2MDVaMCMGCSqGSIb3DQEJ BDEWBBS0uO2aMUOuyIgdMIOlhVfZ9D54xjA+BgkrBgEEAYI3EAQxMTAvMCIxCzAJBgNVBAYTAlVT MRMwEQYDVQQKEwpJRUNBLCBJbmMuAgkAnVjMSjbrVHwwQAYLKoZIhvcNAQkQAgsxMaAvMCIxCzAJ BgNVBAYTAlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuAgkAnVjMSjbrVHwwDQYJKoZIhvcNAQEBBQAE ggEAZ9Q2HSZKp8rmdxrJn1XMCt8r+kTGwtF4tBp8ba9Dai/EMeMfD6fuLNBEFTH81RWsejEl8iSc R9/nnrvoBB9G9YJp2U+YngHUaHQ50cpPQt9jvH/2JEfOq6v1QyC3OjupR8mzqI7RE7hvL0OQ+oLc OU9Ddt2jfXOYXyleJJ1pKUzEGDjAm7qkre5Ats9JC6uDY7tFE2VyhL6tXxK1mHjekc7DOVKPQ0ch wnOTh7Bq7yeQsnau3RKg7yICtybWIXlbytI4HoheHRoDGOGeGLE2Rf0x5SYxcLkA9PLj2S0I9HL7 htjmO0SDCawWxEMpyijsnxic+c/ICcCa8sQDlxX0MAAAAAAAAA== --Apple-Mail=_54F1270D-CD98-44B5-BC33-440B2A8535A4-- From nobody Mon Nov 10 18:35:33 2014 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 C72791AD484 for ; Mon, 10 Nov 2014 18:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 VwW-_ndDDePo for ; Mon, 10 Nov 2014 18:35:29 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5DF1AD478 for ; Mon, 10 Nov 2014 18:35:28 -0800 (PST) X-AuditID: 1209190c-f795e6d000006c66-ef-546175effef3 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 73.2F.27750.FE571645; Mon, 10 Nov 2014 21:35:27 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id sAB2ZR19031357; Mon, 10 Nov 2014 21:35:27 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sAB2ZOC0015712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Nov 2014 21:35:26 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sAB2ZOhH011348; Mon, 10 Nov 2014 21:35:24 -0500 (EST) Date: Mon, 10 Nov 2014 21:35:24 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> <87y4rkxntk.fsf@alice.fifthhorseman.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6nrvu+NDHE4Pp0XYtT146wWUzp72Ry YPJ4eeoco8eSJT+ZApiiuGxSUnMyy1KL9O0SuDK+tixjLVjPWrFi0SvmBsYFLF2MnBwSAiYS j14tZ4OwxSQu3FsPZHNxCAnMZpK48HQvI4SzkVHiZMt7VpAqIYFDTBIP51hBJBoYJbbN6wMb xSKgLTGzZzs7iM0moCIx881GsLEiApoS1+ctBbOZBZQlWq+eZgSxhQUsJKZffQxWzykQKHG2 4RuQzcHBK+Ao0bLbE2L+HRaJ9b/3gdWICuhIrN4/BWwXr4CgxMmZT1ggZmpJLJ++jWUCo+As JKlZSFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrq5WaW6KWmlG5iBIUqpyTPDsY3B5UO MQpwMCrx8Gr4J4YIsSaWFVfmHmKU5GBSEuX1LAQK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuGt TwDK8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8HIDY1JIsCg1PbUi LTOnBCHNxMEJMpwHaPi2EpDhxQWJucWZ6RD5U4y6HC1Nb3uZhFjy8vNSpcR5b4EUCYAUZZTm wc2BpZhXjOJAbwnzHgap4gGmJ7hJr4CWMAEteVeSALKkJBEhJdXAKF22y/NpTsZ0BW7llNVC WT1Vxzb+PbpPfcPlY9FbuIQPelT9N5/ueedybUxZZPuET567433f2t5ZOltJYso0Dt1jRrv2 T1nb6LauNn1nstVPqTU20l6962Pj9f/Hsbe7z046snH7pGebOTQV1WZtS7COzvu3tIx/yjmP mScXasxpcJadGjXpjhJLcUaioRZzUXEiAChEkZ0MAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/saag/XzlcVndC4sErQg12VIk-QDLJypo Cc: "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 11 Nov 2014 02:35:31 -0000 On Mon, 10 Nov 2014, Nico Williams wrote: > Perhaps we should be reaching this conclusion: the time infrastructure > is as critical as a PKI's roots. I don't know if I'm confident enough to say "as critical as", but it does seem pretty critical. CT is all about signed timestamps; lots of things can go wonky if the different actors have different ideas of the current time. (Corrupting a log server's idea of the current time will probably render that log useless!) If I remember correctly, Chrome brands a build timestamp into official builds and disables certain behavior if that time is too far from the current time. I'm sure there are other places. -Ben From nobody Mon Nov 10 19:48:22 2014 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 98B991AD533 for ; Mon, 10 Nov 2014 19:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 PNxUb0YtH3fX for ; Mon, 10 Nov 2014 19:48:18 -0800 (PST) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A85C1AD52A for ; Mon, 10 Nov 2014 19:48:18 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id b6so4467146yha.17 for ; Mon, 10 Nov 2014 19:48:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fi7O1rV9+RJgUgB27qVdcom57NBKpiCTKRS/1TBJxbM=; b=z4+hqN9S4PCsEXDRkbm8UeURUQ6pCJZqLpz1EQTIKZBu66dLNr4uYx15OziNJfEO6k HOVaZaJ87x3Lh38nWqQHr7d/lwlQxBBkANiwFdHd73d4IBVtWMoi9ECkiVugX2IrSr8t 5hwkppIHx/CQUnUgam2d6cpjXl+gW2H3cCPCKBKU0OMtAI5u4dgTkFZhFPoi4EzVyDzU 875nRpZw396UJpIk9p5pIU8bFTLTSeCa+3uOs4NMODBEqMs7pEQakMwYy4EuAZRXbOM9 LmEkp4WHIrcHlr1KkNulOndkk6warg2n4AO/UQqy9qc9uHdMS+62tM1uUQ0aPnBRkgWX zRCQ== MIME-Version: 1.0 X-Received: by 10.236.30.197 with SMTP id k45mr35158939yha.163.1415677697428; Mon, 10 Nov 2014 19:48:17 -0800 (PST) Received: by 10.170.195.203 with HTTP; Mon, 10 Nov 2014 19:48:17 -0800 (PST) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> <87y4rkxntk.fsf@alice.fifthhorseman.net> Date: Mon, 10 Nov 2014 19:48:17 -0800 Message-ID: From: Watson Ladd To: Derek Atkins Content-Type: multipart/alternative; boundary=089e01634d3445950905078d26f4 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/jU7pjrf7ELmrjfYhWLWKikeUK_g Cc: Michael Richardson , "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 11 Nov 2014 03:48:20 -0000 --089e01634d3445950905078d26f4 Content-Type: text/plain; charset=UTF-8 On Nov 10, 2014 12:17 PM, "Derek Atkins" wrote: > > Watson, > > Watson Ladd writes: > > > All motherboards contain a RTC. There is a standard, host-based, > > security measure for NTP that prevents running the clock backwards. > > This measure is not used. Yes, it really is as simple as removing an > > argument from a boot script. > > You're thinking too big. Perhaps all x86_64-level motherboards contain > an RTC. But not all *systems* contain an RTC, and they most definitely > don't always have a battery to maintain it across reboots. You don't > even have to get very small to get into this level of system; many ARM > SoC systems fall into this category. Moreover, once you get into even > smaller systems you're more likely to hit this situation. > > For example, when my Wandboard (ARM SoC running Linux) boots up it comes > up at January 1, 1970, until it contacts the network and obtains a time > (usually about 10-30 seconds after power-up). > > So it behooves us to have a way to securely obtain a current time > reference, because these levels are systems are the major growing > category. You would think this is why NTP security exists. And indeed there is a protocol claiming to secure NTP. But that protocol doesn't work for many uses. And a revision is being proposed that still doesn't work. It's not really a SAAG issue, but an NTP issue. The SAAG issue I want to talk about is structural: Why do drafts go through the process when they don't solve the problem they are supposed to solve? Why do we see changes to protocols made for "extra security" not coupled with effective action to remove the old insecure versions? Why do we see old attacks get new life again and again? If you want to make usable, secure, cryptography, the IETF is not the place. No one sees any benefit to making OTR into an RFC, or the recent work on asynchronous forward secure messaging. We're not getting interoperable standards which we need if we want to encrypt every packet. Instead we're excited by authenticating public keys with RSA-1024, and the real work happens elsewhere, and doesn't become ubiquitous. Sincerely, Watson Ladd --089e01634d3445950905078d26f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Nov 10, 2014 12:17 PM, "Derek Atkins" <derek@ihtfp.com> wrote:
>
> Watson,
>
> Watson Ladd <watsonbladd@gmail.com> writes:
>
> > All motherboards contain a RTC. There is a standard, host-based,<= br> > > security measure for NTP that prevents running the clock backward= s.
> > This measure is not used. Yes, it really is as simple as removing= an
> > argument from a boot script.
>
> You're thinking too big.=C2=A0 Perhaps all x86_64-level motherboar= ds contain
> an RTC.=C2=A0 But not all *systems* contain an RTC, and they most defi= nitely
> don't always have a battery to maintain it across reboots.=C2=A0 Y= ou don't
> even have to get very small to get into this level of system; many ARM=
> SoC systems fall into this category.=C2=A0 Moreover, once you get into= even
> smaller systems you're more likely to hit this situation.
>
> For example, when my Wandboard (ARM SoC running Linux) boots up it com= es
> up at January 1, 1970, until it contacts the network and obtains a tim= e
> (usually about 10-30 seconds after power-up).
>
> So it behooves us to have a way to securely obtain a current time
> reference, because these levels are systems are the major growing
> category.

You would think this is why NTP security exists. And indeed = there is a protocol claiming to secure NTP.

But that protocol doesn't work for many uses. And a revi= sion is being proposed that still doesn't work.

It's not really a SAAG issue, but an NTP issue. The SAAG issue I wan= t to talk about is structural:

Why do drafts go through the process when they don't sol= ve the problem they are supposed to solve? Why do we see changes to protoco= ls made for "extra security" not coupled with effective action to= remove the old insecure versions? Why do we see old attacks get new life a= gain and again?

If you want to make usable, secure, cryptography, the IETF i= s not the place. No one sees any benefit to making OTR into an RFC, or the = recent work on asynchronous forward secure messaging. We're not getting= interoperable standards which we need if we want to encrypt every packet. = Instead we're excited by authenticating public keys with RSA-1024, and = the real work happens elsewhere, and doesn't become ubiquitous.

S= incerely,
Watson Ladd

--089e01634d3445950905078d26f4-- From nobody Tue Nov 11 03:48:08 2014 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 26B951A89C7 for ; Tue, 11 Nov 2014 03:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 n6Jb-AG8aL35 for ; Tue, 11 Nov 2014 03:48:04 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) (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 13A521A89B8 for ; Tue, 11 Nov 2014 03:48:04 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:55822) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Xo9vS-0005lZ-DU (Exim 4.82_3-c0e5623) (return-path ); Tue, 11 Nov 2014 11:47:58 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Xo9vS-0005nS-31 (Exim 4.72) (return-path ); Tue, 11 Nov 2014 11:47:58 +0000 Date: Tue, 11 Nov 2014 11:47:58 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Erik Nygren In-Reply-To: Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> <87y4rkxntk.fsf@alice.fifthhorseman.net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Jn-NkvGbzkf92Uiy_Eb2hvk8JOA Cc: "saag@ietf.org" , Michael Richardson Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 11 Nov 2014 11:48:06 -0000 Erik Nygren wrote: > While there may be no solution for devices powered off for a long time > with neither RTC nor long-term storage, we should explore leveraging > existing PKI roots to ensure monotonic coarse-grained time. For example, > if some intermediary of the PKI roots and DNSSEC TLD roots periodically > signed "current time" and made it available somewhere, clients could > fetch some number of these and update a time floor (minimum allowable > time) if over some number of trusted roots agreed. You could perhaps get this information from the RRSIG records on TLD zones. They aren't great for this purpose since a lot of them have a 24h TTL, but you could plausibly use the maximum inception time from several RRSIGs, possibly after discarding outliers. (And note that most of the TLDs set their inception time to an hour in the past to allow for some clock skew.) Tony. -- f.anthony.n.finch http://dotat.at/ North Rockall, Malin, Hebrides, Bailey: Easterly or southeasterly 5 to 7, occasionally gale 8. Rough or very rough. Rain or showers. Good, occasionally moderate. From nobody Tue Nov 11 12:09:13 2014 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 594B81A19F9 for ; Tue, 11 Nov 2014 12:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594] 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 r3QU_Gi41CdX for ; Tue, 11 Nov 2014 12:09:11 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0D951A1B6F for ; Tue, 11 Nov 2014 12:08:46 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A0179817C1 for ; Tue, 11 Nov 2014 15:08:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1415736525; bh=koGgFbDoBVcr7dkq+bI0+qV8QcgRzTJRUyHmPaZHHSw=; h=Date:From:To:Subject; b=I5J/8KZVLJf185zCSsjSV3GfGnXmvlFqVbwvUXo6u+W61cNMcA5+iDHlRW6MtLQtj zwqyFpNDnoo8dTBxkgYB9azHblY/Cg+lq7JWcp+UmPkbrkNXbVmRUsYYl6kcKfdBC8 E+r9mlztSV+PHvPc//SfCZL+T5E2bH/+uRTLNi80= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sABK8j7J014449 for ; Tue, 11 Nov 2014 15:08:45 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 11 Nov 2014 15:08:45 -0500 (EST) From: Paul Wouters To: saag@ietf.org Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/USGl2AmITxlUkHmLBpD-RXPALEE Subject: [saag] Trans meeting IETF91 summary 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, 11 Nov 2014 20:09:12 -0000 Work on 6962bis continues, but PreCertificate Format and Log Acceptance criteria still have no concensus. Scaffolding documents were created for Gossip message format and HTTP/TLS transport. Confirmation there is quite an interest in CT for DNSSEC and CT for Binaries, which the WG will pursue for adoption once the core documents are in better shape. Paul & Melinda From nobody Tue Nov 11 15:27:06 2014 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 7971A1A6FD2 for ; Tue, 11 Nov 2014 15:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] 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 QUrb7KB6uBhD for ; Tue, 11 Nov 2014 15:26:55 -0800 (PST) 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 3B5E81A6F56 for ; Tue, 11 Nov 2014 15:26:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 1347DE2034; Tue, 11 Nov 2014 18:26:46 -0500 (EST) 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 25316-08; Tue, 11 Nov 2014 18:26:44 -0500 (EST) Received: from securerf.ihtfp.org (s2001067c03700176ea2aeafffe7d0235.wireless-a.v6.meeting.ietf.org [IPv6:2001:67c:370:176:ea2a:eaff:fe7d:235]) (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 AD7CDE2031; Tue, 11 Nov 2014 18:26:43 -0500 (EST) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id sABNQeJd019411; Tue, 11 Nov 2014 18:26:40 -0500 From: Derek Atkins To: Watson Ladd References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> <87y4rkxntk.fsf@alice.fifthhorseman.net> Date: Tue, 11 Nov 2014 18:24:49 -0500 In-Reply-To: (Watson Ladd's message of "Mon, 10 Nov 2014 19:48:17 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Vq7hLencYTq52HUSHHncNEinld8 Cc: Michael Richardson , "saag@ietf.org" Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 11 Nov 2014 23:26:56 -0000 Watson Ladd writes: >> So it behooves us to have a way to securely obtain a current time >> reference, because these levels are systems are the major growing >> category. > > You would think this is why NTP security exists. And indeed there is a protocol > claiming to secure NTP. > > But that protocol doesn't work for many uses. And a revision is being proposed > that still doesn't work. It doesn't work in the general case. It could certanly work in many cases. For example, I *do* run a couple NTP servers on my home network, so I *could* set up secure NTP to my devices that need it. > It's not really a SAAG issue, but an NTP issue. The SAAG issue I want to talk > about is structural: > > Why do drafts go through the process when they don't solve the problem they are > supposed to solve? Why do we see changes to protocols made for "extra security" > not coupled with effective action to remove the old insecure versions? Why do > we see old attacks get new life again and again? Well, this is a loaded question. What problem was it *supposed* to solve? The problem we're talking about here, secure loose time coordination (e.g. +/- 5s coordination) is definitely NOT the problem that the SNTP group took on. You could ask the question "why didn't they take it on", but that's not a SAAG question, that's a question for the relevant WG and possibly the IESG. You could ask the question "why hasn't anyone taken this on", and that would also not be a SAAG question but one again directed at the IESG. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Nov 11 16:22:54 2014 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 795C11A8A71 for ; Tue, 11 Nov 2014 16:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 WEDVtIx5dXIw for ; Tue, 11 Nov 2014 16:22:49 -0800 (PST) Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id ABE1F1A8A41 for ; Tue, 11 Nov 2014 16:22:49 -0800 (PST) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 715C520046912 for ; Tue, 11 Nov 2014 16:22:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=k827jUhRmcYZ8qhPIZxU EHqawNI=; b=mbprtxie+4DRc3hsrqQ5RdYdS9VjOQhpcPoYWKeUB09CnC7M8ykJ 9OpXiBnhjedwPUVDs5T2xyLeE3cr+8Tb3Irn3yHFjSgsLU+Gi2hnSqQCAWub2ACV NvDC/fRqABT7P7z6kjBziCt2/O1HS6vKJniZRgqudQ9Y3W29uHWurFs= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id 4B6172005D82E for ; Tue, 11 Nov 2014 16:22:49 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id ex7so3264201wid.16 for ; Tue, 11 Nov 2014 16:22:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.19.234 with SMTP id i10mr46027452wie.28.1415751768321; Tue, 11 Nov 2014 16:22:48 -0800 (PST) Received: by 10.216.32.135 with HTTP; Tue, 11 Nov 2014 16:22:48 -0800 (PST) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C739B9DEE40@uxcn10-5.UoA.auckland.ac.nz> <27873.1415044942@sandelman.ca> <8258.1415404113@sandelman.ca> <87y4rkxntk.fsf@alice.fifthhorseman.net> Date: Tue, 11 Nov 2014 18:22:48 -0600 Message-ID: From: Nico Williams To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/9yb3YSdKTZ2ornQot0YPIAqITmk Cc: "saag@ietf.org" , Michael Richardson Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 12 Nov 2014 00:22:50 -0000 On Tue, Nov 11, 2014 at 5:24 PM, Derek Atkins wrote: > Watson Ladd writes: >> [...]? > > Well, this is a loaded question. What problem was it *supposed* to > solve? The problem we're talking about here, secure loose time > coordination (e.g. +/- 5s coordination) is definitely NOT the problem > that the SNTP group took on. > > You could ask the question "why didn't they take it on", but that's not > a SAAG question, that's a question for the relevant WG and possibly the > IESG. > > You could ask the question "why hasn't anyone taken this on", and that > would also not be a SAAG question but one again directed at the IESG. Another fair question would be "should we take this on?", but that might require actually making a stab at a specification, a BoF, an implementation. It'd be nicer if we could nudge the NTP WG to take it on. Nico -- From nobody Tue Nov 11 16:32:51 2014 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 8C1EE1A885E for ; Tue, 11 Nov 2014 16:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 R0dE1VPMNKCQ for ; Tue, 11 Nov 2014 16:32:48 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8211A7032 for ; Tue, 11 Nov 2014 16:32:48 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id E42E076805C for ; Tue, 11 Nov 2014 16:32:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=BVommDTuQb/UrV2Z9lVtz1h X74Y=; b=JlihG9vXjvVORR75z/O6ruJq92KtzAZIB2ubXMWMbiQoS4kb9AU8Od2 XUqpyZD2kwIrcQ+YaAtlwFMF0+UNQGkZpxpWFGaHmuGpbE0r2/Gcn/lgZ7+9d/Ux HX6cc3uWJmcxKqgxiCpBJu/i7KgbEO4Wg4N4zH1f7lY1dMHV3P24= Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id BD4AC768057 for ; Tue, 11 Nov 2014 16:32:47 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id ex7so3301903wid.14 for ; Tue, 11 Nov 2014 16:32:46 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.20.173 with SMTP id o13mr18220801wie.70.1415752366902; Tue, 11 Nov 2014 16:32:46 -0800 (PST) Received: by 10.216.32.135 with HTTP; Tue, 11 Nov 2014 16:32:46 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Nov 2014 18:32:46 -0600 Message-ID: From: Nico Williams To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/CIF-pK-cmDv9vxQhUVNbc28_bew Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 12 Nov 2014 00:32:48 -0000 If NTP WG is concluded, it should be marked as such. It's not, but it looks very stale. Nico -- From nobody Tue Nov 11 17:40:39 2014 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 57F641A8A75 for ; Tue, 11 Nov 2014 17:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 4Rv_0VT0_Qh0 for ; Tue, 11 Nov 2014 17:40:36 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CBA011A87AB for ; Tue, 11 Nov 2014 17:40:36 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 908FA20046B15 for ; Tue, 11 Nov 2014 17:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=Laclg/pn95wjVbjZuCRZHy9 geH0=; b=P5Mh889uY2r65xtlUrJvvp3cd7V4vm8ckPvAYKDGFfA4+66jdANY4Q5 BQX0rRf4QGOYH9q0xp7gK7RZwk/yKrJlNGIgpattTpXqZB5+09TYPLQlrZ1/GHIm xub+neAJbiTwZmo2EQjFc5p2Dkv3kAmiiUaL3Bj4ExeKNCJFTgEQ= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 6ACDD20046915 for ; Tue, 11 Nov 2014 17:40:36 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id d1so3371979wiv.15 for ; Tue, 11 Nov 2014 17:40:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.240.4 with SMTP id vw4mr14074446wjc.36.1415756435479; Tue, 11 Nov 2014 17:40:35 -0800 (PST) Received: by 10.216.32.135 with HTTP; Tue, 11 Nov 2014 17:40:35 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Nov 2014 19:40:35 -0600 Message-ID: From: Nico Williams To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/gAEAj9ZLhluVXpD5GeVoakJ8sQ4 Subject: Re: [saag] NTP security, and thoughts on Hawaii 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, 12 Nov 2014 01:40:37 -0000 Oh, har, it's been pointed out that NTP WG does meet this week. Apologies for the noise. From nobody Wed Nov 12 17:11:41 2014 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 5D0BE1A0354; Wed, 12 Nov 2014 17:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 MmnYFpGXVvO8; Wed, 12 Nov 2014 17:11:19 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECCF31A00AD; Wed, 12 Nov 2014 17:11:18 -0800 (PST) Received: from dhcp-b3ac.meeting.ietf.org (unknown [31.133.179.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F3D2422E1F4; Wed, 12 Nov 2014 20:11:11 -0500 (EST) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_905FBF98-5B8F-497E-9FFE-4408CBDD8DC1"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 12 Nov 2014 15:10:14 -1000 References: <20141113010325.6972.40106.idtracker@ietfa.amsl.com> To: saag@ietf.org, pkix@ietf.org, smime@ietf.org Message-Id: <0A1D811C-DB7A-49FD-84E4-4816334A400E@seantek.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/aw3p9rLoAkrgzlPSTYz3uMnJJE8 Subject: [saag] Fwd: New Version Notification for draft-josefsson-pkix-textual-08.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, 13 Nov 2014 01:11:27 -0000 --Apple-Mail=_905FBF98-5B8F-497E-9FFE-4408CBDD8DC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Per Yoav Nir=92s request, pkix-textual was updated to move PKCS #8 = [RFC5208] to Informative. This draft should be ready to proceed. Sean Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-josefsson-pkix-textual-08.txt > Date: November 12, 2014 at 3:03:25 PM HST A new version of I-D, draft-josefsson-pkix-textual-08.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-josefsson-pkix-textual Revision: 08 Title: Textual Encodings of PKIX, PKCS, and CMS Structures Document date: 2014-11-12 Group: Individual Submission Pages: 17 URL: = http://www.ietf.org/internet-drafts/draft-josefsson-pkix-textual-08.txt Status: = https://datatracker.ietf.org/doc/draft-josefsson-pkix-textual/ Htmlized: = http://tools.ietf.org/html/draft-josefsson-pkix-textual-08 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-josefsson-pkix-textual-08 Abstract: This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document is intended to articulate the de-facto rules that existing implementations operate by, and to give recommendations that will promote interoperability. The IETF Secretariat= --Apple-Mail=_905FBF98-5B8F-497E-9FFE-4408CBDD8DC1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO7TCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqT PDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTMxMTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J 9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2g uKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G 53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia33JN+ oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50 ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMf WE2/5myX518DB+kTa5iQDbKYRuJp3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmI H4kfI4LWrY8XrPhlX3JmHjD6hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3 jx9VF/gA3vqYpL+jNumInz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d 9ljRDEiAts5OopkeeFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYID rjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MTExMzAxMTEwOFowIwYJKoZIhvcNAQkEMRYEFA3dtTpffSvVwwpWN84GsEIB P3t0MIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQDKkzwxu6lupsyQvhKSvQd8MIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEBBQAE ggEAcx9lqNEEetPy6fxgP3OblpeYf4GS5iZRvcL608BMInXmcsfowj9bqoM0bcXssAZvfewe4PgK aBqOxHpbH2o/+kvsWWldgoXJ4GLLEMCHdtTn00CyZWuKE106huOoN8sQdSYoGFEmbacGnLJ+G10A RJQLMozPrKEc/JhbV0EtIJbQIWziBDnst2+HX1twwJPtsyEDKAfXjLcNiCWITlvNGtD0yK1SBr4f CUwhRFmCrVrN4X8j93lX+qjRbWTjgaRET/XUXTwSMkKxphP2XfRBnP5A9/x33U3I1OOJQXfn6gdZ 71Um+xSwJoq/gBqIrNS1hJB78rTzgj4RDWWiFu8/5QAAAAAAAA== --Apple-Mail=_905FBF98-5B8F-497E-9FFE-4408CBDD8DC1-- From nobody Wed Nov 12 17:15:51 2014 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 326EA1A013B for ; Wed, 12 Nov 2014 17:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.913 X-Spam-Level: * X-Spam-Status: No, score=1.913 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.594, 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 yR1SoSLDB7NQ for ; Wed, 12 Nov 2014 17:15:47 -0800 (PST) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730B11A0030 for ; Wed, 12 Nov 2014 17:15:47 -0800 (PST) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id sAD1FjtM006864 for ; Thu, 13 Nov 2014 10:15:46 +0900 (JST) Received: from TakeVaioVJP13 (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id sAD1Fju3005718 for ; Thu, 13 Nov 2014 10:15:45 +0900 (JST) From: "Takeshi Takahashi" To: Date: Thu, 13 Nov 2014 10:15:48 +0900 Message-ID: <000001cffedf$5c62e1a0$1528a4e0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac/+3x4sUrsQclCCQdynvOFxPvMU6Q== Content-Language: ja X-Virus-Scanned: clamav-milter 0.97.8 at zenith2 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ntu6ottgFun0hbdHIXuKCikcEjM Subject: [saag] MILE report 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, 13 Nov 2014 01:15:49 -0000 MILE met at IETF 91 at 13:00 on Monday. There were about 30 attendees in the room and Jabber. We discussed the three working group drafts. [Enum draft] o the IANA registry issue pointed by AppsDir review was discussed o the compatibility with RFC 5070 was discussed o the resultant direction is clear; we will make sure to confirm the direction on the list and proceed to the IETF last call [IODEF-bis draft] o the last remaining issues of IODEF-bis was discussed, including - the structure of IANA registry - the use of IANA table and "ext-value" for node type - the design of HashData class - the use of iodef:SoftwareType - the structure of the RelatedDNS class, etc. o Some issues are left for the discussion on the mailing list o the authors will sort out the remaining issues within a coupe of weeks, and will start WGLC by the end of January 2015. [Implementation draft] o The draft included new contents, which includes - the NATO's tool - the CERT Polska's tool See http://www.ietf.org/proceedings/91/minutes/minutes-91-mile for the detailed minutes of the meeting. Take From nobody Wed Nov 12 20:45:54 2014 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 A9DB31A1B62; Wed, 12 Nov 2014 20:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 WdJ69uRUAn2G; Wed, 12 Nov 2014 20:45:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA8AD1A1B5E; Wed, 12 Nov 2014 20:45:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLO58816; Thu, 13 Nov 2014 04:45:44 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Nov 2014 04:45:43 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.205]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Thu, 13 Nov 2014 12:45:37 +0800 From: Likepeng To: "saag@ietf.org" , "Ace@ietf.org" Thread-Topic: ACE meeting summary Thread-Index: Ac/+/KRmKDGKezptQZKSRX8bN7DYIw== Date: Thu, 13 Nov 2014 04:45:37 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F2581AF996@SZXEMA501-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.110.77] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F2581AF996SZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/saag/xcRqFci1cwX-_BJc4_JRV7oV5UY Subject: [saag] ACE meeting summary 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, 13 Nov 2014 04:45:49 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F2581AF996SZXEMA501MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ACE WG Meeting IETF 91 - Honolulu Wednesday 12 November 2014, 13:00 - 15:00 HST Chairs: Kepeng Li, Hannes Tschofenig * Use Cases (Sandeep Kumar, 30 mins) - http://datatracker.ietf.org/doc/draft-seitz-ace-usecases/ 7 use cases should cover most interesting IoT areas. Updates include the nu= merous feedback and change of focus, requirements removed. About 20 participants haves read the draft. There were some comments to rem= ove the requirements from the document. Also there were some comments to ad= d more use cases to cover industrial control, etc. Humm result is to adopt this document as WG document, and this will be conf= irmed in the mailing list. * Actors (Carsten Bormann, 25 mins) - http://datatracker.ietf.org/doc/draft-gerdes-ace-actors/ Several participants show interests to this draft. Open issues: 1) Should we reuse existing terminologies in other standards, or should we = use new terminologies? 2) Should we keep CAM and SAM separately? 3) Should we move some terminologies into use case document, or keep this d= ocument standalone or move it to the solution draft? Continue the discussion in the mailing list. * Architecture Comparison (Bert Greevenbosch, 25 mins) - http://datatracker.ietf.org/doc/draft-greevenbosch-ace-comparison/ This document compares several technical solutions for ACE on the table. Co= mpared 5 different solutions in this draft. There were some discussions about Pull model, OAuth and DCAF solution. Continue the discussion in the mailing list. * Object Security (John Mattsson, 30 mins) - http://datatracker.ietf.org/doc/draft-selander-ace-object-security/ There were comments about the reuse of CBOR and JOSE. There was a question about the additional overhead. Continue the discussion in the mailing list. * Wrap-up (Chairs, 5 mins) - Use case document was most important, audience voted for adoption, please= still provide input on additional use cases. - We are not yet there to go for solutions, so no adoptions there. - Aiming for next IETF meeting to go into solution space. - Webinar on IoT hardware: another round specifically on energy-efficiency = (Doodle). - Some data points on ECC performance will be sent around. Please refer to discussion details in: http://tools.ietf.org/wg/ace/minutes Kind Regards Kepeng --_000_34966E97BE8AD64EAE9D3D6E4DEE36F2581AF996SZXEMA501MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

ACE WG Meeting

IETF 91 - Honolulu

Wednesday 12 November 2014, = 13:00 - 15:00 HST

Chairs: Kepeng Li, Hannes Ts= chofenig

 

* Use Cases (Sandeep Kumar, = 30 mins) 

   - http://datatracker.ie= tf.org/doc/draft-seitz-ace-usecases/

 

7 use cases should cover mos= t interesting IoT areas. Updates include the numerous feedback and change o= f focus, requirements removed.

 

About 20 participants haves = read the draft. There were some comments to remove the requirements from th= e document. Also there were some comments to add more use cases to cover in= dustrial control, etc.

 

Humm result is to adopt this= document as WG document, and this will be confirmed in the mailing list.

 

* Actors (Carsten Bormann, 2= 5 mins)

   - http://datatracker.ie= tf.org/doc/draft-gerdes-ace-actors/

 

Several participants show in= terests to this draft. Open issues:

1) Should we reuse existing = terminologies in other standards, or should we use new terminologies?<= /o:p>

2) Should we keep CAM and SA= M separately?

3) Should we move some termi= nologies into use case document, or keep this document standalone or move i= t to the solution draft?

 

Continue the discussion in t= he mailing list.

 

* Architecture Comparison (B= ert Greevenbosch, 25 mins) 

   - http://datatracker.ie= tf.org/doc/draft-greevenbosch-ace-comparison/<= /p>

 

This document compares sever= al technical solutions for ACE on the table. Compared 5 different solutions= in this draft.

 

There were some discussions = about Pull model, OAuth and DCAF solution.

 

Continue the discussion in t= he mailing list.

 

* Object Security (John Matt= sson, 30 mins)

   - http://datatracker.ie= tf.org/doc/draft-selander-ace-object-security/=

 

There were comments about th= e reuse of CBOR and JOSE.

 

There was a question about t= he additional overhead.

 

Continue the discussion in t= he mailing list.

 

* Wrap-up (Chairs, 5 mins)

 

- Use case document was most= important, audience voted for adoption, please still provide input on addi= tional use cases.

- We are not yet there to go= for solutions, so no adoptions there.

- Aiming for next IETF meeti= ng to go into solution space.

- Webinar on IoT hardware: a= nother round specifically on energy-efficiency (Doodle).<= /p>

- Some data points on ECC pe= rformance will be sent around.

 

Please refer to discussion d= etails in:

= http://tools.ietf.org/wg/ace/minutes

 

Kind Regards

Kepeng

 

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F2581AF996SZXEMA501MBSchi_-- From nobody Wed Nov 12 21:24:17 2014 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 04C671A1B8B; Wed, 12 Nov 2014 21:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 nRoecJRwEChP; Wed, 12 Nov 2014 21:24:13 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B441A1B7A; Wed, 12 Nov 2014 21:24:13 -0800 (PST) Received: from dhcp-bbc0.meeting.ietf.org (unknown [31.133.187.192]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0C1AA22E200; Thu, 13 Nov 2014 00:24:10 -0500 (EST) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_A04047D2-5679-4DAE-BF1F-0AE85625A581"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 12 Nov 2014 19:23:10 -1000 References: <20141113051500.12824.67140.idtracker@ietfa.amsl.com> To: pkix@ietf.org, saag@ietf.org Message-Id: <8FF19ABF-17F7-4A83-ABF9-DF84C93528A8@seantek.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ozWInBjhPYj_JfUv256bXiQwGBM Subject: [saag] (it updates RFC 2585) New Version Notification for draft-seantek-certfrag-02.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, 13 Nov 2014 05:24:15 -0000 --Apple-Mail=_A04047D2-5679-4DAE-BF1F-0AE85625A581 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii draft-seantek-certfrag-02 has been posted. Among other nits, I think that this draft needs to be Standards Track = with IETF Consensus because it updates RFC 2585, which is Standards = Track, and application/pkix-cert and application/pkix-crl are in the = standards tree [RFC 6838]. (Thanks Sean T.) Sean Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-seantek-certfrag-02.txt > Date: November 12, 2014 at 7:15:00 PM HST A new version of I-D, draft-seantek-certfrag-02.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-seantek-certfrag Revision: 02 Title: URI Fragment Identifiers for the application/pkix-cert = Media Type Document date: 2014-11-12 Group: Individual Submission Pages: 4 URL: = http://www.ietf.org/internet-drafts/draft-seantek-certfrag-02.txt Status: https://datatracker.ietf.org/doc/draft-seantek-certfrag/ Htmlized: http://tools.ietf.org/html/draft-seantek-certfrag-02 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-seantek-certfrag-02 Abstract: This memo describes Uniform Resource Identifier (URI) fragment identifiers for PKIX certificates, which are identified with the Internet media type application/pkix-cert. The IETF Secretariat= --Apple-Mail=_A04047D2-5679-4DAE-BF1F-0AE85625A581 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO7TCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqT PDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTMxMTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J 9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2g uKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G 53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia33JN+ oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50 ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMf WE2/5myX518DB+kTa5iQDbKYRuJp3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmI H4kfI4LWrY8XrPhlX3JmHjD6hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3 jx9VF/gA3vqYpL+jNumInz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d 9ljRDEiAts5OopkeeFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYID rjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MTExMzA1MjQwNVowIwYJKoZIhvcNAQkEMRYEFIDOvhp6MdaXYCNeZb/a4fjH 8mpyMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQDKkzwxu6lupsyQvhKSvQd8MIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEBBQAE ggEAZR0ezzWJ5z91C3OdGGHg1JPsndnMFxRgJFmXanrudRIQD4gCyC3C0drRl/htKhivu6h0VNjk P5BoZphSdp86H4cYkujLy5EEXKgnIcaEZrLqkDCbPYNrmN7hE3p7k8WgZ2ce91UaZCapkWx7MZUH 6GzyolMsKUfzPu90rzk0PQlj/6uzCCZAGj9dAHP7SQtpnoX/mE2Gk+aGoJqr+bMVY70hGd0uv+34 SLJPga3b8W/guoXxbGNcYnOgiHDORyVnL+Pfh/lPTm7EevIHpHMajsNfo7ao+uHBQFPmqbiLANYR SB0f6qX9qmZyYLqh0HotEwKqQakjqJIg7H59dt5jiQAAAAAAAA== --Apple-Mail=_A04047D2-5679-4DAE-BF1F-0AE85625A581-- From nobody Thu Nov 13 00:49:23 2014 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 124AA1A6FB9 for ; Thu, 13 Nov 2014 00:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 K3wlQpyP5Tkz for ; Thu, 13 Nov 2014 00:49:19 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9EED1A2130 for ; Thu, 13 Nov 2014 00:49:18 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAD8nHQB000996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 13 Nov 2014 08:49:18 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAD8nG7p028522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Nov 2014 08:49:17 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id sAD8nGwR022749 for ; Thu, 13 Nov 2014 08:49:16 GMT Received: from [31.133.162.70] (/31.133.162.70) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Nov 2014 00:49:15 -0800 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 References: <53D079B3.1050809@oracle.com> In-Reply-To: <53D079B3.1050809@oracle.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 X-Forwarded-Message-Id: <53D079B3.1050809@oracle.com> X-Identity-Key: id5 Fcc: imap://shawn.emery%40oracle.com@stbeehive.oracle.com/Sent Message-Id: <1418138F-7A93-46A1-8650-F199B50066AC@oracle.com> X-Account-Key: account6 From: Shawn M Emery X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0; attachmentreminder=0 Date: Wed, 12 Nov 2014 22:44:28 -1000 To: "saag@ietf.org" X-Mailer: iPad Mail (12B410) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ZSrUKYY_3evAXq1pMl3BsSVjtg8 Subject: [saag] kitten Summary - IETF 91 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, 13 Nov 2014 08:49:20 -0000 Co-chairs: Shawn Emery, Matt Miller, and Ben Kaduk The WG met Thursday for the second afternoon session. The meeting went extr= emely well. I've included the high-lighted topics on the agenda that were discussed: SASL-OAuth Bill Mills had presented the update to the draft which includes a normative r= eference that gives guidance on dynamic client registration and endpoint dis= covery. The update should necessitate another WGLC. PKINIT-Freshness Andrei Popov presented a proposal for indicating recent possession of a priv= ate key. New work proposed is covered in the existing charter. Open mic There were no dissenting comments. Shawn. -- kitten co-chair= From nobody Thu Nov 13 08:46:14 2014 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 6EC3C1A8A7F for ; Thu, 13 Nov 2014 08:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, 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 DrCLhUWO0gLJ for ; Thu, 13 Nov 2014 08:46:10 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (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 E13EF1A8A8C for ; Thu, 13 Nov 2014 08:46:09 -0800 (PST) Received: from [192.168.14.159] (64-129-13-2.static.twtelecom.net [64.129.13.2] (may be forged)) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sADGk8lF099570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Nov 2014 09:46:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 64-129-13-2.static.twtelecom.net [64.129.13.2] (may be forged) claimed to be [192.168.14.159] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4BB2841A-1204-49EB-8E42-AC8BB7AC4CB9@vpnc.org> Date: Thu, 13 Nov 2014 06:46:08 -1000 To: saag Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/RnAeF9Pq5m2q6nXeK8rrihWaQ9o Subject: [saag] IPsecME at IETF 91 pre-summary 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, 13 Nov 2014 16:46:11 -0000 We are meeting directly after the SAAG meeting today. We have two agenda = items: new thinking on DDoS attacks on IKEv2, and using null = authentication for IKEv2 in some non-traditional scenarios. --Paul Hoffman= From nobody Thu Nov 13 09:14:35 2014 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 1E5101A8AF2 for ; Thu, 13 Nov 2014 09:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 gDvc6Fh8e0ya for ; Thu, 13 Nov 2014 09:14:31 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEC311A8AE3 for ; Thu, 13 Nov 2014 09:14:30 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id kx10so15657162pab.40 for ; Thu, 13 Nov 2014 09:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:from:subject:date:content-type; bh=Ar5kxQNyNkLH9aWbvmo2CqBAr+Dewx8hB03cVnNPg/I=; b=ax6yFbHWgsLIx9OdeK+2OXCQdc/cxjh8QYORQvjCPFnjctR4UAl+ls+MkvW1bwtZk7 o9+iuI+hYAPMFCIPf7CY7rpWcsong9ULmgXTvfHqUv/88xoJgFW1PBXY7QeSxD/G6lwq ppOtplf9vziq9ZMT+Bqla4dZAzqBzx2V6KYbVUnU+HnfTL8dtb5D+ES2ixaqgf7a7go3 KoE1kSa0YxhG7QJlNU6DYI+BQU9+zd+/9FRlTsTU3wpwXEbymInK1dYyupiBw4LHnOwP AfLgaXxg9VTJJaf4SAqwy0CoSHXI18DIAdTpIP/6iZBK5/TiyZQ7Gnbub5IpY6gaW1I1 o8kg== X-Received: by 10.70.93.104 with SMTP id ct8mr4179397pdb.72.1415898870145; Thu, 13 Nov 2014 09:14:30 -0800 (PST) Received: from [10.23.71.8] ([166.170.51.201]) by mx.google.com with ESMTPSA id r4sm25324135pdm.93.2014.11.13.09.14.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 13 Nov 2014 09:14:29 -0800 (PST) Message-ID: <5464e6f5.042e460a.1336.ffffb034@mx.google.com> MIME-Version: 1.0 To: Security Area Advisory Group From: Yoav Nir Date: Thu, 13 Nov 2014 07:14:11 -1000 Content-Type: multipart/alternative; boundary="_D91826EF-C6FF-46E1-BD97-669388E67DB8_" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/1efceLZDW_nSVwVRgFG-p9icmEw Subject: [saag] Http-Auth pre-summary 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, 13 Nov 2014 17:14:32 -0000 --_D91826EF-C6FF-46E1-BD97-669388E67DB8_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="Windows-1252" Http-Auth will meet on Friday last timeslot. We have two things on the agenda: - wrap up Basic & Digest, especially character restriction text - SCRAM HOBA was just sent to Kathleen. Matt & Yoav= --_D91826EF-C6FF-46E1-BD97-669388E67DB8_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="Windows-1252"
Http-Auth will meet on Friday last timeslot.
We have two things on the agenda:
- wrap up Basic & Digest, espec= ially character restriction text
- SCRAM

HOBA was just sent to K= athleen.

Matt & Yoav
= --_D91826EF-C6FF-46E1-BD97-669388E67DB8_-- From nobody Thu Nov 13 09:26:59 2014 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 92D241A8F42 for ; Thu, 13 Nov 2014 09:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 q9HNb2MfN7PJ for ; Thu, 13 Nov 2014 09:26:53 -0800 (PST) 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 CB2151A8F3E for ; Thu, 13 Nov 2014 09:26:53 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1XoyAV-0002po-Nm; Thu, 13 Nov 2014 17:26:52 +0000 Date: Thu, 13 Nov 2014 07:26:50 -1000 Message-ID: From: Randy Bush To: Shawn M Emery In-Reply-To: <1418138F-7A93-46A1-8650-F199B50066AC@oracle.com> References: <53D079B3.1050809@oracle.com> <1418138F-7A93-46A1-8650-F199B50066AC@oracle.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: http://mailarchive.ietf.org/arch/msg/saag/ywelYt-phh9a9s0yxew_o9vspWU Cc: saag Subject: Re: [saag] kitten Summary - IETF 91 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, 13 Nov 2014 17:26:57 -0000 > The WG met Thursday for the second afternoon session. there has been a good discussion of time/ntp security issues on this list randy From nobody Thu Nov 13 11:03:53 2014 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 B0C6B1AC3FD for ; Thu, 13 Nov 2014 11:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 tKB1C-_e3Ptn for ; Thu, 13 Nov 2014 11:03:50 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5BF1AC3F9 for ; Thu, 13 Nov 2014 11:02:16 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sADJ2Eul024138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Nov 2014 19:02:14 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sADJ2CY8003734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Nov 2014 19:02:12 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sADJ2CbY003723; Thu, 13 Nov 2014 19:02:12 GMT Received: from shawn-emerys-computer.local (/107.18.176.106) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Nov 2014 11:02:12 -0800 Message-ID: <54650048.6090701@oracle.com> Date: Thu, 13 Nov 2014 12:02:32 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Randy Bush References: <53D079B3.1050809@oracle.com> <1418138F-7A93-46A1-8650-F199B50066AC@oracle.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/-J-dNyLqbiysVDIovvRzVJnKmnA Cc: saag Subject: Re: [saag] kitten Summary - IETF 91 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, 13 Nov 2014 19:03:51 -0000 On 11/13/14 10:26 AM, Randy Bush wrote: >> The WG met Thursday for the second afternoon session. > there has been a good discussion of time/ntp security issues on this > list > RTC? Why would I need one when I have a flux capacitor? Shawn. -- From nobody Thu Nov 13 13:22:21 2014 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 DC8201AD493 for ; Thu, 13 Nov 2014 13:22:17 -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, HTML_MESSAGE=0.001, 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 5r94eYnacZyE for ; Thu, 13 Nov 2014 13:22:16 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0608.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::608]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824CC1AD58D for ; Thu, 13 Nov 2014 13:22:14 -0800 (PST) Received: from dhcp-bbb9.meeting.ietf.org (2001:67c:370:184:30c9:f0c8:82d2:7fa7) by DM2PR06MB591.namprd06.prod.outlook.com (10.141.176.154) with Microsoft SMTP Server (TLS) id 15.1.16.15; Thu, 13 Nov 2014 21:21:50 +0000 Message-ID: <546520E1.1010404@isoc.org> Date: Thu, 13 Nov 2014 11:21:37 -1000 From: Karen ODonoghue User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Content-Type: multipart/alternative; boundary="------------080504020206050201090105" X-Originating-IP: [2001:67c:370:184:30c9:f0c8:82d2:7fa7] X-ClientProxiedBy: DB4PR04CA0026.eurprd04.prod.outlook.com (25.160.41.36) To DM2PR06MB591.namprd06.prod.outlook.com (10.141.176.154) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR06MB591; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR06MB591; X-Forefront-PRVS: 0394259C80 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(377454003)(199003)(33656002)(86362001)(64126003)(512934002)(87976001)(101416001)(46102003)(59896002)(80316001)(83506001)(92566001)(110136001)(31966008)(92726001)(4396001)(102836001)(120916001)(50986999)(21056001)(87266999)(95666004)(54356999)(107046002)(105586002)(106356001)(122386002)(36756003)(65816999)(42186005)(16236675004)(84326002)(20776003)(64706001)(62966003)(65806001)(229853001)(77156002)(450100001)(77096003)(107886001)(65956001)(71186001)(97736003)(99136001)(2351001)(40100003)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR06MB591; H:dhcp-bbb9.meeting.ietf.org; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR06MB591; X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/saag/dmNnRfvuEkHF7K7NfTCByJBbEJ8 Subject: [saag] JOSE @ IETF91 summary 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, 13 Nov 2014 21:22:18 -0000 --------------080504020206050201090105 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit The JOSE wg met on Monday 10 Nov from 5:30 to 6:30 pm HST. The working group discussed and identified potential resolutions to all the major issues raised by IESG members during their review of the four core documents (JWA, JWS, JWE, JWK). It is expected that the updates to address these issues will be completed in the next month. The cookbook document has completed WGLC. There are a number of changes and a few additional examples to be added prior to forwarding the IESG. This is expected within the month. Finally, the working group agreed to accept draft-ietf-jose-jwk-thumbprint as a working group document. --------------080504020206050201090105 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit The JOSE wg met on Monday 10 Nov from 5:30 to 6:30 pm HST.

The working group discussed and identified potential resolutions to all the major issues raised by IESG members during their review of the four core documents (JWA, JWS, JWE, JWK). It is expected that the updates to address these issues will be completed in the next month.

The cookbook document has completed WGLC. There are a number of changes and a few additional examples to be added prior to forwarding the IESG. This is expected within the month.

Finally, the working group agreed to accept draft-ietf-jose-jwk-thumbprint as a working group document. --------------080504020206050201090105-- From nobody Thu Nov 13 14:45:22 2014 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 C32711AE127 for ; Thu, 13 Nov 2014 14:45:19 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 7QjRXZJ030IR for ; Thu, 13 Nov 2014 14:45:18 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2287A1AE125 for ; Thu, 13 Nov 2014 14:45:18 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id bs8so1051519wib.11 for ; Thu, 13 Nov 2014 14:45:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=V9OjTJVpnFUz/kVL5DHVRkbNfxAsnxiEYtD+3cLkwL0=; b=OKcltTMmz+Bn6aDxhaW6D59HmNMnhUv0XE0Jt2VbsT+WJDyzMqFtvcMhLhQCKQhmYK uXp9oPJrT3Rz4/3/1vN5NdXduUBm6Yq5kcBgnlWXRf0+qtkAdPzcGET+jpcAG9xYTWNd tiUJBAvWc0xI0zUyRWsdczcIrluXA5KXWD9wqzy3/+urNgaukfbqktGpFcdMAKMo1x7b FHR3cZIt754f6yIxRr6pzSudmnG2sPREGBI9qcGRlmJvqvB6k9QtSymrSeejGFNDEX+t pvydcZUKH9jyn6kG3LYz+nI5wISpGK9nVoHrv2jbhVcCk3sSiw29pQnYD8FdHF+57HtB JehA== X-Gm-Message-State: ALoCoQkOYvDSe0gHRBhr+vITF4ISHBUIfnFw10JUZYUaSPuCOCmi2DpMON0TtAo4xPk1GH6E7whW X-Received: by 10.195.13.14 with SMTP id eu14mr7836042wjd.31.1415918716916; Thu, 13 Nov 2014 14:45:16 -0800 (PST) Received: from ?IPv6:2001:67c:370:160:95ce:c5e6:4f4a:d47b? (t2001067c0370016095cec5e64f4ad47b.wireless.v6.meeting.ietf.org. [2001:67c:370:160:95ce:c5e6:4f4a:d47b]) by mx.google.com with ESMTPSA id fk16sm1061685wic.16.2014.11.13.14.45.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Nov 2014 14:45:16 -0800 (PST) Message-ID: <5465347B.7080403@mnt.se> Date: Thu, 13 Nov 2014 23:45:15 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/yooPscY80Egj4ORGHhv6B_6iXzA Subject: [saag] abfab @ IETF91 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, 13 Nov 2014 22:45:19 -0000 abfab didn't meet at IETF91 From nobody Thu Nov 13 15:10:36 2014 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 762201AE21B for ; Thu, 13 Nov 2014 15:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 MoMhmK4jPsbp for ; Thu, 13 Nov 2014 15:10:31 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 439061AE20F for ; Thu, 13 Nov 2014 15:10:30 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 8FAC228B0042 for ; Thu, 13 Nov 2014 18:10:29 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 20E471F8036; Thu, 13 Nov 2014 18:10:28 -0500 (EST) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_2F03A60F-F0B9-409A-8441-976E93EF5EBB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 13 Nov 2014 18:10:27 -0500 Message-Id: <2D8741AF-2640-4082-987E-931A38ADA23D@tislabs.com> To: "saag@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/zDwNecKs2N7BX0ZlW0W1kyOpOcs Subject: [saag] report from sidr 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, 13 Nov 2014 23:10:34 -0000 --Apple-Mail=_2F03A60F-F0B9-409A-8441-976E93EF5EBB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The SIDR wg had an interim as a tutorial for the idr folk who will be = commenting on the BGPSEC protocol in a joint meeting on Friday morning. The SIDR group met Monday morning. The agenda was short. A short report on the hopefully last updates to the BGPSEC protocol was = first. That was followed by a short discussion on the risks involved in = removing resources from an RPKI certificate and considerations of = transfer of resources between parts of the RPKI tree. These issues are = related to the reconsideration of the validation algorithm. There was a = suggestion of a need to specify the details of a transfer in the RPKI. We had a energetic discussion of a proposed replacement for rsync as a = transfer protocol for RPKI. One advantage of the new protocol is to = reduce the burden on the servers. There were several constructive = comments. We expect to be asked to take this protocol on as a working = group work item. We had a discussion about possible misbehavior of CA, revoking someone's = resources. The proposal was to provide a new RPKI object that would = ensure that the someone consented to have their resources revoked. The = discussion was energetic, and covered the authority of a resource holder = to revoke a sub-allocation to a customer (or further down the allocation = tree) and the balance of the rights of the resource granter and the = resource recipient. --Sandy --Apple-Mail=_2F03A60F-F0B9-409A-8441-976E93EF5EBB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUZTpjAAoJEHplpQeet0IZNSoP/2meGiPgjWlPXWaypgDxbXS7 DhrRo+G6rNmD/ushDzlaGo2aY+zCvlGPilDgajJxxhpNcJ2iZvUrTUzTbvSjIPbq fkpIouSrGz4hEmZacLfBWpriFcSjUlFNKMwDnr+ikYHWz3pqm/ptER1yzW+L84px cpvMDijaGtlFXJRAfXTEDlYVXMsocF9xhqk7BLBJc/MFeqYp+wRIsFUSI+YOq+XP 4V1gdmHUz3ivxNPrW4eNUQ25e5XnGgT7IU75NSfCcVVhHKVHw8iCV55NQQIXMCB6 2hXHDIFn+AoTmHU+0959CmiiE41Yl+sjIJVqStz/NPiyWlcqVgSUrrqghEEo8MOP jpvgysvVhfvfwA1kJw4mGMXIs/zxjavN6Gc6YYhobIwLuVPjEtbdq0THI4DFVE7P Gr8ZLS1juMN0X5DvkFjeWVcso/S6nMcoM/0lQ/pOxE2BVN4h6N5mShOXdQGJGpcg LHobkpX6h9vc5sle+f8t9SwQvO4k181RxDptUs8/KmbB1H2sLrpb01VTyNyLA+C0 y98L7mGtq6oXDfv91Y8tV/TCljLqK+4JpQAyIDcQU/ccmwExmiJW3oqa3Eixd2yZ grKlloruR1bvxRxDqcgsRP2accOjb5Uydz8D+sBKgop92CUwdsAw7/Z1w4t1UlZb +aRZni/nu4JlgO5gv5Sg =xXxI -----END PGP SIGNATURE----- --Apple-Mail=_2F03A60F-F0B9-409A-8441-976E93EF5EBB-- From nobody Thu Nov 13 15:17:23 2014 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 0F7141AE26B for ; Thu, 13 Nov 2014 15:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 gIbwRl38boDn for ; Thu, 13 Nov 2014 15:17:19 -0800 (PST) Received: from smtp104.iad3a.emailsrvr.com (smtp104.iad3a.emailsrvr.com [173.203.187.104]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0EA91AE0E2 for ; Thu, 13 Nov 2014 15:16:37 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DC83318026B for ; Thu, 13 Nov 2014 18:16:36 -0500 (EST) X-Virus-Scanned: OK Received: from app6.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C5BA0180252 for ; Thu, 13 Nov 2014 18:16:35 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from app6.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.3.2); Thu, 13 Nov 2014 23:16:36 GMT Received: from ogud.com (localhost.localdomain [127.0.0.1]) by app6.wa-webapps.iad3a (Postfix) with ESMTP id D865180041 for ; Thu, 13 Nov 2014 18:16:35 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: ogud@ogud.com, from: ogud@ogud.com) with HTTP; Thu, 13 Nov 2014 18:16:35 -0500 (EST) Date: Thu, 13 Nov 2014 18:16:35 -0500 (EST) From: ogud@ogud.com To: saag@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain X-Auth-ID: ogud@ogud.com Message-ID: <1415920595.884628910@apps.rackspace.com> X-Mailer: webmail7.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Aw3sOIdsUQnWLJn6Ef9pqdwlRu4 Subject: [saag] DANE summary @ IETF-91 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, 13 Nov 2014 23:17:21 -0000 =0ADane met on Wed. =0A=0AThere were a number of topics discussed, one of t= he larger thre what the probability that S/MIME is likely to be another maj= or driver of DANE.=0A=0AWe had an interesting "demo" (screenshots of an imp= lementation)of a DANE+S/MIME prototype. There was also a long discussion on= the status of DANE deployment, and if there were any major sticking points= *that the IETF should solve*.=0A=0AOn the S/MIME / usage issue, we decided= that we needed more discussion, but only after the working group had had a= chance to re-read the draft (which was discussed a while back, but not rec= ently). We are holding a virtual interim meeting on December 2nd. =0A=0AWe = have started a WG last call on "Service record" protocol Documents i.e. dan= e-srv and=0Adane-smtp. =0A=0A Warren & Olafur From nobody Thu Nov 13 18:56:28 2014 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 0583B1A0174 for ; Thu, 13 Nov 2014 18:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 LsbrvDOScnTq for ; Thu, 13 Nov 2014 18:56:21 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429911A1B24 for ; Thu, 13 Nov 2014 18:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3007; q=dns/txt; s=iport; t=1415933781; x=1417143381; h=from:to:subject:date:message-id:mime-version; bh=Q0iabOqL/cTBwNmmAVD63ysLi6xna/1+TEY7OhEUaWI=; b=mI7HoAe9dcVb3qrMSKAv4Y8Ypbw7KYm2VNGnbxfyqM3mEgHer0nQgjhL MwoyTRUjeufbOrNFZTQ6biM6ElVYGetfIUhfXHNA0El9lj8SZCPrHaEM9 dP1czulEhFlRuKPucvzXaby3PCRG0Y8jwEgxeaLE0qfdPX4Gs8fwMGhtT I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FANFuZVStJA2M/2dsb2JhbABbgkgjI4Ex1WkWAQEBAQFyC4QJgQsBDAFzDxgELogmAap1pWgBCwEfjS2IOQWQFoIki3eWZ4N8gjWBAwEBAQ X-IronPort-AV: E=Sophos; i="5.07,382,1413244800"; d="scan'208,217"; a="96454054" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP; 14 Nov 2014 02:56:20 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sAE2uKwd024545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Nov 2014 02:56:20 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Thu, 13 Nov 2014 20:56:18 -0600 From: "Nancy Cam-Winget (ncamwing)" To: "saag@ietf.org" Thread-Topic: ANIMA report Thread-Index: AQHP/7aQAtQOhls0o0Kc5KD5UGT2bA== Date: Fri, 14 Nov 2014 02:56:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.117.155] Content-Type: multipart/alternative; boundary="_000_D08AAF52D8BAEncamwingciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_C06dC5V_yFRKM24nVijIk0QEVU Subject: [saag] ANIMA report 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, 14 Nov 2014 02:56:25 -0000 --_000_D08AAF52D8BAEncamwingciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Here=92s the ANIMA report for IETF 91: ANIMA met for the first time as a Working Group. The session started with = a review of the charter and a highlight for the need to coordinate with HOM= ENET given points of commonality. A review of HOMENET and their functional requirements was also presented wi= th highlight to points of commonality between HOMENET and ANIMA. The two g= roups will have to coordinate to address the points of commonality with the= intent to come up with the same solutions if possible. Proposal presentations were made to address (autonomic) node discovery, a r= eference model for an autonomic control plane and a couple of proposals for= doing bootstrapping and provisioning. There was much discussion around th= e presented proposals and applicability or suitability for either or both A= NIMA and HOMENET. >From a security perspective, review for the overall threat model for the AN= IMA reference model (and commonality with HOMENET) is needed. Nancy. --_000_D08AAF52D8BAEncamwingciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6A21F0D6AA569E4C8D1B4654A4E05B1F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

Here=92s the ANIMA report for IETF 91:

ANIMA met for the first time as a Working Group.  The session sta= rted with a review of the charter and a highlight for the need to coordinat= e with HOMENET given points of commonality.

A review of HOMENET and their functional requirements was also present= ed with highlight to points of commonality between HOMENET and ANIMA.  = ;The two groups will have to coordinate to address the points of commonalit= y with the intent to come up with the same solutions if possible.

Proposal presentations were made to address (autonomic) node discovery= , a reference model for an autonomic control plane and a couple of proposal= s for doing bootstrapping and provisioning.  There was much discussion= around the presented proposals and applicability or suitability for either or both ANIMA and HOMENET. 

From a security perspective, review for the overall threat model for t= he ANIMA reference model (and commonality with HOMENET)  is needed.

Nancy.=
--_000_D08AAF52D8BAEncamwingciscocom_-- From nobody Sun Nov 16 11:54:08 2014 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 B2ECA1A1ACA; Sun, 16 Nov 2014 11:54:06 -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] 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 ZkrzqQ0irzvk; Sun, 16 Nov 2014 11:54:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1E51A1AAF; Sun, 16 Nov 2014 11:54:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141116195404.29678.99130.idtracker@ietfa.amsl.com> Date: Sun, 16 Nov 2014 11:54:04 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/taTf8TdijUwqi0k0m01apJc_HOY Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Stephen Farrell's Yes on draft-dukhovni-opportunistic-security-05: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 19:54:07 -0000 Stephen Farrell has entered the following ballot position for draft-dukhovni-opportunistic-security-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In reviewing this just before the end of IETF LC, there's one place where I'd prefer a slightly different emphasis. I've run this by Viktor and he however disagrees with the change so I'll leave it for folks to comment and see what other IESG members think.. To be clear, I don't myself think the document needs to be blocked to get this fixed, but I'd like it to be considered. And I figure there are good arguments for both OLD and NEW paragraphs below so I'm not saying that the NEW one below is "right" and the OLD is "wrong" but I do think the NEW is more consistent with what we want to see happen in future. Others, (Viktor for example:-) can reasonably disagree. OLD: With unauthenticated, encrypted communication, OS protocols may employ more liberal settings than would be best-practice when security is mandated by policy. Some legacy systems support encryption, but implement only outdated algorithms or protocol versions. Compatibility with these systems avoids the need to resort to cleartext fallback. NEW: With unauthenticated, encrypted communication, OS protocols may employ more liberal settings than would be best-practice when security is mandated by policy. Some legacy systems support encryption, but implement only outdated algorithms or protocol versions. Compatibility with these systems avoids the need to resort to cleartext fallback. However, the use of "broken" algorithms, especially ones for which a ciphertext-only attack may be feasible in the near term, is not consistent with the OS approach. In such cases, avoiding the "broken" cipher, and falling back to cleartext is in fact the correct outcome, as recorded ciphertext for an algorithm with a feasible ciphertext-only attack is really the same as cleartext. That said, there may be cases where an implementation does negotiate use of such an algorithm for some (hopefully) short period with (hopefully) very few peers, while software and/or configurations are in the process of being updated, but this should be considered a failure (to update) and not as an acceptable outcome that is consistent with the OS approach. From nobody Sun Nov 16 17:02:55 2014 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 611D61A3B9C; Sun, 16 Nov 2014 17:02:47 -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] 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 CrujLQ7wnpON; Sun, 16 Nov 2014 17:02:45 -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 D9D931A1C00; Sun, 16 Nov 2014 17:02:41 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 86DDF282EC3; Mon, 17 Nov 2014 01:02:40 +0000 (UTC) Date: Mon, 17 Nov 2014 01:02:40 +0000 From: Viktor Dukhovni To: The IESG Message-ID: <20141117010240.GV13179@mournblade.imrryr.org> References: <20141116195404.29678.99130.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141116195404.29678.99130.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4ZFtW-W7bV6qUIfRdrMdDboAFYA Cc: saag@ietf.org Subject: Re: [saag] Stephen Farrell's Yes on draft-dukhovni-opportunistic-security-05: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 17 Nov 2014 01:02:47 -0000 On Sun, Nov 16, 2014 at 11:54:04AM -0800, Stephen Farrell wrote: For my counter-offer, as a middle-ground between OLD and NEW, see below. The idea is to note that support for weak crypto is an interim measure, without taking sides on the weak crypto is worse than no crypto debate. I am very relunctant to endorse cleartext fallback as a better alternative than leaving deprecated crypto enabled. My preference is to see opportunistic security applications drop support for weak crypto as soon as it is in practice "never" needed, but not much sooner. > In reviewing this just before the end of IETF LC, there's one place > where I'd prefer a slightly different emphasis. I've run this by > Viktor and he however disagrees with the change so I'll leave it > for folks to comment and see what other IESG members think.. > To be clear, I don't myself think the document needs to be > blocked to get this fixed, but I'd like it to be considered. And > I figure there are good arguments for both OLD and NEW > paragraphs below so I'm not saying that the NEW one below > is "right" and the OLD is "wrong" but I do think the NEW is > more consistent with what we want to see happen in future. > Others, (Viktor for example:-) can reasonably disagree. > > OLD: > > With unauthenticated, encrypted communication, OS protocols may > employ more liberal settings than would be best-practice when > security is mandated by policy. Some legacy systems support > encryption, but implement only outdated algorithms or protocol > versions. Compatibility with these systems avoids the need to resort > to cleartext fallback. > > NEW: > > With unauthenticated, encrypted communication, OS protocols may > employ more liberal settings than would be best-practice when > security is mandated by policy. Some legacy systems support > encryption, but implement only outdated algorithms or protocol > versions. Compatibility with these systems avoids the need to resort > to cleartext fallback. However, the use of "broken" algorithms, > especially ones for which a ciphertext-only attack may be > feasible in the near term, is not consistent with the OS > approach. In such cases, avoiding the "broken" cipher, and > falling back to cleartext is in fact the correct outcome, as > recorded ciphertext for an algorithm with a feasible > ciphertext-only attack is really the same as cleartext. That > said, there may be cases where an implementation does negotiate > use of such an algorithm for some (hopefully) short period > with (hopefully) very few peers, while software and/or > configurations are in the process of being updated, but this > should be considered a failure (to update) and not as an > acceptable outcome that is consistent with the OS approach. IN GOOD CONDITION: Some legacy systems support encryption, but implement only outdated algorithms or protocol versions. With unauthenticated, encrypted communication, OS protocols may tolerate the use of outdated algorithms that would generally be excluded when security is mandated by policy. Compatibility with legacy systems avoids the need to resort to cleartext fallback. However, the use of outdated algorithms needs to be a temporary transition strategy, used only to in support of an orderly phase-out of such algorithms. Outdated algorithms, especially those that are already broken in some use-cases, or are expected to soon be broken, should not be supported indefinitely. For a recent example, my SMTP server preempts the SMTP client's TLS cipherlist order, and lists RC4 only as a last resort. And yet: Nov 12 03:52:32 amnesiac postfix/smtpd[1144]: Anonymous TLS connection established from nk11p03mm-asmtpout002.mac.com[17.158.232.237]: TLSv1 with cipher RC4-MD5 (128/128 bits) So this system, sending mail from a "me.com" user is capable nothing better than RC4-MD5. I expect such silliness to end soon, but for the immediate future, I am leaving RC4 enabled. -- Viktor. From nobody Mon Nov 17 05:52:18 2014 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 C12001A1A0A; Mon, 17 Nov 2014 05:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 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.594, 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 lK84t-FaRwIB; Mon, 17 Nov 2014 05:52:07 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037031A19F9; Mon, 17 Nov 2014 05:52:06 -0800 (PST) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sAHDq40c004271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2014 08:52:05 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com sAHDq40c004271 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1416232325; bh=OdzKHtH4N4I9iekjAOgqljA1Ikg=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=XJfb+eLCeRjJShj6Vr2ofMhoa7RDjkw2B85F3XOVQrkebqZg10MknvP5KYj8zRYee irxlLyHAcTxh1lIFaObE0sxoRzQqFOt+ehX6FgGaGmFDkdmqi1sjM0brX8Vzo3e33B XcgTfwhJB1qJ5aPiMxSJgCzQ8Z3MjOZyVcnigD+g= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com sAHDq40c004271 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd04.lss.emc.com (RSA Interceptor); Mon, 17 Nov 2014 08:51:30 -0500 Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sAHDpq7X007009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Nov 2014 08:51:52 -0500 Received: from MXHUB101.corp.emc.com (10.253.50.15) by mxhub36.corp.emc.com (10.254.93.84) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 17 Nov 2014 08:51:51 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.125]) by MXHUB101.corp.emc.com ([::1]) with mapi id 14.03.0195.001; Mon, 17 Nov 2014 08:51:51 -0500 From: "Black, David" To: "saag@ietf.org" , The IESG Thread-Topic: [saag] Stephen Farrell's Yes on draft-dukhovni-opportunistic-security-05: (with COMMENT) Thread-Index: AQHQAdch8EKvQcpQUUa4HNHY6ybalJxkVIEAgACCH3A= Date: Mon, 17 Nov 2014 13:51:51 +0000 Message-ID: References: <20141116195404.29678.99130.idtracker@ietfa.amsl.com> <20141117010240.GV13179@mournblade.imrryr.org> In-Reply-To: <20141117010240.GV13179@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public, GIS Solicitation Archived-At: http://mailarchive.ietf.org/arch/msg/saag/L-oiGmqi38FS76yvvnSr3K0V3CM Subject: Re: [saag] Stephen Farrell's Yes on draft-dukhovni-opportunistic-security-05: (with COMMENT) 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, 17 Nov 2014 13:52:10 -0000 +1 on Viktor's middle-ground. "broken" algorithms come in various forms and degrees of "broken". Even increasing the effort required of a pervasive passive attacker to obtain cleartext from a "broken" algorithm is useful, and we should be encouraging deployment of "non-broken" technology. Thanks, --David > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Viktor Dukhovni > Sent: Sunday, November 16, 2014 8:03 PM > To: The IESG > Cc: saag@ietf.org > Subject: Re: [saag] Stephen Farrell's Yes on draft-dukhovni-opportunistic= - > security-05: (with COMMENT) >=20 > On Sun, Nov 16, 2014 at 11:54:04AM -0800, Stephen Farrell wrote: >=20 > For my counter-offer, as a middle-ground between OLD and NEW, see > below. The idea is to note that support for weak crypto is an > interim measure, without taking sides on the weak crypto is worse > than no crypto debate. I am very relunctant to endorse cleartext > fallback as a better alternative than leaving deprecated crypto > enabled. My preference is to see opportunistic security applications > drop support for weak crypto as soon as it is in practice "never" > needed, but not much sooner. >=20 > > In reviewing this just before the end of IETF LC, there's one place > > where I'd prefer a slightly different emphasis. I've run this by > > Viktor and he however disagrees with the change so I'll leave it > > for folks to comment and see what other IESG members think.. > > To be clear, I don't myself think the document needs to be > > blocked to get this fixed, but I'd like it to be considered. And > > I figure there are good arguments for both OLD and NEW > > paragraphs below so I'm not saying that the NEW one below > > is "right" and the OLD is "wrong" but I do think the NEW is > > more consistent with what we want to see happen in future. > > Others, (Viktor for example:-) can reasonably disagree. > > > > OLD: > > > > With unauthenticated, encrypted communication, OS protocols may > > employ more liberal settings than would be best-practice when > > security is mandated by policy. Some legacy systems support > > encryption, but implement only outdated algorithms or protocol > > versions. Compatibility with these systems avoids the need to resor= t > > to cleartext fallback. > > > > NEW: > > > > With unauthenticated, encrypted communication, OS protocols may > > employ more liberal settings than would be best-practice when > > security is mandated by policy. Some legacy systems support > > encryption, but implement only outdated algorithms or protocol > > versions. Compatibility with these systems avoids the need to resor= t > > to cleartext fallback. However, the use of "broken" algorithms, > > especially ones for which a ciphertext-only attack may be > > feasible in the near term, is not consistent with the OS > > approach. In such cases, avoiding the "broken" cipher, and > > falling back to cleartext is in fact the correct outcome, as > > recorded ciphertext for an algorithm with a feasible > > ciphertext-only attack is really the same as cleartext. That > > said, there may be cases where an implementation does negotiate > > use of such an algorithm for some (hopefully) short period > > with (hopefully) very few peers, while software and/or > > configurations are in the process of being updated, but this > > should be considered a failure (to update) and not as an > > acceptable outcome that is consistent with the OS approach. >=20 > IN GOOD CONDITION: >=20 > Some legacy systems support encryption, but implement only > outdated algorithms or protocol versions. With unauthenticated, > encrypted communication, OS protocols may tolerate the use of > outdated algorithms that would generally be excluded when > security is mandated by policy. Compatibility with legacy > systems avoids the need to resort to cleartext fallback. > However, the use of outdated algorithms needs to be a temporary > transition strategy, used only to in support of an orderly > phase-out of such algorithms. Outdated algorithms, especially > those that are already broken in some use-cases, or are expected > to soon be broken, should not be supported indefinitely. >=20 > For a recent example, my SMTP server preempts the SMTP client's > TLS cipherlist order, and lists RC4 only as a last resort. And > yet: >=20 > Nov 12 03:52:32 amnesiac postfix/smtpd[1144]: > Anonymous TLS connection established > from nk11p03mm-asmtpout002.mac.com[17.158.232.237]: > TLSv1 with cipher RC4-MD5 (128/128 bits) >=20 > So this system, sending mail from a "me.com" user is capable nothing > better than RC4-MD5. I expect such silliness to end soon, but for > the immediate future, I am leaving RC4 enabled. >=20 > -- > Viktor. >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Mon Nov 17 07:34:30 2014 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 1064B1A6FA0; Mon, 17 Nov 2014 07:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 Cfu12prLAu5P; Mon, 17 Nov 2014 07:34:19 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA641A6F90; Mon, 17 Nov 2014 07:34:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 36292BE49; Mon, 17 Nov 2014 15:34:18 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8zi-6MEAqDq; Mon, 17 Nov 2014 15:34:18 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 11908BE38; Mon, 17 Nov 2014 15:34:18 +0000 (GMT) Message-ID: <546A157A.4060700@cs.tcd.ie> Date: Mon, 17 Nov 2014 15:34:18 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Black, David" , "saag@ietf.org" , The IESG References: <20141116195404.29678.99130.idtracker@ietfa.amsl.com> <20141117010240.GV13179@mournblade.imrryr.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/phnltCZd4djlhRU__obVrQv6JyI Subject: Re: [saag] Stephen Farrell's Yes on draft-dukhovni-opportunistic-security-05: (with COMMENT) 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, 17 Nov 2014 15:34:22 -0000 On 17/11/14 13:51, Black, David wrote: > +1 on Viktor's middle-ground. > > "broken" algorithms come in various forms and degrees of "broken". Even > increasing the effort required of a pervasive passive attacker to obtain > cleartext from a "broken" algorithm is useful, and we should be encouraging > deployment of "non-broken" technology. True, otoh md5 shows how long it still takes to get rid of stuff even after a bad break. But Viktor's latest below is better than -05 I agree. I might suggest a tweak which is to change the last clause from "should not be supported indefinitely." to "ought not be used." giving (with one typo fix): YETANOTHERNEW: Some legacy systems support encryption, but implement only outdated algorithms or protocol versions. With unauthenticated, encrypted communication, OS protocols may tolerate the use of outdated algorithms that would generally be excluded when security is mandated by policy. Compatibility with legacy systems avoids the need to resort to cleartext fallback. However, the use of outdated algorithms needs to be a temporary transition strategy, used only in support of an orderly phase-out of such algorithms. Outdated algorithms, especially those that are already broken in some use-cases, or are expected to soon be broken, ought not be used. > > Thanks, > --David > >> -----Original Message----- >> From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Viktor Dukhovni >> Sent: Sunday, November 16, 2014 8:03 PM >> To: The IESG >> Cc: saag@ietf.org >> Subject: Re: [saag] Stephen Farrell's Yes on draft-dukhovni-opportunistic- >> security-05: (with COMMENT) >> >> On Sun, Nov 16, 2014 at 11:54:04AM -0800, Stephen Farrell wrote: >> >> For my counter-offer, as a middle-ground between OLD and NEW, see >> below. The idea is to note that support for weak crypto is an >> interim measure, without taking sides on the weak crypto is worse >> than no crypto debate. I am very relunctant to endorse cleartext >> fallback as a better alternative than leaving deprecated crypto >> enabled. My preference is to see opportunistic security applications >> drop support for weak crypto as soon as it is in practice "never" >> needed, but not much sooner. >> >>> In reviewing this just before the end of IETF LC, there's one place >>> where I'd prefer a slightly different emphasis. I've run this by >>> Viktor and he however disagrees with the change so I'll leave it >>> for folks to comment and see what other IESG members think.. >>> To be clear, I don't myself think the document needs to be >>> blocked to get this fixed, but I'd like it to be considered. And >>> I figure there are good arguments for both OLD and NEW >>> paragraphs below so I'm not saying that the NEW one below >>> is "right" and the OLD is "wrong" but I do think the NEW is >>> more consistent with what we want to see happen in future. >>> Others, (Viktor for example:-) can reasonably disagree. >>> >>> OLD: >>> >>> With unauthenticated, encrypted communication, OS protocols may >>> employ more liberal settings than would be best-practice when >>> security is mandated by policy. Some legacy systems support >>> encryption, but implement only outdated algorithms or protocol >>> versions. Compatibility with these systems avoids the need to resort >>> to cleartext fallback. >>> >>> NEW: >>> >>> With unauthenticated, encrypted communication, OS protocols may >>> employ more liberal settings than would be best-practice when >>> security is mandated by policy. Some legacy systems support >>> encryption, but implement only outdated algorithms or protocol >>> versions. Compatibility with these systems avoids the need to resort >>> to cleartext fallback. However, the use of "broken" algorithms, >>> especially ones for which a ciphertext-only attack may be >>> feasible in the near term, is not consistent with the OS >>> approach. In such cases, avoiding the "broken" cipher, and >>> falling back to cleartext is in fact the correct outcome, as >>> recorded ciphertext for an algorithm with a feasible >>> ciphertext-only attack is really the same as cleartext. That >>> said, there may be cases where an implementation does negotiate >>> use of such an algorithm for some (hopefully) short period >>> with (hopefully) very few peers, while software and/or >>> configurations are in the process of being updated, but this >>> should be considered a failure (to update) and not as an >>> acceptable outcome that is consistent with the OS approach. >> >> IN GOOD CONDITION: >> >> Some legacy systems support encryption, but implement only >> outdated algorithms or protocol versions. With unauthenticated, >> encrypted communication, OS protocols may tolerate the use of >> outdated algorithms that would generally be excluded when >> security is mandated by policy. Compatibility with legacy >> systems avoids the need to resort to cleartext fallback. >> However, the use of outdated algorithms needs to be a temporary >> transition strategy, used only to in support of an orderly >> phase-out of such algorithms. Outdated algorithms, especially >> those that are already broken in some use-cases, or are expected >> to soon be broken, should not be supported indefinitely. >> >> For a recent example, my SMTP server preempts the SMTP client's >> TLS cipherlist order, and lists RC4 only as a last resort. And >> yet: >> >> Nov 12 03:52:32 amnesiac postfix/smtpd[1144]: >> Anonymous TLS connection established >> from nk11p03mm-asmtpout002.mac.com[17.158.232.237]: >> TLSv1 with cipher RC4-MD5 (128/128 bits) >> >> So this system, sending mail from a "me.com" user is capable nothing >> better than RC4-MD5. I expect such silliness to end soon, but for >> the immediate future, I am leaving RC4 enabled. >> >> -- >> Viktor. >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Mon Nov 17 07:57:35 2014 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 1F3421A7015; Mon, 17 Nov 2014 07:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 Jx_8RO8-bEJ0; Mon, 17 Nov 2014 07:57:26 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id BF4401A7013; Mon, 17 Nov 2014 07:57:26 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 86049438072; Mon, 17 Nov 2014 07:57:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=pa6VJTn/N8t9txO5dOtR 1YxG8CE=; b=RYVevJOOjoBmCCLmIkZBLAFo+0ZmBbaSjRAp7V/xpO16JvwN18/E BcgDRNS/E8fiJyS7uHmr7hlZGtV/tjdPWgpYsBYekFM7QAa9fudmC7hH5XX38hxh ict3AMEj3hdXeG6/GzasXoeeIl7fW1ScvCDSy1wktheagRB10GV14Z8= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 5638B43806C; Mon, 17 Nov 2014 07:57:26 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so2108875wiv.11 for ; Mon, 17 Nov 2014 07:57:25 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.104.234 with SMTP id gh10mr31759601wib.3.1416239845226; Mon, 17 Nov 2014 07:57:25 -0800 (PST) Received: by 10.216.32.135 with HTTP; Mon, 17 Nov 2014 07:57:25 -0800 (PST) In-Reply-To: <546A157A.4060700@cs.tcd.ie> References: <20141116195404.29678.99130.idtracker@ietfa.amsl.com> <20141117010240.GV13179@mournblade.imrryr.org> <546A157A.4060700@cs.tcd.ie> Date: Mon, 17 Nov 2014 09:57:25 -0600 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/poBcTyB_3F9PH_HjBdjjfxciqvY Cc: "saag@ietf.org" , The IESG Subject: Re: [saag] Stephen Farrell's Yes on draft-dukhovni-opportunistic-security-05: (with COMMENT) 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, 17 Nov 2014 15:57:28 -0000 On Mon, Nov 17, 2014 at 9:34 AM, Stephen Farrell wrote: > On 17/11/14 13:51, Black, David wrote: >> +1 on Viktor's middle-ground. I'm +1 on the original. I'd settle for Viktor's counter to Stephen's text (either variant). Needless to say, the identity function is the weakest, most obsolete cryptographic security algorithm available to us. We should ban it before RC4, MD5, ... -- that's the principle that I'm basing my reply on. We have a mostly political trade-off here: - outright prohibitions of broken algorithms provide a strong incentive for making progress on deploying new algorithms - but outright prohibitions on cleartext of the same strength as prohibitions of broken algorithms have not really been tested. Of course, one side effect of more deployment of OS will be to make prohibition of cleartext transmission easier. But if we start by making deployment of any crypto harder... Pushing for a stronger ban of broken algorithms than of cleartext is a recipe for ending up with more cleartext and less OS. But if we allow OS to take root first then we'll be able to improve security across the board, and we'll arrive more quickly at a situation where it's easy to forbid the use of cleartext and weak algorithms. Nico -- From nobody Mon Nov 17 13:28:01 2014 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 5E94F1AC41D for ; Mon, 17 Nov 2014 13:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 A3qOixLJTnYR for ; Mon, 17 Nov 2014 13:27:57 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 44F631ACCFD for ; Mon, 17 Nov 2014 13:27:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9C852BEF8 for ; Mon, 17 Nov 2014 21:27:55 +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 UtXrWDIp1KFR for ; Mon, 17 Nov 2014 21:27:40 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.42.22.166]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DF952BE2F for ; Mon, 17 Nov 2014 21:27:39 +0000 (GMT) Message-ID: <546A684B.2090702@cs.tcd.ie> Date: Mon, 17 Nov 2014 21:27:39 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <99E579B9-63A7-4C4F-864F-84F539B8381E@iab.org> In-Reply-To: <99E579B9-63A7-4C4F-864F-84F539B8381E@iab.org> X-Forwarded-Message-Id: <99E579B9-63A7-4C4F-864F-84F539B8381E@iab.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/sB9nZThUu0RXkOQ44ruZPPIMbgU Subject: [saag] Fwd: IAB Statement on Internet Confidentiality 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, 17 Nov 2014 21:27:59 -0000 Just for the benefit of anyone who's not already seen this fine bit of IAB produce... Cheers, S. -------- Forwarded Message -------- Subject: IAB Statement on Internet Confidentiality Date: Fri, 14 Nov 2014 04:26:02 -0500 From: IAB Chair Reply-To: ietf@ietf.org To: IETF Announce CC: IAB , IETF Please find this statement issued by the IAB today. On behalf of the IAB, Russ Housley IAB Chair = = = = = = = = = = = = = IAB Statement on Internet Confidentiality In 1996, the IAB and IESG recognized that the growth of the Internet depended on users having confidence that the network would protect their private information. RFC 1984 documented this need. Since that time, we have seen evidence that the capabilities and activities of attackers are greater and more pervasive than previously known. The IAB now believes it is important for protocol designers, developers, and operators to make encryption the norm for Internet traffic. Encryption should be authenticated where possible, but even protocols providing confidentiality without authentication are useful in the face of pervasive surveillance as described in RFC 7258. Newly designed protocols should prefer encryption to cleartext operation. There may be exceptions to this default, but it is important to recognize that protocols do not operate in isolation. Information leaked by one protocol can be made part of a more substantial body of information by cross-correlation of traffic observation. There are protocols which may as a result require encryption on the Internet even when it would not be a requirement for that protocol operating in isolation. We recommend that encryption be deployed throughout the protocol stack since there is not a single place within the stack where all kinds of communication can be protected. The IAB urges protocol designers to design for confidential operation by default. We strongly encourage developers to include encryption in their implementations, and to make them encrypted by default. We similarly encourage network and service operators to deploy encryption where it is not yet deployed, and we urge firewall policy administrators to permit encrypted traffic. We believe that each of these changes will help restore the trust users must have in the Internet. We acknowledge that this will take time and trouble, though we believe recent successes in content delivery networks, messaging, and Internet application deployments demonstrate the feasibility of this migration. We also acknowledge that many network operations activities today, from traffic management and intrusion detection to spam prevention and policy enforcement, assume access to cleartext payload. For many of these activities there are no solutions yet, but the IAB will work with those affected to foster development of new approaches for these activities which allow us to move to an Internet where traffic is confidential by default. From nobody Mon Nov 17 20:34:22 2014 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 414981AD0C4; Mon, 17 Nov 2014 20:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 v6EOXVtjo5tE; Mon, 17 Nov 2014 20:34:14 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6C91AD05C; Mon, 17 Nov 2014 20:34:14 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D8C042002A; Mon, 17 Nov 2014 23:36:39 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 802DE637F5; Mon, 17 Nov 2014 23:34:13 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 655F8637EA; Mon, 17 Nov 2014 23:34:13 -0500 (EST) From: Michael Richardson To: Nico Williams In-Reply-To: References: <20141116195404.29678.99130.idtracker@ietfa.amsl.com> <20141117010240.GV13179@mournblade.imrryr.org> <546A157A.4060700@cs.tcd.ie> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/JIh5c6D_HG1-cLwdRJ2HIodA2Yc Cc: The IESG , "saag@ietf.org" Subject: Re: [saag] Stephen Farrell's Yes on draft-dukhovni-opportunistic-security-05: (with COMMENT) 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, 18 Nov 2014 04:34:16 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Nico Williams wrote: > Needless to say, the identity function is the weakest, most obsolete > cryptographic security algorithm available to us. We should ban it > before RC4, MD5, ... -- that's the principle that I'm basing my reply > on. +10. If we can get code and infrastructure deployed to do RC4, then upgrading it to be AES is much simpler than starting from scratch. Remember that if it= 's opportunistic, we might choose the identity encryption algorithm instead. > Pushing for a stronger ban of broken algorithms than of cleartext is a > recipe for ending up with more cleartext and less OS. But if we allow > OS to take root first then we'll be able to improve security across > the board, and we'll arrive more quickly at a situation where it's > easy to forbid the use of cleartext and weak algorithms. Bait and switch doesn't work if you tell people about it :-) =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGrMQYCLcPvd0N1lAQKVGQf/cI5BRU8F2Q+gzTEUyMp+b5tt70x4GIq7 V6vypZhXIfHMxOydFxO5obv6+JfEpZUz2zfFeOb3XGqKucEz6S8RqpIkd/LvHL+Z TKVb5B/1WaVX063F6jL/L+isQuHhz5Y3H6twwmSVcxHtZLWDvkFzj/wZan7/VmVF jvQg8kaWwa9bhkGqkgyxViD37fVFtfqADNL68Sh5Gr89337vHiVMvmz5NCg7oOCy hXq8+vCZrLtMZlNmlH2gbfX7w4SoP5onfQpSMbnkJTZUEiI3CtEroOFSL3Z8Ieb1 YZ5msOaeWf7LPs7F4cKQiQHBYoa9DSPJWddqXSDSkranZLMwMTJcTQ== =fjh5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 18 13:36:51 2014 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 E59511A8F4D for ; Tue, 18 Nov 2014 13:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 4Ux-Ro_poPZu for ; Tue, 18 Nov 2014 13:36:40 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 476531A8ABC for ; Tue, 18 Nov 2014 13:36:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E320CBE1D; Tue, 18 Nov 2014 21:36:38 +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 a0CAZ3xfS5K4; Tue, 18 Nov 2014 21:36:36 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.46.20.163]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B1023BDCA; Tue, 18 Nov 2014 21:36:36 +0000 (GMT) Message-ID: <546BBBE4.7060303@cs.tcd.ie> Date: Tue, 18 Nov 2014 21:36:36 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "saag@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/xAFhawx2ocVhOaJ-PEl090XYKVk Subject: [saag] draft saag minutes posted 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, 18 Nov 2014 21:36:43 -0000 They're at [1]. Please send corrections (if any) here. Thanks to whoever took the initial minutes (who was that?) Thanks, S. [1] https://www.ietf.org/proceedings/91/minutes/minutes-91-saag From nobody Wed Nov 19 11:47:40 2014 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 D46231A6F2A; Wed, 19 Nov 2014 11:47:36 -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] 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 3VsNuFiZEGiZ; Wed, 19 Nov 2014 11:47:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 296871A6EF9; Wed, 19 Nov 2014 11:47:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141119194735.12520.89383.idtracker@ietfa.amsl.com> Date: Wed, 19 Nov 2014 11:47:35 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/NhXgMAynkV0BplUaJN-nqZT_2nI Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Barry Leiba's Yes on draft-dukhovni-opportunistic-security-05: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 19:47:37 -0000 Barry Leiba has entered the following ballot position for draft-dukhovni-opportunistic-security-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This second last call has resolved all the questions I had about this document, and I'm keen to see it move forward. I'll make one note about Stephen's notes: There is no IANA considerations section and no need for one. It'll be interesting to see if this note gets noticed or if folks complain about the lack of a redundant section. I hope the former and not the latter:-) I'm neither complaining nor objecting about the document. But I will point out that RFC 5226 is a BCP that defines our process, and we're supposed to follow it. This note shows an unfortunate disdain for the process that we (the IESG) are supposed to be tending. From nobody Thu Nov 20 05:44:49 2014 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 0EC671A19F7; Thu, 20 Nov 2014 05:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 BOIUG63cBqjz; Thu, 20 Nov 2014 05:44:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3C11A19F6; Thu, 20 Nov 2014 05:44:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141120134443.16690.23726.idtracker@ietfa.amsl.com> Date: Thu, 20 Nov 2014 05:44:43 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Sq_Qe-QOcbX-ozXBgYVjwxMVu_g Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Adrian Farrel's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 13:44:45 -0000 Adrian Farrel has entered the following ballot position for draft-dukhovni-opportunistic-security-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the extra cycle on this document. I think the added polish has made for a much better document. From nobody Fri Nov 21 08:01:23 2014 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 180401A0068; Tue, 18 Nov 2014 00:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 ax0bAvLyxbzM; Tue, 18 Nov 2014 00:11:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C961A0069; Tue, 18 Nov 2014 00:11:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, ietf-dane@dukhovni.org, draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141118081150.22998.27241.idtracker@ietfa.amsl.com> Date: Tue, 18 Nov 2014 00:11:50 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/GqxCMGxYeMLABPunmHPVlCo7GtY X-Mailman-Approved-At: Fri, 21 Nov 2014 08:01:16 -0800 Cc: iesg-secretary@ietf.org Subject: [saag] Last Call Expired: X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 08:11:59 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Sun Nov 23 13:28:29 2014 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 5EA8D1A1B14; Sun, 23 Nov 2014 13:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 ZfT4_gym6RVq; Sun, 23 Nov 2014 13:28:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF971A1AAA; Sun, 23 Nov 2014 13:28:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141123212827.14187.28164.idtracker@ietfa.amsl.com> Date: Sun, 23 Nov 2014 13:28:27 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/zdf6SpjuwdFSwOITv_4r4Jf3twE Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Kathleen Moriarty's Yes on draft-dukhovni-opportunistic-security-05: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 21:28:28 -0000 Kathleen Moriarty has entered the following ballot position for draft-dukhovni-opportunistic-security-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support this document moving forward and think it is important to have the concepts defined and documented. Thanks for your work on this draft. I'd prefer some alternate text to the first paragraph of page 4, but realize this is just a preference and will let it go instead of proposing new text. From nobody Mon Nov 24 08:42:07 2014 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 6E60C1A3BA5 for ; Mon, 24 Nov 2014 08:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 bFdluE3cCAvL for ; Mon, 24 Nov 2014 08:42:04 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id EE6F31A1F02 for ; Mon, 24 Nov 2014 08:42:03 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 9C6499A403E for ; Mon, 24 Nov 2014 11:41:53 -0500 (EST) 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 hJFG-njApgn3 for ; Mon, 24 Nov 2014 11:41:52 -0500 (EST) Received: from [192.168.2.108] (pool-96-255-26-251.washdc.fios.verizon.net [96.255.26.251]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 272659A4006 for ; Mon, 24 Nov 2014 11:41:53 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Nov 2014 11:41:41 -0500 References: <8f573b25b2fc4ff9a294842dd219d45d@CY1PR09MB0444.namprd09.prod.outlook.com> To: IETF SAAG Message-Id: <8D4D433A-0597-419D-889E-0E64EB70CB60@vigilsec.com> Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/blgi62gXi7840qB_BGXyj9SL3lI Subject: [saag] NIST Requests Comments on Latest Revision of NIST SP 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators 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, 24 Nov 2014 16:42:05 -0000 NIST SP 800-90A Rev.1 - DRAFT Recommendation for Random Number = Generation Using Deterministic Random Bit Generators NIST requests your comments on the latest revision of NIST SP 800-90A, = Recommendation for Random Number Generation Using Deterministic Random = Bit Generators, which is dated November 2014. This document specifies = Deterministic Random Bit Generators based on approved hash functions (as = specified in FIPS 180-4), HMAC (as specified in FIPS 198-1) and block = ciphers (as specified in FIPS 197 for AES, and SP 800-67 for TDEA). This = revision removes the previously approved Dual_EC_DRBG that was based on = the use of elliptic curves and includes a number of other changes that = are listed in the final appendix of the document. Please submit comments = to rbg_comments@nist.gov with "SP 800-90A comments" in the subject line = by December 31, 2014. From nobody Mon Nov 24 10:06:21 2014 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 2BB261A87BE; Mon, 24 Nov 2014 10:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1uNtE4eIeW0; Mon, 24 Nov 2014 10:06:17 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 53EA51A87BB; Mon, 24 Nov 2014 10:06:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A61E1BDFD; Mon, 24 Nov 2014 18:06:08 +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 CrP5GQxOXEX7; Mon, 24 Nov 2014 18:06:07 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.46.28.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E3C36BDF7; Mon, 24 Nov 2014 18:06:06 +0000 (GMT) Message-ID: <5473738E.1010501@cs.tcd.ie> Date: Mon, 24 Nov 2014 18:06:06 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "saag@ietf.org" , pkix References: <547372F5.6000606@cs.tcd.ie> In-Reply-To: <547372F5.6000606@cs.tcd.ie> X-Forwarded-Message-Id: <547372F5.6000606@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/UY15mYr-y1qrjGx5UUX7B_p7TfQ Subject: [saag] Fwd: Re: [therightkey] Proposal: ACME list 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, 24 Nov 2014 18:06:19 -0000 FYI, we've made a new list as a result of a request to therightkey@ietf.org. Cheers, S. -------- Forwarded Message -------- Subject: Re: [therightkey] Proposal: ACME list Date: Mon, 24 Nov 2014 18:03:33 +0000 From: Stephen Farrell To: Richard Barnes CC: therightkey@ietf.org Hi Richard, That's done now. [1] I assume you'll kick off discussion in a few days S. [1] https://www.ietf.org/mailman/listinfo/acme On 21/11/14 10:03, Stephen Farrell wrote: > > > On 20/11/14 22:58, Phillip Hallam-Baker wrote: >> On Thu, Nov 20, 2014 at 5:03 PM, Richard Barnes wrote: >>> As some of you may have heard, some of us have been working on a protocol to >>> automate certificate management, including things like registration, >>> enrollment, issuance, and revocation. >>> >>> >>> There is some similarity to existing CA-proprietary issuance APIs, and to >>> projects like SSLMate. >>> >>> >>> Would folks be interested in spinning up an IETF mailing list on this topic? >>> It seems like we could probably get this in shape for a BoF in Dallas. >> >> There is definitely a need for this to enable use of short liver certs > > Lovely typo! (Or were you only kidneying:-) > >> and to clean up the mess of existing proposals, none of which are >> really viable as automated protocols. >> >> I proposed this a while back: >> >> http://tools.ietf.org/html/draft-hallambaker-omnipublish-00 > > Yep, this seems like something we've all been waiting to see > happen, and given that we have credible folks announcing the > accompanying service(s) too, and being willing to run their > protocol through here, I think it's probably a fine plan to > start that list - I'll go ask and get back here once it's > sorted. > > Cheers, > S. > >> >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey >> >> > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > > _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey From nobody Mon Nov 24 10:21:06 2014 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 CE95C1A8791 for ; Mon, 24 Nov 2014 10:21:00 -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] 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 qIrY3yhg2JPs for ; Mon, 24 Nov 2014 10:20:58 -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 71A101A701E for ; Mon, 24 Nov 2014 10:20:58 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8DB21282FBC; Mon, 24 Nov 2014 18:20:57 +0000 (UTC) Date: Mon, 24 Nov 2014 18:20:57 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20141124182057.GH20723@mournblade.imrryr.org> References: <547372F5.6000606@cs.tcd.ie> <5473738E.1010501@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5473738E.1010501@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/XE1XeIcv5sc3cKIcNDZUy9BheYM Subject: Re: [saag] Fwd: Re: [therightkey] Proposal: ACME list X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 24 Nov 2014 18:21:01 -0000 On Mon, Nov 24, 2014 at 06:06:06PM +0000, Stephen Farrell wrote: > FYI, we've made a new list as a result of a request to > therightkey@ietf.org. Likely you already know, and this will be created soon, but just in case, the list archive currently returns 404: http://www.ietf.org/mail-archive/web/acme/ -- Viktor. From nobody Mon Nov 24 10:29:56 2014 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 332A81A7113 for ; Mon, 24 Nov 2014 10:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 1p6sx_mzLl4i for ; Mon, 24 Nov 2014 10:29:44 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B252A1A7035 for ; Mon, 24 Nov 2014 10:29:44 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id E41466B007B for ; Mon, 24 Nov 2014 10:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=+XjOWByoFhnwT2OMyVThE41 dwTY=; b=kphTQeXQST9d3VukxAxGv1IIRTtQP4FJerbFiwvtyOf8GQosA7LG7mi j6FQAOApEdSLBdKXvbnfdunHVnTdAtFzv9KSUH0bvko4peD+X383CaVUTlc+O2LJ etj/JpvVTWAm7HI9dmrxv5fULRjMA2x8PTED9uhBF0Bu2MDybRa8= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id BA3C46B0078 for ; Mon, 24 Nov 2014 10:29:43 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so6657958wiv.5 for ; Mon, 24 Nov 2014 10:29:42 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.98.233 with SMTP id el9mr23756050wib.3.1416853782743; Mon, 24 Nov 2014 10:29:42 -0800 (PST) Received: by 10.216.32.136 with HTTP; Mon, 24 Nov 2014 10:29:42 -0800 (PST) In-Reply-To: <20141124182057.GH20723@mournblade.imrryr.org> References: <547372F5.6000606@cs.tcd.ie> <5473738E.1010501@cs.tcd.ie> <20141124182057.GH20723@mournblade.imrryr.org> Date: Mon, 24 Nov 2014 12:29:42 -0600 Message-ID: From: Nico Williams To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/KTwlBcQ5xfUKbHCuawNePwplZ78 Subject: Re: [saag] Fwd: Re: [therightkey] Proposal: ACME list 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, 24 Nov 2014 18:29:45 -0000 Also, I'm not getting subscription confirmation emails. From nobody Mon Nov 24 10:40:13 2014 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 2194B1A879D for ; Mon, 24 Nov 2014 10:40: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] 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 z7h4hWihTIDx for ; Mon, 24 Nov 2014 10:40:02 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 854DB1A87A2 for ; Mon, 24 Nov 2014 10:39:56 -0800 (PST) Received: from [10.70.10.64] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 15E68F984 for ; Mon, 24 Nov 2014 13:39:54 -0500 (EST) Message-ID: <54737B72.1030706@fifthhorseman.net> Date: Mon, 24 Nov 2014 13:39:46 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Icedove/33.0 MIME-Version: 1.0 To: saag References: <547372F5.6000606@cs.tcd.ie> <5473738E.1010501@cs.tcd.ie> <20141124182057.GH20723@mournblade.imrryr.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/cjr5Nx0utHTOQtBa1eWsQAWfES8 Subject: Re: [saag] Fwd: Re: [therightkey] Proposal: ACME list 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, 24 Nov 2014 18:40:08 -0000 On 11/24/2014 01:29 PM, Nico Williams wrote: > Also, I'm not getting subscription confirmation emails. i got subscription confirmation mails (both the initial callback verification and the "you're now subscribed"). I started the process with: echo subscribe | mail -s subscribe acme-request@ietf.org ymmv, of course. --dkg From nobody Mon Nov 24 10:53:07 2014 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 20D3C1A87BF for ; Mon, 24 Nov 2014 10:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 Zsw-CYZ4Yzay for ; Mon, 24 Nov 2014 10:52:59 -0800 (PST) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C8D981A879B for ; Mon, 24 Nov 2014 10:52:53 -0800 (PST) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id AA0BD20058D82; Mon, 24 Nov 2014 10:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=SQz3tP99uGvAux eVP+wInTKUd0M=; b=JdsNwGmnZOrVRZLzQ4v5k99cRZOW5nftUaQqq7Sh7Xv+sG N88iv/lpLLLazvIw2LVJ9zTTvGFvfNMzxzwDerIs23DQGS6nlPUwqyrBt71ZGR5H vXw2QLovmuDYRQEnaY84+5dFwnITfvc2gHAj85PW7A5nWsP6RRoLkUwAk7Vdk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPA id 5CE772005D82D; Mon, 24 Nov 2014 10:52:53 -0800 (PST) Date: Mon, 24 Nov 2014 12:52:52 -0600 From: Nico Williams To: Daniel Kahn Gillmor Message-ID: <20141124185251.GO3200@localhost> References: <547372F5.6000606@cs.tcd.ie> <5473738E.1010501@cs.tcd.ie> <20141124182057.GH20723@mournblade.imrryr.org> <54737B72.1030706@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54737B72.1030706@fifthhorseman.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4Vy09lPKicBOBthYKOu0ZeRuiZc Cc: saag Subject: Re: [saag] Fwd: Re: [therightkey] Proposal: ACME list 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, 24 Nov 2014 18:53:02 -0000 On Mon, Nov 24, 2014 at 01:39:46PM -0500, Daniel Kahn Gillmor wrote: > On 11/24/2014 01:29 PM, Nico Williams wrote: > > Also, I'm not getting subscription confirmation emails. > > i got subscription confirmation mails (both the initial callback > verification and the "you're now subscribed"). I started the process with: > > echo subscribe | mail -s subscribe acme-request@ietf.org > > ymmv, of course. Thanks. It's working for me now. From nobody Mon Nov 24 14:59:36 2014 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 497631A8A74; Mon, 24 Nov 2014 14:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] 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 uNhdMNX7vN5w; Mon, 24 Nov 2014 14:59:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F821A8749; Mon, 24 Nov 2014 14:59:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141124225931.29823.9415.idtracker@ietfa.amsl.com> Date: Mon, 24 Nov 2014 14:59:31 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/MtYAtaz7JcHtIMERcODmAtT8qrE Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Alissa Cooper's Yes on draft-dukhovni-opportunistic-security-05: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 22:59:32 -0000 Alissa Cooper has entered the following ballot position for draft-dukhovni-opportunistic-security-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for all the work on this, much improved. = Section 3 = "In general, communication should be at least encrypted." I agree with this, but it is a little out of sync with the more factual description given in Section 1.2. I also don't know if it's supposed to have a normative feel (the goal should be, at a minimum, encryption) or a descriptive feel (one can expect communications to be, at a minimum, encrypted). Clarification and streamlining with what is said in 1.2 and immediately preceding this sentence would help -- perhaps by just deleting this sentence? From nobody Mon Nov 24 17:37:06 2014 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 6E7CE1A700B; Mon, 24 Nov 2014 17:37:01 -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] 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 EkzoxUugp5Zr; Mon, 24 Nov 2014 17:36:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FE51A6FF5; Mon, 24 Nov 2014 17:36:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141125013634.21270.3059.idtracker@ietfa.amsl.com> Date: Mon, 24 Nov 2014 17:36:34 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/hpuWWJBxQfXg6ShPVUk7rKqcn_Q Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Pete Resnick's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 01:37:01 -0000 Pete Resnick has entered the following ballot position for draft-dukhovni-opportunistic-security-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Well, either Stephen or I get to hold the DISCUSS, so I guess it's going to be me. As soon as this discussion is addressed, I'll switch to "Yes". I disagree with the change to section 3 in the RFC Editor Note, as it does not represent IETF consensus. The current text as stated in the document is fine. I feel that any discussion of the "transition" from broken algorithms to good ones (not to mention the transition from cleartext to encrypted) is really orthogonal to this document: This document is saying that, if clear text is permitted, the protocol will work it's way up from clear text (if possible) to the best security it is able to achieve. That includes encryption using broken algorithms, which is still better than clear text to prevent a passive observer, who might not be willing to invest in saving the data and decrypting it later, from seeing the data. That we want to transition away from broken algorithms is as true as the fact that we want to transition away from clear text, but even the latter is not currently mentioned in the document, except by implication in the last paragraph of section 3. I think a reasonable compromise is to add some discussion of broken algorithms to the last paragraph of section 3: OLD Cleartext is supported for backwards compatibility with systems already deployed. Even when cleartext needs to be supported, protocol designs based on Opportunistic Security prefer to encrypt, employing cleartext only with peers that do not appear to be encryption capable. NEW The support of cleartext and the use of outdated algorithms, and especially broken algorithms, is for backwards compatibility with systems already deployed. Protocol designs based on Opportunistic Security prefer to encrypt, and prefer to use the best available encryption algorithms available. OS protocols employ cleartext or broken encryption algorithms only with peers that do not appear to be capable of doing otherwise. If Stephen or others insist that transition be mentioned, you could add a sentence to that paragraph, and I am likely willing to hold my nose: The eventual desire is to transition away from cleartext and broken algorithms, and particularly for broken algorithms, it is highly desirable to remove such functionality from implementations. But I really don't believe that such a sentence belongs in this document; if it does, it probably belongs in every Security Considerations section ever written that mentions the use of cleartext or encryption algorithms. From nobody Mon Nov 24 17:44:49 2014 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 194011A700B; Mon, 24 Nov 2014 17:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwBt1RsILUtV; Mon, 24 Nov 2014 17:44:46 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9281A6F07; Mon, 24 Nov 2014 17:44:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5FEDEBEB3; Tue, 25 Nov 2014 01:44:45 +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 T908ExDzV7ec; Tue, 25 Nov 2014 01:44:43 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.46.28.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7557DBEAA; Tue, 25 Nov 2014 01:44:43 +0000 (GMT) Message-ID: <5473DF0B.4070901@cs.tcd.ie> Date: Tue, 25 Nov 2014 01:44:43 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Pete Resnick , The IESG References: <20141125013634.21270.3059.idtracker@ietfa.amsl.com> In-Reply-To: <20141125013634.21270.3059.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/iPOMVQJdCvlPn9DkSxg4NOwpTDs Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Pete Resnick's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS) 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, 25 Nov 2014 01:44:48 -0000 Hi Pete, I could live with your nose-holding text and have updated the RFC editor note accordingly. Let me know if I got that right or not. Thanks, S. On 25/11/14 01:36, Pete Resnick wrote: > Pete Resnick has entered the following ballot position for > draft-dukhovni-opportunistic-security-05: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Well, either Stephen or I get to hold the DISCUSS, so I guess it's going > to be me. As soon as this discussion is addressed, I'll switch to "Yes". > > I disagree with the change to section 3 in the RFC Editor Note, as it > does not represent IETF consensus. The current text as stated in the > document is fine. I feel that any discussion of the "transition" from > broken algorithms to good ones (not to mention the transition from > cleartext to encrypted) is really orthogonal to this document: This > document is saying that, if clear text is permitted, the protocol will > work it's way up from clear text (if possible) to the best security it is > able to achieve. That includes encryption using broken algorithms, which > is still better than clear text to prevent a passive observer, who might > not be willing to invest in saving the data and decrypting it later, from > seeing the data. That we want to transition away from broken algorithms > is as true as the fact that we want to transition away from clear text, > but even the latter is not currently mentioned in the document, except by > implication in the last paragraph of section 3. > > I think a reasonable compromise is to add some discussion of broken > algorithms to the last paragraph of section 3: > > OLD > Cleartext is supported for backwards compatibility with systems > already deployed. Even when cleartext needs to be supported, > protocol designs based on Opportunistic Security prefer to encrypt, > employing cleartext only with peers that do not appear to be > encryption capable. > NEW > The support of cleartext and the use of outdated algorithms, and > especially broken algorithms, is for backwards compatibility with > systems already deployed. Protocol designs based on Opportunistic > Security prefer to encrypt, and prefer to use the best available > encryption algorithms available. OS protocols employ cleartext or > broken encryption algorithms only with peers that do not appear to be > capable of doing otherwise. > > If Stephen or others insist that transition be mentioned, you could add a > sentence to that paragraph, and I am likely willing to hold my nose: > > The eventual desire is to transition > away from cleartext and broken algorithms, and particularly for > broken algorithms, it is highly desirable to remove such > functionality from implementations. > > But I really don't believe that such a sentence belongs in this document; > if it does, it probably belongs in every Security Considerations section > ever written that mentions the use of cleartext or encryption algorithms. > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Mon Nov 24 17:57:29 2014 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 C244D1A8748; Mon, 24 Nov 2014 17:57:27 -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] 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 BlInPFDiSChJ; Mon, 24 Nov 2014 17:57:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4602E1A8747; Mon, 24 Nov 2014 17:57:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141125015725.21158.76393.idtracker@ietfa.amsl.com> Date: Mon, 24 Nov 2014 17:57:25 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/xXloFSH6QuQdUbobO0Q-QDBLrXU Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Pete Resnick's Yes on draft-dukhovni-opportunistic-security-05: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 01:57:27 -0000 Pete Resnick has entered the following ballot position for draft-dukhovni-opportunistic-security-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The last sentence of replacement paragraph for section 3 in the RFC Editor Note is distasteful. Discussion of the "transition" from broken algorithms to good ones (let alone the transition from cleartext to encrypted) is really orthogonal to the purpose of this document. But if the sponsoring AD (and the IESG) truly believe that saying such a thing represents the consensus of the IETF, I am willing to hold my nose on this sentence. I am otherwise fully supportive of this document. From nobody Mon Nov 24 17:57:52 2014 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 267201A0398; Mon, 24 Nov 2014 17:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_-1PR9blfkH; Mon, 24 Nov 2014 17:57:39 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0D901A8792; Mon, 24 Nov 2014 17:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1416880660; x=1448416660; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=D1Baupq5vzV8QZROB9ab5VdsqAVN+X1W3CqRwaE3dKo=; b=ZCGPPQn2Jrb3csfF2/VeehSo2DAJpw8MKj9PZ9qn71lReJ5TPpKGRjFW EOIhFOIvSIkVmGRt7vfMEX4LT1ndTKOVwHtl1P0eiFmPtfJoIvbUeMqn2 jKJvKXq75DdqJVYGfH5BFMNhMCDsvs5Mb0w2Y2i5Ftx8Z1iDmYPxDREVc g=; X-IronPort-AV: E=McAfee;i="5600,1067,7632"; a="179720294" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine02.qualcomm.com with ESMTP; 24 Nov 2014 17:57:39 -0800 X-IronPort-AV: E=Sophos;i="5.07,452,1413270000"; d="scan'208";a="31100007" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Nov 2014 17:57:38 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 24 Nov 2014 17:57:38 -0800 Message-ID: <5473E210.70601@qti.qualcomm.com> Date: Mon, 24 Nov 2014 19:57:36 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Stephen Farrell References: <20141125013634.21270.3059.idtracker@ietfa.amsl.com> <5473DF0B.4070901@cs.tcd.ie> In-Reply-To: <5473DF0B.4070901@cs.tcd.ie> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Lc7tiNSB-oCkarIXfatJGUbmsYQ Cc: The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org Subject: Re: [saag] Pete Resnick's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS) 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, 25 Nov 2014 01:57:47 -0000 Clothespin firmly attached to proboscis, I have switched to a "Yes". pr On 11/24/14 7:44 PM, Stephen Farrell wrote: > Hi Pete, > > I could live with your nose-holding text and have updated > the RFC editor note accordingly. Let me know if I got that > right or not. > > Thanks, > S. > > On 25/11/14 01:36, Pete Resnick wrote: > >> Pete Resnick has entered the following ballot position for >> draft-dukhovni-opportunistic-security-05: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Well, either Stephen or I get to hold the DISCUSS, so I guess it's going >> to be me. As soon as this discussion is addressed, I'll switch to "Yes". >> >> I disagree with the change to section 3 in the RFC Editor Note, as it >> does not represent IETF consensus. The current text as stated in the >> document is fine. I feel that any discussion of the "transition" from >> broken algorithms to good ones (not to mention the transition from >> cleartext to encrypted) is really orthogonal to this document: This >> document is saying that, if clear text is permitted, the protocol will >> work it's way up from clear text (if possible) to the best security it is >> able to achieve. That includes encryption using broken algorithms, which >> is still better than clear text to prevent a passive observer, who might >> not be willing to invest in saving the data and decrypting it later, from >> seeing the data. That we want to transition away from broken algorithms >> is as true as the fact that we want to transition away from clear text, >> but even the latter is not currently mentioned in the document, except by >> implication in the last paragraph of section 3. >> >> I think a reasonable compromise is to add some discussion of broken >> algorithms to the last paragraph of section 3: >> >> OLD >> Cleartext is supported for backwards compatibility with systems >> already deployed. Even when cleartext needs to be supported, >> protocol designs based on Opportunistic Security prefer to encrypt, >> employing cleartext only with peers that do not appear to be >> encryption capable. >> NEW >> The support of cleartext and the use of outdated algorithms, and >> especially broken algorithms, is for backwards compatibility with >> systems already deployed. Protocol designs based on Opportunistic >> Security prefer to encrypt, and prefer to use the best available >> encryption algorithms available. OS protocols employ cleartext or >> broken encryption algorithms only with peers that do not appear to be >> capable of doing otherwise. >> >> If Stephen or others insist that transition be mentioned, you could add a >> sentence to that paragraph, and I am likely willing to hold my nose: >> >> The eventual desire is to transition >> away from cleartext and broken algorithms, and particularly for >> broken algorithms, it is highly desirable to remove such >> functionality from implementations. >> >> But I really don't believe that such a sentence belongs in this document; >> if it does, it probably belongs in every Security Considerations section >> ever written that mentions the use of cleartext or encryption algorithms. >> >> >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> >> > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Nov 24 20:41:37 2014 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 2ED5D1A1B9B; Mon, 24 Nov 2014 20:41:35 -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] 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 FCSLG_psX2Lt; Mon, 24 Nov 2014 20:41:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 967141A1B94; Mon, 24 Nov 2014 20:41:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141125044133.22746.78939.idtracker@ietfa.amsl.com> Date: Mon, 24 Nov 2014 20:41:33 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Nbo_Ww_-qoXwzjOTmUBfjEdO_XY Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 04:41:35 -0000 Ted Lemon has entered the following ballot position for draft-dukhovni-opportunistic-security-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm generally in favor of this document, but there is something I feel needs to be discussed. Section 4 describes the use of OE with SMTP, using STARTTLS. However, it turns out that recently it's been discovered that this convention is under attack by some ISPs: https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks It's pretty clear that this downgrade attack is inexpensive to do, and it does exactly what a passive attacker would want: it defeats OE. If OE is that easily subverted, what good is it? I don't see the current document touching on this issue: instead, it simply accepts that this is true, but ignores it as an issue, asserting that MITM attacks are expensive, so OE helps. I think the facts on the ground show that this is not so. From nobody Mon Nov 24 20:44:17 2014 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 6AF741A6F57; Mon, 24 Nov 2014 20:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 R3Qy7GmoQ7n5; Mon, 24 Nov 2014 20:44:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4942E1A1B89; Mon, 24 Nov 2014 20:44:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141125044413.15149.6361.idtracker@ietfa.amsl.com> Date: Mon, 24 Nov 2014 20:44:13 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/t-F07gGDJuQDIBYeMsj5fROHxzw Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Spencer Dawkins' No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 04:44:14 -0000 Spencer Dawkins has entered the following ballot position for draft-dukhovni-opportunistic-security-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The document is much improved in -05. Thank you for circling back around. From nobody Mon Nov 24 20:54:10 2014 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 61EFB1A1B94; Mon, 24 Nov 2014 20:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOCKnUIQ6wih; Mon, 24 Nov 2014 20:54:02 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6A31A1B7D; Mon, 24 Nov 2014 20:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1416891242; x=1448427242; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WeWtSWwVRbs2wJyFeFIb5ggbCf65WLFMquAsAsXurIs=; b=AAnxMlJPQWGIeoUxPcaXYdwgGc0uXOeLHAH3S4IMc0XOp25sqDJn/+FH XbpHeQ9eFfinfXNMSStvLdsNzVg3Bnk+n0+1ng6eviaEQw39xROj+1lGT 7fdGrq0WY9T1+mF49FztdhPcrLMEAyBO/alas97Y5G8wTizGfkKJfY9ty 0=; X-IronPort-AV: E=McAfee;i="5600,1067,7632"; a="179751999" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Nov 2014 20:54:02 -0800 X-IronPort-AV: E=Sophos;i="5.07,453,1413270000"; d="scan'208";a="798433227" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Nov 2014 20:54:01 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 24 Nov 2014 20:54:01 -0800 Message-ID: <54740B66.7010505@qti.qualcomm.com> Date: Mon, 24 Nov 2014 22:53:58 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Ted Lemon References: <20141125044133.22746.78939.idtracker@ietfa.amsl.com> In-Reply-To: <20141125044133.22746.78939.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01H.na.qualcomm.com (10.85.0.34) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/fKXTdGrFrdfYVG1us8RQhebdzjY Cc: The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS) 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, 25 Nov 2014 04:54:04 -0000 On 11/24/14 10:41 PM, Ted Lemon wrote: > Section 4 describes the use of OE with SMTP, using STARTTLS. However, > it turns out that recently it's been discovered that this convention is > under attack by some ISPs: > https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks > > It's pretty clear that this downgrade attack is inexpensive to do, and it > does exactly what a passive attacker would want: it defeats OE. If OE > is that easily subverted, what good is it? I don't see the current > document touching on this issue: instead, it simply accepts that this is > true, but ignores it as an issue, asserting that MITM attacks are > expensive, so OE helps. I think the facts on the ground show that this > is not so. > How cheap is it for an ISP to make you its customer? MiTM attacks are way more expensive than passive attacks. It is no doubt true that on-path attacks can pretty straightforwardly defeat the encryption part of OS, but as section 3 says, the main benefit of encryption in OS is to prevent passive attacks, and that you need authentication to prevent the active (e.g. MiTM) attacks. The document directly addresses this point, so I'm not clear what's missing. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Nov 24 21:01:37 2014 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 996211A1BBC; Mon, 24 Nov 2014 21:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD0Y7Y-9Fi-c; Mon, 24 Nov 2014 21:01:34 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 6F0C61A1BBD; Mon, 24 Nov 2014 21:01:34 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 55671DA0174; Tue, 25 Nov 2014 05:01:24 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 14B4F53E078; Mon, 24 Nov 2014 21:01:04 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 24 Nov 2014 21:01:03 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <54740B66.7010505@qti.qualcomm.com> Date: Tue, 25 Nov 2014 00:00:53 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <1F510558-3C0E-4F30-AC99-15AF2FD50C0C@nominum.com> References: <20141125044133.22746.78939.idtracker@ietfa.amsl.com> <54740B66.7010505@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/vUfTAHQ0QnckffLj8shq7s51kq4 Cc: The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS) 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, 25 Nov 2014 05:01:35 -0000 On Nov 24, 2014, at 11:53 PM, Pete Resnick = wrote: > How cheap is it for an ISP to make you its customer? MiTM attacks are = way more expensive than passive attacks. Actually no, MITM attacks that just prevent attempts to encrypt are not = way more expensive than passive attacks. Passive attacks are actually = pretty expensive because of the need to store the data. It is a very = safe bet that if OE becomes widespread, we will see attacks of this = type. > It is no doubt true that on-path attacks can pretty straightforwardly = defeat the encryption part of OS, but as section 3 says, the main = benefit of encryption in OS is to prevent passive attacks, and that you = need authentication to prevent the active (e.g. MiTM) attacks. The = document directly addresses this point, so I'm not clear what's missing. No, the document does not address this point. It says that we can't = prevent MITM without authentication, but it also says that OE is worth = doing because MITM is expensive. MITM on an OE link _is_ expensive for = TLS, because you have to decrypt and re-encrypt the data. However, it = is _not_ expensive if you can just prevent encryption from happening at = all. The document doesn't really talk about this. That's what I'm = asking for. I am _not_ saying the document is wrong or shouldn't be = published, but it's going to be a real lame duck if it doesn't talk = about this, given that the EFF is crying to the four winds about the = STARTTLS issue (IMHO rightly so). From nobody Mon Nov 24 21:42:33 2014 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 D76EE1A6FED; Mon, 24 Nov 2014 21:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mfoayoA0oK2; Mon, 24 Nov 2014 21:42:29 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3B61A6FD5; Mon, 24 Nov 2014 21:42:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1416894149; x=1448430149; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Tv3/LkU6R75NqXhsgYWJhvzMLHTH7GYmyEPmxBG2teo=; b=AmI9pIj4kd+hdbR+7Gy13ORG4iKgAUe+RR77Oo+HSE0iGWpsVTsBz8jI 0EwFCc9ujRUHbuu/XZ3TE/MfKzrsdTWzdOHPvvhiudkoghJPCoprmFUxt wmo1WNk/I3dPCPz5sAuC21IEORPNdScHc06NmlEa2oYTRygcmpnQ3LFy4 o=; X-IronPort-AV: E=McAfee;i="5600,1067,7632"; a="87953822" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Nov 2014 21:42:27 -0800 X-IronPort-AV: E=Sophos;i="5.07,453,1413270000"; d="scan'208";a="798457028" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Nov 2014 21:42:28 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 24 Nov 2014 21:42:26 -0800 Message-ID: <547416B5.7030905@qti.qualcomm.com> Date: Mon, 24 Nov 2014 23:42:13 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Ted Lemon References: <20141125044133.22746.78939.idtracker@ietfa.amsl.com> <54740B66.7010505@qti.qualcomm.com> <1F510558-3C0E-4F30-AC99-15AF2FD50C0C@nominum.com> In-Reply-To: <1F510558-3C0E-4F30-AC99-15AF2FD50C0C@nominum.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.85.0.33) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HUonPXeMI6Rh2qyl8Geu2uul6Jc Cc: saag@ietf.org, The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS) 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, 25 Nov 2014 05:42:31 -0000 On 11/24/14 11:00 PM, Ted Lemon wrote: > On Nov 24, 2014, at 11:53 PM, Pete Resnick wrote: > >> How cheap is it for an ISP to make you its customer? MiTM attacks are way more expensive than passive attacks. >> > Actually no, MITM attacks that just prevent attempts to encrypt are not way more expensive than passive attacks. But in order to do the kind of attack EFF is talking about, you have to be on-path. Getting on-path is more expensive than listening from off-path. > Passive attacks are actually pretty expensive because of the need to store the data. No need to store all the clear text, depending on your target. You can just scan for what you're looking for. > It is a very safe bet that if OE becomes widespread, we will see attacks of this type. > Of course. But the document already warns of the attack. >> It is no doubt true that on-path attacks can pretty straightforwardly defeat the encryption part of OS, but as section 3 says, the main benefit of encryption in OS is to prevent passive attacks, and that you need authentication to prevent the active (e.g. MiTM) attacks. The document directly addresses this point, so I'm not clear what's missing. >> > No, the document does not address this point. It says that we can't prevent MITM without authentication, but it also says that OE is worth doing because MITM is expensive. No it doesn't. The document doesn't say anywhere that MiTM is expensive. It says in the intro that clear text makes passive monitoring easier because it makes it "cost-effective, or at least not cost-prohibitive", but it says nothing about the relative cost of MiTM. So I'm not sure what you're arguing against. > MITM on an OE link _is_ expensive for TLS, because you have to decrypt and re-encrypt the data. However, it is _not_ expensive if you can just prevent encryption from happening at all. The document doesn't really talk about this. You are correct that it does not talk about MiTM not being (very) expensive, But it does say: When encryption capability is advertised over an insecure channel, MiTM downgrade attacks to cleartext may be possible. Since encryption without authentication only mitigates passive attacks, this risk is consistent with the expected level of protection. > That's what I'm asking for. I am _not_ saying the document is wrong or shouldn't be published, but it's going to be a real lame duck if it doesn't talk about this, given that the EFF is crying to the four winds about the STARTTLS issue (IMHO rightly so). > I think you're going to have to point me toward where in the doc you might want text and what you think it might say to convince me that something's missing. The document acknowledges that MiTM downgrade (really lack-of-upgrade) attacks are possible, and that this is to be expected. The fact that it doesn't talk about relative expense for any of these attacks says to me that there's no need to add text saying that this particular attack happens to be cheaper than some others. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Nov 24 21:59:34 2014 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 163A61A1B94; Mon, 24 Nov 2014 21:59:33 -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] 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 jvA7VPgVkrOV; Mon, 24 Nov 2014 21:59:31 -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 D71481A6FD5; Mon, 24 Nov 2014 21:59:30 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A194D28302F; Tue, 25 Nov 2014 05:59:29 +0000 (UTC) Date: Tue, 25 Nov 2014 05:59:29 +0000 From: Viktor Dukhovni To: Ted Lemon Message-ID: <20141125055929.GW20723@mournblade.imrryr.org> References: <20141125044133.22746.78939.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141125044133.22746.78939.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/upe8T9SkUc3Jgf88iKKnyAzvJDQ Cc: The IESG , saag@ietf.org Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 25 Nov 2014 05:59:33 -0000 On Mon, Nov 24, 2014 at 08:41:33PM -0800, Ted Lemon wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 4 describes the use of OE with SMTP, using STARTTLS. However, > it turns out that recently it's been discovered that this convention is > under attack by some ISPs: > https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks This "attack" has been discussed at length on various lists. Indeed opportunistic STARTTLS is easily defeated by active attacks. It addresses ONLY passive monitoring. This is why I've invested a year and a half of my life into building DANE TLS for SMTP. However, not all is lost even without DANE: * Active attacks on everyone all the time are bound to be noticed. Attackers engaged in large scale passive monitoring might no longer be able to just collect everything, they'll have to be more selective. * In particular, substantial deviations from the norm are noticeable! Look, for example the 90-day (default display is 30 days, click on 90 for a longer-term view) outbound stats from gmail. What happened around Oct 15th? https://www.google.com/transparencyreport/saferemail/ Though Google are not saying what happened, and it may well not have been a downgrade attack, this sort of thing does not escape attention. * Some applications will employ various pinning strategies, and some sessions will be authenticated, and it is not always possible for the attacker to know which is which. > It's pretty clear that this downgrade attack is inexpensive to do, and it > does exactly what a passive attacker would want: it defeats OE. If OE > is that easily subverted, what good is it? I don't see the current > document touching on this issue: instead, it simply accepts that this is > true, but ignores it as an issue, asserting that MITM attacks are > expensive, so OE helps. I think the facts on the ground show that this > is not so. Specific techniques for detection and mitigation of active attacks in the absence of authentication are I think out of scope for this document. Individual application protocols may define additional measures to make systematic downgrades less likely and once we have more experience in this space future revisions may be able to make generally applicable observations and recommendations. The document encourages opportunistic protection against active attacks too, and does not call itself OE in good part for that reason. If it were only OE, I would not have objected to Steve Kent's draft as much, and we'd likely be polishing that (a lot less work for me). In a departure from a pure OE to thwart PM agenda, the draft recommends negotiation of authentication (over already established channels, via pinning, DANE, whatever), precisely because we should do better than just unauthenticated, encrypted communication if at all possible. My personal view is that DANE is the way forward in that space, but it is not yet mature enough to assert a strong claim along those lines. We have many years of operational obstacles to overcome first (DNSSEC last-mile, nameserver bugs, registrar interfaces, ...). SMTP with DANE has seen some real deployment this year in Germany, and if all goes well, deployment will grow beyond Germany's borders in 2015. -- Viktor. From nobody Mon Nov 24 23:31:17 2014 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 A659F1A0029; Mon, 24 Nov 2014 23:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 d0Gk_upKoixH; Mon, 24 Nov 2014 23:31:08 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344FE1A0006; Mon, 24 Nov 2014 23:31:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5086; q=dns/txt; s=iport; t=1416900668; x=1418110268; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=eR1YHdMEWruNFjfE1g7woR33zGRvwOc+mlb2hm9vN7Y=; b=YMHPcCeyB2U/Dhw21UpqLOJ7tyRmq9HyPmZPAWkgofEbwBmTh5flztNP JGNFYdnvFNj3Ef4sSh2X5n/IEvT/sr8VSriBwYjehbgLUf4/l6Y33Ji/O +LCV+w/XH2RwPHbBHsJ25BfL6GVD+YkzEQUGEjsJmbBmmNob74/KtWhET w=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoEABIvdFStJssW/2dsb2JhbABbg1iDXLdgjk2GUAKBKQEBAQEBfYQDAQEEI1UBEAsYCRYLAgIJAwIBAgFFBgEMAQcBARWIJw25dJZoAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSQegeCeIFVAQSEeDYCgR2OO4FVhUOCWogJjw+CN4FGRoJ6AQEB X-IronPort-AV: E=Sophos;i="5.07,454,1413244800"; d="asc'?scan'208";a="248523248" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 25 Nov 2014 07:31:05 +0000 Received: from [10.61.200.210] ([10.61.200.210]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sAP7V56n006632; Tue, 25 Nov 2014 07:31:05 GMT Message-ID: <54743038.6020401@cisco.com> Date: Tue, 25 Nov 2014 08:31:04 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org, Ted Lemon References: <20141125044133.22746.78939.idtracker@ietfa.amsl.com> <20141125055929.GW20723@mournblade.imrryr.org> In-Reply-To: <20141125055929.GW20723@mournblade.imrryr.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O9MMsdu9GUF66OrPef2PNv18M1BC31Sg9" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/QQXPZ9uarSKo1NctvycwBt1n-MQ Cc: The IESG Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS) 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, 25 Nov 2014 07:31:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --O9MMsdu9GUF66OrPef2PNv18M1BC31Sg9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Viktor and everyone, Sorry to post during the IESG debate, but I have one observation and perhaps a suggestion to move things forward. On 11/25/14, 6:59 AM, Viktor Dukhovni wrote: > On Mon, Nov 24, 2014 at 08:41:33PM -0800, Ted Lemon wrote: > >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> Section 4 describes the use of OE with SMTP, using STARTTLS. However= , >> it turns out that recently it's been discovered that this convention i= s >> under attack by some ISPs: >> https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks > This "attack" has been discussed at length on various lists. Indeed > opportunistic STARTTLS is easily defeated by active attacks. It > addresses ONLY passive monitoring. This is why I've invested a > year and a half of my life into building DANE TLS for SMTP. > > However, not all is lost even without DANE: > > * Active attacks on everyone all the time are bound to be noticed. > Attackers engaged in large scale passive monitoring might no > longer be able to just collect everything, they'll have to be more > selective. > > * In particular, substantial deviations from the norm are > noticeable! Look, for example the 90-day (default display is > 30 days, click on 90 for a longer-term view) outbound stats > from gmail. What happened around Oct 15th? > > https://www.google.com/transparencyreport/saferemail/ > > Though Google are not saying what happened, and it may well > not have been a downgrade attack, this sort of thing does not > escape attention. First, my observation is that looking at quantity of messages only tells one part of the story when it comes to encryption. Rather the percentage of sites is probably more important. To put it another way: if Netflix turned on IPv6, perhaps the majority of traffic in America would shift to IPv6, but that wouldn't mean that the majority of hosts or connections were. In short, the method in the draft is somewhat overstating the case. > > * Some applications will employ various pinning strategies, and > some sessions will be authenticated, and it is not always > possible for the attacker to know which is which. > >> It's pretty clear that this downgrade attack is inexpensive to do, and= it >> does exactly what a passive attacker would want: it defeats OE. If O= E >> is that easily subverted, what good is it? I don't see the current >> document touching on this issue: instead, it simply accepts that this = is >> true, but ignores it as an issue, asserting that MITM attacks are >> expensive, so OE helps. I think the facts on the ground show that th= is >> is not so. > Specific techniques for detection and mitigation of active attacks > in the absence of authentication are I think out of scope for this > document. Individual application protocols may define additional > measures to make systematic downgrades less likely and once we have > more experience in this space future revisions may be able to make > generally applicable observations and recommendations. > > The document encourages opportunistic protection against active > attacks too, and does not call itself OE in good part for that > reason. If it were only OE, I would not have objected to Steve > Kent's draft as much, and we'd likely be polishing that (a lot > less work for me). > My suggestion is simply that at some point in the draft, perhaps in Section 4, you use as an example a reference to current STARTTLS downgrade attack to reinforce the point that OS does not thwart active attacks. You could even mention, if you so chose, that a sneaky active attacker might intercept SMTP transactions, and then encrypt them upstream without authentication. In fact, anyone doing this could masquerade as the original endpoint because they are in path. This reinforces a point, that we really do need to get DANE out the door, even if you don't actually say that. Eliot --O9MMsdu9GUF66OrPef2PNv18M1BC31Sg9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUdDA4AAoJEIe2a0bZ0nozs2UIAIkSJiwZfkjdceu+UDLQguFw DYc12pDVOi9kxOx4GJbr8nL4mkIWYXp1byy4dxi+anZxz5pXbHd5AEr2ND3s/lZj lNgnrwZGY/h3AW1Lc/LgeVUcCCBf5MlSVjVH+6N0RtqMDxSriE3YJayRoO6FSDpW Yqw2u+2IwwWbGZLyZJKogEdL9cPEnJww/6Ina5ZY876cIvA9txNDH1gAoIVM+IiU YECRRlGAE1qRUcx3JRdfmDdUZGUPr0OttSuuNofty/Lx/yHkirFTmCIJ23KVgIge HhJpTjvmQAzuvKyVHLhEb9HBcvYeXIqu4jPLWy5MSUPMJf2kwJqOSvaHJkMztB4= =YTZt -----END PGP SIGNATURE----- --O9MMsdu9GUF66OrPef2PNv18M1BC31Sg9-- From nobody Tue Nov 25 01:43:03 2014 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 2EF121A0099; Tue, 25 Nov 2014 01:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rV4L9nF8Qply; Tue, 25 Nov 2014 01:42:54 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 60C6C1A0081; Tue, 25 Nov 2014 01:42:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 19CFABEC0; Tue, 25 Nov 2014 09:42: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 9R7RbPdqn-Jd; Tue, 25 Nov 2014 09:42:52 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.46.28.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DEDE0BE73; Tue, 25 Nov 2014 09:42:51 +0000 (GMT) Message-ID: <54744F1B.8050401@cs.tcd.ie> Date: Tue, 25 Nov 2014 09:42:51 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Ted Lemon References: <20141125044133.22746.78939.idtracker@ietfa.amsl.com> <54740B66.7010505@qti.qualcomm.com> <1F510558-3C0E-4F30-AC99-15AF2FD50C0C@nominum.com> <547416B5.7030905@qti.qualcomm.com> In-Reply-To: <547416B5.7030905@qti.qualcomm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/YuIV7JXIYq6Wd9PwbnR9lKf3juk Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS) 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, 25 Nov 2014 09:42:57 -0000 Hi Ted, On 25/11/14 05:42, Pete Resnick wrote: > > I think you're going to have to point me toward where in the doc you > might want text and what you think it might say to convince me that > something's missing. I think Pete's right there - suggested text here is going to be much easier to deal with than trying to do this in the abstract. As others have noted, messing about with STARTTLS gets noticed. That is already a huge improvement over cleartext so that benefit of OS even in the face of this attack is, I think, crystal clear and the concern in your discuss is just unfounded. I also think your extrapolation from that one issue with STARTTLS and SMTP to questioning OS entirely ("what good is it") ignores quite a lot and doesn't logically follow at all. Even if OS had a problem with SMTP/STARTLTS, that cannot by itself imply OS is just no "good." But if you'd like to suggest text, perhaps there is something we've missed that's needed. Or if you cannot, I think maybe the right thing to do is to just clear, but we can talk about it on the call later. Thanks, S. PS: When suggesting text, if necessary please try use OS and not OE :-) From nobody Tue Nov 25 02:43:57 2014 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 2AD981A00BD; Tue, 25 Nov 2014 02:43:56 -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] 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 qY2cS5unfyDu; Tue, 25 Nov 2014 02:43:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CC51A00B6; Tue, 25 Nov 2014 02:43:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141125104354.20090.85063.idtracker@ietfa.amsl.com> Date: Tue, 25 Nov 2014 02:43:54 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/UvjB5bcB1I7X7tYYmFAqDAifddM Cc: rbonica@juniper.net, saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 10:43:56 -0000 Benoit Claise has entered the following ballot position for draft-dukhovni-opportunistic-security-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection to the publication of the document, but please engage in the discussion, and clarify the text. I don't understand what a "OS protocol" is, for example in section 5 "operational considerations"? Is this a protocol that follows the OS definition, so that use a cleartext as the baseline communication security policy, with encryption and authentication negotiated and applied to the communication when available? Or is this one protocol that follows the principles in section 3? The following point is key to me No misrepresentation of security: Unauthenticated, encrypted communication must not be misrepresented to users or in application logs of non-interactive applications as equivalent to authenticated, encrypted communication. I would go as far as telling that the communication characteristics (encrypted with authentication versus encrypted without authentication) must be clearly labeled to the end user, and not only in a log. Who reads log files, anyway? That reminds me of the questions asked during one of the plenaries: are you in favor opportunistic encryption? I bet that many people thought: well encryption is good, opportunistic has got a positive touch. So sure, I'm in favor. If my mother would see "opportunistic encryption" when communicating with his bank application, I'm sure she would think: yep, everything is good! From nobody Tue Nov 25 02:53:12 2014 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 3D9F11A00B9; Tue, 25 Nov 2014 02:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmNfiUVYCf5C; Tue, 25 Nov 2014 02:53:04 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 748311A00C0; Tue, 25 Nov 2014 02:53:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 38BF1BEB3; Tue, 25 Nov 2014 10:53: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 DPn446rJvZpZ; Tue, 25 Nov 2014 10:53:01 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.46.28.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 128D8BE73; Tue, 25 Nov 2014 10:53:01 +0000 (GMT) Message-ID: <54745F8C.2020100@cs.tcd.ie> Date: Tue, 25 Nov 2014 10:53:00 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Benoit Claise , The IESG References: <20141125104354.20090.85063.idtracker@ietfa.amsl.com> In-Reply-To: <20141125104354.20090.85063.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_FQ54Ot45Gy3zo1ZMrNFWMxk2no Cc: rbonica@juniper.net, saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT) 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, 25 Nov 2014 10:53:07 -0000 Hi Benoit, On 25/11/14 10:43, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-dukhovni-opportunistic-security-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > No objection to the publication of the document, but please engage in the > discussion, and clarify the text. > > I don't understand what a "OS protocol" is, for example in section 5 > "operational considerations"? > Is this a protocol that follows the OS definition, so that use a > cleartext as the baseline communication security policy, with encryption > and authentication negotiated and applied to the communication when > available? > Or is this one protocol that follows the principles in section 3? I'll let Viktor respond to that one. > > The following point is key to me > > No misrepresentation of security: Unauthenticated, encrypted > communication must not be misrepresented to users or in > application logs of non-interactive applications as equivalent to > authenticated, encrypted communication. > > I would go as far as telling that the communication characteristics > (encrypted with authentication versus encrypted without authentication) > must be clearly labeled to the end user, and not only in a log. We had and have pretty strong consensus I'd say within the security community that the lock icon and security warnings in browsers have were bad ideas. And people have done a bunch of studies on that. (Can go find references or explain further if you're interested). That is not to say that the lock icon (for authenticated https web sites) will go away right now, and whether or not it goes away ever would have nothing to do with this draft, but measurements show that such icons and warnings are not understood and counterproductive. So the current text is really the right thing to say and ought not change. > Who reads > log files, anyway? Many applications have no UI, e.g. mail servers. So the best the runtime can do is log stuff. > That reminds me of the questions asked during one of the plenaries: are > you in favor opportunistic encryption? > I bet that many people thought: well encryption is good, opportunistic > has got a positive touch. So sure, I'm in favor. > If my mother would see "opportunistic encryption" when communicating with > his bank application, I'm sure she would think: yep, everything is good! Our fervent hope is that neither she nor anyone else ever sees that. Cheers, S. > > From nobody Tue Nov 25 03:13:58 2014 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 9E6031A00CA; Tue, 25 Nov 2014 03:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 HRKL7DxXzoLi; Tue, 25 Nov 2014 03:13:41 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A5A1A00B9; Tue, 25 Nov 2014 03:13:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3380; q=dns/txt; s=iport; t=1416914021; x=1418123621; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=p3JMiiki5a0N3HkD46mrQrDZ7sDkguGCHIsPhOYNrHE=; b=l0O0DpIJfkRowhJJdgM/2cbrvZl6VKjnJ+AQPItgDrgjsyXshj0UnpXM sXyudf4qd5vraIF/+pfOq5bYn0AoirEQaXs2T3+gRDeN82Z5qeZGehptS kGIEGO2G17V69eKB5XeVGZq4BpJ+QmpPszPocr1R/JqFLbY0lfqHVeY8o A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8EAFdjdFStJssW/2dsb2JhbABFFoNYV4MFvASKG4ZQAoEqAQEBAQF9hAMBAQQjFUABEAsYAgIFCgwLAgIJAwIBAgFFBgEMAQcBAQULiCwNugOWbQEBAQEBAQEBAQEBAQEBAQEBAQEBAReBLY5jCBACAU8HgniBVQEEhk2Qe4cygTQ/gxmCfY8PgjeBRkYwAYJJAQEB X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="249360992" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 25 Nov 2014 11:13:38 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sAPBDcc6019869; Tue, 25 Nov 2014 11:13:38 GMT Message-ID: <5474645F.3030209@cisco.com> Date: Tue, 25 Nov 2014 12:13:35 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20141125104354.20090.85063.idtracker@ietfa.amsl.com> <54745F8C.2020100@cs.tcd.ie> In-Reply-To: <54745F8C.2020100@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ZxFPhwka0yXB6z4pIKJTnozj1x4 Cc: rbonica@juniper.net, saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT) 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, 25 Nov 2014 11:13:44 -0000 Hi Stephen, > Hi Benoit, > > On 25/11/14 10:43, Benoit Claise wrote: >> Benoit Claise has entered the following ballot position for >> draft-dukhovni-opportunistic-security-05: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> No objection to the publication of the document, but please engage in the >> discussion, and clarify the text. >> >> I don't understand what a "OS protocol" is, for example in section 5 >> "operational considerations"? >> Is this a protocol that follows the OS definition, so that use a >> cleartext as the baseline communication security policy, with encryption >> and authentication negotiated and applied to the communication when >> available? >> Or is this one protocol that follows the principles in section 3? > I'll let Viktor respond to that one. > >> The following point is key to me >> >> No misrepresentation of security: Unauthenticated, encrypted >> communication must not be misrepresented to users or in >> application logs of non-interactive applications as equivalent to >> authenticated, encrypted communication. >> >> I would go as far as telling that the communication characteristics >> (encrypted with authentication versus encrypted without authentication) >> must be clearly labeled to the end user, and not only in a log. > We had and have pretty strong consensus I'd say within the > security community that the lock icon and security warnings > in browsers have were bad ideas. And people have done a > bunch of studies on that. (Can go find references or explain > further if you're interested). > > That is not to say that the lock icon (for authenticated > https web sites) will go away right now, and whether or not > it goes away ever would have nothing to do with this draft, > but measurements show that such icons and warnings are not > understood and counterproductive. > > So the current text is really the right thing to say and > ought not change. > >> Who reads >> log files, anyway? > Many applications have no UI, e.g. mail servers. So the > best the runtime can do is log stuff. > >> That reminds me of the questions asked during one of the plenaries: are >> you in favor opportunistic encryption? >> I bet that many people thought: well encryption is good, opportunistic >> has got a positive touch. So sure, I'm in favor. >> If my mother would see "opportunistic encryption" when communicating with >> his bank application, I'm sure she would think: yep, everything is good! > Our fervent hope is that neither she nor anyone else > ever sees that. So what should I answer to her when she asks me: is this communication safe? Regards, Benoit > > Cheers, > S. > > >> > . > From nobody Tue Nov 25 03:17:27 2014 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 5C39C1A00D8; Tue, 25 Nov 2014 03:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rI2ppeJMd5wm; Tue, 25 Nov 2014 03:17:24 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id F16671A00D7; Tue, 25 Nov 2014 03:17:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 52BB4BDCB; Tue, 25 Nov 2014 11:17:23 +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 jVMYYot-FTPn; Tue, 25 Nov 2014 11:17:22 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.46.28.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 33437BE04; Tue, 25 Nov 2014 11:17:22 +0000 (GMT) Message-ID: <54746541.2040404@cs.tcd.ie> Date: Tue, 25 Nov 2014 11:17:21 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Benoit Claise , The IESG References: <20141125104354.20090.85063.idtracker@ietfa.amsl.com> <54745F8C.2020100@cs.tcd.ie> <5474645F.3030209@cisco.com> In-Reply-To: <5474645F.3030209@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/IMLVZbDSQD7FJP5Txo3ZOGVTO0E Cc: rbonica@juniper.net, saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT) 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, 25 Nov 2014 11:17:25 -0000 On 25/11/14 11:13, Benoit Claise wrote: > So what should I answer to her when she asks me: is this communication > safe? Well you can tell her to call me, but you won't and shouldn't be telling her anything that relates to this draft:-) (Or at least, that last is something for which I believe we have strong consensus.) S. From nobody Tue Nov 25 03:35:04 2014 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 57C161A00E8; Tue, 25 Nov 2014 03:34:57 -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] 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 8ZTrYkAROppL; Tue, 25 Nov 2014 03:34:55 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id AA4131A00B9; Tue, 25 Nov 2014 03:34:55 -0800 (PST) Received: from [10.70.10.64] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id C55E6F984; Tue, 25 Nov 2014 06:34:51 -0500 (EST) Message-ID: <54746951.1020008@fifthhorseman.net> Date: Tue, 25 Nov 2014 06:34:41 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Icedove/33.0 MIME-Version: 1.0 To: Benoit Claise , Stephen Farrell , The IESG References: <20141125104354.20090.85063.idtracker@ietfa.amsl.com> <54745F8C.2020100@cs.tcd.ie> <5474645F.3030209@cisco.com> In-Reply-To: <5474645F.3030209@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SojUJfkILrpGiWgbi4jl1wJGAM2oqqcTU" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/OUu58DR2aSEnaCLkYNOYvZOJwQs Cc: rbonica@juniper.net, saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT) 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, 25 Nov 2014 11:34:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SojUJfkILrpGiWgbi4jl1wJGAM2oqqcTU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/25/2014 06:13 AM, Benoit Claise wrote: >> On 25/11/14 10:43, Benoit Claise wrote: >>> If my mother would see "opportunistic encryption" when communicating >>> with his bank application, I'm sure she would think: yep, everything = is good! >> Our fervent hope is that neither she nor anyone else >> ever sees that. > So what should I answer to her when she asks me: is this communication > safe? If you want to give an answer to a specific question like this, you could say something like: "you have no guarantee that any particular OS communication is safe, OS provides some network-level resistance against bulk surveillance, but is not intended to defend against a targeted attacks." Regards, --dkg PS Can we stop using "mother" as a proxy for "technically unsophisticated user" please? There are lots of technically sophisticated mothers, and lots of technically unsophisticated non-mothers. Let's use less traditionally-exclusive rhetoric. --SojUJfkILrpGiWgbi4jl1wJGAM2oqqcTU 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 iQJ8BAEBCgBmBQJUdGlRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpcOVgP/AljRYW2PsjqtCAKnUqaJ0ea uXgR2IG1xxWijA41FzW8OyiPl6wZ3hRuc7xTkgS6kp0gpqpN4YSq4aowiAseUtgO ly4EKWEsNX1xWQoGWqsq6R0v5ljRN1IQsi++BT/QogCFwGhC604/PF9we3QIT20G c44SKhbDFfChrrToAZCrFcR06xC3ptKrir1TnBk1qElF0AFW/HtcgtyDfc+IWeF9 5Tl0GuDReeQLXrxCeMrc4YxP6015E1zqauqqphHr7pbm61X4AZENrjTyu791zcHy jZyfdh8lna0QGx+3WBnZ/3EKENjQlQEFifYUXAFIV9SekxGGlIT7LEyJqmHQBPfT NkRiek9o1U7wUiFhZ5DO3ZyTazZOA8Uh1S9JS42CByjEXRrIjBFOpHZYnyrHZZ/S 06cbbgriFVmnzH1stfneQ/pqr1i4VBQNvQ4F2AzBI0a8Js8VNX9ZNqFapAFmMkfW ZBykcyLaRIvoMBofhmR5xcR7wXmAai7M01hKEYn5CxgFMvYfcElZh2z9NlyGJbml xkj8bR9jNeY8ZpyobWenyF/xUSvm6Pd+tDnpiDWKpGxVbLag5hhBaxQv+QNzbUo7 AnRbb+TRprXMbM4rYlVQ2syC02BZALxq6TXxXEVO24Bbs4LIzaoRf4wOie998BqC UhHadIXLM/zsgckmcJs2 =k0dy -----END PGP SIGNATURE----- --SojUJfkILrpGiWgbi4jl1wJGAM2oqqcTU-- From nobody Tue Nov 25 05:36:38 2014 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 BD3A41A1A10; Tue, 25 Nov 2014 05:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gfm8n4k8xVvB; Tue, 25 Nov 2014 05:36:31 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 B929E1A1A0B; Tue, 25 Nov 2014 05:36:31 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id C4AFCDA02ED; Tue, 25 Nov 2014 13:36:23 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 4AA1753E07A; Tue, 25 Nov 2014 05:36:01 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 25 Nov 2014 05:36:01 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <20141125055929.GW20723@mournblade.imrryr.org> Date: Tue, 25 Nov 2014 08:35:56 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <7177AD3F-A597-4705-B74E-DA125CF661FD@nominum.com> References: <20141125044133.22746.78939.idtracker@ietfa.amsl.com> <20141125055929.GW20723@mournblade.imrryr.org> To: , Viktor Dukhovni X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/yeoe4HgAPA71lZsoVdHHfChuwDI Cc: The IESG Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS) 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, 25 Nov 2014 13:36:32 -0000 So, what I was looking for is actually contained in this message: > * Active attacks on everyone all the time are bound to be noticed. > Attackers engaged in large scale passive monitoring might no > longer be able to just collect everything, they'll have to be more > selective. > Specific techniques for detection and mitigation of active attacks > in the absence of authentication are I think out of scope for this > document. Individual application protocols may define additional > measures to make systematic downgrades less likely and once we have > more experience in this space future revisions may be able to make > generally applicable observations and recommendations. The above two paragraphs, suitably tweaked and added to the security = considerations section, would completely address the DISCUSS. (And = thanks for the longer exposition on the topic!) From nobody Tue Nov 25 05:38:16 2014 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 988801A1A15; Tue, 25 Nov 2014 05:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wO5baE91tjT; Tue, 25 Nov 2014 05:38:11 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 B06681A1A19; Tue, 25 Nov 2014 05:38:10 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id C01A2DA02B9; Tue, 25 Nov 2014 13:38:02 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 7C58253E078; Tue, 25 Nov 2014 05:37:40 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 25 Nov 2014 05:37:39 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <54744F1B.8050401@cs.tcd.ie> Date: Tue, 25 Nov 2014 08:37:34 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <0433EF63-2BE4-4C25-8445-3296CC7B52B9@nominum.com> References: <20141125044133.22746.78939.idtracker@ietfa.amsl.com> <54740B66.7010505@qti.qualcomm.com> <1F510558-3C0E-4F30-AC99-15AF2FD50C0C@nominum.com> <547416B5.7030905@qti.qualcomm.com> <54744F1B.8050401@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/vELjHXuSv6SWBpqfgUq_wLSRHOw Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS) 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, 25 Nov 2014 13:38:12 -0000 On Nov 25, 2014, at 4:42 AM, Stephen Farrell = wrote: > PS: When suggesting text, if necessary please try use OS and > not OE :-) I'm still not over that. I just don't see what Operating Systems have = to do with opportunistic security. :) From nobody Tue Nov 25 05:53:20 2014 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 D3B2C1A00CA; Tue, 25 Nov 2014 05:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 fkZ35IxEa_1J; Tue, 25 Nov 2014 05:53:13 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7950D1A1A32; Tue, 25 Nov 2014 05:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3904; q=dns/txt; s=iport; t=1416923591; x=1418133191; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=PoEbooMi+t5FXshn2FRC4cqaGhliUGpigpIUMD04F0w=; b=Z06s7UBVB9f/aR0QffCS96kJuGDEX+WbAwkSVKg3kv8xNIfECYMFGvcN mVJqq1XK/fa3O/i5ZRk+VwxL/o8XgEcfFDPU639Pa7fANP1zehMUZo5uj 6F7pKYdqG64e//u2nESCM9xxKIkJGPkUPi0p5mO4qKcJJLkkfRvQlUaw5 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoEABKJdFStJssW/2dsb2JhbABFFoc0yV2DEQKBJAEBAQEBfYQDAQEEI1UBEAsEFAkKDAQHAgIJAwIBAgFFBgEMAQcBAYg8uhuWZwEBAQEBAQEBAQEBAQEBAQEBAQEBAReQEWoHgniBVQEEnnyBNYNZgn6PEII3gUZGgnoBAQE X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208,217";a="244777097" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 25 Nov 2014 13:53:09 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sAPDr9en018516; Tue, 25 Nov 2014 13:53:09 GMT Message-ID: <547489C4.4060409@cisco.com> Date: Tue, 25 Nov 2014 14:53:08 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , Stephen Farrell , The IESG References: <20141125104354.20090.85063.idtracker@ietfa.amsl.com> <54745F8C.2020100@cs.tcd.ie> <5474645F.3030209@cisco.com> <54746951.1020008@fifthhorseman.net> In-Reply-To: <54746951.1020008@fifthhorseman.net> Content-Type: multipart/alternative; boundary="------------030506070602050703060109" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/n7-BlfbLQnESrg2UO22r3_eCCmo Cc: rbonica@juniper.net, saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT) 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, 25 Nov 2014 13:53:15 -0000 This is a multi-part message in MIME format. --------------030506070602050703060109 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 25/11/2014 12:34, Daniel Kahn Gillmor wrote: > On 11/25/2014 06:13 AM, Benoit Claise wrote: >>> On 25/11/14 10:43, Benoit Claise wrote: >>>> If my mother would see "opportunistic encryption" when communicating >>>> with his bank application, I'm sure she would think: yep, everything is good! >>> Our fervent hope is that neither she nor anyone else >>> ever sees that. >> So what should I answer to her when she asks me: is this communication >> safe? > If you want to give an answer to a specific question like this, you > could say something like: "you have no guarantee that any particular OS > communication is safe, OS provides some network-level resistance against > bulk surveillance, but is not intended to defend against a targeted > attacks." That's the entire point. You spoke about OS not being safe, but don't tell the end user whether his application uses encryption with authentication without authentication (except in a log). Anyway ... > > Regards, > > --dkg > > PS Can we stop using "mother" as a proxy for "technically > unsophisticated user" please? Note that I spoke about "_my _mother". Btw, I could have written: So what would you answer to me if I would ask: is this communication safe? Anyway, it's besides the point. Regards, Benoit --------------030506070602050703060109 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 25/11/2014 12:34, Daniel Kahn Gillmor wrote:
On 11/25/2014 06:13 AM, Benoit Claise wrote:

On 25/11/14 10:43, Benoit Claise wrote:


      

        

          

            
If my mother would see "opportunistic encryption" when communicating
with his bank application, I'm sure she would think: yep, everything is good!


          

          
Our fervent hope is that neither she nor anyone else
ever sees that.


        

        
So what should I answer to her when she asks me: is this communication
safe?


      

      
If you want to give an answer to a specific question like this, you
could say something like: "you have no guarantee that any particular OS
communication is safe, OS provides some network-level resistance against
bulk surveillance, but is not intended to defend against a targeted
attacks."

    

    That's the entire point. You spoke about OS not being safe, but
    don't tell the end user whether his application uses encryption with
    authentication without authentication (except in a log).

    Anyway ...

    

      

Regards,

	--dkg

PS Can we stop using "mother" as a proxy for "technically
unsophisticated user" please?  

    

    Note that I spoke about "my mother".

    Btw, I could have written: So what would you answer to me if I would
    ask: is this communication
    safe?

    Anyway, it's besides the point.

    

    Regards, Benoit

  


--------------030506070602050703060109--


From nobody Tue Nov 25 06:05:12 2014
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 C8C381A1A56 for ; Tue, 25 Nov 2014 06:05:10 -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] 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 qsojb2iN6ZkE for ; Tue, 25 Nov 2014 06:05:09 -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 1CA4C1A1A3B for ; Tue, 25 Nov 2014 06:04:50 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 27EE128302F; Tue, 25 Nov 2014 14:04:49 +0000 (UTC)
Date: Tue, 25 Nov 2014 14:04:49 +0000
From: Viktor Dukhovni 
To: saag@ietf.org
Message-ID: <20141125140448.GX20723@mournblade.imrryr.org>
References: <20141125104354.20090.85063.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20141125104354.20090.85063.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/0AmquqaXunsnT42aLlh58ogyess
Subject: Re: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT)
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 25 Nov 2014 14:05:11 -0000

On Tue, Nov 25, 2014 at 02:43:54AM -0800, Benoit Claise wrote:

> I don't understand what a "OS protocol" is, for example in section 5
> "operational considerations"?

> Is this a protocol that follows the OS definition, so that use a
> cleartext as the baseline communication security policy, with encryption
> and authentication negotiated and applied to the communication when
> available?

Yes, this.

> Or is this one protocol that follows the principles in section 3?
> 
> The following point is key to me
> 
>  No misrepresentation of security:  Unauthenticated, encrypted
>       communication must not be misrepresented to users or in
>       application logs of non-interactive applications as equivalent to
>       authenticated, encrypted communication.

And not this.  Because it seems that protocols don't have user
interfaces, applications do.  So while applications that employ an
OS protocol are advised to follow the principles, the above principle
ventures into application territory and is not directly applicable
to the underlying protocol.

> I would go as far as telling that the communication characteristics
> (encrypted with authentication versus encrypted without authentication)
> must be clearly labeled to the end user, and not only in a log. Who reads
> log files, anyway?

What and when to communicate to users is I think a difficult and
out of scope question, but a statement to not misrepresent the
security achieved is reasonably safe, and was broadly requested.

The principle addresses a broadly shared concern that OS could be
used to mislead users into a false sense of security.  The principle
specifically disavows such misrepresentation.

-- 
	Viktor.


From nobody Tue Nov 25 06:07:27 2014
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 F211C1A1A4D; Tue, 25 Nov 2014 06:07:19 -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] 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 ARg7cm6b0jfB; Tue, 25 Nov 2014 06:07:16 -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 071AE1A1A32; Tue, 25 Nov 2014 06:07:16 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 279FD28302F; Tue, 25 Nov 2014 14:07:15 +0000 (UTC)
Date: Tue, 25 Nov 2014 14:07:15 +0000
From: Viktor Dukhovni 
To: saag@ietf.org
Message-ID: <20141125140714.GY20723@mournblade.imrryr.org>
References: <20141125104354.20090.85063.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20141125104354.20090.85063.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Zs4SGZ2QV_ubbAkvkmnPg1oFY9o
Cc: rbonica@juniper.net, The IESG 
Subject: Re: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT)
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, 25 Nov 2014 14:07:20 -0000

[ Sorry for the second post to saag, for Posts to subscribed lists,
  my MUA is set to auto-trim the Cc list and set Reply-To. ].

On Tue, Nov 25, 2014 at 02:43:54AM -0800, Benoit Claise wrote:

> I don't understand what a "OS protocol" is, for example in section 5
> "operational considerations"?

> Is this a protocol that follows the OS definition, so that use a
> cleartext as the baseline communication security policy, with encryption
> and authentication negotiated and applied to the communication when
> available?

Yes, this.

> Or is this one protocol that follows the principles in section 3?
> 
> The following point is key to me
> 
>  No misrepresentation of security:  Unauthenticated, encrypted
>       communication must not be misrepresented to users or in
>       application logs of non-interactive applications as equivalent to
>       authenticated, encrypted communication.

And not this.  Because it seems that protocols don't have user
interfaces, applications do.  So while applications that employ an
OS protocol are advised to follow the principles, the above principle
ventures into application territory and is not directly applicable
to the underlying protocol.

> I would go as far as telling that the communication characteristics
> (encrypted with authentication versus encrypted without authentication)
> must be clearly labeled to the end user, and not only in a log. Who reads
> log files, anyway?

What and when to communicate to users is I think a difficult and
out of scope question, but a statement to not misrepresent the
security achieved is reasonably safe, and was broadly requested.

The principle addresses a broadly shared concern that OS could be
used to mislead users into a false sense of security.  The principle
specifically disavows such misrepresentation.

-- 
	Viktor.


From nobody Tue Nov 25 06:09:03 2014
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 355CC1A1A42; Tue, 25 Nov 2014 06:08:56 -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 ROLbzRF7zL1D; Tue, 25 Nov 2014 06:08:54 -0800 (PST)
Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2CCA1A1A32; Tue, 25 Nov 2014 06:08:53 -0800 (PST)
Received: by mail-qg0-f42.google.com with SMTP id z107so450438qgd.1 for ; Tue, 25 Nov 2014 06:08:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gVRMISXRmLg8VFXej3DwHUEgJHyrHy7BnH/qcw0XqDA=; b=knWaohKznZPC9VbaV1EYecQt0rJMAyChfdOcDwvdJjPRZCcOse8+Yn702HIy/WQeWz 5QufC3e4BWSpbxqS6QMdQhyK6yWzQ3Lf3xKE+yalfPEyvIl9fw41E++9ji94pKlyCvOg MWXV3KVkOdVltCqAIzl8/++WXsPndBwb6LmMk+auzuSNz3ot4Mmn0ep5GsCwknGqEfUR l3H97e2dPZl/RwNYqxcSBgyrXm1S4ghldpDSkoMGzfJFCdlH1Z6D8shxGHEJy5Lv1uZ+ 5f3z8hJghNzrk4HMMnPSAlBDJaq0vB9Y5ie49XKyTIXXmRMWhsnVioyIqx7n7goHJmDa oBjg==
X-Received: by 10.140.18.240 with SMTP id 103mr13584133qgf.1.1416924533203; Tue, 25 Nov 2014 06:08:53 -0800 (PST)
Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id l11sm1131579qaj.23.2014.11.25.06.08.51 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Nov 2014 06:08:51 -0800 (PST)
From: Kathleen Moriarty 
X-Google-Original-From: Kathleen Moriarty 
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (11D257)
In-Reply-To: <7177AD3F-A597-4705-B74E-DA125CF661FD@nominum.com>
Date: Tue, 25 Nov 2014 09:08:51 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20141125044133.22746.78939.idtracker@ietfa.amsl.com> <20141125055929.GW20723@mournblade.imrryr.org> <7177AD3F-A597-4705-B74E-DA125CF661FD@nominum.com>
To: Ted Lemon 
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Eq8saMdD9ZOpWoNNNoYnBTICytM
Cc: The IESG , "" 
Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS)
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, 25 Nov 2014 14:08:56 -0000

Sorry to chime in late, but shouldn't this concern be covered already in the=
 TLS Attack draft (I believe it is) from UTA?  I think this is better to hav=
e in that document with the security considerations of this draft pointing t=
o that one.  Hopefully the reader will understand the attacks that apply to a=
uthenticated vs unauthenticated TLS.

Thanks,
Kathleen

Sent from my iPhone

> On Nov 25, 2014, at 8:35 AM, Ted Lemon  wrote:
>=20
> So, what I was looking for is actually contained in this message:
>=20
>> * Active attacks on everyone all the time are bound to be noticed.
>>   Attackers engaged in large scale passive monitoring might no
>>   longer be able to just collect everything, they'll have to be more
>>   selective.
>=20
>> Specific techniques for detection and mitigation of active attacks
>> in the absence of authentication are I think out of scope for this
>> document.  Individual application protocols may define additional
>> measures to make systematic downgrades less likely and once we have
>> more experience in this space future revisions may be able to make
>> generally applicable observations and recommendations.
>=20
> The above two paragraphs, suitably tweaked and added to the security consi=
derations section, would completely address the DISCUSS.  (And thanks for th=
e longer exposition on the topic!)
>=20


From nobody Tue Nov 25 06:17:38 2014
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 42B4A1A1A7A; Tue, 25 Nov 2014 06:17:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 j-kyLHAXYq04; Tue, 25 Nov 2014 06:17:27 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE8C1A1A48; Tue, 25 Nov 2014 06:17:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1981; q=dns/txt; s=iport; t=1416925047; x=1418134647; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=HCYZE5vN+GkOntaSQ2UkWDbd2fgY5gZ22udT25WPGF0=; b=VWK34OTz5arwukJZEQdIRKl53UfLZYct9hZ1oWjyO0v427v7fN6qEChj gBBxe9CgitFIKczotBPunnTo2ebwt6D98D0IbLersbE5UB5hYj397dLm9 /UEYoxo8L+cYkqm3HlCaNhgCFEzqRAajTTWOhdGZF/6iwbCtLQgBkNffe I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqYEAD+OdFStJssW/2dsb2JhbABb1CICgSQBAQEBAX2EAwEBBDhAARALDgoJFg8JAwIBAgFFBgEMAQcBAYg80QUBAQEBAQEBAQEBAQEBAQEBAQEBARiQeweETQEEnnyIDI8QgjeBRkaCegEBAQ
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="244736547"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 25 Nov 2014 14:17:25 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sAPEHPUM020254; Tue, 25 Nov 2014 14:17:25 GMT
Message-ID: <54748F75.7070301@cisco.com>
Date: Tue, 25 Nov 2014 15:17:25 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Viktor Dukhovni , saag@ietf.org
References: <20141125104354.20090.85063.idtracker@ietfa.amsl.com> <20141125140714.GY20723@mournblade.imrryr.org>
In-Reply-To: <20141125140714.GY20723@mournblade.imrryr.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HejRVuYmcbzuYCJaxQOVDPs3jxc
Cc: rbonica@juniper.net, The IESG 
Subject: Re: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT)
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, 25 Nov 2014 14:17:32 -0000

Hi Viktor,
> [ Sorry for the second post to saag, for Posts to subscribed lists,
>    my MUA is set to auto-trim the Cc list and set Reply-To. ].
>
> On Tue, Nov 25, 2014 at 02:43:54AM -0800, Benoit Claise wrote:
>
>> I don't understand what a "OS protocol" is, for example in section 5
>> "operational considerations"?
>> Is this a protocol that follows the OS definition, so that use a
>> cleartext as the baseline communication security policy, with encryption
>> and authentication negotiated and applied to the communication when
>> available?
> Yes, this.
Thanks.
An extra sentence would be helpful.

Regards, Benoit
>
>> Or is this one protocol that follows the principles in section 3?
>>
>> The following point is key to me
>>
>>   No misrepresentation of security:  Unauthenticated, encrypted
>>        communication must not be misrepresented to users or in
>>        application logs of non-interactive applications as equivalent to
>>        authenticated, encrypted communication.
> And not this.  Because it seems that protocols don't have user
> interfaces, applications do.  So while applications that employ an
> OS protocol are advised to follow the principles, the above principle
> ventures into application territory and is not directly applicable
> to the underlying protocol.
>
>> I would go as far as telling that the communication characteristics
>> (encrypted with authentication versus encrypted without authentication)
>> must be clearly labeled to the end user, and not only in a log. Who reads
>> log files, anyway?
> What and when to communicate to users is I think a difficult and
> out of scope question, but a statement to not misrepresent the
> security achieved is reasonably safe, and was broadly requested.
>
> The principle addresses a broadly shared concern that OS could be
> used to mislead users into a false sense of security.  The principle
> specifically disavows such misrepresentation.
>


From nobody Tue Nov 25 06:19:32 2014
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 39FDD1A1A58; Tue, 25 Nov 2014 06:19:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnjkysmfL-LH; Tue, 25 Nov 2014 06:19:25 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 14BF41A1A54; Tue, 25 Nov 2014 06:19:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0B88CBEDA; Tue, 25 Nov 2014 14:19:24 +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 v4ou8vlz3C8E; Tue, 25 Nov 2014 14:19:22 +0000 (GMT)
Received: from [10.87.48.5] (unknown [86.46.28.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C3B8ABEC3; Tue, 25 Nov 2014 14:19:22 +0000 (GMT)
Message-ID: <54748FEA.1050709@cs.tcd.ie>
Date: Tue, 25 Nov 2014 14:19:22 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ted Lemon , saag@ietf.org,  Viktor Dukhovni 
References: <20141125044133.22746.78939.idtracker@ietfa.amsl.com> <20141125055929.GW20723@mournblade.imrryr.org> <7177AD3F-A597-4705-B74E-DA125CF661FD@nominum.com>
In-Reply-To: <7177AD3F-A597-4705-B74E-DA125CF661FD@nominum.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Ol2CCJq66TQFMA1krB2yDcVFgXU
Cc: The IESG 
Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS)
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, 25 Nov 2014 14:19:27 -0000

Hiya,

On 25/11/14 13:35, Ted Lemon wrote:
> So, what I was looking for is actually contained in this message:
> 
>> * Active attacks on everyone all the time are bound to be noticed. 
>> Attackers engaged in large scale passive monitoring might no longer
>> be able to just collect everything, they'll have to be more 
>> selective.
> 
>> Specific techniques for detection and mitigation of active attacks 
>> in the absence of authentication are I think out of scope for this 
>> document.  Individual application protocols may define additional 
>> measures to make systematic downgrades less likely and once we
>> have more experience in this space future revisions may be able to
>> make generally applicable observations and recommendations.
> 
> The above two paragraphs, suitably tweaked and added to the security
> considerations section, would completely address the DISCUSS.  (And
> thanks for the longer exposition on the topic!)

Fair 'nuff - I've added a version to the RFC editor note.
We can chat about it on the call or feel free to suggest
changes.

Cheers,
S.

PS: I agree with Kathleen that the above points are maybe
redundant (perhaps mostly being in 7258) but I'm ok with
having 'em here too - it's no harm.


> 


From nobody Tue Nov 25 06:26:15 2014
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 CA60C1A1A76; Tue, 25 Nov 2014 06:26:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gjf7ktoEKKh; Tue, 25 Nov 2014 06:26:09 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D1C121A1A9C; Tue, 25 Nov 2014 06:25:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 41339BEDA; Tue, 25 Nov 2014 14:25:55 +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 D9uh-TIne5bH; Tue, 25 Nov 2014 14:25:49 +0000 (GMT)
Received: from [10.87.48.5] (unknown [86.46.28.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B7AC3BEC3; Tue, 25 Nov 2014 14:25:49 +0000 (GMT)
Message-ID: <5474916D.4040606@cs.tcd.ie>
Date: Tue, 25 Nov 2014 14:25:49 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Benoit Claise ,  Viktor Dukhovni , saag@ietf.org
References: <20141125104354.20090.85063.idtracker@ietfa.amsl.com> <20141125140714.GY20723@mournblade.imrryr.org> <54748F75.7070301@cisco.com>
In-Reply-To: <54748F75.7070301@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/GNHV1kxOflh3mS8YGXf0V55ypvQ
Cc: rbonica@juniper.net, The IESG 
Subject: Re: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT)
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, 25 Nov 2014 14:26:12 -0000

Benoit, Viktor,

On 25/11/14 14:17, Benoit Claise wrote:
> Hi Viktor,
>> [ Sorry for the second post to saag, for Posts to subscribed lists,
>>    my MUA is set to auto-trim the Cc list and set Reply-To. ].
>>
>> On Tue, Nov 25, 2014 at 02:43:54AM -0800, Benoit Claise wrote:
>>
>>> I don't understand what a "OS protocol" is, for example in section 5
>>> "operational considerations"?
>>> Is this a protocol that follows the OS definition, so that use a
>>> cleartext as the baseline communication security policy, with encryption
>>> and authentication negotiated and applied to the communication when
>>> available?
>> Yes, this.
> Thanks.
> An extra sentence would be helpful.

How about we add a term to section 2 such as:

"OS protocol: a protocol that follows the opportunistic approach
 to security described herein"

I think the term is used in >1 place.

Cheers,
S.


> 
> Regards, Benoit
>>
>>> Or is this one protocol that follows the principles in section 3?
>>>
>>> The following point is key to me
>>>
>>>   No misrepresentation of security:  Unauthenticated, encrypted
>>>        communication must not be misrepresented to users or in
>>>        application logs of non-interactive applications as equivalent to
>>>        authenticated, encrypted communication.
>> And not this.  Because it seems that protocols don't have user
>> interfaces, applications do.  So while applications that employ an
>> OS protocol are advised to follow the principles, the above principle
>> ventures into application territory and is not directly applicable
>> to the underlying protocol.
>>
>>> I would go as far as telling that the communication characteristics
>>> (encrypted with authentication versus encrypted without authentication)
>>> must be clearly labeled to the end user, and not only in a log. Who
>>> reads
>>> log files, anyway?
>> What and when to communicate to users is I think a difficult and
>> out of scope question, but a statement to not misrepresent the
>> security achieved is reasonably safe, and was broadly requested.
>>
>> The principle addresses a broadly shared concern that OS could be
>> used to mislead users into a false sense of security.  The principle
>> specifically disavows such misrepresentation.
>>
> 
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag


From nobody Tue Nov 25 06:43:18 2014
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 300BD1A1AEA; Tue, 25 Nov 2014 06:43:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQRmi2rze0Tp; Tue, 25 Nov 2014 06:43:11 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D94CA1A1AC1; Tue, 25 Nov 2014 06:43:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3F3B4BEDA; Tue, 25 Nov 2014 14:43:06 +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 f_ZUa0QUqK8L; Tue, 25 Nov 2014 14:43:01 +0000 (GMT)
Received: from [10.87.48.5] (unknown [86.46.28.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EC0CCBEDB; Tue, 25 Nov 2014 14:42:56 +0000 (GMT)
Message-ID: <54749570.7090400@cs.tcd.ie>
Date: Tue, 25 Nov 2014 14:42:56 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Benoit Claise ,  Viktor Dukhovni , saag@ietf.org
References: <20141125104354.20090.85063.idtracker@ietfa.amsl.com> <20141125140714.GY20723@mournblade.imrryr.org> <54748F75.7070301@cisco.com> <5474916D.4040606@cs.tcd.ie>
In-Reply-To: <5474916D.4040606@cs.tcd.ie>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/gesvZspgthWaBLw_N2sDXBjknP8
Cc: rbonica@juniper.net, The IESG 
Subject: Re: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT)
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, 25 Nov 2014 14:43:12 -0000

On 25/11/14 14:25, Stephen Farrell wrote:
> "OS protocol: a protocol that follows the opportunistic approach
>  to security described herein"

Being an optimist, I added that to the RFC editor note.

S.


From nobody Tue Nov 25 06:45:09 2014
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 820A91A1A9F; Tue, 25 Nov 2014 06:45:02 -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 oOTgRN4k155G; Tue, 25 Nov 2014 06:45:00 -0800 (PST)
Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C391A1A72; Tue, 25 Nov 2014 06:45:00 -0800 (PST)
Received: by mail-qc0-f171.google.com with SMTP id r5so505390qcx.16 for ; Tue, 25 Nov 2014 06:44:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5uYdVOniM8YWKGCRFJ3o02zW59YbydnsVGWHksCdMFs=; b=zJ41n0AeDgtiajlhXsqz18za1AembCwMgT4vmmZZkRAXHIIX1ITktJdjaEToR4mhjv DmYS3FEm3V/i8BTqO0SQNCVOHmcy4zdD0pDWBMWcoxQjzCYxvbkTxR3PCNAl+o/BAkrn Rt0G4seqWyz6HlusB694/oYmRKIzSz0bZp6uSX6oSprBawdkagZ6Z1uHCu1pkN61wXIk 0ikPmCLuIx3FwMhTpXEStyUFg71Fn/WXtbt5o1EI2Yo9hxXUBfD88+MpUKXvk6JPR6Hf a4VmBYkywhFW179bCCfnEpy5ZLvukWeLjBkvqDDaDIpa3z4wl8+qlB5VNhHrVYyk0x06 zTmA==
X-Received: by 10.224.79.212 with SMTP id q20mr23983382qak.4.1416926699480; Tue, 25 Nov 2014 06:44:59 -0800 (PST)
Received: from [10.94.19.43] (mobile-166-171-186-251.mycingular.net. [166.171.186.251]) by mx.google.com with ESMTPSA id j11sm1194935qaa.47.2014.11.25.06.44.58 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Nov 2014 06:44:58 -0800 (PST)
From: Kathleen Moriarty 
X-Google-Original-From: Kathleen Moriarty 
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (11D257)
In-Reply-To: <5474916D.4040606@cs.tcd.ie>
Date: Tue, 25 Nov 2014 09:44:57 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <105D9D4D-F187-4305-8CD4-7637AA9F3FFD@gmail.com>
References: <20141125104354.20090.85063.idtracker@ietfa.amsl.com> <20141125140714.GY20723@mournblade.imrryr.org> <54748F75.7070301@cisco.com> <5474916D.4040606@cs.tcd.ie>
To: Stephen Farrell 
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/LWBO04BeSQ6gh4eS0yk7fjpbOBM
Cc: Benoit Claise , "rbonica@juniper.net" , The IESG , "saag@ietf.org" 
Subject: Re: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT)
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, 25 Nov 2014 14:45:02 -0000

I know this is settled, but would like to go back to one of Benoit's questio=
ns that doesn't require an update in the draft.  Top posting because it's fu=
rther back in the thread.

The consensus for displaying icons and HTTPS was that it would only be used f=
or encrypted and authenticated sessions, not for OS or plaintext.  It wasn't=
 that they would go away.  I was part of the small group that discussed this=
 at the STRINT workshop.

To further this response, in implementations, OS is an upgrade from HTTP and=
 not a fallback from HTTPS.  As such, the incremental security would be to t=
he HTTP session (when that's the encapsulated protocol), rather than a redir=
ect to HTTPS for a limited negotiation (no authentication unless that was av=
ailable - OS will try to negotiate both - I think incrementally when availab=
le).=20

I hope this is helpful.
Kathleen

Sent from my iPhone

> On Nov 25, 2014, at 9:25 AM, Stephen Farrell  w=
rote:
>=20
>=20
> Benoit, Viktor,
>=20
>> On 25/11/14 14:17, Benoit Claise wrote:
>> Hi Viktor,
>>> [ Sorry for the second post to saag, for Posts to subscribed lists,
>>>   my MUA is set to auto-trim the Cc list and set Reply-To. ].
>>>=20
>>>> On Tue, Nov 25, 2014 at 02:43:54AM -0800, Benoit Claise wrote:
>>>>=20
>>>> I don't understand what a "OS protocol" is, for example in section 5
>>>> "operational considerations"?
>>>> Is this a protocol that follows the OS definition, so that use a
>>>> cleartext as the baseline communication security policy, with encryptio=
n
>>>> and authentication negotiated and applied to the communication when
>>>> available?
>>> Yes, this.
>> Thanks.
>> An extra sentence would be helpful.
>=20
> How about we add a term to section 2 such as:
>=20
> "OS protocol: a protocol that follows the opportunistic approach
> to security described herein"
>=20
> I think the term is used in >1 place.
>=20
> Cheers,
> S.
>=20
>=20
>>=20
>> Regards, Benoit
>>>=20
>>>> Or is this one protocol that follows the principles in section 3?
>>>>=20
>>>> The following point is key to me
>>>>=20
>>>>  No misrepresentation of security:  Unauthenticated, encrypted
>>>>       communication must not be misrepresented to users or in
>>>>       application logs of non-interactive applications as equivalent to=

>>>>       authenticated, encrypted communication.
>>> And not this.  Because it seems that protocols don't have user
>>> interfaces, applications do.  So while applications that employ an
>>> OS protocol are advised to follow the principles, the above principle
>>> ventures into application territory and is not directly applicable
>>> to the underlying protocol.
>>>=20
>>>> I would go as far as telling that the communication characteristics
>>>> (encrypted with authentication versus encrypted without authentication)=

>>>> must be clearly labeled to the end user, and not only in a log. Who
>>>> reads
>>>> log files, anyway?
>>> What and when to communicate to users is I think a difficult and
>>> out of scope question, but a statement to not misrepresent the
>>> security achieved is reasonably safe, and was broadly requested.
>>>=20
>>> The principle addresses a broadly shared concern that OS could be
>>> used to mislead users into a false sense of security.  The principle
>>> specifically disavows such misrepresentation.
>>=20
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>=20


From nobody Tue Nov 25 07:13:29 2014
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 D683C1A8032; Tue, 25 Nov 2014 07:13:24 -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] 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 xcZTqK2m3480; Tue, 25 Nov 2014 07:13:18 -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 C1B501A8770; Tue, 25 Nov 2014 07:12:14 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CA8D128302F; Tue, 25 Nov 2014 15:12:13 +0000 (UTC)
Date: Tue, 25 Nov 2014 15:12:13 +0000
From: Viktor Dukhovni 
To: The IESG 
Message-ID: <20141125151213.GA20723@mournblade.imrryr.org>
References: <20141125104354.20090.85063.idtracker@ietfa.amsl.com> <20141125140714.GY20723@mournblade.imrryr.org> <54748F75.7070301@cisco.com> <5474916D.4040606@cs.tcd.ie> <105D9D4D-F187-4305-8CD4-7637AA9F3FFD@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <105D9D4D-F187-4305-8CD4-7637AA9F3FFD@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/u4-c_xfg4qAgNGEcoE24VOmX3fg
Cc: rbonica@juniper.net, saag@ietf.org
Subject: Re: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT)
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, 25 Nov 2014 15:13:25 -0000

On Tue, Nov 25, 2014 at 09:44:57AM -0500, Kathleen Moriarty wrote:

> (no authentication unless that was available - OS will try to
> negotiate both - I think incrementally when available).

There are a few ways to employ authentication to deal with active
attacks:

    1.  Tamper-resistance:  Make active attacks difficult
	to carry out.

    2.  Tamper-evidence:  Make instances of active attacks
	difficult to hide.

    3.  Integrity-evidence (to coin a phrase): When it happens,
	to be possible, record evidence of channel integrity.

The draft discusses opportunistic authentication with a view to
achieving the strongest of these, i.e. "1".

Without pinning or DANE, ... if one records authentication successes,
but proceeds despite authentication failure, one generally only
gets "3", Sometimes "3" can be upgraded to "2" after the fact if
information is later obtained that the peer ought to have presented
usable credentials.

So, specifically for opportunistic security with HTTP upgrading to
TLS when possible, absent DANE support or pinning, you only get
"3".  You need tamper-resistant signalling whether/how to authenticate
a peer to get "1".  As for "2" that gets us into a tricky space of
forensic counter-measures with which we don't yet have much
experience.

So I hope that everyone reading the draft understands that the
opportunistic authentication described is of the first kind, and
that merely recording authentication successes without a secure
signal of when to require success does not achieve MiTM protection,
it just records some instances when MiTM "was probably" avoided,
without specifically doing anything to avoid MiTM.

-- 
	Viktor.


From nobody Tue Nov 25 07:25:19 2014
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 D6FA61A1C06; Tue, 25 Nov 2014 07:25:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4Vs0wZBPjI2; Tue, 25 Nov 2014 07:25:15 -0800 (PST)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 9FD2D1A0222; Tue, 25 Nov 2014 07:25:02 -0800 (PST)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id C0318DA0214; Tue, 25 Nov 2014 15:24:54 +0000 (UTC)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id DE2C953E07A; Tue, 25 Nov 2014 07:24:31 -0800 (PST)
Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 25 Nov 2014 07:24:25 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Tue, 25 Nov 2014 10:24:18 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <9483BE3D-7336-4065-A535-6EDBC131CE9E@nominum.com>
References: <20141125044133.22746.78939.idtracker@ietfa.amsl.com> <20141125055929.GW20723@mournblade.imrryr.org> <7177AD3F-A597-4705-B74E-DA125CF661FD@nominum.com> 
To: Kathleen Moriarty 
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Q67LGNKbbbglH_aOnS8kETWYYDE
Cc: The IESG , "" 
Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS)
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, 25 Nov 2014 15:25:17 -0000

On Nov 25, 2014, at 9:08 AM, Kathleen Moriarty =
 wrote:
> Sorry to chime in late, but shouldn't this concern be covered already =
in the TLS Attack draft (I believe it is) from UTA?  I think this is =
better to have in that document with the security considerations of this =
draft pointing to that one.  Hopefully the reader will understand the =
attacks that apply to authenticated vs unauthenticated TLS.

The reason I want this mentioned in this draft is so that people don't =
read it and think "huh, they didn't address the STARTTLS hack, and they =
use STARTTLS as an example: do they have a clue?"   By explicitly =
discussing the attack and explaining why OS (!) is still worth doing, we =
eliminate the likelihood that someone might read the document that way.


From nobody Tue Nov 25 07:40:16 2014
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 4042C1A906D; Tue, 25 Nov 2014 07:40:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMR3tsvy_Xy9; Tue, 25 Nov 2014 07:39:58 -0800 (PST)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 E67C21A8776; Tue, 25 Nov 2014 07:39:56 -0800 (PST)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 89A32DA02EF; Tue, 25 Nov 2014 15:39:49 +0000 (UTC)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id A954253E078; Tue, 25 Nov 2014 07:39:26 -0800 (PST)
Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 25 Nov 2014 07:39:26 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <20141125151213.GA20723@mournblade.imrryr.org>
Date: Tue, 25 Nov 2014 10:39:18 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <58C0C68C-8FE1-47A4-BF53-3EF111819FD9@nominum.com>
References: <20141125104354.20090.85063.idtracker@ietfa.amsl.com> <20141125140714.GY20723@mournblade.imrryr.org> <54748F75.7070301@cisco.com> <5474916D.4040606@cs.tcd.ie> <105D9D4D-F187-4305-8CD4-7637AA9F3FFD@gmail.com> <20141125151213.GA20723@mournblade.imrryr.org>
To: Viktor Dukhovni 
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FpTcEpBgTriCHZ_EglIKVYVY_oM
Cc: rbonica@juniper.net, The IESG , saag@ietf.org
Subject: Re: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT)
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, 25 Nov 2014 15:40:00 -0000

On Nov 25, 2014, at 10:12 AM, Viktor Dukhovni  =
wrote:
> So I hope that everyone reading the draft understands that the
> opportunistic authentication described is of the first kind, and
> that merely recording authentication successes without a secure
> signal of when to require success does not achieve MiTM protection,
> it just records some instances when MiTM "was probably" avoided,
> without specifically doing anything to avoid MiTM.

The language in the draft is a bit abstruse.   To someone who is already =
familiar with the milieu, it's clear what's being said, but the hope you =
express above would only be fulfilled for those readers, not for readers =
who are interested but don't already have a good understanding of the =
milieu.   If you would like the hope you have expressed to be fulfilled =
for the latter class of readers, it might be worth taking the email =
message you just sent and figuring out a way to incorporate it into the =
document.


From nobody Tue Nov 25 07:56:56 2014
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 8D7E21A9115; Tue, 25 Nov 2014 07:56:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 9vH1nGv5Ajb8; Tue, 25 Nov 2014 07:56:45 -0800 (PST)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84FD81A8702; Tue, 25 Nov 2014 07:56:44 -0800 (PST)
Received: by mail-la0-f47.google.com with SMTP id hz20so786000lab.20 for ; Tue, 25 Nov 2014 07:56:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ZV0cpos4f+bFCR1w9w5TxvHaIjnSYvMlNMSa6SXznNs=; b=ZN385IiqzeQzOtee90OxGXhbHLjOJtPCczKj3Au7wfJOXPhDDJt2S7ZSMv+TzNW68C XPnT+iet7ljqqWm1mSFcFa4KUcWgGta7jqozJPZ2/GpDuoLLuaW6Tdcm9sNc1DaEiH0e RAb37zbOwAqOF3JQiypLJLTzsXcOXtIwiNFNAvu+x8Axdm4Yq2DQ6ZFF2oIYl6rH+Vir +5em7fBSjy4AhuOHXowaK97JhYSGPjH7Alw/borhVclA44LYZDMbIKxxuFuwsoWAnlMA pV5mt087gYbWgIUwSssSiSl9aFEbka2MMVDicOgcw4NR36HoLSXSnP33OBhX+sOZz0w7 K9Jw==
MIME-Version: 1.0
X-Received: by 10.152.170.131 with SMTP id am3mr27770002lac.15.1416931002940;  Tue, 25 Nov 2014 07:56:42 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.152.127.168 with HTTP; Tue, 25 Nov 2014 07:56:42 -0800 (PST)
In-Reply-To: <547489C4.4060409@cisco.com>
References: <20141125104354.20090.85063.idtracker@ietfa.amsl.com> <54745F8C.2020100@cs.tcd.ie> <5474645F.3030209@cisco.com> <54746951.1020008@fifthhorseman.net> <547489C4.4060409@cisco.com>
Date: Tue, 25 Nov 2014 10:56:42 -0500
X-Google-Sender-Auth: fMd67UJ7j50GnBqdYFoLErbKF7Y
Message-ID: 
From: Barry Leiba 
To: Benoit Claise 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/EOrnXetn5iMTGuAg25h4DmCs2UM
Cc: Ron Bonica , "saag@ietf.org" , draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG 
Subject: Re: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT)
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, 25 Nov 2014 15:56:46 -0000

> That's the entire point. You spoke about OS not being safe, but don't tel=
l
> the end user whether his application uses encryption with authentication
> without authentication (except in a log).

Trying to clarify for Beno=EEt:

- The overall point here is that we use the strongest mechanism we
can, but no less than the weakest we're willing to accept.  When we
want authenticated encryption, we demand that, and won't drop to
unauthenticated, because that won't do.  HTTPS is still HTTPS, but
with OS, some HTTP (non-S) might start using encryption as well.

- If we tell the user anything (see below), and we do that today with
the lock symbol, the green URL-bar icon, and whatnot, we *only* tell
the user about authenticated encryption.  Unauthenticated encryption
will and should be entirely a matter for the wire, not noticed by the
user.

- As Stephen says, studies are clear on this (I've been following them
for years): users misunderstand anything we tell them about security,
and they misunderstand it so badly that indications to users open wide
doors to misleading them into making bad choices[1] -- worse choices
than if we had never told them anything at all.  Unfortunately, that
horse has left the barn: we've been harping on the lock symbol and the
like for so long that even if we should stop using it, fake lock
symbols will continue to mislead users for many years.

I hope this helps.

Barry

[1] This makes Spencer, especially, very sad.


From nobody Tue Nov 25 08:07:39 2014
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 0DA461AC3A1; Tue, 25 Nov 2014 08:07:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 scjhUVwKw8PR; Tue, 25 Nov 2014 08:07:29 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09CF11ACCEB; Tue, 25 Nov 2014 08:05:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1607; q=dns/txt; s=iport; t=1416931513; x=1418141113; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=evO7Nbwl2/6oaGDIgPFhvZwCXXjxSx7rh6bmdKksIYA=; b=BCSld9nd1/CCAkhXDYMEN2tLwABUsTuPYpDh+huybTSCWAjkWSQQlwqu /P9AaaQ36jkfOQw7Ym5I5tHFD0Tx4MNBUA56FZg5oHxdPSxwrHRoXphU7 pcnPGDRaAvdjGBLM4ThSPlDHpG2v2fQBtdNGfsUNe79Rg3t7PoxSjJKFJ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqYEAMendFStJssW/2dsb2JhbABbg1jQSgKBJQEBAQEBfYQDAQEEMgEFQAEQCyEWBAsJAwIBAgFFBg0BBwEBiDzRSwEBAQEBAQEBAgEBAQEBAQEBGpB7B4RNAQSefIgMjxCCN4FGRoJ6AQEB
X-IronPort-AV: E=Sophos;i="5.07,456,1413244800"; d="scan'208";a="244897756"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 25 Nov 2014 16:05:10 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sAPG5ASL009065; Tue, 25 Nov 2014 16:05:10 GMT
Message-ID: <5474A8B6.9010109@cisco.com>
Date: Tue, 25 Nov 2014 17:05:10 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Barry Leiba 
References: <20141125104354.20090.85063.idtracker@ietfa.amsl.com>	<54745F8C.2020100@cs.tcd.ie>	<5474645F.3030209@cisco.com>	<54746951.1020008@fifthhorseman.net>	<547489C4.4060409@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/XuJ2HNHhAuw34X85LreLxRIWusQ
Cc: Ron Bonica , "saag@ietf.org" , draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG 
Subject: Re: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT)
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, 25 Nov 2014 16:07:32 -0000

Thanks for the clarification Barry.

Regard, Benoit
>> That's the entire point. You spoke about OS not being safe, but don't tell
>> the end user whether his application uses encryption with authentication
>> without authentication (except in a log).
> Trying to clarify for Benoît:
>
> - The overall point here is that we use the strongest mechanism we
> can, but no less than the weakest we're willing to accept.  When we
> want authenticated encryption, we demand that, and won't drop to
> unauthenticated, because that won't do.  HTTPS is still HTTPS, but
> with OS, some HTTP (non-S) might start using encryption as well.
>
> - If we tell the user anything (see below), and we do that today with
> the lock symbol, the green URL-bar icon, and whatnot, we *only* tell
> the user about authenticated encryption.  Unauthenticated encryption
> will and should be entirely a matter for the wire, not noticed by the
> user.
>
> - As Stephen says, studies are clear on this (I've been following them
> for years): users misunderstand anything we tell them about security,
> and they misunderstand it so badly that indications to users open wide
> doors to misleading them into making bad choices[1] -- worse choices
> than if we had never told them anything at all.  Unfortunately, that
> horse has left the barn: we've been harping on the lock symbol and the
> like for so long that even if we should stop using it, fake lock
> symbols will continue to mislead users for many years.
>
> I hope this helps.
>
> Barry
>
> [1] This makes Spencer, especially, very sad.
> .
>


From nobody Tue Nov 25 08:11:14 2014
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 7E6F41AC39D; Tue, 25 Nov 2014 08:11:12 -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] 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 1EqYq2NM2qmD; Tue, 25 Nov 2014 08:11:04 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A878F1ACCF5; Tue, 25 Nov 2014 08:09:23 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Joel Jaeggli" 
To: The IESG 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141125160923.14619.5614.idtracker@ietfa.amsl.com>
Date: Tue, 25 Nov 2014 08:09:23 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/H0VZOvPx9n3SNKOOB8tY8jrnBPY
Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org
Subject: [saag] Joel Jaeggli's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS)
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Nov 2014 16:11:12 -0000

Joel Jaeggli has entered the following ballot position for
draft-dukhovni-opportunistic-security-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

hanging on Ted's point a bit. I might clear if he does.

If the use of what are essentially transparent proxies makes downgrade
attacks, or effectively the removal of OE signaling entirely trivial then
certain people will do that routinetly in order to support all sorts of
ugly business models (the prexy is already there).

if you read about other cases that are effectively downgrades you can
sort of imagine how insidious it is to think you reducing the visible
surface area when in fact it's being stripped off again.

http://www.theregister.co.uk/2014/11/20/gotcha_google_caught_stripping_ssl_search_from_bt_wifi_users_searches/





From nobody Tue Nov 25 08:22:24 2014
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 5A8FD1ACD36; Tue, 25 Nov 2014 08:22:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAPKvv1N8Fqk; Tue, 25 Nov 2014 08:22:21 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 158361ACD2D; Tue, 25 Nov 2014 08:22:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2D3DEBE79; Tue, 25 Nov 2014 16:22:18 +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 7QCW0EIahI9l; Tue, 25 Nov 2014 16:22:12 +0000 (GMT)
Received: from [10.87.48.5] (unknown [86.46.28.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D0861BEC9; Tue, 25 Nov 2014 16:22:01 +0000 (GMT)
Message-ID: <5474ACA9.1060506@cs.tcd.ie>
Date: Tue, 25 Nov 2014 16:22:01 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Joel Jaeggli , The IESG 
References: <20141125160923.14619.5614.idtracker@ietfa.amsl.com>
In-Reply-To: <20141125160923.14619.5614.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_gfAknAmkAi4bdc_P0OyTypYous
Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org
Subject: Re: [saag] Joel Jaeggli's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS)
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, 25 Nov 2014 16:22:22 -0000

Joel,

On 25/11/14 16:09, Joel Jaeggli wrote:
> Joel Jaeggli has entered the following ballot position for
> draft-dukhovni-opportunistic-security-05: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> hanging on Ted's point a bit. I might clear if he does.
> 
> If the use of what are essentially transparent proxies makes downgrade
> attacks, or effectively the removal of OE signaling entirely trivial then
> certain people will do that routinetly in order to support all sorts of
> ugly business models (the prexy is already there).
> 
> if you read about other cases that are effectively downgrades you can
> sort of imagine how insidious it is to think you reducing the visible
> surface area when in fact it's being stripped off again.
> 
> http://www.theregister.co.uk/2014/11/20/gotcha_google_caught_stripping_ssl_search_from_bt_wifi_users_searches/

So a) I don't see what's different there compared to Ted's
discuss, b) Ted's discuss is (I think/hope) handled already
in an RFC editor note, and c) OS allows us to catch these
things (see "caught" in the URL above), wherewas with cleartext
we cannot.

So you need to explain to me what's discussable there since
I'm not getting it. (On the call is fine.)

S.


> 
> 
> 


From nobody Tue Nov 25 08:25:42 2014
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 E4B3C1ACD4C; Tue, 25 Nov 2014 08:25:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij565UM_QpGp; Tue, 25 Nov 2014 08:25:34 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 6E91F1ACD72; Tue, 25 Nov 2014 08:25:13 -0800 (PST)
Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id sAPGP3gN091583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Nov 2014 16:25:04 GMT (envelope-from joelja@bogus.com)
Message-ID: <5474AD58.1050202@bogus.com>
Date: Tue, 25 Nov 2014 08:24:56 -0800
From: joel jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0
MIME-Version: 1.0
To: Stephen Farrell , The IESG 
References: <20141125160923.14619.5614.idtracker@ietfa.amsl.com> <5474ACA9.1060506@cs.tcd.ie>
In-Reply-To: <5474ACA9.1060506@cs.tcd.ie>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DvlXI4W209bJGxoGaeKCteP2WEVLb8n8E"
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/cXGKpWw4yPXsO9VpW7rV5FQ3YYA
Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org
Subject: Re: [saag] Joel Jaeggli's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS)
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, 25 Nov 2014 16:25:38 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--DvlXI4W209bJGxoGaeKCteP2WEVLb8n8E
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/25/14 8:22 AM, Stephen Farrell wrote:
>=20
> Joel,
>=20
> On 25/11/14 16:09, Joel Jaeggli wrote:
>> Joel Jaeggli has entered the following ballot position for
>> draft-dukhovni-opportunistic-security-05: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut thi=
s
>> introductory paragraph, however.)
>>
>>
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.ht=
ml
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/=

>>
>>
>>
>> ----------------------------------------------------------------------=

>> DISCUSS:
>> ----------------------------------------------------------------------=

>>
>> hanging on Ted's point a bit. I might clear if he does.
>>
>> If the use of what are essentially transparent proxies makes downgrade=

>> attacks, or effectively the removal of OE signaling entirely trivial t=
hen
>> certain people will do that routinetly in order to support all sorts o=
f
>> ugly business models (the prexy is already there).
>>
>> if you read about other cases that are effectively downgrades you can
>> sort of imagine how insidious it is to think you reducing the visible
>> surface area when in fact it's being stripped off again.
>>
>> http://www.theregister.co.uk/2014/11/20/gotcha_google_caught_stripping=
_ssl_search_from_bt_wifi_users_searches/
>=20
> So a) I don't see what's different there compared to Ted's
> discuss, b) Ted's discuss is (I think/hope) handled already
> in an RFC editor note, and c) OS allows us to catch these
> things (see "caught" in the URL above), wherewas with cleartext
> we cannot.

I didn't want to see it cleared until I had evaluated the response to
his discuss.

So I agree there is not much to it.

> So you need to explain to me what's discussable there since
> I'm not getting it. (On the call is fine.)
>=20
> S.
>=20
>=20
>>
>>
>>
>=20



--DvlXI4W209bJGxoGaeKCteP2WEVLb8n8E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlR0rVkACgkQ8AA1q7Z/VrJDLACeNX0aL1Hqhle9HlCrPK7k2zEh
DwQAn3iX6/usEZU7N7W4trfOcfjORYNQ
=mG/b
-----END PGP SIGNATURE-----

--DvlXI4W209bJGxoGaeKCteP2WEVLb8n8E--


From nobody Tue Nov 25 08:27:22 2014
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 B20941ACD8E; Tue, 25 Nov 2014 08:27:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cp3AcZ9O6fcM; Tue, 25 Nov 2014 08:27:20 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C65FE1ACD8A; Tue, 25 Nov 2014 08:27:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3D20BBED5; Tue, 25 Nov 2014 16:27:19 +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 LpZe_K98oWWR; Tue, 25 Nov 2014 16:27:13 +0000 (GMT)
Received: from [10.87.48.5] (unknown [86.46.28.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9BDEEBEDE; Tue, 25 Nov 2014 16:26:57 +0000 (GMT)
Message-ID: <5474ADD1.9050108@cs.tcd.ie>
Date: Tue, 25 Nov 2014 16:26:57 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: joel jaeggli , The IESG 
References: <20141125160923.14619.5614.idtracker@ietfa.amsl.com> <5474ACA9.1060506@cs.tcd.ie> <5474AD58.1050202@bogus.com>
In-Reply-To: <5474AD58.1050202@bogus.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/uWo5j01036iKigEpqzqsZWE9b2k
Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org
Subject: Re: [saag] Joel Jaeggli's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS)
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, 25 Nov 2014 16:27:21 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 25/11/14 16:24, joel jaeggli wrote:
> On 11/25/14 8:22 AM, Stephen Farrell wrote:
>> 
>> Joel,
>> 
>> On 25/11/14 16:09, Joel Jaeggli wrote:
>>> Joel Jaeggli has entered the following ballot position for 
>>> draft-dukhovni-opportunistic-security-05: Discuss
>>> 
>>> When responding, please keep the subject line intact and reply
>>> to all email addresses included in the To and CC lines. (Feel
>>> free to cut this introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to
>>> http://www.ietf.org/iesg/statement/discuss-criteria.html for
>>> more information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found
>>> here: 
>>> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/
>>>
>>>
>>>
>>>
>>> 
- ----------------------------------------------------------------------
>>> DISCUSS: 
>>> ----------------------------------------------------------------------
>>>
>>>
>>> 
hanging on Ted's point a bit. I might clear if he does.
>>> 
>>> If the use of what are essentially transparent proxies makes
>>> downgrade attacks, or effectively the removal of OE signaling
>>> entirely trivial then certain people will do that routinetly in
>>> order to support all sorts of ugly business models (the prexy
>>> is already there).
>>> 
>>> if you read about other cases that are effectively downgrades
>>> you can sort of imagine how insidious it is to think you
>>> reducing the visible surface area when in fact it's being
>>> stripped off again.
>>> 
>>> http://www.theregister.co.uk/2014/11/20/gotcha_google_caught_stripping_ssl_search_from_bt_wifi_users_searches/
>>
>>
>>> 
So a) I don't see what's different there compared to Ted's
>> discuss, b) Ted's discuss is (I think/hope) handled already in an
>> RFC editor note, and c) OS allows us to catch these things (see
>> "caught" in the URL above), wherewas with cleartext we cannot.
> 
> I didn't want to see it cleared until I had evaluated the response
> to his discuss.
> 
> So I agree there is not much to it.

Ah gotcha, that's fine

Ta,
S.

> 
>> So you need to explain to me what's discussable there since I'm
>> not getting it. (On the call is fine.)
>> 
>> S.
>> 
>> 
>>> 
>>> 
>>> 
>> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUdK3RAAoJEC88hzaAX42iBfkH/RbxOo7PwtYfAculyYuI5Xx8
1SM8uJaZKN10alHGrowsUxZsOAAtB/yYxm6pobNr0v9KMsK4m8qSfCsnB7GcYPzX
1kWPrtYicQRsADtMQliAQimjLSAmt8C5d3lmIbbHVAlS0vQHsugxpSLVpmmsQ/LV
JGAWDnCTh2oxtIMpBuhm1D01Tpaukst//xX3aEpKnxJ4Zr9nQqAxZmpEBl0hJNB7
MuAXyqCKBcklVYybOewA0CJkA1AAPVQF7uG9mjy0HvacJrobHpZku/FFlGZIPCRd
/JxSlZZxXw5sovpbJh1iIDAFTN2zQvR1IHXjKf0MJGWnDRPkemxu3YSOtvuJ5Jo=
=X3m2
-----END PGP SIGNATURE-----


From nobody Tue Nov 25 08:33:55 2014
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 714B11ACDBF; Tue, 25 Nov 2014 08:33:54 -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] 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 eEWITFIgxQ7j; Tue, 25 Nov 2014 08:33:52 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E944F1ACDAB; Tue, 25 Nov 2014 08:33:52 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Ted Lemon" 
To: The IESG 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141125163352.29683.12293.idtracker@ietfa.amsl.com>
Date: Tue, 25 Nov 2014 08:33:52 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/daQgp7h1o7L7oeiG3cjQvAbm0ic
Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org
Subject: [saag] Ted Lemon's Yes on draft-dukhovni-opportunistic-security-05: (with COMMENT)
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Nov 2014 16:33:54 -0000

Ted Lemon has entered the following ballot position for
draft-dukhovni-opportunistic-security-05: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing my discuss.   I'm very happy to see this document
progress!



From nobody Tue Nov 25 08:39:30 2014
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 73D6C1ACDBA; Tue, 25 Nov 2014 08:39:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMEmMaeEBkVO; Tue, 25 Nov 2014 08:39:23 -0800 (PST)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 28DFB1ACDD6; Tue, 25 Nov 2014 08:39:23 -0800 (PST)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id E2156DA02F8; Tue, 25 Nov 2014 16:39:15 +0000 (UTC)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id B692E53E078; Tue, 25 Nov 2014 08:38:52 -0800 (PST)
Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 25 Nov 2014 08:38:52 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <20141125160923.14619.5614.idtracker@ietfa.amsl.com>
Date: Tue, 25 Nov 2014 11:38:44 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <81804E05-734A-4567-A64F-4688CF261BC0@nominum.com>
References: <20141125160923.14619.5614.idtracker@ietfa.amsl.com>
To: Joel Jaeggli 
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/0FosMqDXfa-6EQ2iPeUkTAcK2yE
Cc: The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org
Subject: Re: [saag] Joel Jaeggli's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS)
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, 25 Nov 2014 16:39:25 -0000

On Nov 25, 2014, at 11:09 AM, Joel Jaeggli  wrote:
> If the use of what are essentially transparent proxies makes downgrade
> attacks, or effectively the removal of OE signaling entirely trivial =
then
> certain people will do that routinetly in order to support all sorts =
of
> ugly business models (the prexy is already there).

This is now addressed in the RFC editor's note, and I am happy with the =
outcome.   YMMV, of course!   :)


From nobody Tue Nov 25 08:59:51 2014
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 CF8FE1ACE16; Tue, 25 Nov 2014 08:59:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYlG-b0l4h0o; Tue, 25 Nov 2014 08:59:43 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 27E051A6FB0; Tue, 25 Nov 2014 08:59:43 -0800 (PST)
Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id sAPGxeux091802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Nov 2014 16:59:40 GMT (envelope-from joelja@bogus.com)
Message-ID: <5474B577.3030200@bogus.com>
Date: Tue, 25 Nov 2014 08:59:35 -0800
From: joel jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0
MIME-Version: 1.0
To: Ted Lemon 
References: <20141125160923.14619.5614.idtracker@ietfa.amsl.com> <81804E05-734A-4567-A64F-4688CF261BC0@nominum.com>
In-Reply-To: <81804E05-734A-4567-A64F-4688CF261BC0@nominum.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tk5CFs4qwb6pVuLbeGW5jE4PdH3THeBg9"
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/pvoRM-8R4NU75ieEXTywK_BCT6E
Cc: saag@ietf.org, The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org
Subject: Re: [saag] Joel Jaeggli's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS)
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, 25 Nov 2014 16:59:45 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--tk5CFs4qwb6pVuLbeGW5jE4PdH3THeBg9
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 11/25/14 8:38 AM, Ted Lemon wrote:
> On Nov 25, 2014, at 11:09 AM, Joel Jaeggli  wrote:
>> If the use of what are essentially transparent proxies makes downgrade=

>> attacks, or effectively the removal of OE signaling entirely trivial t=
hen
>> certain people will do that routinetly in order to support all sorts o=
f
>> ugly business models (the proxy is already there).
>=20
> This is now addressed in the RFC editor's note, and I am happy with the=
 outcome.   YMMV, of course!   :)

yeah I'm not super happy with

   However, when such attacks are
   employed pervasively in order to facilitate e,g, surveillance,
   this is readily detectable; hence, even in such scenarios
   OS protocols provide a positive benefit.

e.g. if today 70% of my servers outgoing smtp connections use start-tls
and tomorrow 67% use them is that evidence of an attack?

there are many cases where these are in fact not readily detectable so
this statment provides more certainty then it should.

I'm ok with the uncertainty (it's inevitable I think) but  not with our
statement of it yet.


>=20



--tk5CFs4qwb6pVuLbeGW5jE4PdH3THeBg9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlR0tXcACgkQ8AA1q7Z/VrI1vQCdHZWXXqJtLyYaUJG08kVvlDxI
COQAnicu+w4t+ip5o6VcaZmjLX9Ic8tN
=WdQ2
-----END PGP SIGNATURE-----

--tk5CFs4qwb6pVuLbeGW5jE4PdH3THeBg9--


From nobody Tue Nov 25 09:02:20 2014
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 736C01ACE6B; Tue, 25 Nov 2014 09:02:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWXLf6lBoL7e; Tue, 25 Nov 2014 09:02:12 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A8DAC1A702B; Tue, 25 Nov 2014 09:02:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 928DFBDD6; Tue, 25 Nov 2014 17:02:01 +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 fngpETK2Ov2s; Tue, 25 Nov 2014 17:01:59 +0000 (GMT)
Received: from [10.87.48.5] (unknown [86.46.28.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C38F7BDCA; Tue, 25 Nov 2014 17:01:59 +0000 (GMT)
Message-ID: <5474B607.8040208@cs.tcd.ie>
Date: Tue, 25 Nov 2014 17:01:59 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: joel jaeggli , Ted Lemon 
References: <20141125160923.14619.5614.idtracker@ietfa.amsl.com> <81804E05-734A-4567-A64F-4688CF261BC0@nominum.com> <5474B577.3030200@bogus.com>
In-Reply-To: <5474B577.3030200@bogus.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/pDViZewQYCZW3WZelj3jIwdskO0
Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG 
Subject: Re: [saag] Joel Jaeggli's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS)
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, 25 Nov 2014 17:02:15 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 25/11/14 16:59, joel jaeggli wrote:
> On 11/25/14 8:38 AM, Ted Lemon wrote:
>> On Nov 25, 2014, at 11:09 AM, Joel Jaeggli 
>> wrote:
>>> If the use of what are essentially transparent proxies makes
>>> downgrade attacks, or effectively the removal of OE signaling
>>> entirely trivial then certain people will do that routinetly in
>>> order to support all sorts of ugly business models (the proxy
>>> is already there).
>> 
>> This is now addressed in the RFC editor's note, and I am happy
>> with the outcome.   YMMV, of course!   :)
> 
> yeah I'm not super happy with
> 
> However, when such attacks are employed pervasively in order to
> facilitate e,g, surveillance, this is readily detectable; hence,
> even in such scenarios OS protocols provide a positive benefit.
> 
> e.g. if today 70% of my servers outgoing smtp connections use
> start-tls and tomorrow 67% use them is that evidence of an attack?
> 
> there are many cases where these are in fact not readily detectable
> so this statment provides more certainty then it should.
> 
> I'm ok with the uncertainty (it's inevitable I think) but  not with
> our statement of it yet.

Got any words to suggest?

Would s/readily/often/ be enough?

S.

> 
> 
>> 
> 
> 
> 
> 
> _______________________________________________ saag mailing list 
> saag@ietf.org https://www.ietf.org/mailman/listinfo/saag
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUdLYHAAoJEC88hzaAX42iXOsH/19UNNV9YInWWFBkeRyBd0tY
sD46ddK2OQBrui0Cdc3zKUzHyRW2KghTfik3ZBRjNituHF/0sx/k+k8rgicIDsqp
8/dLCdxtDKoaZmkO5qXzyPflu2iJ8jT74NaUZziw5LxTgOh/DA+mHZygGJurmxVh
l4mb4JFc8ANdwiBfobkxHqeELV4zsYKLLXNaKJvE7uZJivKA+Zy8OVY7VhJhIyaM
7QYAuPWTXcYQJYvDRvndzHBp2nVtMy8fWaarwtnwaOsQPQ304wStyG0al0R+BQu9
1q6jyhwilSmTuq/RCp0Wq5z9FifuxyFy5Z45jwE35MDVS7Mk7VszbJLenpaVccg=
=yjMX
-----END PGP SIGNATURE-----


From nobody Tue Nov 25 09:05:06 2014
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 BE1B81ACE9F; Tue, 25 Nov 2014 09:04:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HmuoP2NzIHR; Tue, 25 Nov 2014 09:04:51 -0800 (PST)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 346ED1A6F84; Tue, 25 Nov 2014 09:04:51 -0800 (PST)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 31BACDA02FE; Tue, 25 Nov 2014 17:04:44 +0000 (UTC)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id E58D453E078; Tue, 25 Nov 2014 09:04:20 -0800 (PST)
Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 25 Nov 2014 09:04:21 -0800
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <5474B577.3030200@bogus.com>
Date: Tue, 25 Nov 2014 12:04:12 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <6779A1B2-EAA2-4337-904F-A43082665FEC@nominum.com>
References: <20141125160923.14619.5614.idtracker@ietfa.amsl.com> <81804E05-734A-4567-A64F-4688CF261BC0@nominum.com> <5474B577.3030200@bogus.com>
To: Joel Jaeggli 
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/917J__IjzfshrzWJ0v9VcjacjHU
Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG 
Subject: Re: [saag] Joel Jaeggli's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS)
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, 25 Nov 2014 17:04:58 -0000

On Nov 25, 2014, at 11:59 AM, joel jaeggli  wrote:
> e.g. if today 70% of my servers outgoing smtp connections use =
start-tls
> and tomorrow 67% use them is that evidence of an attack?

I think your bar for "readily detectable" is too high.   In the example =
you give, it would be a fairly straightforward statistical analysis =
problem to show whether this is coincidence or enemy action.  E.g., if =
you have a lot of new users and they are all using cleartext, that's =
okay.   If you have a lot of the same users, and suddenly 3% more of =
them are using cleartext, that's probably enemy action.

Remember that OS works best to change _how much_ surveillance succeeds, =
not to _prevent_ surveillance.   So there are no guarantees.   We're =
just trying to throw a spanner in the surveillance works here.


From nobody Tue Nov 25 09:22:58 2014
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 464091ACDCA; Tue, 25 Nov 2014 09:22:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UM8tR2MgPBly; Tue, 25 Nov 2014 09:22:52 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 811531A6F86; Tue, 25 Nov 2014 09:21:35 -0800 (PST)
Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id sAPHLUO1091953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Nov 2014 17:21:31 GMT (envelope-from joelja@bogus.com)
Message-ID: <5474BA95.5000207@bogus.com>
Date: Tue, 25 Nov 2014 09:21:25 -0800
From: joel jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0
MIME-Version: 1.0
To: Stephen Farrell , Ted Lemon 
References: <20141125160923.14619.5614.idtracker@ietfa.amsl.com> <81804E05-734A-4567-A64F-4688CF261BC0@nominum.com> <5474B577.3030200@bogus.com> <5474B607.8040208@cs.tcd.ie>
In-Reply-To: <5474B607.8040208@cs.tcd.ie>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="evWxQVebSMH8sEwCUlAEgWgS5Q0JX2P64"
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/I0UTeJ_AAx4l2u0yLtuta9RySYg
Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG 
Subject: Re: [saag] Joel Jaeggli's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS)
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, 25 Nov 2014 17:22:54 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--evWxQVebSMH8sEwCUlAEgWgS5Q0JX2P64
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/25/14 9:01 AM, Stephen Farrell wrote:
>=20
>=20
> On 25/11/14 16:59, joel jaeggli wrote:
>> On 11/25/14 8:38 AM, Ted Lemon wrote:
>>> On Nov 25, 2014, at 11:09 AM, Joel Jaeggli 
>>> wrote:
>>>> If the use of what are essentially transparent proxies makes
>>>> downgrade attacks, or effectively the removal of OE signaling
>>>> entirely trivial then certain people will do that routinetly in
>>>> order to support all sorts of ugly business models (the proxy
>>>> is already there).
>>>
>>> This is now addressed in the RFC editor's note, and I am happy
>>> with the outcome.   YMMV, of course!   :)
>=20
>> yeah I'm not super happy with
>=20
>> However, when such attacks are employed pervasively in order to
>> facilitate e,g, surveillance, this is readily detectable; hence,
>> even in such scenarios OS protocols provide a positive benefit.
>=20
>> e.g. if today 70% of my servers outgoing smtp connections use
>> start-tls and tomorrow 67% use them is that evidence of an attack?
>=20
>> there are many cases where these are in fact not readily detectable
>> so this statment provides more certainty then it should.
>=20
>> I'm ok with the uncertainty (it's inevitable I think) but  not with
>> our statement of it yet.
>=20
> Got any words to suggest?
>=20
> Would s/readily/often/ be enough?

often / probably / should be / might be

is probably a spectrum, it's better than readily.


>=20
> S.
>=20
>=20
>=20
>>>
>=20
>=20
>=20
>=20
>> _______________________________________________ saag mailing list=20
>> saag@ietf.org https://www.ietf.org/mailman/listinfo/saag
>=20
>=20



--evWxQVebSMH8sEwCUlAEgWgS5Q0JX2P64
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlR0upUACgkQ8AA1q7Z/VrLYLwCfTu4fSzxU5rnhlRDpWxYiFZRc
63kAnArK9jRXiGNE1Y1CuU6BO58DbjBW
=4WQ6
-----END PGP SIGNATURE-----

--evWxQVebSMH8sEwCUlAEgWgS5Q0JX2P64--


From nobody Tue Nov 25 09:23:56 2014
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 B3F951A6EE2; Tue, 25 Nov 2014 09:23:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7llHkRbuMoB; Tue, 25 Nov 2014 09:23:52 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 92F221A6F86; Tue, 25 Nov 2014 09:23:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 00AE8BED1; Tue, 25 Nov 2014 17:23:51 +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 CyJVYins8z3V; Tue, 25 Nov 2014 17:23:47 +0000 (GMT)
Received: from [10.87.48.5] (unknown [86.46.28.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A188ABEE0; Tue, 25 Nov 2014 17:23:45 +0000 (GMT)
Message-ID: <5474BB21.4040501@cs.tcd.ie>
Date: Tue, 25 Nov 2014 17:23:45 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: joel jaeggli , Ted Lemon 
References: <20141125160923.14619.5614.idtracker@ietfa.amsl.com> <81804E05-734A-4567-A64F-4688CF261BC0@nominum.com> <5474B577.3030200@bogus.com> <5474B607.8040208@cs.tcd.ie> <5474BA95.5000207@bogus.com>
In-Reply-To: <5474BA95.5000207@bogus.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HOkoeDiV764lmCwynAnyChu0-lU
Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG 
Subject: Re: [saag] Joel Jaeggli's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS)
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, 25 Nov 2014 17:23:54 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 25/11/14 17:21, joel jaeggli wrote:
> often / probably / should be / might be

"often" it is - done now

S.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUdLsgAAoJEC88hzaAX42iylEH/2wBLCQNMfdEkWQwCa5gZzbU
m3euzSpIlBqZjsC/cVj6X43Lb35MpX4ZBaLIHlK+5SjCHtX95jp1c5GGyfC7FMKh
7dseEVxVLUCYT/GU8rNAx2FDNHa6aSZtt4K5TD2rikgK0HzYkwUZWe+KYY4JX0wE
MjeVZT/GMtrV060Nd2tYMkHuKe1WhxkT3CdsIW6D0bdUZ1LurcHlids8zsJkRs4F
waztC2GJr71Cj60U55scOyfWclezJD6/ANd4APe1D9qIAn8hCMmW4ntLFuoqYPmF
YoUskY2Z07T7DbNXXpeZh6HfbgHcCI0cR9kAD7d91WSzPy9A6/6SjTv4w/HU+AA=
=irBf
-----END PGP SIGNATURE-----


From nobody Tue Nov 25 09:24:59 2014
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 5D3611A871A; Tue, 25 Nov 2014 09:24:56 -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] 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 ZvYebrFaWJfp; Tue, 25 Nov 2014 09:24:54 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9781A8715; Tue, 25 Nov 2014 09:24:54 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Joel Jaeggli" 
To: The IESG 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141125172454.1370.86668.idtracker@ietfa.amsl.com>
Date: Tue, 25 Nov 2014 09:24:54 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/wSWlohFVDhkGzuX5t0y8u2tE2gk
Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org
Subject: [saag] Joel Jaeggli's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT)
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Nov 2014 17:24:56 -0000

Joel Jaeggli has entered the following ballot position for
draft-dukhovni-opportunistic-security-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

woud prefer


 However, when such attacks are employed pervasively in order to
 facilitate e,g, surveillance, this is probably detectable; hence,
 even in such scenarios OS protocols may provide a positive benefit.

but I've said my piece and I will trust the shepherding AD.

was:

hanging on Ted's point a bit. I might clear if he does.

If the use of what are essentially transparent proxies makes downgrade
attacks, or effectively the removal of OE signaling entirely trivial then
certain people will do that routinetly in order to support all sorts of
ugly business models (the prexy is already there).

if you read about other cases that are effectively downgrades you can
sort of imagine how insidious it is to think you reducing the visible
surface area when in fact it's being stripped off again.

http://www.theregister.co.uk/2014/11/20/gotcha_google_caught_stripping_ssl_search_from_bt_wifi_users_searches/



From nobody Tue Nov 25 09:26:35 2014
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 19A051A00C3; Tue, 25 Nov 2014 09:26:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUcvBtyra602; Tue, 25 Nov 2014 09:26:29 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 033D01A0368; Tue, 25 Nov 2014 09:26:28 -0800 (PST)
Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id sAPHQNU8092009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Nov 2014 17:26:23 GMT (envelope-from joelja@bogus.com)
Message-ID: <5474BBB9.8080201@bogus.com>
Date: Tue, 25 Nov 2014 09:26:17 -0800
From: joel jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0
MIME-Version: 1.0
To: Stephen Farrell , Ted Lemon 
References: <20141125160923.14619.5614.idtracker@ietfa.amsl.com> <81804E05-734A-4567-A64F-4688CF261BC0@nominum.com> <5474B577.3030200@bogus.com> <5474B607.8040208@cs.tcd.ie> <5474BA95.5000207@bogus.com> <5474BB21.4040501@cs.tcd.ie>
In-Reply-To: <5474BB21.4040501@cs.tcd.ie>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E0bdpCxKvedcgLcTWfRk8fjLEuLxsKMfl"
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/tqQjoP9iqKrdOg7NIG4JmYdvYl8
Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG 
Subject: Re: [saag] Joel Jaeggli's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS)
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, 25 Nov 2014 17:26:30 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--E0bdpCxKvedcgLcTWfRk8fjLEuLxsKMfl
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/25/14 9:23 AM, Stephen Farrell wrote:
>=20
>=20
> On 25/11/14 17:21, joel jaeggli wrote:
>> often / probably / should be / might be
>=20
> "often" it is - done now

often works,

I was in the process of clearing anyway.

> S.
>=20



--E0bdpCxKvedcgLcTWfRk8fjLEuLxsKMfl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlR0u7oACgkQ8AA1q7Z/VrITkgCfX2O5wNBRcBbHGk8dwr6Ld9gb
iA0AnjxG3jZGsPJiU0XdEtRBqqucUImM
=yWNk
-----END PGP SIGNATURE-----

--E0bdpCxKvedcgLcTWfRk8fjLEuLxsKMfl--


From nobody Tue Nov 25 09:27:40 2014
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 47B6D1A6F8A; Tue, 25 Nov 2014 09:27:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nq55c0N9JcTT; Tue, 25 Nov 2014 09:27:38 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3388C1A6EDA; Tue, 25 Nov 2014 09:27:38 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 936A2BEDB; Tue, 25 Nov 2014 17:27: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 lTFLFaDYrDXF; Tue, 25 Nov 2014 17:27:36 +0000 (GMT)
Received: from [10.87.48.5] (unknown [86.46.28.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4EF16BEB0; Tue, 25 Nov 2014 17:27:36 +0000 (GMT)
Message-ID: <5474BC07.2030509@cs.tcd.ie>
Date: Tue, 25 Nov 2014 17:27:35 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: joel jaeggli , Ted Lemon 
References: <20141125160923.14619.5614.idtracker@ietfa.amsl.com> <81804E05-734A-4567-A64F-4688CF261BC0@nominum.com> <5474B577.3030200@bogus.com> <5474B607.8040208@cs.tcd.ie> <5474BA95.5000207@bogus.com> <5474BB21.4040501@cs.tcd.ie> <5474BBB9.8080201@bogus.com>
In-Reply-To: <5474BBB9.8080201@bogus.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rPYae3GRm1QygpX9-zYWgFQGalM
Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG 
Subject: Re: [saag] Joel Jaeggli's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS)
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, 25 Nov 2014 17:27:39 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 25/11/14 17:26, joel jaeggli wrote:
> On 11/25/14 9:23 AM, Stephen Farrell wrote:
>> 
>> 
>> On 25/11/14 17:21, joel jaeggli wrote:
>>> often / probably / should be / might be
>> 
>> "often" it is - done now
> 
> often works,
> 
> I was in the process of clearing anyway.

Thanks,
S.

> 
>> S.
>> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUdLwHAAoJEC88hzaAX42iVpQH/jFgApSDjKLdqyt7L6WsJBsJ
kEyE0zE9hVnAFwddbXHOpRUH6W11GECpxVT8mgzbek/ht4IJWNwVxKnBWJMNQfzy
W9irdWevy+xeAUYuRPsdPCfx5gQvDECgVJaRI7zqBGeZGQaqYwqlaPc+/2hicat4
g8TkYeRnlvwM8o+mK2M9nTP5OE+aWlzds6PJjrDsPDCWTfDMBO4ZXMWozA2BeitT
QKdh8AS81VqWx6PuesUiSYt4sotQimZqrNyux4ByYGONgAd7XUe92hvRg7xH0jMR
eIS08UOVDOvuz2c66BtLYHy346wkFdrcINJ6oZC17CIX0s6Mos4l+Y/soWJ/0ms=
=HZkx
-----END PGP SIGNATURE-----


From nobody Tue Nov 25 09:30:39 2014
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 EE2E01ACEBE; Tue, 25 Nov 2014 09:30:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjWkSXKiSeVT; Tue, 25 Nov 2014 09:30:30 -0800 (PST)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 A79BC1A8722; Tue, 25 Nov 2014 09:30:30 -0800 (PST)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id B192ADA02F8; Tue, 25 Nov 2014 17:30:23 +0000 (UTC)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 4F0ED53E078; Tue, 25 Nov 2014 09:30:00 -0800 (PST)
Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 25 Nov 2014 09:29:59 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <20141125172454.1370.86668.idtracker@ietfa.amsl.com>
Date: Tue, 25 Nov 2014 12:29:50 -0500
Content-Transfer-Encoding: 7bit
Message-ID: <99E861F8-68ED-490E-B6F8-A09E551B93A8@nominum.com>
References: <20141125172454.1370.86668.idtracker@ietfa.amsl.com>
To: Joel Jaeggli 
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/RkExfNx11voTHIW9LBDRixhAmhA
Cc: The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org
Subject: Re: [saag] Joel Jaeggli's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT)
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, 25 Nov 2014 17:30:32 -0000

On Nov 25, 2014, at 12:24 PM, Joel Jaeggli  wrote:
> However, when such attacks are employed pervasively in order to
> facilitate e,g, surveillance, this is probably detectable; hence,
> even in such scenarios OS protocols may provide a positive benefit.

WFM


From nobody Tue Nov 25 09:41:46 2014
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 B85201A86EC; Tue, 25 Nov 2014 09:41:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QDFCt76CCczx; Tue, 25 Nov 2014 09:41:39 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A8C1A8703; Tue, 25 Nov 2014 09:41:39 -0800 (PST)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sAPHfWfc015597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Nov 2014 09:41:36 -0800
Message-ID: <5474BF3F.2060702@dcrocker.net>
Date: Tue, 25 Nov 2014 09:41:19 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Barry Leiba , Benoit Claise 
References: <20141125104354.20090.85063.idtracker@ietfa.amsl.com> <54745F8C.2020100@cs.tcd.ie> <5474645F.3030209@cisco.com> <54746951.1020008@fifthhorseman.net> <547489C4.4060409@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 25 Nov 2014 09:41:36 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/f4L2n8OfQSiRdxbxOJ9Jv5WV3BI
Cc: Ron Bonica , "saag@ietf.org" , draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG 
Subject: Re: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT)
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Nov 2014 17:41:41 -0000

On 11/25/2014 7:56 AM, Barry Leiba wrote:
> - If we tell the user anything (see below), and we do that today with
> the lock symbol, the green URL-bar icon, and whatnot, we *only* tell
> the user about authenticated encryption.  Unauthenticated encryption
> will and should be entirely a matter for the wire, not noticed by the
> user.


The problem with language like this ("will and should") is that it
really does presume to direct user interface design.  Besides ignoring
the problematic human factors history you cited in your note, it might
or might not be a good suggestion.

The current "no misrepresentation" language is bland, conceptual and
reasonable.  It stays away from UI design and merely talks about user
'effects'.  Saying anything else invites UI design debate. This IETF
document should leave such things entirely open-ended.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Tue Nov 25 09:44:16 2014
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 EDE4D1A8727; Tue, 25 Nov 2014 09:44:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rC0U3Qzz5oNK; Tue, 25 Nov 2014 09:44:12 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BBB9B1A8726; Tue, 25 Nov 2014 09:44:12 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 23EF5BEC4; Tue, 25 Nov 2014 17:44: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 QoC_4H41_8qg; Tue, 25 Nov 2014 17:44:07 +0000 (GMT)
Received: from [10.87.48.5] (unknown [86.41.50.31]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 14C3CBEE1; Tue, 25 Nov 2014 17:44:00 +0000 (GMT)
Message-ID: <5474BFDF.3090209@cs.tcd.ie>
Date: Tue, 25 Nov 2014 17:43:59 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: dcrocker@bbiw.net, Barry Leiba ,  Benoit Claise 
References: <20141125104354.20090.85063.idtracker@ietfa.amsl.com> <54745F8C.2020100@cs.tcd.ie> <5474645F.3030209@cisco.com> <54746951.1020008@fifthhorseman.net> <547489C4.4060409@cisco.com>  <5474BF3F.2060702@dcrocker.net>
In-Reply-To: <5474BF3F.2060702@dcrocker.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_uJ7YHJ_cDPI_OJWT3syVIObgRY
Cc: Ron Bonica , "saag@ietf.org" , draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG 
Subject: Re: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT)
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, 25 Nov 2014 17:44:14 -0000

On 25/11/14 17:41, Dave Crocker wrote:
> The current "no misrepresentation" language is bland, conceptual and
> reasonable.  It stays away from UI design and merely talks about user
> 'effects'.  Saying anything else invites UI design debate. This IETF
> document should leave such things entirely open-ended.

Fair point.

Amd btw, the iesg just approved that. Viktor's going to
fold in the RFC editor note changes then we'll be done.

Thanks all for your efforts with this.

Cheers,
S.


From nobody Tue Nov 25 11:19:20 2014
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 863ED1A6EED for ; Tue, 25 Nov 2014 11:18:10 -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] 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 nfn9L56w193V; Tue, 25 Nov 2014 11:18:08 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DD11A87DB; Tue, 25 Nov 2014 11:18:07 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: ietf-dane@dukhovni.org, draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141125191807.15843.57885.idtracker@ietfa.amsl.com>
Date: Tue, 25 Nov 2014 11:18:07 -0800
From: IETF Secretariat 
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/MJaUoOIQ7vWrkTK23t7E8181l7Y
Subject: [saag] ID Tracker State Update Notice: 
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Nov 2014 19:18:10 -0000

IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from Waiting for AD Go-Ahead
ID Tracker URL: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/


From nobody Wed Nov 26 06:30:27 2014
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 A96F91A0140 for ; Wed, 26 Nov 2014 06:30:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-bICqVfMXWt for ; Wed, 26 Nov 2014 06:30:24 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BEF591A00E2 for ; Wed, 26 Nov 2014 06:30:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9AAD1BF02 for ; Wed, 26 Nov 2014 14:30:23 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGUk4jWeFMqS for ; Wed, 26 Nov 2014 14:30:23 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 77DD2BEFE for ; Wed, 26 Nov 2014 14:30:23 +0000 (GMT)
Message-ID: <5475E3FE.6040109@cs.tcd.ie>
Date: Wed, 26 Nov 2014 14:30:22 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "saag@ietf.org" 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/x9tNHmSXfzk6N5xU40-TWpWypBQ
Subject: [saag] pkcs#11 URI scheme
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, 26 Nov 2014 14:30:26 -0000

Hiya,

I've been asked if I'd AD sponsor this [1] draft that
defines a URI scheme for pkcs#11. Feedback is welcome
before I decide. (On/off list, whatever is ok for now.)

Thanks,
S.

[1] https://datatracker.ietf.org/doc/draft-pechanec-pkcs11uri/


From nobody Wed Nov 26 07:36:18 2014
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 77AEA1A01AA for ; Wed, 26 Nov 2014 07:36:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08eDedUke9RV for ; Wed, 26 Nov 2014 07:36:16 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 105181A01A8 for ; Wed, 26 Nov 2014 07:36:15 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAQFaFZA009530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 26 Nov 2014 10:36:15 -0500
Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.128.7]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAQFaDtt019006 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 26 Nov 2014 10:36:14 -0500
Message-ID: <5475F36D.90007@redhat.com>
Date: Wed, 26 Nov 2014 16:36:13 +0100
From: Petr Spacek 
Organization: Red Hat
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: saag@ietf.org
References: <5475E3FE.6040109@cs.tcd.ie>
In-Reply-To: <5475E3FE.6040109@cs.tcd.ie>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/AH3eTQIptAqFs6lNfKIFXosuTno
Subject: Re: [saag] pkcs#11 URI scheme
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, 26 Nov 2014 15:36:17 -0000

On 26.11.2014 15:30, Stephen Farrell wrote:
> Hiya,
> 
> I've been asked if I'd AD sponsor this [1] draft that
> defines a URI scheme for pkcs#11. Feedback is welcome
> before I decide. (On/off list, whatever is ok for now.)
> 
> Thanks,
> S.
> 
> [1] https://datatracker.ietf.org/doc/draft-pechanec-pkcs11uri/

I can say only that various versions of the draft are already used in
practice. From Open Source I can name BIND, p11-kit, and FreeIPA projects.

To sum it up: To me, standardization sounds like the right thing to do.

Have a nice day!

-- 
Petr Spacek  @  Red Hat


From nobody Wed Nov 26 07:40:17 2014
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 8F6DB1A0354 for ; Wed, 26 Nov 2014 07:40:15 -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] 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 iJWtnKfJy0oR; Wed, 26 Nov 2014 07:40:14 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 351341A0318; Wed, 26 Nov 2014 07:40:12 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: ietf-dane@dukhovni.org, draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org, stephen.farrell@cs.tcd.ie
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141126154012.1032.28708.idtracker@ietfa.amsl.com>
Date: Wed, 26 Nov 2014 07:40:12 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/nSUCOyJ8LCePnJJqg_JTyIdpJjA
Subject: [saag] New Version Notification - draft-dukhovni-opportunistic-security-06.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Nov 2014 15:40:15 -0000

A new version (-06) has been submitted for draft-dukhovni-opportunistic-security:
http://www.ietf.org/internet-drafts/draft-dukhovni-opportunistic-security-06.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-dukhovni-opportunistic-security-06

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.

IETF Secretariat.


From nobody Wed Nov 26 09:13:26 2014
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 D0E621A0204 for ; Wed, 26 Nov 2014 09:13:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 kDwK7gD6Dn2S for ; Wed, 26 Nov 2014 09:13:22 -0800 (PST)
Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D10281A0147 for ; Wed, 26 Nov 2014 09:13:22 -0800 (PST)
Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 8DA2E20058D84 for ; Wed, 26 Nov 2014 09:13:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=9pBR/2m9fqglVxtYHLcE 53CiUGY=; b=A7tNhLgmodopHDIZHzYBW+ndwMv8ovS9U3gz5bIlmjHv3scAkqEZ JgGqKbYK+M9m0HKgHOoTA1b5U/SbNU5fI6H+t53X24jlAdFe3AC/HQizVTQddzCC pQci7dhAQc01Z+uz0wAOoAwbHZUKYmtEIhUE2jszvfmi9vK9xWOVNc0=
Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPSA id 6668420058D83 for ; Wed, 26 Nov 2014 09:13:22 -0800 (PST)
Received: by mail-wg0-f49.google.com with SMTP id x12so4310708wgg.36 for ; Wed, 26 Nov 2014 09:13:21 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.195.11.68 with SMTP id eg4mr49263922wjd.18.1417022001361; Wed, 26 Nov 2014 09:13:21 -0800 (PST)
Received: by 10.216.32.136 with HTTP; Wed, 26 Nov 2014 09:13:21 -0800 (PST)
In-Reply-To: <5475E3FE.6040109@cs.tcd.ie>
References: <5475E3FE.6040109@cs.tcd.ie>
Date: Wed, 26 Nov 2014 11:13:21 -0600
Message-ID: 
From: Nico Williams 
To: Stephen Farrell 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_DalQJ8HwPTRLXRHmAAZmHbY6K8
Cc: "saag@ietf.org" 
Subject: Re: [saag] pkcs#11 URI scheme
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, 26 Nov 2014 17:13:24 -0000

On Wednesday, November 26, 2014, Stephen Farrell
 wrote:
> I've been asked if I'd AD sponsor this [1] draft that
> defines a URI scheme for pkcs#11. Feedback is welcome
> before I decide. (On/off list, whatever is ok for now.)

> [1] https://datatracker.ietf.org/doc/draft-pechanec-pkcs11uri/

I support this.  I believe it will be very useful to have such URIs
for a variety of applications -- mostly not as part of UIs, but as
part of admin interfaces.  A regular and portable way of referencing
providers, slots, tokens, objects -- this is a badly needed thing.

Nico
--


From nobody Wed Nov 26 09:31:22 2014
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 B88361A1A3D for ; Wed, 26 Nov 2014 09:31:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnkC4gw1SjXR for ; Wed, 26 Nov 2014 09:31:19 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B399A1A1A3B for ; Wed, 26 Nov 2014 09:31:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2DBF3BEE1 for ; Wed, 26 Nov 2014 17:31:19 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLPQB6Oocz4f for ; Wed, 26 Nov 2014 17:31:19 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E948DBEC9 for ; Wed, 26 Nov 2014 17:31:18 +0000 (GMT)
Message-ID: <54760E66.1080100@cs.tcd.ie>
Date: Wed, 26 Nov 2014 17:31:18 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "saag@ietf.org" 
References: <54760C84.30201@cs.tcd.ie>
In-Reply-To: <54760C84.30201@cs.tcd.ie>
X-Forwarded-Message-Id: <54760C84.30201@cs.tcd.ie>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/wem3WvdcgMUDHU9ifpnVv-l843Q
Subject: [saag] Fwd: Approved: draft-dukhovni-opportunistic-security
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, 26 Nov 2014 17:31:20 -0000

FYI. Thanks again all for your work on getting this done.
Hopefully, we'll start to see protocols following this
approach and I'd encourage you to try help people do that
as you can.

Cheers,
S.


-------- Forwarded Message --------
Subject: Approved: draft-dukhovni-opportunistic-security
Date: Wed, 26 Nov 2014 17:23:16 +0000
From: Stephen Farrell 
To: IESG ,
draft-dukhovni-opportunistic-security.all@tools.ietf.org


Dear secretariat folks (bcc'd),

draft-dukhovni-opportunistic-security-06 is approved. There
are no longer any RFC editor notes as those were incorporated
into -06.

Please take advantage of the chance to send this one along
to the RFC editor,

Thanks,
Stephen.




From nobody Thu Nov 27 04:52:01 2014
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 596B11A88F2 for ; Thu, 27 Nov 2014 04:52:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 eeZiwoayAAgt for ; Thu, 27 Nov 2014 04:51:59 -0800 (PST)
Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5756C1A88ED for ; Thu, 27 Nov 2014 04:51:59 -0800 (PST)
Received: by mail-qg0-f44.google.com with SMTP id z60so3508791qgd.3 for ; Thu, 27 Nov 2014 04:51:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Efyoy5pdXzwPMeDZVDafhS3Bl9gjbxV2uED5od9MF8Y=; b=Hrbk7SK2mhkcYLKCegLiagg1pafy93lAnKirzNt+uGyeFpgtVfm5wLb7EnqnWfYLAr HNFDBIPc28++ghBTYzBx6CL3Ot+B6l52M+0o7wKsgDvZsT6Bm0URb5cq7XHU0sEn88f6 OCXZF1Vd+QRPc605o3+yYOoPSvqeWOTTkwIx2PrAlgrOVe+P2RPatIhcfgyTHsShrVoE qQruPM54CnoaOO7hMja2oaQEMlZwNfkUYVZY9auh6MN9lnwBMB0/MvJBxjkDOCMeUI/f aGd4OQcuvGgNWTgwpg+zUoz2qvAHgouMELHgtLHHPok1E60TTVGbP0naAbqRI2gZi5Bt TIqg==
MIME-Version: 1.0
X-Received: by 10.224.37.133 with SMTP id x5mr54213328qad.59.1417092718599; Thu, 27 Nov 2014 04:51:58 -0800 (PST)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.229.222.131 with HTTP; Thu, 27 Nov 2014 04:51:58 -0800 (PST)
In-Reply-To: <5475E3FE.6040109@cs.tcd.ie>
References: <5475E3FE.6040109@cs.tcd.ie>
Date: Thu, 27 Nov 2014 13:51:58 +0100
X-Google-Sender-Auth: R0JNi_bpguAYlzMZcpYkWEIzeq0
Message-ID: 
From: Nikos Mavrogiannopoulos 
To: Stephen Farrell 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/CZq6m7JfY2hB2CrnTNHihHRp9ys
Cc: "saag@ietf.org" 
Subject: Re: [saag] pkcs#11 URI scheme
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, 27 Nov 2014 12:52:00 -0000

On Wed, Nov 26, 2014 at 3:30 PM, Stephen Farrell
 wrote:
> Hiya,
> I've been asked if I'd AD sponsor this [1] draft that
> defines a URI scheme for pkcs#11. Feedback is welcome
> before I decide. (On/off list, whatever is ok for now.)

I support this. With that draft crypto software have the ability to
refer to tokens as HSM and smart cards, as well as objects in them, in
a uniform way. GnuTLS makes use of that URI scheme.

regards,
Nikos