From nobody Thu Jun 2 20:41:30 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EAF12D61D for ; Thu, 2 Jun 2016 20:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1JVBhyXXTSZ for ; Thu, 2 Jun 2016 20:41:26 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8703C12D0FA for ; Thu, 2 Jun 2016 20:41:26 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id a136so256796614wme.0 for ; Thu, 02 Jun 2016 20:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=4yEWzBJozp0BupdjBciZlZ7jO+LbPxOCq6WQqpkswlE=; b=NIJXA8bPPJY2bgrWvIDSaGfCo0SCXPq85cjD6293Q8CrX7vi0o17IJEI+jV1PTueb0 pS+q8STnio5hndTWNGPuD+QhD3nRpTLcbd+vS2hTYt9C11uq5hJAe/l1p+K21Q7MpHvU HkIGimh5To5y/MtH0vtGaE/966jGnSc6zHP7TuoyG9U2jKajY+p0RiNREbUAwKUTtZG+ wHdLaFhicG0Ulwpy05wI1b/A0BKysLawsvUV8oa8CKKCYPr7oiro+2BOwZ1sr2z0jaLh +3xSdqmAo8rPdKpB2AbG1BscKoq8HKhrSAAtlW4RIujRFJayCENu7QSjbU1DclOERa2C 2qQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=4yEWzBJozp0BupdjBciZlZ7jO+LbPxOCq6WQqpkswlE=; b=CYQ9pCm6xEJaxT+TBNsWGFUCtS23rG2038QuJrjbVGgUNFe1u9m4vHvd4Cbhqzu4/6 ZQkgn19M3dF357mz3yPqPsH2iUrjxvlmpTdGuIXL9J7sSGUT6yOYR5gUZi7ge2Q68D0k 54woy3YDhaHlqW6lSvKq5BfkPyDIWbIbBnuQpuO3YhiBWMoQBefSzY42+2UZttPV2D4u JVXB2dk6xTLz1YqL81MPeRUQQx2pDpx9f87xozj+Bo3HmkRo3PQbMGSDxUZEmBTo+LM6 T0n6UShLjz1pg8hDhJbeGPlznZU7JKNPayMnJ0Kw2NNuiZMjmubOicQhz2+CPzMrX5j9 sMKQ== X-Gm-Message-State: ALyK8tLVox37DM2brxKknIvZ0AJrWXxejJFdpd2ZpnBF0rZwGbQHHLMoKsp7+2R+DmlFww== X-Received: by 10.28.148.136 with SMTP id w130mr1682694wmd.10.1464925284887; Thu, 02 Jun 2016 20:41:24 -0700 (PDT) Received: from nomad (ip-94-112-138-148.net.upcbroadband.cz. [94.112.138.148]) by smtp.googlemail.com with ESMTPSA id b201sm4205962wmb.9.2016.06.02.20.41.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2016 20:41:23 -0700 (PDT) Message-ID: <1464925282.1967.6.camel@gmail.com> From: Nikos Mavrogiannopoulos To: "philliph@comodo.com" Date: Fri, 03 Jun 2016 05:41:22 +0200 In-Reply-To: <23F24B75-9B2E-41E5-8405-457421C370A2@comodo.com> References: <23F24B75-9B2E-41E5-8405-457421C370A2@comodo.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.1-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: IETF SAAG Subject: Re: [saag] PKIX - TLS Feature Extension X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 03:41:28 -0000 I am not sure I understand your reply. My understanding of this draft is that it will cause future compatibility issues because it assumes that a TLS "feature" is equivalent to a TLS extension. The TLS extensions "Multiple Certificate Status Request Extension" (17) and "Certificate Status Request" (5) are a prominent example. They are the same feature (a method to provide OCSP staples) but utilize different TLS extensions. If any of the intermediate certificates in a chain is restricted the way the draft describes (with tls-feature=5), then the deployment of the multiple certificate status request extension becomes impossible, even though the intention the original restriction was to require servers to provide OCSP staples.  On Tue, 2016-05-31 at 13:15 -0400, philliph@comodo.com wrote: > Yes, that is exactly what is done and the reason that the spec is > written the way it is. > > > > > On May 30, 2016, at 6:26 AM, Nikos Mavrogiannopoulos > poulos@gmail.com> wrote: > > > > Hi, > > RFC7633 describes a PKIX certificate extension to indicate > > mandatory > > to be present TLS extensions (called feature extensions in the > > text). > > In particular this draft while generic, is mainly about requiring > > an > > OCSP staple from the connecting server if the certificate mandates > > it. > > > > However, the rfc text doesn't go into details on how to do that. My > > understanding and as far as I've seen in practice certificates will > > include a "Feature" extension containing integer 5 which is the > > OCSP > > status request. > > > > If the reading above is correct, how does this scale with > > status_request_v2 (which has TLS extension ID 17)? How could the > > certificate be used to indicate that the server can provide any of > > these TLS extensions? Should both the numbers 5,17 be listed as TLS > > features (which can also mean that both TLS extensions must be > > used), > > or having 5 listed is sufficient? > > > > regards, > > Nikos From nobody Fri Jun 3 05:07:03 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400C412D146 for ; Fri, 3 Jun 2016 05:07:02 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrrBt9DJGXn9 for ; Fri, 3 Jun 2016 05:06:59 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 55E2E12D12A for ; Fri, 3 Jun 2016 05:06:58 -0700 (PDT) Received: (qmail 17098 invoked by uid 1004); 3 Jun 2016 12:06:55 -0000 Received: from clofcgmail2.cl.office.comodo.net (HELO clofcgmail2.cl.office.comodo.net) (10.104.70.204) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 03 Jun 2016 13:06:55 +0100 Received: (qmail 17264 invoked by uid 1012); 3 Jun 2016 12:06:55 -0000 Received: from pool-96-230-12-42.bstnma.fios.verizon.net (HELO galifrey.hallambaker.com) (96.230.12.42) (smtp-auth username philliph, mechanism plain) by clofcgmail2.cl.office.comodo.net (qpsmtpd/0.84/v0.84-169-ga857589) with (AES256-SHA encrypted) ESMTPSA; Fri, 03 Jun 2016 08:06:55 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "philliph@comodo.com" In-Reply-To: <1464925282.1967.6.camel@gmail.com> Date: Fri, 3 Jun 2016 08:06:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <23F24B75-9B2E-41E5-8405-457421C370A2@comodo.com> <1464925282.1967.6.camel@gmail.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF SAAG Subject: Re: [saag] PKIX - TLS Feature Extension X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 12:07:02 -0000 No, "Multiple Certificate Status Request Extension" (17) and = "Certificate Status Request" (5) are different features implemented = differently on the client and server. There are many servers that = support one but not the other. Hence the need to advertise them = differently. If a certificate specifies feature 5, that does not prohibit the server = offering 17. But a certificate that specifies 17 cannot be used by a = server that does not support 5. Replacement of a certificate is usually straightforward. There may be a = fee for the very cheapest but but most CAs seem to replace expensive = ones at no cost. > On Jun 2, 2016, at 11:41 PM, Nikos Mavrogiannopoulos = wrote: >=20 > I am not sure I understand your reply. My understanding of this draft > is that it will cause future compatibility issues because it assumes > that a TLS "feature" is equivalent to a TLS extension. The TLS > extensions "Multiple Certificate Status Request Extension" (17) and > "Certificate Status Request" (5) are a prominent example. They are the > same feature (a method to provide OCSP staples) but utilize different > TLS extensions. >=20 > If any of the intermediate certificates in a chain is restricted the > way the draft describes (with tls-feature=3D5), then the deployment of > the multiple certificate status request extension becomes impossible, > even though the intention the original restriction was to require > servers to provide OCSP staples.=20 >=20 >=20 >=20 > On Tue, 2016-05-31 at 13:15 -0400, philliph@comodo.com wrote: >> Yes, that is exactly what is done and the reason that the spec is >> written the way it is. >>=20 >>>=20 >>> On May 30, 2016, at 6:26 AM, Nikos Mavrogiannopoulos >> poulos@gmail.com> wrote: >>>=20 >>> Hi, >>> RFC7633 describes a PKIX certificate extension to indicate >>> mandatory >>> to be present TLS extensions (called feature extensions in the >>> text). >>> In particular this draft while generic, is mainly about requiring >>> an >>> OCSP staple from the connecting server if the certificate mandates >>> it. >>>=20 >>> However, the rfc text doesn't go into details on how to do that. My >>> understanding and as far as I've seen in practice certificates will >>> include a "Feature" extension containing integer 5 which is the >>> OCSP >>> status request. >>>=20 >>> If the reading above is correct, how does this scale with >>> status_request_v2 (which has TLS extension ID 17)? How could the >>> certificate be used to indicate that the server can provide any of >>> these TLS extensions? Should both the numbers 5,17 be listed as TLS >>> features (which can also mean that both TLS extensions must be >>> used), >>> or having 5 listed is sufficient? >>>=20 >>> regards, >>> Nikos From nobody Wed Jun 8 01:36:07 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F31212D874 for ; Wed, 8 Jun 2016 01:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTNaVRGJAfEE for ; Wed, 8 Jun 2016 01:36:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47E812D871 for ; Wed, 8 Jun 2016 01:36:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F4142BE25 for ; Wed, 8 Jun 2016 09:36:00 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAxgW-RPRjA3 for ; Wed, 8 Jun 2016 09:35:59 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DBFBABDCA for ; Wed, 8 Jun 2016 09:35:58 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1465374959; bh=yBZkxR4Hl/w157Yg9VlJidugAvVfbSpQOdtSt9TlmP0=; h=Subject:References:To:From:Date:In-Reply-To:From; b=tOQboek5mZhkHCGMwDAqU6nhnZmr8kH3whp4PFB9AMtVXwUrASBiajVcvZOI/gbfx eKT9nqvK0s0Mm3ooJeIWtfLSlGMnx98/RGD0vfnz2hJ/q+XcS6W/O0ju2x2D7o9abQ rMqmImP8JJYIwreWJqlIQ0Poh3vPzn/NVbBUNKvU= References: To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: Message-ID: <5757D8EC.5080508@cs.tcd.ie> Date: Wed, 8 Jun 2016 09:35:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7TmOe55MtujVeINQ8GUJWmFgSVVdNx8cS" Archived-At: Subject: [saag] Fwd: [IRTF-Announce] ANRP presentations at IETF-96 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 08:36:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7TmOe55MtujVeINQ8GUJWmFgSVVdNx8cS Content-Type: multipart/mixed; boundary="7e2O9QAiU52oDMrwWD8WbDWGwOHdjkoUx" From: Stephen Farrell To: "saag@ietf.org" Message-ID: <5757D8EC.5080508@cs.tcd.ie> Subject: Fwd: [IRTF-Announce] ANRP presentations at IETF-96 References: In-Reply-To: --7e2O9QAiU52oDMrwWD8WbDWGwOHdjkoUx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI, whenever the IETF meeting agenda is finalised you might want to consider the talk on QUIC security below which'll be in the irtfopen session. Cheers, S. -------- Forwarded Message -------- Subject: [IRTF-Announce] ANRP presentations at IETF-96 Resent-Date: Wed, 8 Jun 2016 01:32:21 -0700 (PDT) Resent-From: alias-bounces@ietf.org Resent-To: @ietf.org Date: Wed, 8 Jun 2016 08:31:43 +0000 From: Eggert, Lars Reply-To: anrp@irtf.org To: irtf-announce@irtf.org , ietf@ietf.org , 96attendees@ietf.org <96attendees@ietf.org>, wgchairs@ietf.org , bofchairs@ietf.org Hi, we are extremely pleased to report that for the 2016 award period of the Applied Networking Research Prize (ANRP), 53 eligible nominations were received. Each submission was reviewed by several members of the selection committee selection committee according to a diverse set of criteria, including scientific excellence and substance, timeliness, relevance, and potential impact on the Internet. Based on this review, six submissions are awarded an Applied Networking Research Prize in 2016. Two prize winners will present their work at the IRTF Open Meeting during IETF-96 in Berlin, Germany. The ANRPs for IETF-96 go to: *** Samuel Jero *** for a security analysis of the QUIC protocol: Robert Lychev, Samuel Jero, Alexandra Boldyreva and Cristina Nita-Rotaru. How Secure and Quick is QUIC? Provable Security and Performance Analyses. Proc. IEEE Symposium on Security and Privacy, pp. 214=E2=80=93231, San Jose, CA, USA, May 201= 5. *** Dario Rossi *** for characterizing anycast adoption and deployment in the IPv4 Internet: Danilo Cicalese, Jordan Aug=C3=A9, Diana Joumblatt, Timur Friedman and Dario Rossi. Characterizing IPv4 Anycast Adoption and Deployment. Proc. ACM CoNEXT, Heidelberg, Germany, December 2015. Please subscribe to the IRTF-Announce mailing list in order to receive future calls for ANRP nominations and join ISOC to stay informed of other networking research initiatives: https://irtf.org/mailman/listinfo/irtf-announce https://isoc.org/join More information about the ANRP is at https://irtf.org/anrp Regards, Lars Eggert, IRTF Chair https://irtf.org/anrp Mat Ford, Internet Society https://isoc.org/research/ 2016 ANRP Selection Committee Mark Allman, ICIR Marcelo Bagnulo, UC3M Lou Berger, LabN KC Claffy, CAIDA Mark Crovella, Boston University Lars Eggert, NetApp Stephen Farrell, Trinity College Dublin Nick Feamster, Princeton Mat Ford, ISOC Lisandro Granville, UFRGS Volker Hilt, Bell Labs Suresh Krishnan, Ericsson Al Morton, AT&T Laboratories J=C3=B6rg Ott, Aalto University Colin Perkins, University of Glasgow Aiko Pras, University of Twente J=C3=BCrgen Sch=C3=B6nw=C3=A4lder, Jacobs University Bremen Joe Touch, USC/ISI Rolf Winter, Hochschule Augsburg Lixia Zhang, UCLA --7e2O9QAiU52oDMrwWD8WbDWGwOHdjkoUx-- --7TmOe55MtujVeINQ8GUJWmFgSVVdNx8cS 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 iQEcBAEBCAAGBQJXV9jsAAoJEC88hzaAX42i5KsH/094hT3S5sb+hZGxk/jqU0sm kLV/2SEGhTZx6OoH+pEKSppbdn+SyM28V4ScZiMErIn3AYKEAMuBC7sD6ygHIict Lxp0TiGMznAzlciltzyUO6TRJgW4eia6n4hO+3oExd3Zv90ej+uT/iaNGHX9EqvR VVcwV75yB7gkk8UUannmev8uOJ64riJbVg/b8UzccehffaVqe7aoKtTCWny+rafT q54b3d+HKlzXwkwYDPe/ozq/heeXVYBZPapGxu82qPtciUhNPxRYls0e3lyBDNmX XBjmzBQrQO1Pd/WUgecJiv0d6xpgxsbJTiBMBDXfCQ0kRSYp0zRK3zHiqWjZQt0= =+EKK -----END PGP SIGNATURE----- --7TmOe55MtujVeINQ8GUJWmFgSVVdNx8cS-- From nobody Fri Jun 10 17:38:22 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7925712D1A7 for ; Fri, 10 Jun 2016 17:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kV8iTuCvf9Yf for ; Fri, 10 Jun 2016 17:38:19 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD8412D0BB for ; Fri, 10 Jun 2016 17:38:18 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id u63so45649449qkh.0 for ; Fri, 10 Jun 2016 17:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=NfIRIUmGrCp5EXXRgLZcKaQRhaYVqlyBT5GrURgk7WY=; b=d2Nxpw45PqYz4s8rgl3S6xuNkb2uCRb0TJJHa97WiYhGrU8p4ktW0t6V5X4dEncu8i 7uoGmPQynySDL4pTTREIYMtJj4Bwc/f/HVuVk8dcvvGNFBYAfyZSAmIT/mFPsj4siI7T 5Grvqd5tqaeK6lsJqW7KtMVSfeMxlbDvuL4snki0mYZDAN/Gv2nAqJOO5bS2PlMpV3+i nZ+rfQhlnf31U8EYjyE74fEFqJ4ZDcZs0DhpcubrkdbE4fvUjdKBVoHcnjJEz10bmYTe zMSuSLvq7NxJmZoFj7QUvL4KtBxSKrnAnipiXDkRPnb8H/n2Zk4tJu03X+WI+YaJvWXp Owzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=NfIRIUmGrCp5EXXRgLZcKaQRhaYVqlyBT5GrURgk7WY=; b=aaynnYu5pQTpPnF7fpDk42UmAfutJhW0SMs4/vPZnCLmUWlER/zIcdN5qwPrBl4qAM hLdcP1PKpgumDRK9pkgzYM4W+XC8M0rLoLzoP5GIpkjm8Fk7Lsc3gdIwTL7Dag6Swhbh eX9t32J1ALxwxI9IrLFWdu0IXymkaXFOz+y2RYjqpSbLe6JrfY8NRRDnrO10jRHCDIa3 XsSsdaUKN2VJgAZ+h+F4aEPYd9qB04zulp/w0EDAs8mld+d1w1g+ces4GJQQ6ETwvDCP A5/tqIJz/osy441w9jPLHV33S5JFW9Pb2vy6/5nK0Ipgwc+2QHlBxDP34uDRMUFdaoKe D6Mg== X-Gm-Message-State: ALyK8tKvfDEATUv753/lcDxD4i811RqRfH4seCbPvWdFq4B03i/Ygzrgtgyy7PiqyAtW2EPWETCfWq+ZeqHqDA== X-Received: by 10.55.5.144 with SMTP id 138mr4759704qkf.196.1465605498115; Fri, 10 Jun 2016 17:38:18 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.25.85 with HTTP; Fri, 10 Jun 2016 17:38:17 -0700 (PDT) From: Phillip Hallam-Baker Date: Fri, 10 Jun 2016 20:38:17 -0400 X-Google-Sender-Auth: bbhIDanH8B9Xiz2Ei0kRgWBpbaA Message-ID: To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=001a114c86ae189f210534f5df21 Archived-At: Subject: [saag] Micali's simultaneous transactions patent seems to have expired. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 00:38:20 -0000 --001a114c86ae189f210534f5df21 Content-Type: text/plain; charset=UTF-8 https://www.google.com/patents/US5666420 This was something I always thought was his best idea. --001a114c86ae189f210534f5df21 Content-Type: text/html; charset=UTF-8
https://www.google.com/patents/US5666420

This was something I always thought was his best idea.
--001a114c86ae189f210534f5df21-- From nobody Sun Jun 12 05:24:12 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAB8128E18 for ; Sun, 12 Jun 2016 05:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8eUOuFNf5Dj for ; Sun, 12 Jun 2016 05:24:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECFCD12D0CA for ; Sun, 12 Jun 2016 05:24:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 71E2BBDCF for ; Sun, 12 Jun 2016 13:24:05 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hORs7Zdp85Q0 for ; Sun, 12 Jun 2016 13:24:04 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 27311BDCC for ; Sun, 12 Jun 2016 13:24:03 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1465734244; bh=PqcFLiWFt8ekLJ4Ln3ZxfCO1srWQj3xBis446mtkrZM=; h=To:From:Subject:Date:From; b=CyyAHdl/ryqZCoVluXFzXltwD2VOSpIv2nEBW51s35VtqGNnFveCLmDL9bgVs8Wug 9NBv1CxfA2ZYQKUhwrgQaKj2BGRp/qDGhjiJTpauVnHWLLjvaB39WoPE0k9jyb5iO+ bFjPNALB0kIlByh1rbT6aw7rVU26BXocuFrfIJME= To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <575D5462.8010809@cs.tcd.ie> Date: Sun, 12 Jun 2016 13:24:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080708030309000501010603" Archived-At: Subject: [saag] SAAG slot requests for Berlin X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 12:24:10 -0000 This is a cryptographically signed message in MIME format. --------------ms080708030309000501010603 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Nearly that time again! If you'd like to make a presentation at the saag session in Berlin or have some other thing put on the agenda, please send a mail to Kathleen and I. Do please re-tx if you previously sent one and we've not chatted about it recently - I at least am very prone to not remembering everything;-) Cheers, S. --------------ms080708030309000501010603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MTIx MjI0MDJaMC8GCSqGSIb3DQEJBDEiBCBwDHXsdWlyBe+tKrTgC/QGfNPQBmGhubj57z0gmSUX ZjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQA0tp5e1HuMhXjzXLMlCCTEZhvyozcu+xWGxEV7wgDbqgQ+2qxlz/yW z5rbQbg2YwcWSYUjez3YgR57J0A2rg3tzS0gyT5YAmD2/4AEIK8Nu90NDt4uomFI0FbBZH3f KeBw12CXByZynxhvG+yQKFb37tAxG2p/acXunVHu8Wucsvz7lkwBkanWYcYv3W64pawrZaYs 72n+b+OK1CxeOFa7feukCTDzbB/i/g3H4nbn5CqE4M2NTy1UpBaLWl+ybcuXiVsZh0VqouiB sNVu3X/yVlOKv/djWML5xBfRZvXNliApl+xi2YGsQq4aZGJp32e51w5DVmdvUbIvZcacoNlS AAAAAAAA --------------ms080708030309000501010603-- From nobody Wed Jun 15 13:21:00 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EFF12DBA5 for ; Wed, 15 Jun 2016 13:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEat7j6zu85d for ; Wed, 15 Jun 2016 13:20:57 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECDCE12DB9F for ; Wed, 15 Jun 2016 13:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=881; q=dns/txt; s=iport; t=1466022056; x=1467231656; h=date:from:to:subject:message-id:mime-version; bh=IyN2dKuEX7YZnZXyz24N/pNsbYzLWgD2Lj6GIn7hdz4=; b=MWikhiIX28tg503TJ2QRFN8eYs3EmfsETTRT/LU1TqgXdOmVQCf8jKDn RNDmhaynGUOOusA831leq/sqbEaM4CK9wVzjBWF+S5fR67mdeJzz944Mf TOn23IiykoHPdsw4p8OsSfz0Typw/S45YnsIeYN7S1tJso7glu5pXGrK2 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D0AQCOt2FX/4YNJK1dgz5WuVmCD4F5I?= =?us-ascii?q?ocrOBQBAQEBAQEBZSeFDHs0BXeIFQ6eaaBFAQEIAQEBAQEdBZAAhQ8FjmWKBIY?= =?us-ascii?q?FiBoKjyACj3QeNoQPHIo6AQEB?= X-IronPort-AV: E=Sophos;i="5.26,477,1459814400"; d="scan'208";a="285413783" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jun 2016 20:20:56 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u5FKKt84016540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Jun 2016 20:20:56 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u5FKKt0N024376 for ; Wed, 15 Jun 2016 13:20:55 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u5FKKtsg024375 for saag@ietf.org; Wed, 15 Jun 2016 13:20:55 -0700 Date: Wed, 15 Jun 2016 13:20:55 -0700 From: Toerless Eckert To: saag@ietf.org Message-ID: <20160615202055.GT31598@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: Subject: [saag] SAAG: Q re. https://tools.ietf.org/html/draft-wing-quic-network-req-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 20:20:58 -0000 In Berlin there is a BOF for QUIC targeted to be WG forming. Today, QUIC does not provide the same level of flow behavior visibility to the network as TCP/HTTPs does. A lot of this visibility is used by middleboxes like firewall to provide eg: DoS protection. If QUIC would take over from TCP in the Internet and controlled networks, this would cause regression in security for which no known alternatve solutions exist AFAIK. An ask was raised for the target QUIC WG charter to discuss network-interaction/ flow visibility, but the mayority of people active in QUIC expressed a dedicated desinterest in including this topic. The problem and proposed solutions are nicely summarized in subject draft. I am wondering how any part of the security area in the IETF is interested in or would have opinions about how to deal with this problem. Cheers Toerless From nobody Wed Jun 15 14:05:57 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB1212DB9B for ; Wed, 15 Jun 2016 14:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7Ah90BvuZaM for ; Wed, 15 Jun 2016 14:05:54 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD97812D965 for ; Wed, 15 Jun 2016 14:05:53 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id d132so39464607oig.1 for ; Wed, 15 Jun 2016 14:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ak227EVtDAZsL8LDzdJvuJ0csh4wZQ3Q0rku7ilNYNI=; b=JRL0j/hCjZBptcDPdiMrPJCSwX3OWGEdyXANK6oFkhsx8NK3CyjmYdBa+sMvqlFB66 eog9DEvZG6JuXrKDvf8Zf9jnEp7BP52QgN4iJjgqeoKjXORMLcTRh8+B1t69jK2nIuNK c38PtqR7PfZcFn48/vZqJY7qqa04jlbHbixFRtla5t9jnX6Bm5PINipiGm/K1NRNZOei gUY7gkqMPTo+FrbRm00DpNbCZkQF+/xJMqLnZmxgZclc3c+GhEZOHeBgn/TLD1pjPpfL EMIMAO/70QvibaD/AOPNs6EEdzuB976fTPrc+7lVUJGzAc2nFt/P/WBqtJ1D8VmTM86B axeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ak227EVtDAZsL8LDzdJvuJ0csh4wZQ3Q0rku7ilNYNI=; b=lanePaZoT2i7pM9x5+6JlSvzj0LYBhDVmxGj30gqSPe8smtwd5RZF/+UyNDvJoivId +HHKjszfFfOCHbDwTRLlMvJ6t5u9FlvTXGu8yZ/+5rrHEdqlAQfS3EyO0p+46BH6Zvt+ bqAGaFuOiRp9brnkITFpTUJ3G2UxdPrqmakUQkkQE9RLJ/e6/4NbvrlbYfj0/fJotMH0 dnqjC22Nug6B5X37dn5wR+2FRc+TSKE5ONB3S+biBza4eby9TwrfMpRjKajRXLDAUbVw Pg2jj/lH7Sn7GCO0YiUTZyRw9YAEClT4qoaK8gPdt4vbTsNFSjc2Zaljn3qAcoRXg8si x8/w== X-Gm-Message-State: ALyK8tKa2edCIbnawJ32iig393KxbUbfkD4+7pjsgsm+JbVJQV59ymQJFWvddM3jNueV3is02JAEUtzHVBDRRQ== X-Received: by 10.157.35.111 with SMTP id k44mr518767otd.18.1466024753084; Wed, 15 Jun 2016 14:05:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Wed, 15 Jun 2016 14:05:33 -0700 (PDT) In-Reply-To: <20160615202055.GT31598@cisco.com> References: <20160615202055.GT31598@cisco.com> From: Ted Hardie Date: Wed, 15 Jun 2016 14:05:33 -0700 Message-ID: To: Toerless Eckert , Jana Iyengar Content-Type: multipart/alternative; boundary=001a113d0c28a3be170535577ce9 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] SAAG: Q re. https://tools.ietf.org/html/draft-wing-quic-network-req-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 21:05:56 -0000 --001a113d0c28a3be170535577ce9 Content-Type: text/plain; charset=UTF-8 Hi Toerless, I've cc'ed Jana, so he's aware of this message, but I also wanted to point out some of the comments Jana made to Joe and Dan on the ietf-quic list: QUIC currently has most of the QUIC header fields encrypted and > authenticated (invisible to the network), and some header fields > authenticated but not encrypted (visible to the network but tamper > resistant). The fields that are exposed have well-defined use cases --- > Connection ID, for example, is visible and can be used by load-balancers to > direct traffic belonging to a QUIC connection to the same server. I expect > that these fields will be debated and discussed in the wg, and I think > these considerations will be quite helpful when that conversation is > underway. It'll be good to identify precisely which fields of QUIC that > aren't currently exposed should be exposed (or vice versa), to have a > debate in more concrete terms. > A lot the issues raised in the draft can already be handled by a box that understands QUIC's format (in fact, using the Connection ID allows you to scope consent better than a 5-tuple based would), but not many boxes do yet. Hopefully, if we do get the WG approved and the formats standardized, that number will go up. I understand Joe is also concerned about ossification of the format around early versions, so I'd encourage folks interested in this from a middlebox point of view to continue to treat this as evolving. regards, Ted On Wed, Jun 15, 2016 at 1:20 PM, Toerless Eckert wrote: > In Berlin there is a BOF for QUIC targeted to be WG forming. Today, QUIC > does not provide the same level of flow behavior visibility to the network > as TCP/HTTPs does. A lot of this visibility is used by middleboxes like > firewall to provide eg: DoS protection. If QUIC would take over from TCP > in the Internet and controlled networks, this would cause regression in > security for which no known alternatve solutions exist AFAIK. > > An ask was raised for the target QUIC WG charter to discuss > network-interaction/ > flow visibility, but the mayority of people active in QUIC expressed a > dedicated > desinterest in including this topic. > > The problem and proposed solutions are nicely summarized in subject draft. > > I am wondering how any part of the security area in the IETF is interested > in or would have opinions about how to deal with this problem. > > Cheers > Toerless > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a113d0c28a3be170535577ce9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Toerles= s,

I've cc'ed Jana, so he's aware of this message,= but I also wanted to point out some of the comments Jana made to Joe and D= an on the ietf-quic list:

QUIC currently has most of the QUIC header fields encrypted a= nd authenticated (invisible to the network), and some header fields authent= icated but not encrypted (visible to the network but tamper resistant). The= fields that are exposed have well-defined use cases --- Connection ID, for= example, is visible and can be used by load-balancers to direct traffic be= longing to a QUIC connection to the same server. I expect that these fields= will be debated and discussed in the wg, and I think these considerations = will be quite helpful when that conversation is underway. It'll be good= to identify precisely which fields of QUIC that aren't currently expos= ed should be exposed (or vice versa), to have a debate in more concrete ter= ms. =C2=A0

A lot the issues raised in the draft can already be handle= d by a box that understands QUIC's format (in fact, using the Connectio= n ID allows you to scope consent better than a 5-tuple based would), but no= t many boxes do yet.=C2=A0 Hopefully, if we do get the WG approved and the = formats standardized, that number will go up.=C2=A0=C2=A0

I underst= and Joe is also concerned about ossification of the format around early ver= sions, so I'd encourage folks interested in this from a middlebox point= of view to continue to treat this as evolving.

regards,

Ted
=



On Wed, J= un 15, 2016 at 1:20 PM, Toerless Eckert <eckert@cisco.com> wr= ote:
In Berlin there is a BOF for QUIC ta= rgeted to be WG forming. Today, QUIC
does not provide the same level of flow behavior visibility to the network<= br> as TCP/HTTPs does. A lot of this visibility is used by middleboxes like
firewall to provide eg: DoS protection. If QUIC would take over from TCP in the Internet and controlled networks, this would cause regression in
security for which no known alternatve solutions exist AFAIK.

An ask was raised for the target QUIC WG charter to discuss network-interac= tion/
flow visibility, but the mayority of people active in QUIC expressed a dedi= cated
desinterest in including this topic.

The problem and proposed solutions are nicely summarized in subject draft.<= br>
I am wondering how any part of the security area in the IETF is interested<= br> in or would have opinions about how to deal with this problem.

Cheers
=C2=A0 =C2=A0 Toerless

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

--001a113d0c28a3be170535577ce9-- From nobody Wed Jun 15 14:46:39 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C9A12DBFB for ; Wed, 15 Jun 2016 14:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqLLN0G0U2Qn for ; Wed, 15 Jun 2016 14:46:35 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90AB512DBFA for ; Wed, 15 Jun 2016 14:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3344; q=dns/txt; s=iport; t=1466027195; x=1467236795; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=QzljEQ3jHXp0XQQk/jyKmwYwqgYEwPr+HFcq1PqaUcI=; b=SnHmu+8ugG4VZuMTnp+GL7YNHCa7MHMNUXkP9Oe4bkpBHv79xoEyieem gnCWnBCynh6zVZEAdJVZrIa8+/u/UAlDrB4pBVoC5wqTkkmLThzIJRKFs riomKIywOGY7HMySGYE2kDUBErLlA2KBAKZ/6AJ+WhzGoqgycqPw1uHwC 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgB2y2FX/4oNJK1TCoM+Vn26bYF6F?= =?us-ascii?q?wuFdQKBNDgUAQEBAQEBAWUnhEsBAQEDAQEBATcrCQsFCwsYCSUPBRM2ExuIDQg?= =?us-ascii?q?Ov0UBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYp0hBgShXEFjmWKBIYFiBoKjyKPd?= =?us-ascii?q?B42gjqBVRwyiggBAQE?= X-IronPort-AV: E=Sophos;i="5.26,477,1459814400"; d="scan'208";a="286193995" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jun 2016 21:46:34 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u5FLkYvw006771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2016 21:46:34 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u5FLkXRr001479; Wed, 15 Jun 2016 14:46:33 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u5FLkXi0001478; Wed, 15 Jun 2016 14:46:33 -0700 Date: Wed, 15 Jun 2016 14:46:33 -0700 From: Toerless Eckert To: Ted Hardie Message-ID: <20160615214633.GY31598@cisco.com> References: <20160615202055.GT31598@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Jana Iyengar , "saag@ietf.org" Subject: Re: [saag] SAAG: Q re. https://tools.ietf.org/html/draft-wing-quic-network-req-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 21:46:37 -0000 Thanks, Ted, Inline On Wed, Jun 15, 2016 at 02:05:33PM -0700, Ted Hardie wrote: > I've cc'ed Jana, so he's aware of this message, but I also wanted to point > out some of the comments Jana made to Joe and Dan on the ietf-quic list: > > QUIC currently has most of the QUIC header fields encrypted and > > authenticated (invisible to the network), and some header fields > > authenticated but not encrypted (visible to the network but tamper > > resistant). The fields that are exposed have well-defined use cases --- > > Connection ID, for example, is visible and can be used by load-balancers to > > direct traffic belonging to a QUIC connection to the same server. I expect > > that these fields will be debated and discussed in the wg, and I think > > these considerations will be quite helpful when that conversation is > > underway. It'll be good to identify precisely which fields of QUIC that > > aren't currently exposed should be exposed (or vice versa), to have a > > debate in more concrete terms. > > > > A lot the issues raised in the draft can already be handled by a box that > understands QUIC's format (in fact, using the Connection ID allows you to > scope consent better than a 5-tuple based would), but not many boxes do > yet. Hopefully, if we do get the WG approved and the formats standardized, > that number will go up. Would it not be fair to have the working group charted to discuss/analyze those type of statements instead of assuming them to be resolved by declaration ? Thats effectively what the ask was against the charter. > I understand Joe is also concerned about ossification of the format around > early versions, so I'd encourage folks interested in this from a middlebox > point of view to continue to treat this as evolving. Good point. Yes, if QUIC is intentional or unintental hostile to middleboxes by repeat change of middlebox relevant parts of its signature then this does introduce an ongoing problem for middleboxes trying to secure the network. Cheers Toerless > > regards, > > Ted > > > > On Wed, Jun 15, 2016 at 1:20 PM, Toerless Eckert wrote: > > > In Berlin there is a BOF for QUIC targeted to be WG forming. Today, QUIC > > does not provide the same level of flow behavior visibility to the network > > as TCP/HTTPs does. A lot of this visibility is used by middleboxes like > > firewall to provide eg: DoS protection. If QUIC would take over from TCP > > in the Internet and controlled networks, this would cause regression in > > security for which no known alternatve solutions exist AFAIK. > > > > An ask was raised for the target QUIC WG charter to discuss > > network-interaction/ > > flow visibility, but the mayority of people active in QUIC expressed a > > dedicated > > desinterest in including this topic. > > > > The problem and proposed solutions are nicely summarized in subject draft. > > > > I am wondering how any part of the security area in the IETF is interested > > in or would have opinions about how to deal with this problem. > > > > Cheers > > Toerless > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > -- --- Toerless Eckert, eckert@cisco.com From nobody Wed Jun 15 15:04:21 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663B912D0A9 for ; Wed, 15 Jun 2016 15:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhP1VGn_jEAe for ; Wed, 15 Jun 2016 15:04:18 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE3612D953 for ; Wed, 15 Jun 2016 15:04:17 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id p204so41467028oih.3 for ; Wed, 15 Jun 2016 15:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Uvtr3Ppxm7kX0XB/xGZATezhj1SRIsJ7sftpF7rj1X0=; b=NjLsh7/AmiS9ObtcVFD1Xg54Tz8Op8xcCKFXcjHbt4T7J1lI284Soxryz1Fu+KuTak tRi2/0WjvtZP73bSGrOHLFoi+edYgrIxO5ydgW1EUHYC3kjIG2u50mCk4BJMQMJ17Uuq BPw/UyxATy3QlgHAZLxNu5yzMNNVsWgu+HjXo2DV5pnfUy+UMGk+6szdVsaaZsO57LuZ k+dp593/WMBxwwo/D3GlOP/sAVTx9EnCsYJCzQ49dB2SbiCyrV1fVheHQRi64CMrgdP5 ZsncNi+jV+TwOGYv8Bu7rwIDyQet7sSMrCFGxwandQ1nymqGh9Pw3q0yRm0r+WuKCMot S/vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Uvtr3Ppxm7kX0XB/xGZATezhj1SRIsJ7sftpF7rj1X0=; b=MDvRmdd2O5HeErd8vVI0svVJazTBQjbLmG/g0GUrfp3NEMpgExKzXsZ3RxRESDSEtB qrKUSv6z5YLRVCrLjtdAftanQwFNBRTUMjxp/3UE2aeswaiBVhfXTUjghQ42iNHrauiT 3nqRH1Gg+wT+mHr64lqQp+V96H/nZEl12TiHiasBJweNW9ovDkfbIPRcaiAQ46Xu0Of8 54REX8+IhKiNhGrqm2Y8ydZl8n8ufMghTA1EahwaNu/wV1ibXHjlDgJAX9vIztBsiXWa n0Tz8uIhMqBCzFnggoHCHOzw32n18b0i+tTUcit1MuRMt2HpM2L7neKsbwAER/PKHfF6 bzSg== X-Gm-Message-State: ALyK8tJ7kzBIH/srouPVmq3GkdtJxdzUlWzvCMmj/N3jzhAUhweMTXLHuKdKykLJ+cDfVfmyA/UCe+KgMIFXxg== X-Received: by 10.157.58.52 with SMTP id j49mr686747otc.118.1466028257269; Wed, 15 Jun 2016 15:04:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Wed, 15 Jun 2016 15:03:57 -0700 (PDT) In-Reply-To: <20160615214633.GY31598@cisco.com> References: <20160615202055.GT31598@cisco.com> <20160615214633.GY31598@cisco.com> From: Ted Hardie Date: Wed, 15 Jun 2016 15:03:57 -0700 Message-ID: To: Toerless Eckert Content-Type: multipart/alternative; boundary=001a11471a08815cc20535584d09 Archived-At: Cc: Jana Iyengar , "saag@ietf.org" Subject: Re: [saag] SAAG: Q re. https://tools.ietf.org/html/draft-wing-quic-network-req-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 22:04:20 -0000 --001a11471a08815cc20535584d09 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 15, 2016 at 2:46 PM, Toerless Eckert wrote: > > Thanks, Ted, > > > A lot the issues raised in the draft can already be handled by a box that > > understands QUIC's format (in fact, using the Connection ID allows you to > > scope consent better than a 5-tuple based would), but not many boxes do > > yet. Hopefully, if we do get the WG approved and the formats > standardized, > > that number will go up. > > Would it not be fair to have the working group charted to discuss/analyze > those > type of statements instead of assuming them to be resolved by declaration ? > Thats effectively what the ask was against the charter. > > Howdy, As Jana's message points out, the ideal would be to discuss them in concrete terms when we're talking about a specific protocol. I think Joe and Dan have made a stab at requirements that are more general than QUIC, but QUIC has to answer those requirements with bits on the wire. The working group will, of course, be deciding what the bits on the wire are. regards, Ted > > I understand Joe is also concerned about ossification of the format > around > > early versions, so I'd encourage folks interested in this from a > middlebox > > point of view to continue to treat this as evolving. > > Good point. Yes, if QUIC is intentional or unintental hostile to > middleboxes > by repeat change of middlebox relevant parts of its signature then this > does > introduce an ongoing problem for middleboxes trying to secure the network. > > Cheers > Toerless > > > > regards, > > > > Ted > > > > > > > > On Wed, Jun 15, 2016 at 1:20 PM, Toerless Eckert > wrote: > > > > > In Berlin there is a BOF for QUIC targeted to be WG forming. Today, > QUIC > > > does not provide the same level of flow behavior visibility to the > network > > > as TCP/HTTPs does. A lot of this visibility is used by middleboxes like > > > firewall to provide eg: DoS protection. If QUIC would take over from > TCP > > > in the Internet and controlled networks, this would cause regression in > > > security for which no known alternatve solutions exist AFAIK. > > > > > > An ask was raised for the target QUIC WG charter to discuss > > > network-interaction/ > > > flow visibility, but the mayority of people active in QUIC expressed a > > > dedicated > > > desinterest in including this topic. > > > > > > The problem and proposed solutions are nicely summarized in subject > draft. > > > > > > I am wondering how any part of the security area in the IETF is > interested > > > in or would have opinions about how to deal with this problem. > > > > > > Cheers > > > Toerless > > > > > > _______________________________________________ > > > saag mailing list > > > saag@ietf.org > > > https://www.ietf.org/mailman/listinfo/saag > > > > > -- > --- > Toerless Eckert, eckert@cisco.com > --001a11471a08815cc20535584d09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 15, 2016 at 2:46 PM, Toerless Eckert <eckert@c= isco.com> wrote:

Thanks, Ted,

> A lot the issues raised in the draft can already be handled by a box t= hat
> understands QUIC's format (in fact, using the Connection ID allows= you to
> scope consent better than a 5-tuple based would), but not many boxes d= o
> yet.=C2=A0 Hopefully, if we do get the WG approved and the formats sta= ndardized,
> that number will go up.

Would it not be fair to have the working group charted to discuss/an= alyze those
type of statements instead of assuming them to be resolved by declaration ?=
Thats effectively what the ask was against the charter.

Howdy,

As J= ana's message points out, the ideal would be to discuss them in concret= e terms when we're talking about a specific protocol.=C2=A0 I think Joe= and Dan have made a stab at requirements that are more general than QUIC, = but QUIC has to answer those requirements with bits on the wire.=C2=A0 The = working group will, of course, be deciding what the bits on the wire are.
regards,

Ted

=C2=A0
> I understand Joe is also concerned about ossification of the format ar= ound
> early versions, so I'd encourage folks interested in this from a m= iddlebox
> point of view to continue to treat this as evolving.

Good point. Yes, if QUIC is intentional or unintental hostile to mid= dleboxes
by repeat change of middlebox relevant parts of its signature then this doe= s
introduce an ongoing problem for middleboxes trying to secure the network.<= br>
Cheers
=C2=A0 =C2=A0Toerless
>
> regards,
>
> Ted
>
>
>
> On Wed, Jun 15, 2016 at 1:20 PM, Toerless Eckert <eckert@cisco.com> wrote:
>
> > In Berlin there is a BOF for QUIC targeted to be WG forming. Toda= y, QUIC
> > does not provide the same level of flow behavior visibility to th= e network
> > as TCP/HTTPs does. A lot of this visibility is used by middleboxe= s like
> > firewall to provide eg: DoS protection. If QUIC would take over f= rom TCP
> > in the Internet and controlled networks, this would cause regress= ion in
> > security for which no known alternatve solutions exist AFAIK.
> >
> > An ask was raised for the target QUIC WG charter to discuss
> > network-interaction/
> > flow visibility, but the mayority of people active in QUIC expres= sed a
> > dedicated
> > desinterest in including this topic.
> >
> > The problem and proposed solutions are nicely summarized in subje= ct draft.
> >
> > I am wondering how any part of the security area in the IETF is i= nterested
> > in or would have opinions about how to deal with this problem. > >
> > Cheers
> >=C2=A0 =C2=A0 =C2=A0Toerless
> >
> > _______________________________________________
> > saag mailing list
> > saag@ietf.org
> > https://www.ietf.org/mailman/listinfo/saag > >

--
---
Toerless Eckert, eckert@cisco.com

--001a11471a08815cc20535584d09-- From nobody Wed Jun 15 15:11:15 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AE412D8F1 for ; Wed, 15 Jun 2016 15:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3_l1cfdzS0W for ; Wed, 15 Jun 2016 15:11:11 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97DED12D7D1 for ; Wed, 15 Jun 2016 15:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2819; q=dns/txt; s=iport; t=1466028671; x=1467238271; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=nG9a7FuZEUeSM5EAhYcb6RYb2DyYxYgRnnwDPO5U9FY=; b=d1YYCMLVbAJcr0wXkg6xshsNDVw6VnVo6bOX5l7fU4EJvzyDYUBDIuTW sFyygZEXuz60ztginHfzHWdRsy/ejynEJKDPyfhaj8n0vf3352TX6BK// Rde4MoBv1EDTQ+wu5TNtjKRHL4o1PS0jtBNV/8Mv5Po12L5MvELhKwb26 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgCO0WFX/5RdJa1dgz5WfbptgXoXC?= =?us-ascii?q?4V1AoE0OBQBAQEBAQEBZSeETAEBBAEBATc0CxALGAklDwUTNhMbiBUOvz4BAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEXBYp0h2yCLwWIEIZVigSGBYgaCo8ij3QeNoI6g?= =?us-ascii?q?VUcMooIAQEB?= X-IronPort-AV: E=Sophos;i="5.26,477,1459814400"; d="scan'208";a="119108437" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2016 22:11:10 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u5FMBAs5015127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2016 22:11:10 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u5FMB8IE005662; Wed, 15 Jun 2016 15:11:09 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u5FMB8Ku005659; Wed, 15 Jun 2016 15:11:08 -0700 Date: Wed, 15 Jun 2016 15:11:08 -0700 From: Toerless Eckert To: Ted Hardie Message-ID: <20160615221108.GB31598@cisco.com> References: <20160615202055.GT31598@cisco.com> <20160615214633.GY31598@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Jana Iyengar , "saag@ietf.org" Subject: Re: [saag] SAAG: Q re. https://tools.ietf.org/html/draft-wing-quic-network-req-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 22:11:13 -0000 Thanks, Ted On Wed, Jun 15, 2016 at 03:03:57PM -0700, Ted Hardie wrote: > As Jana's message points out, the ideal would be to discuss them in > concrete terms when we're talking about a specific protocol. I think Joe > and Dan have made a stab at requirements that are more general than QUIC, > but QUIC has to answer those requirements with bits on the wire. The > working group will, of course, be deciding what the bits on the wire are. If the working group does not want to acknowledge in the charter the need to be at least on par with TCP when it comes to eg: enabling firewall protection, then there is little chance of getting to the level of discussing the bits required to do that, right ? Cheers Toerless > > regards, > > Ted > > > > > > I understand Joe is also concerned about ossification of the format > > around > > > early versions, so I'd encourage folks interested in this from a > > middlebox > > > point of view to continue to treat this as evolving. > > > > Good point. Yes, if QUIC is intentional or unintental hostile to > > middleboxes > > by repeat change of middlebox relevant parts of its signature then this > > does > > introduce an ongoing problem for middleboxes trying to secure the network. > > > > Cheers > > Toerless > > > > > > regards, > > > > > > Ted > > > > > > > > > > > > On Wed, Jun 15, 2016 at 1:20 PM, Toerless Eckert > > wrote: > > > > > > > In Berlin there is a BOF for QUIC targeted to be WG forming. Today, > > QUIC > > > > does not provide the same level of flow behavior visibility to the > > network > > > > as TCP/HTTPs does. A lot of this visibility is used by middleboxes like > > > > firewall to provide eg: DoS protection. If QUIC would take over from > > TCP > > > > in the Internet and controlled networks, this would cause regression in > > > > security for which no known alternatve solutions exist AFAIK. > > > > > > > > An ask was raised for the target QUIC WG charter to discuss > > > > network-interaction/ > > > > flow visibility, but the mayority of people active in QUIC expressed a > > > > dedicated > > > > desinterest in including this topic. > > > > > > > > The problem and proposed solutions are nicely summarized in subject > > draft. > > > > > > > > I am wondering how any part of the security area in the IETF is > > interested > > > > in or would have opinions about how to deal with this problem. > > > > > > > > Cheers > > > > Toerless > > > > > > > > _______________________________________________ > > > > saag mailing list > > > > saag@ietf.org > > > > https://www.ietf.org/mailman/listinfo/saag > > > > > > > > -- > > --- > > Toerless Eckert, eckert@cisco.com > > -- --- Toerless Eckert, eckert@cisco.com From nobody Wed Jun 15 15:30:16 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4FA12D581 for ; Wed, 15 Jun 2016 15:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YXsv0j7m14P for ; Wed, 15 Jun 2016 15:30:12 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 506DB12D56E for ; Wed, 15 Jun 2016 15:30:12 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id w5so42351033oib.2 for ; Wed, 15 Jun 2016 15:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aU0kHbEEWuUe2K6eRQIF2k8w0mGGrA+85u+1xT3gUNw=; b=oRA/kbHhKSxAHTlweat2E8ukQmf+HN8yRMoU5TL4ZXOKHeZAsHjsqhRrdr2Ot/P5eB GvyAH6QFH97x4TxBf3JBuJ1/KPktX3PEtS0VVbIw+Lxfh/53hwUEwuIO1fLmxJfzxUQZ H9xA+4bv43dGCoj6FvYSRE+WgE5njsHEHNItmhJNbOukQIF7EU2ZmLrkDppcGrjppGYt llnL8EDUJsaofXL+DK+frUArZBpJqE1iwvoQ4vLNWX0mGtDfzm52Z31x7+V4t4kTQQDT MtwPwmHDBzpjpsWR6tvV3IYvbpI+jCdnSPWvxjQybCLYlDP5w3MoWh3K7wL4dtcaj0qQ Y9rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aU0kHbEEWuUe2K6eRQIF2k8w0mGGrA+85u+1xT3gUNw=; b=MuK9XEQvkU6L/m7HCCfcIbKiCMLaptTQzrbgi4vLcmPvmt5vWQPKy9vPokKPSDLhHS kZoLW/wBrsVjjE/L+HDZ/5pWmEZbyod1p7QlrvYpZcCTVd9S95rZbbUN7IIRZ5uL2TlC 2JDs/BSZ+ukb5AIiH1lpHsMxrLXG5ht/dm05wSDA/mZtLyHVlZOHA6yIzUg7jwBCn202 nxB2N4J5vHgvTz6BJo1KNLVbvsgSoAgHhOnfSHx4dUkHb/vcS5hmd6qjBMCw0krr462e Kr6ZUMoXRHFlgFKqGk/ROTDDQmqO8MgDgchNDOIpf5+kvY5nUHxu1nOlBLLfxygjE2wx 8b7A== X-Gm-Message-State: ALyK8tKjXfsPDG7MkGTUKinooh+HKVK4vadVKhs5eRA1pWIRBm8R6SOe2qBK2wx917E/PLF/SmBdXOcbxPDYRA== X-Received: by 10.157.35.111 with SMTP id k44mr754533otd.18.1466029811540; Wed, 15 Jun 2016 15:30:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Wed, 15 Jun 2016 15:29:52 -0700 (PDT) In-Reply-To: <20160615221108.GB31598@cisco.com> References: <20160615202055.GT31598@cisco.com> <20160615214633.GY31598@cisco.com> <20160615221108.GB31598@cisco.com> From: Ted Hardie Date: Wed, 15 Jun 2016 15:29:52 -0700 Message-ID: To: Toerless Eckert Content-Type: multipart/alternative; boundary=001a113d0c2825aa89053558aa7e Archived-At: Cc: Jana Iyengar , "saag@ietf.org" Subject: Re: [saag] SAAG: Q re. https://tools.ietf.org/html/draft-wing-quic-network-req-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 22:30:14 -0000 --001a113d0c2825aa89053558aa7e Content-Type: text/plain; charset=UTF-8 On Wed, Jun 15, 2016 at 3:11 PM, Toerless Eckert wrote: > Thanks, Ted > > > If the working group does not want to acknowledge in the charter the need > to > be at least on par with TCP when it comes to eg: enabling firewall > protection, then > there is little chance of getting to the level of discussing the bits > required to > do that, right ? > > I'm not sure that "on par with TCP" is the right bar to set here. QUIC offers facilities that are not quite the same as TCP's, and those may get used in ways that differ from TCP's. This isn't about hostility to anyone; it's about the trade-offs that need to be made. The working group will make those trade-offs (if it is chartered, obviously) and express them as bits on the wire. regards, Ted Cheers > Toerless > > > > regards, > > > > Ted > > > > > > > > > > I understand Joe is also concerned about ossification of the format > > > around > > > > early versions, so I'd encourage folks interested in this from a > > > middlebox > > > > point of view to continue to treat this as evolving. > > > > > > Good point. Yes, if QUIC is intentional or unintental hostile to > > > middleboxes > > > by repeat change of middlebox relevant parts of its signature then this > > > does > > > introduce an ongoing problem for middleboxes trying to secure the > network. > > > > > > Cheers > > > Toerless > > > > > > > > regards, > > > > > > > > Ted > > > > > > > > > > > > > > > > On Wed, Jun 15, 2016 at 1:20 PM, Toerless Eckert > > > wrote: > > > > > > > > > In Berlin there is a BOF for QUIC targeted to be WG forming. Today, > > > QUIC > > > > > does not provide the same level of flow behavior visibility to the > > > network > > > > > as TCP/HTTPs does. A lot of this visibility is used by middleboxes > like > > > > > firewall to provide eg: DoS protection. If QUIC would take over > from > > > TCP > > > > > in the Internet and controlled networks, this would cause > regression in > > > > > security for which no known alternatve solutions exist AFAIK. > > > > > > > > > > An ask was raised for the target QUIC WG charter to discuss > > > > > network-interaction/ > > > > > flow visibility, but the mayority of people active in QUIC > expressed a > > > > > dedicated > > > > > desinterest in including this topic. > > > > > > > > > > The problem and proposed solutions are nicely summarized in subject > > > draft. > > > > > > > > > > I am wondering how any part of the security area in the IETF is > > > interested > > > > > in or would have opinions about how to deal with this problem. > > > > > > > > > > Cheers > > > > > Toerless > > > > > > > > > > _______________________________________________ > > > > > saag mailing list > > > > > saag@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/saag > > > > > > > > > > > -- > > > --- > > > Toerless Eckert, eckert@cisco.com > > > > > -- > --- > Toerless Eckert, eckert@cisco.com > --001a113d0c2825aa89053558aa7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 15, 2016 at 3:11 PM, Toerless Eckert <eckert@c= isco.com> wrote:
Thanks, Ted<= br>

If the working group does not want to acknowledge in the charter the= need to
be at least on par with TCP when it comes to eg: enabling firewall protecti= on, then
there is little chance of getting to the level of discussing the bits requi= red to
do that, right ?


I'm not sure that "on par wit= h TCP" is the right bar to set here.=C2=A0 QUIC offers facilities that= are not quite the same as TCP's, and those may get used in ways that d= iffer from TCP's.=C2=A0 This isn't about hostility to anyone; it= 9;s about the trade-offs that need to be made.=C2=A0 The working group will= make those trade-offs (if it is chartered, obviously) and express them as = bits on the wire.

regards,

Ted

<= /div>

Cheers
=C2=A0 =C2=A0 Toerless
>
> regards,
>
> Ted
>
>
>
> > > I understand Joe is also concerned about ossification of the= format
> > around
> > > early versions, so I'd encourage folks interested in thi= s from a
> > middlebox
> > > point of view to continue to treat this as evolving.
> >
> > Good point. Yes, if QUIC is intentional or unintental hostile to<= br> > > middleboxes
> > by repeat change of middlebox relevant parts of its signature the= n this
> > does
> > introduce an ongoing problem for middleboxes trying to secure the= network.
> >
> > Cheers
> >=C2=A0 =C2=A0 Toerless
> > >
> > > regards,
> > >
> > > Ted
> > >
> > >
> > >
> > > On Wed, Jun 15, 2016 at 1:20 PM, Toerless Eckert <eckert@cisco.com>
> > wrote:
> > >
> > > > In Berlin there is a BOF for QUIC targeted to be WG for= ming. Today,
> > QUIC
> > > > does not provide the same level of flow behavior visibi= lity to the
> > network
> > > > as TCP/HTTPs does. A lot of this visibility is used by = middleboxes like
> > > > firewall to provide eg: DoS protection. If QUIC would t= ake over from
> > TCP
> > > > in the Internet and controlled networks, this would cau= se regression in
> > > > security for which no known alternatve solutions exist = AFAIK.
> > > >
> > > > An ask was raised for the target QUIC WG charter to dis= cuss
> > > > network-interaction/
> > > > flow visibility, but the mayority of people active in Q= UIC expressed a
> > > > dedicated
> > > > desinterest in including this topic.
> > > >
> > > > The problem and proposed solutions are nicely summarize= d in subject
> > draft.
> > > >
> > > > I am wondering how any part of the security area in the= IETF is
> > interested
> > > > in or would have opinions about how to deal with this p= roblem.
> > > >
> > > > Cheers
> > > >=C2=A0 =C2=A0 =C2=A0Toerless
> > > >
> > > > _______________________________________________
> > > > saag mailing list
> > > > saag@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/= saag
> > > >
> >
> > --
> > ---
> > Toerless Eckert, eckert@cisco= .com
> >

--
---
Toerless Eckert, eckert@cisco.com

--001a113d0c2825aa89053558aa7e-- From nobody Wed Jun 15 16:24:56 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CD212D834 for ; Wed, 15 Jun 2016 16:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIln2sN-QJnt for ; Wed, 15 Jun 2016 16:24:53 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4C812D7EA for ; Wed, 15 Jun 2016 16:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3657; q=dns/txt; s=iport; t=1466033093; x=1467242693; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=QYh2WV+g29k6+nVIM3e1rVUN8mfO05oJmL2MVcMlfPY=; b=EvZR5i//1qtGRZtOadCUsSgoLjoC1DmyBUGGybsjmUYbbsSNQz/1l5XE DaCG9z0reAE6evS0xSXxdmNLxpV3t/VrM1PXQnMAFEzLISEFJirvbCfhV 16mJKQWcKtQB+SIzYlbZ3vxjZtUHgFE+NTn5QT31JKjsAv2IGAxS9CHQE M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgAM42FX/5JdJa1dgz5WfbpsgXoXC?= =?us-ascii?q?4V1AoEuOBQBAQEBAQEBZSeETAEBBAEBATc0CxALGAklDwUTNhMbiBUOv0YBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEXBYp0h2yCLwWIEIZVigSGBYgaCo8ij3QeNoI6g?= =?us-ascii?q?VUcMooIAQEB?= X-IronPort-AV: E=Sophos;i="5.26,478,1459814400"; d="scan'208";a="284640945" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2016 23:24:52 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u5FNOpqV019013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2016 23:24:52 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u5FNOpgv008863; Wed, 15 Jun 2016 16:24:51 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u5FNOpbt008862; Wed, 15 Jun 2016 16:24:51 -0700 Date: Wed, 15 Jun 2016 16:24:51 -0700 From: Toerless Eckert To: Ted Hardie Message-ID: <20160615232451.GD31598@cisco.com> References: <20160615202055.GT31598@cisco.com> <20160615214633.GY31598@cisco.com> <20160615221108.GB31598@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] SAAG: Q re. https://tools.ietf.org/html/draft-wing-quic-network-req-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 23:24:55 -0000 Thanks Ted I still do not understand why you would not approve of a statement for the WG charter wrt. to reviewing the interaction (implicit) between QUIC and middleboxes, eg: compare with TCP and explicitly weigh security vs. functionality benefits. Cheers Toerless On Wed, Jun 15, 2016 at 03:29:52PM -0700, Ted Hardie wrote: > On Wed, Jun 15, 2016 at 3:11 PM, Toerless Eckert wrote: > > > Thanks, Ted > > > > > > If the working group does not want to acknowledge in the charter the need > > to > > be at least on par with TCP when it comes to eg: enabling firewall > > protection, then > > there is little chance of getting to the level of discussing the bits > > required to > > do that, right ? > > > > > I'm not sure that "on par with TCP" is the right bar to set here. QUIC > offers facilities that are not quite the same as TCP's, and those may get > used in ways that differ from TCP's. This isn't about hostility to anyone; > it's about the trade-offs that need to be made. The working group will > make those trade-offs (if it is chartered, obviously) and express them as > bits on the wire. > > regards, > > Ted > > > Cheers > > Toerless > > > > > > regards, > > > > > > Ted > > > > > > > > > > > > > > I understand Joe is also concerned about ossification of the format > > > > around > > > > > early versions, so I'd encourage folks interested in this from a > > > > middlebox > > > > > point of view to continue to treat this as evolving. > > > > > > > > Good point. Yes, if QUIC is intentional or unintental hostile to > > > > middleboxes > > > > by repeat change of middlebox relevant parts of its signature then this > > > > does > > > > introduce an ongoing problem for middleboxes trying to secure the > > network. > > > > > > > > Cheers > > > > Toerless > > > > > > > > > > regards, > > > > > > > > > > Ted > > > > > > > > > > > > > > > > > > > > On Wed, Jun 15, 2016 at 1:20 PM, Toerless Eckert > > > > wrote: > > > > > > > > > > > In Berlin there is a BOF for QUIC targeted to be WG forming. Today, > > > > QUIC > > > > > > does not provide the same level of flow behavior visibility to the > > > > network > > > > > > as TCP/HTTPs does. A lot of this visibility is used by middleboxes > > like > > > > > > firewall to provide eg: DoS protection. If QUIC would take over > > from > > > > TCP > > > > > > in the Internet and controlled networks, this would cause > > regression in > > > > > > security for which no known alternatve solutions exist AFAIK. > > > > > > > > > > > > An ask was raised for the target QUIC WG charter to discuss > > > > > > network-interaction/ > > > > > > flow visibility, but the mayority of people active in QUIC > > expressed a > > > > > > dedicated > > > > > > desinterest in including this topic. > > > > > > > > > > > > The problem and proposed solutions are nicely summarized in subject > > > > draft. > > > > > > > > > > > > I am wondering how any part of the security area in the IETF is > > > > interested > > > > > > in or would have opinions about how to deal with this problem. > > > > > > > > > > > > Cheers > > > > > > Toerless > > > > > > > > > > > > _______________________________________________ > > > > > > saag mailing list > > > > > > saag@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/saag > > > > > > > > > > > > > > -- > > > > --- > > > > Toerless Eckert, eckert@cisco.com > > > > > > > > -- > > --- > > Toerless Eckert, eckert@cisco.com > > -- --- Toerless Eckert, eckert@cisco.com From nobody Wed Jun 15 16:51:43 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E9912D9C2 for ; Wed, 15 Jun 2016 16:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kV3vnaCbsbvU for ; Wed, 15 Jun 2016 16:51:36 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8D512D9C9 for ; Wed, 15 Jun 2016 16:51:35 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id v137so28527562ywa.3 for ; Wed, 15 Jun 2016 16:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3ksE8m+bqUjWK/SuBP6jEU5RxXNmluyVGVc6vMerDTU=; b=pqEBPoCVWqFQs+rHPf16Yq2CpC2Wi4rDcMD+dZ6sK4yjs2JEYteyN7Zfrdgb25+D3v DtJKxsMZa+tTmDQBnBfvhrj0W4cS7gdo8/vdRvRNSBFx4Z9hntDPaxuZYnGsAc/uBXus 9wNML5uVm9jIbfkfi+jyp/hyf4mqOT8h5uP2z2uFFd7c5Hn2XAPGczN5PjznPiAOCtwr MLDcC9LYj3xc0M/9eGTDw6Wa8RbpKuYS63zgv+9lXFFDlGa65JbkcnQatA2euTOFLPIj zYO8akXpGWj8jAZqjivGfcmiT7KA/FNx4JJL/hNH0c9grH3bkjgq/z5rYqy2jhtdg8eW PEpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3ksE8m+bqUjWK/SuBP6jEU5RxXNmluyVGVc6vMerDTU=; b=g3oDbWqLj7iU2A+J9INv84OQCv7S0YkLxu4Z3VV1DAK280OdF+NskqJlZDuEMq3HL8 4bwpqooWF7w1em0+ozLjItmNkfUmfqfTeLeERw3XQ42aWhhMRMeC8IZVSVyRsxlxG++O YWzh7DUciG5TON+HDrktVYZKQNDlL+YzrywCBTanCQo852tUOJliWokozPHdy5azE6vm OA6ChrfC0NZxZxQQq2z+y3SyjB5GEqqWTWtF2K2GNyBD+udgnPx+uk+cZBFkF9zehPUv WGUITNguYoH/mWvaT+pxbSYom9gjRwFsI4uQeZ6EuFuIoVuKYCmURMi58ok+YREDVqK1 MyLw== X-Gm-Message-State: ALyK8tLt8zSaJncYy4Ny9nhh9xjgN4PAIlvYIe4TVGQZfz1jbu69q53/I0MnMydIz6O0INHYusBCPIYNNfj35jjn X-Received: by 10.129.72.12 with SMTP id v12mr1027329ywa.110.1466034694698; Wed, 15 Jun 2016 16:51:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.224.136 with HTTP; Wed, 15 Jun 2016 16:51:34 -0700 (PDT) In-Reply-To: References: <20160615202055.GT31598@cisco.com> <20160615214633.GY31598@cisco.com> <20160615221108.GB31598@cisco.com> From: Jana Iyengar Date: Wed, 15 Jun 2016 16:51:34 -0700 Message-ID: To: Ted Hardie Content-Type: multipart/alternative; boundary=001a114ddbac3521df053559cd72 Archived-At: Cc: Toerless Eckert , "saag@ietf.org" Subject: Re: [saag] SAAG: Q re. https://tools.ietf.org/html/draft-wing-quic-network-req-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 23:51:38 -0000 --001a114ddbac3521df053559cd72 Content-Type: text/plain; charset=UTF-8 Toerless, (I am surprised to see this post on SAAG; folks in SAAG who are interested in QUIC are quite likely on quic@ietf.org already. I'd like to respond to this email thread here, but there is an ongoing thread in quic@ietf.org about this draft; I suggest that we continue this discussion on that list.) It's wrong at best to characterize the response to the draft on the QUIC list as a "dedicated disinterest", when the response is really a stipulation that "there's nothing to be done with this draft yet." It's also wrong at best to say that that's the opinion of "the majority of the people active in QUIC", when there are exactly 3 people who responded to the draft on the QUIC list, all in their capacities as individuals. It is disingenuous to suggest that there's no interest in solving for middleboxes in QUIC, when the QUIC charter states one of the goals as "Enabling deployment over unmodified Internet paths". If middleboxes exist on path in the Internet, then this goal covers them. I think the sentiment I've heard on the list (and agreed with) is that the problem the draft is stating is not yet precisely defined in terms of the QUIC protocol, and it's not clear that the sub-problems in the draft all need solving. Specifically, the bits you are asking for may already be there. For the ones that aren't already there, the wg will have to decide if it cares or not. But the interest is in a concrete conversation around engineering a solution to a specific problem, not around an abstract one about a broad functional problem, such as "enable firewall protection". - jana On Wed, Jun 15, 2016 at 3:29 PM, Ted Hardie wrote: > On Wed, Jun 15, 2016 at 3:11 PM, Toerless Eckert wrote: > >> Thanks, Ted >> >> >> If the working group does not want to acknowledge in the charter the need >> to >> be at least on par with TCP when it comes to eg: enabling firewall >> protection, then >> there is little chance of getting to the level of discussing the bits >> required to >> do that, right ? >> >> > I'm not sure that "on par with TCP" is the right bar to set here. QUIC > offers facilities that are not quite the same as TCP's, and those may get > used in ways that differ from TCP's. This isn't about hostility to anyone; > it's about the trade-offs that need to be made. The working group will > make those trade-offs (if it is chartered, obviously) and express them as > bits on the wire. > > regards, > > Ted > > > Cheers >> Toerless >> > >> > regards, >> > >> > Ted >> > >> > >> > >> > > > I understand Joe is also concerned about ossification of the format >> > > around >> > > > early versions, so I'd encourage folks interested in this from a >> > > middlebox >> > > > point of view to continue to treat this as evolving. >> > > >> > > Good point. Yes, if QUIC is intentional or unintental hostile to >> > > middleboxes >> > > by repeat change of middlebox relevant parts of its signature then >> this >> > > does >> > > introduce an ongoing problem for middleboxes trying to secure the >> network. >> > > >> > > Cheers >> > > Toerless >> > > > >> > > > regards, >> > > > >> > > > Ted >> > > > >> > > > >> > > > >> > > > On Wed, Jun 15, 2016 at 1:20 PM, Toerless Eckert >> > > wrote: >> > > > >> > > > > In Berlin there is a BOF for QUIC targeted to be WG forming. >> Today, >> > > QUIC >> > > > > does not provide the same level of flow behavior visibility to the >> > > network >> > > > > as TCP/HTTPs does. A lot of this visibility is used by >> middleboxes like >> > > > > firewall to provide eg: DoS protection. If QUIC would take over >> from >> > > TCP >> > > > > in the Internet and controlled networks, this would cause >> regression in >> > > > > security for which no known alternatve solutions exist AFAIK. >> > > > > >> > > > > An ask was raised for the target QUIC WG charter to discuss >> > > > > network-interaction/ >> > > > > flow visibility, but the mayority of people active in QUIC >> expressed a >> > > > > dedicated >> > > > > desinterest in including this topic. >> > > > > >> > > > > The problem and proposed solutions are nicely summarized in >> subject >> > > draft. >> > > > > >> > > > > I am wondering how any part of the security area in the IETF is >> > > interested >> > > > > in or would have opinions about how to deal with this problem. >> > > > > >> > > > > Cheers >> > > > > Toerless >> > > > > >> > > > > _______________________________________________ >> > > > > saag mailing list >> > > > > saag@ietf.org >> > > > > https://www.ietf.org/mailman/listinfo/saag >> > > > > >> > > >> > > -- >> > > --- >> > > Toerless Eckert, eckert@cisco.com >> > > >> >> -- >> --- >> Toerless Eckert, eckert@cisco.com >> > > --001a114ddbac3521df053559cd72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Toerless,

(I am surprised to see this p= ost on SAAG; folks in SAAG who are interested in QUIC are quite likely on <= a href=3D"mailto:quic@ietf.org">quic@ietf.org already. I'd like to = respond to this email thread here, but there is an ongoing thread in quic@ietf.org about this draft; I suggest th= at we continue this discussion on that list.)

=
It's wrong at best to characterize the response to the draft on th= e QUIC list as a "dedicated disinterest", when the response is re= ally a stipulation that "there's nothing to be done with this draf= t yet." It's also wrong at best to say that that's the opinion= of "the majority of the people active in QUIC", when there are e= xactly 3 people who responded to the draft on the QUIC list, all in their c= apacities as individuals.

It is disingenuous to su= ggest that there's no interest in solving for middleboxes in QUIC, when= the QUIC charter states one of the goals as "Enabling deployment over= unmodified Internet paths". If middleboxes exist on path in the Inter= net, then this goal covers them. I think the sentiment I've heard on th= e list (and agreed with) is that the problem the draft is stating is not ye= t precisely defined in terms of the QUIC protocol, and it's not clear t= hat the sub-problems in the draft all need solving. Specifically, the bits = you are asking for may already be there. For the ones that aren't alrea= dy there, the wg will have to decide if it cares or not.

But the interest is in a concrete conversation around engineering a = solution to a specific problem, not around an abstract one about a broad fu= nctional problem, such as "enable firewall protection".

- jana

On Wed, Jun 15, 2016 at 3:29 PM, Ted Hardie <ted.ietf@gmail.com= > wrote:
On Wed, Jun 15,= 2016 at 3:11 PM, Toerless Eckert <eckert@cisco.com> wrote:
Thanks, Ted


If the working group does not want to acknowledge in the charter the= need to
be at least on par with TCP when it comes to eg: enabling firewall protecti= on, then
there is little chance of getting to the level of discussing the bits requi= red to
do that, right ?


I'm not sure that "on = par with TCP" is the right bar to set here.=C2=A0 QUIC offers faciliti= es that are not quite the same as TCP's, and those may get used in ways= that differ from TCP's.=C2=A0 This isn't about hostility to anyone= ; it's about the trade-offs that need to be made.=C2=A0 The working gro= up will make those trade-offs (if it is chartered, obviously) and express t= hem as bits on the wire.

regards,

Ted

Cheers
=C2=A0 =C2=A0 Toerless
>
> regards,
>
> Ted
>
>
>
> > > I understand Joe is also concerned about ossification of the= format
> > around
> > > early versions, so I'd encourage folks interested in thi= s from a
> > middlebox
> > > point of view to continue to treat this as evolving.
> >
> > Good point. Yes, if QUIC is intentional or unintental hostile to<= br> > > middleboxes
> > by repeat change of middlebox relevant parts of its signature the= n this
> > does
> > introduce an ongoing problem for middleboxes trying to secure the= network.
> >
> > Cheers
> >=C2=A0 =C2=A0 Toerless
> > >
> > > regards,
> > >
> > > Ted
> > >
> > >
> > >
> > > On Wed, Jun 15, 2016 at 1:20 PM, Toerless Eckert <eckert@cisco.com>
> > wrote:
> > >
> > > > In Berlin there is a BOF for QUIC targeted to be WG for= ming. Today,
> > QUIC
> > > > does not provide the same level of flow behavior visibi= lity to the
> > network
> > > > as TCP/HTTPs does. A lot of this visibility is used by = middleboxes like
> > > > firewall to provide eg: DoS protection. If QUIC would t= ake over from
> > TCP
> > > > in the Internet and controlled networks, this would cau= se regression in
> > > > security for which no known alternatve solutions exist = AFAIK.
> > > >
> > > > An ask was raised for the target QUIC WG charter to dis= cuss
> > > > network-interaction/
> > > > flow visibility, but the mayority of people active in Q= UIC expressed a
> > > > dedicated
> > > > desinterest in including this topic.
> > > >
> > > > The problem and proposed solutions are nicely summarize= d in subject
> > draft.
> > > >
> > > > I am wondering how any part of the security area in the= IETF is
> > interested
> > > > in or would have opinions about how to deal with this p= roblem.
> > > >
> > > > Cheers
> > > >=C2=A0 =C2=A0 =C2=A0Toerless
> > > >
> > > > _______________________________________________
> > > > saag mailing list
> > > > saag@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/saag
> > > >
> >
> > --
> > ---
> > Toerless Eckert, eckert@cisco= .com
> >

--
---
Toerless Eckert, eckert@cisco.com


--001a114ddbac3521df053559cd72-- From nobody Wed Jun 15 18:13:16 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED17B12D504 for ; Wed, 15 Jun 2016 18:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT1gRW9lgKDx for ; Wed, 15 Jun 2016 18:13:12 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B71912DA31 for ; Wed, 15 Jun 2016 18:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6447; q=dns/txt; s=iport; t=1466039592; x=1467249192; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=wmVpWvPvbOIIuyY4hvi/Os+IPQMX3uSGqGTfexTRSPw=; b=AGzrFeXrfoSG+WW56KPsWyBFlUFx5jnLOX0rveL7YV27DHd7eCOMTakU YcG1x2htweenUVaJ1Vp3psNCeRzlpYK+GZspDuJfxmvJPMrp8QvWk+ukW qFG5mdl3y4d4kvRvI+V8x96njWEiwrdT8YtwYu7oxFIqgapk2CL6uoXcf c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAgBl/GFX/4kNJK1dgz5Wfa5ajAKBe?= =?us-ascii?q?hcLhXUCgSw4FAEBAQEBAQFlJ4RMAQEEAQEBNzEDCxALDgoJJQ8FDQY2ExuHewM?= =?us-ascii?q?XDrtaDYNkAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWKdIJDgU8RAYNIgi8FiBCGV?= =?us-ascii?q?YlQNIYFhiqBcAqPIogHh20eNoI6gVUcMohTgTUBAQE?= X-IronPort-AV: E=Sophos;i="5.26,478,1459814400"; d="scan'208";a="286026317" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jun 2016 01:13:11 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5G1DAJJ028491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2016 01:13:11 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u5G1DAiL013302; Wed, 15 Jun 2016 18:13:10 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u5G1DAhJ013301; Wed, 15 Jun 2016 18:13:10 -0700 Date: Wed, 15 Jun 2016 18:13:10 -0700 From: Toerless Eckert To: Jana Iyengar Message-ID: <20160616011310.GE31598@cisco.com> References: <20160615202055.GT31598@cisco.com> <20160615214633.GY31598@cisco.com> <20160615221108.GB31598@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] SAAG: Q re. https://tools.ietf.org/html/draft-wing-quic-network-req-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 01:13:15 -0000 Thanks, Jana 1. Every customer with a firewall or similar network security device will want to understand how QUIC will compare to TCP/HTTPs in terms of attacks, how well the security device can protect against them and if QUIC has taken the necessary steps not to regress behind TCP in the achievable security, or if it does, why so. Who should produce the answer to these questions in your opinion ? I can not find in the tentative charter anything that tells me if the WG will produce answer to these questions, and i wonder why this would be contentuous. 2. On average, discussions on a non-security area WG are mostly full of stuff irrelevant for security experts. Therefore saag is providing a forum for those groups to reach out to a broad base of IETF security experts and focus specifically on security issues. Without such a mechanism, security experts would be extremely thin stretched tracking a lot WG mailing lists and filtering out security aspects. Likewise, this ia AFAIK the main reason why SAAG meetings at the IETF have presentations/review of all those WGs wrt. to their security aspects. Cheers Toerless On Wed, Jun 15, 2016 at 04:51:34PM -0700, Jana Iyengar wrote: > Toerless, > > (I am surprised to see this post on SAAG; folks in SAAG who are interested > in QUIC are quite likely on quic@ietf.org already. I'd like to respond to > this email thread here, but there is an ongoing thread in quic@ietf.org > about this draft; I suggest that we continue this discussion on that list.) > > It's wrong at best to characterize the response to the draft on the QUIC > list as a "dedicated disinterest", when the response is really a > stipulation that "there's nothing to be done with this draft yet." It's > also wrong at best to say that that's the opinion of "the majority of the > people active in QUIC", when there are exactly 3 people who responded to > the draft on the QUIC list, all in their capacities as individuals. > > It is disingenuous to suggest that there's no interest in solving for > middleboxes in QUIC, when the QUIC charter states one of the goals as > "Enabling deployment over unmodified Internet paths". If middleboxes exist > on path in the Internet, then this goal covers them. I think the sentiment > I've heard on the list (and agreed with) is that the problem the draft is > stating is not yet precisely defined in terms of the QUIC protocol, and > it's not clear that the sub-problems in the draft all need solving. > Specifically, the bits you are asking for may already be there. For the > ones that aren't already there, the wg will have to decide if it cares or > not. > > But the interest is in a concrete conversation around engineering a > solution to a specific problem, not around an abstract one about a broad > functional problem, such as "enable firewall protection". > > - jana > > On Wed, Jun 15, 2016 at 3:29 PM, Ted Hardie wrote: > > > On Wed, Jun 15, 2016 at 3:11 PM, Toerless Eckert wrote: > > > >> Thanks, Ted > >> > >> > >> If the working group does not want to acknowledge in the charter the need > >> to > >> be at least on par with TCP when it comes to eg: enabling firewall > >> protection, then > >> there is little chance of getting to the level of discussing the bits > >> required to > >> do that, right ? > >> > >> > > I'm not sure that "on par with TCP" is the right bar to set here. QUIC > > offers facilities that are not quite the same as TCP's, and those may get > > used in ways that differ from TCP's. This isn't about hostility to anyone; > > it's about the trade-offs that need to be made. The working group will > > make those trade-offs (if it is chartered, obviously) and express them as > > bits on the wire. > > > > regards, > > > > Ted > > > > > > Cheers > >> Toerless > >> > > >> > regards, > >> > > >> > Ted > >> > > >> > > >> > > >> > > > I understand Joe is also concerned about ossification of the format > >> > > around > >> > > > early versions, so I'd encourage folks interested in this from a > >> > > middlebox > >> > > > point of view to continue to treat this as evolving. > >> > > > >> > > Good point. Yes, if QUIC is intentional or unintental hostile to > >> > > middleboxes > >> > > by repeat change of middlebox relevant parts of its signature then > >> this > >> > > does > >> > > introduce an ongoing problem for middleboxes trying to secure the > >> network. > >> > > > >> > > Cheers > >> > > Toerless > >> > > > > >> > > > regards, > >> > > > > >> > > > Ted > >> > > > > >> > > > > >> > > > > >> > > > On Wed, Jun 15, 2016 at 1:20 PM, Toerless Eckert > >> > > wrote: > >> > > > > >> > > > > In Berlin there is a BOF for QUIC targeted to be WG forming. > >> Today, > >> > > QUIC > >> > > > > does not provide the same level of flow behavior visibility to the > >> > > network > >> > > > > as TCP/HTTPs does. A lot of this visibility is used by > >> middleboxes like > >> > > > > firewall to provide eg: DoS protection. If QUIC would take over > >> from > >> > > TCP > >> > > > > in the Internet and controlled networks, this would cause > >> regression in > >> > > > > security for which no known alternatve solutions exist AFAIK. > >> > > > > > >> > > > > An ask was raised for the target QUIC WG charter to discuss > >> > > > > network-interaction/ > >> > > > > flow visibility, but the mayority of people active in QUIC > >> expressed a > >> > > > > dedicated > >> > > > > desinterest in including this topic. > >> > > > > > >> > > > > The problem and proposed solutions are nicely summarized in > >> subject > >> > > draft. > >> > > > > > >> > > > > I am wondering how any part of the security area in the IETF is > >> > > interested > >> > > > > in or would have opinions about how to deal with this problem. > >> > > > > > >> > > > > Cheers > >> > > > > Toerless > >> > > > > > >> > > > > _______________________________________________ > >> > > > > saag mailing list > >> > > > > saag@ietf.org > >> > > > > https://www.ietf.org/mailman/listinfo/saag > >> > > > > > >> > > > >> > > -- > >> > > --- > >> > > Toerless Eckert, eckert@cisco.com > >> > > > >> > >> -- > >> --- > >> Toerless Eckert, eckert@cisco.com > >> > > > > -- --- Toerless Eckert, eckert@cisco.com From nobody Sat Jun 18 06:47:11 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46FA12D114 for ; Sat, 18 Jun 2016 06:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ks8flPbNavGb for ; Sat, 18 Jun 2016 06:47:05 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30ACE12D0CC for ; Sat, 18 Jun 2016 06:47:05 -0700 (PDT) Received: from [IPv6:2a02:200:1231:2:c07:ed13:e602:752e] (unknown [IPv6:2a02:200:1231:2:c07:ed13:e602:752e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id EED90800AE; Sat, 18 Jun 2016 15:47:01 +0200 (CEST) To: Martin Thomson , saag References: From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <5765503F.3080602@gont.com.ar> Date: Sat, 18 Jun 2016 15:44:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] Identifier uniqueness and draft-gont-predictable-numeric-ids X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 13:47:09 -0000 Hi, Martin, Not sure if I had responded to this one, but... since we're working on a revision of our I-D, I went through your comments (possibly again). Here are my comments: On 04/07/2016 08:44 PM, Martin Thomson wrote: > Identifiers inherently need to uniquely identify things. That is, > each identifier needs to identify a single thing [48]. That's how we defined the term in our document, it seems. > I believe that > to be constant across these examples, though there might be some > confusion about what is being identified. The example of v6 flow > labels suggests to me that the thing being labelled is not a single > flow, but the set of flows that will be collated. You still mean to identify a single thing. The issue here is that, depending on the type of identifier, etc., the failure severity may be different. e.g., a Flow Label collision is ok, while an IPv6 address collision is not. > What differs is the process by which uniqueness is guaranteed. > Uniqueness in many contexts is assured by fiat: an authority is known > to control a given space and only that authority can generate > identifiers in that space. For example, a server controls what the > TCP port numbers its servers use identify. > > We have a few examples where uniqueness is distributed (e.g., CGA) and > protocol mechanisms are used to ensure uniqueness. There are specific > privacy and security considerations that arise from having a protocol > mechanism, so this method of arriving at uniqueness warrants some > discussion because it entails a new protocol, but I don't believe that > it justifies the hard/soft distinction in the proposed taxonomy. How uniqueness is "guaranteed" also has associated constraints in the algorithms you may employ. For example, when it comes to Frag IDs, you should either remember all Frag IDs that you've used in the last 60 seconds (unfeasible for a real implementation), or simply aim at minimizing the Frag ID resuse frequency. > Finally, the monotonically increasing category is not particularly > special. The identifier (e.g., a TCP sequence number) still uniquely > identifies a subject (in this case, the first octet of a segment). > The process for ensuring uniqueness is merely different. Example: if you just cared about uniqueness, you could e.g. simply come up with a random number (assumming the id space is large enough, etc.). However, if the IDs are required to be monotonically increasing, then such approach is not possible. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Sat Jun 18 07:27:58 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF43212D552 for ; Sat, 18 Jun 2016 07:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eOE1DX4s78k for ; Sat, 18 Jun 2016 07:27:56 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3536B12D54C for ; Sat, 18 Jun 2016 07:27:56 -0700 (PDT) Received: from [IPv6:2a02:200:1231:2:c07:ed13:e602:752e] (unknown [IPv6:2a02:200:1231:2:c07:ed13:e602:752e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6F71F800AE; Sat, 18 Jun 2016 16:27:54 +0200 (CEST) To: Adam Montville , Martin Thomson References: <9B213A1F-92EE-4E94-BB8C-A1E288647C8D@gmail.com> From: Fernando Gont Message-ID: <57655144.9070200@gont.com.ar> Date: Sat, 18 Jun 2016 15:48:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <9B213A1F-92EE-4E94-BB8C-A1E288647C8D@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: saag Subject: Re: [saag] Identifier uniqueness and draft-gont-predictable-numeric-ids X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 14:27:58 -0000 On 04/07/2016 08:55 PM, Adam Montville wrote: [....] >> [48] A thing might have multiple identifiers, a fact that might be >> exploited by this document. > > +1 Additionally, such multiple identifiers might be assigned to one thing by multiple authorities. mm... how does this affect our I-D? Thanks! Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Sat Jun 18 07:28:05 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA95912D561 for ; Sat, 18 Jun 2016 07:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNgY_5iJ0KCc for ; Sat, 18 Jun 2016 07:27:57 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C8612D54D for ; Sat, 18 Jun 2016 07:27:57 -0700 (PDT) Received: from [IPv6:2a02:200:1231:2:c07:ed13:e602:752e] (unknown [IPv6:2a02:200:1231:2:c07:ed13:e602:752e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id AA846800C1; Sat, 18 Jun 2016 16:27:55 +0200 (CEST) To: Martin Thomson , stic@fundacionsadosky.org.ar References: <5706E10C.6060309@fundacionsadosky.org.ar> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <57655A64.9020704@gont.com.ar> Date: Sat, 18 Jun 2016 16:27:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: saag Subject: Re: [saag] Identifier uniqueness and draft-gont-predictable-numeric-ids X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 14:28:00 -0000 On 04/08/2016 03:51 PM, Martin Thomson wrote: > On 7 April 2016 at 19:37, Programa STIC wrote: >> Indeed, identifiers identify things _within a given context_. To avoid a >> recursive definition and to try to narrow down the scope of the document >> just to numeric ids we defined "identifier" in section 2 as: > > Yes, agree, context matters. > >> A data object in a protocol specification that can be used to >> definetely distinguish a protocol object (a datagram, network >> interface, transport protocol endpoint, session, etc) from all >> other objects of the same type, in a given context. > > The word you want is "definitively". Doesn't "definitively" have a "time" connotation whereas uniquely doesn't? >> If you feel the above definition needs to be tweaked please let us know >> of suggested changes. One possible change could be to substitute >> "definetely" with "uniquely" but I don't know if that's strictly necessary. > > I don't have a good answer for the question, but you make a > distinction between fixed sized integer identifiers and other > identifiers. It's not clear what relevance that delineation has on > this subject. I think Iván just meant tat in most cases, IDs are represented as intergers... but that's just an observation, not e requirement. >>> What differs is the process by which uniqueness is guaranteed. >>> Uniqueness in many contexts is assured by fiat: an authority is known >>> to control a given space and only that authority can generate >>> identifiers in that space. For example, a server controls what the >>> TCP port numbers its servers use identify. >> >> Centralized, delegated, federated or distributed generation of >> identifier values does not guarantee uniquess per se, its all dependent >> on the algorithms used. In some scenarios, for example a central >> authority that generates identifiers on demand, some algorithms will >> guarantee uniqueness (ie. a global variable initialized and incremented >> by 1 for each request of a new id) while in other scenarios other >> algorithms may accomplish the same (ie. a lookup on a table of >> precomputed values). However, the point we are trying to raise is that >> from the security & privacy perspective, in many cases uniqueness is not >> sufficient. In many cases non-predictability and collision resistance >> are additional properties desired or even needed to avoid attack. > > A section/paragraph that says exactly that would be a massive > improvement. It belongs in the introduction. mm.. could you please clarify what such section would cover? Because the above paragraph seems to cover multiple issues.... >> During the session today somebody (sorry I did not write down your name) >> indicated that perhaps it is good to differentiate identifier values >> that are generated at "spec time" or/and that remain fixed throughout >> the lifetime of the protocol from those that are generated dynamically >> at runtime by the protocol's implementation. I concur. > > So do I; my email was - in part - about identifying another > distinction. That is, between centralized and decentralized > generation. Thinking out loud, it would seem to me that the only area for which this distinction becomes relevant is that if you want to guarantee availability by keeping state about the IDs that have so far been generated/employed, in a decentralized case you couldn't, or you'd need some for of protocol to synchronize such state. >> We believe it is indeed special. The point here is that requiring >> monotonically increasing values for a identifier introduces additional, >> and sometimes unneeded, property: an ordering relationship. The result >> is a protocol field that is "semantically overloaded", it is not just >> unique but can also be used to order bytes, or even to order sequences >> of bytes. In some cases this property is needed or desirable, in other >> cases it is totally unneeded. Again, here we can see how a global >> counter incremented by 1 per packet does something more than just ensure >> uniqueness. > > Fair point. > >> A protocol that defines an Identifier that needs to be unique (within >> context) but specifies generation of its values using a monotonically >> increasing sequence is "over specifying" the ID definition and should >> trigger a warning in a S&P review. > > Interesting perspective. I'm not convinced that is possible in all > cases. I'm guessing that it could be difficult to sell that to the > community, even in the current climate, without some strong backing. > That could be perceived as quite a heavy burden. Sell what, specifically? > I would be interested in seeing a case study here. For example, how > would you apply this principle to TCP sequence numbers? Simple: RFC0793 suggests to use some form of global counter for generating TCP ISNs. But that suggestion overspecifies TCP ISNs, since they only need to be monotonically increasing for the same connection-id (src ip, src port, dst ip, dst port). RFC6528 achieves such interoperability requirement, without overspecifying the TCP ISNs: it provides monotonically increasing ISNs for each connection id. ISNs corresponding to different connection-ids don't have any order relationship. > On a related note, is this exclusively limited to identifiers that are > sent in a protocol? Or the subset of those that are sent in the > clear? Or are you also interested in implicit identifiers as well, > those things that are not put in protocol PDUs, but are conceptually > important for the functioning of the protocol. ...such us? Just guessing, I'd probably say that this is meant for all of them. > Further thoughts: this discussion sort of suggests to me that the > scope of this work is a little ambitious for a single draft. Maybe > you could think some more about how you might reduce scope or divide > the work into more easily digestible pieces. We're working into that. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Sun Jun 19 07:08:18 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A510F12D129 for ; Sun, 19 Jun 2016 07:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6ouQpW_288W for ; Sun, 19 Jun 2016 07:08:16 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4446C12B015 for ; Sun, 19 Jun 2016 07:08:16 -0700 (PDT) Received: from [192.168.1.102] (BSN-95-241-32.static.siol.net [193.95.241.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 9D0A780241; Sun, 19 Jun 2016 16:08:14 +0200 (CEST) To: "saag@ietf.org" From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <5766A74D.20705@si6networks.com> Date: Sun, 19 Jun 2016 16:08:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-gont-numeric-ids-sec-considerations@tools.ietf.org Subject: [saag] Updating RFC3552 (draft-gont-numeric-ids-sec-considerations) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 14:08:17 -0000 Folks, Based on the suggestion of a number of people, we've published this document: It is a spin-off of our document: draft-gont-predictable-numeric-ids, on predictable numeric IDs, discussed at the last SAAG meeting. Comments are welcome! Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jun 22 04:52:54 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E633E12B03D for ; Wed, 22 Jun 2016 04:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6IHiPKx6VO6 for ; Wed, 22 Jun 2016 04:52:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E7F12B02F for ; Wed, 22 Jun 2016 04:52:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 381F1BE2C for ; Wed, 22 Jun 2016 12:52:48 +0100 (IST) 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 FzMREdVU5V0Y for ; Wed, 22 Jun 2016 12:52:48 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 99606BDD0 for ; Wed, 22 Jun 2016 12:52:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1466596368; bh=TqcqTTrdoyoLTZprQmlM4N5OJviCdDF4PsN09x5ZHXk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=qlDqyYviPuaMbqHF+s/4wMyzb/D9JU1KwC9Fgy2Qc8miKMCmMECWM/PPorK6mUoiB sa68wWGw8IP7rti9CVPxaIf6f7EDMtyHnOaLq6pAFYx5ra8pzF5fdrGzdZICCDg6tT uBxtcVuEo1DAucDYQQZu4C2M2MfVhXjQM7t8pFjY= To: "saag@ietf.org" References: <575D5462.8010809@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <576A7C0F.6010108@cs.tcd.ie> Date: Wed, 22 Jun 2016 12:52:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <575D5462.8010809@cs.tcd.ie> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040107070803040903070704" Archived-At: Subject: Re: [saag] SAAG slot requests for Berlin X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 11:52:53 -0000 This is a cryptographically signed message in MIME format. --------------ms040107070803040903070704 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Just an update: we currently have a full agenda for Berlin, with a couple of standby folks as well. Thanks, S. PS: We'll shortly post a draft agenda. I'll send mail here when that's done. On 12/06/16 13:24, Stephen Farrell wrote: >=20 > Hiya, >=20 > Nearly that time again! >=20 > If you'd like to make a presentation at the saag session in > Berlin or have some other thing put on the agenda, please > send a mail to Kathleen and I. >=20 > Do please re-tx if you previously sent one and we've not > chatted about it recently - I at least am very prone to not > remembering everything;-) >=20 > Cheers, > S. >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --------------ms040107070803040903070704 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MjIx MTUyNDdaMC8GCSqGSIb3DQEJBDEiBCDmuKtX1ZYb+zowAX/+AYaCx8SUJCuloDwwmSiYKc6y NTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCxcf8eSjjInahg7sTMQhNCyPcnlvd9Tun5WKvB/WgriEq2rUuSQ6Zs euIx8tnJcDanPH0HgdyKAh28vKlPEd5Y5/NtFWsKR3fNBaXDz2/aTFBdc+ke7ec39KZGiUUN OmfF6TkoOkd6j74QqNIryk1yYxq3efON55CbzGwVJ7sIzvmdaH0ivSFrq6hjyOq4teoSwRlX uvIomN8NA0q/+ESRwzsSDrvHJi0tM0DXLssbtAXDId5OjTE2VICcDa1HgfGazimmnnVdjID6 WQvCl6fyC23fuSnueysZfdEf4i9W5ybvPKDpRb0EDEVJ08gAZ8mSe8UWCYA7pFjuaZCakSSu AAAAAAAA --------------ms040107070803040903070704-- From nobody Thu Jun 23 00:21:32 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5D712DDC8 for ; Thu, 23 Jun 2016 00:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.625 X-Spam-Level: X-Spam-Status: No, score=-5.625 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSCzVQ2OC2TC for ; Thu, 23 Jun 2016 00:21:28 -0700 (PDT) Received: from atreus.tartarus.org (atreus.tartarus.org [80.252.125.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F791288B8 for ; Thu, 23 Jun 2016 00:21:27 -0700 (PDT) Received: from simon by atreus.tartarus.org with local (Exim 4.69) (envelope-from ) id 1bFyx3-0003be-Qb for saag@ietf.org; Thu, 23 Jun 2016 08:21:25 +0100 Content-Type: text/plain; charset=UTF-8 From: Simon Tatham To: saag Date: Thu, 23 Jun 2016 08:21:25 +0100 Message-Id: <1466666482-sup-1419@atreus.tartarus.org> User-Agent: Sup/git Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Archived-At: Subject: [saag] Draft review request: SSH IUTF8 terminal mode X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 07:21:30 -0000 Hi, I'm currently attempting to get a small RFC published, adding an extra terminal mode flag to the SSH protocol. My current draft is at https://tools.ietf.org/html/draft-sgtatham-secsh-iutf8-01 At Kathleen Moriarty's request, I've posted to the ietf-ssh mailing list requesting reviews of the draft; the beginnings of a discussion (so far just a suggestion to add a reference of two) are in the list archives at ftp://ftp.ietf.org/ietf-mail-archive/secsh/2016-06.mail . Kathleen Moriarty also suggested I should ask for review from this list. So, if anyone has any review comments on this draft, could they send them to me, please? Cheers, Simon -- for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff, 0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7, 0xc83e01379a5fbec5fdd1, 0x19d3d70a8d567e388600e, 0x534e2f6e8a4a33155123]]: print "".join([chr(32+3*((k>>x)&1))for x in range(79)]) # From nobody Fri Jun 24 12:27:37 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8409112D5CE for ; Fri, 24 Jun 2016 12:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FSL_HELO_HOME=1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O35TwYxNWO0Z for ; Fri, 24 Jun 2016 12:27:30 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFAEB12D5D1 for ; Fri, 24 Jun 2016 12:27:30 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id v77so108514531ywg.0 for ; Fri, 24 Jun 2016 12:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=from:subject:to:message-id:date:mime-version; bh=Gfnm/dp/bkO4HBrS1rc28v4uWlilpxGEIRwDTujFvsE=; b=VS/fIZKiXmno+QrdjNe+LQNtbTW04jYaAg0kzACjP2JzK2UarfHp5ks+QBbuLWqJJk F45jF8ZMtg8uVd9Y/n8Ftl0EWzYvQODAV61Qz/fB5A/p229WeZfuYec8emY+cymFerOm RcyxNiE0lAQ6c4V2p88RBAroH9Gpfap34XaXk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:mime-version; bh=Gfnm/dp/bkO4HBrS1rc28v4uWlilpxGEIRwDTujFvsE=; b=aWx9XuvxV/Kl81l4reUJ1L/4RXpixwX2JA0hYkPkguaIsuTptkng8J9aDdU6gvPtl6 nWifc6+xYESesdzIdEb0N0uf+ZbD12FCPZjmiayd8I25GXJH2feUoqBlk6FLq0RVamUU qZkSaWidkoxXO/nfJAucY6ZS5ee/nYmy2ikDk+ZDP4MuNPmoySoqhSUKy3w/X0ZzGv6S oQJ9QsdCH8baJ3sxP/d+SV/Fljw7ZsYFXFFCYIfdL3dbquI7EI8a9ZmdcdHFIjyZT4yy eteFwlpnnY12jDAbPByvAaeTxHmk+ieAK8HPDZQoBya3Muz7pICAtca8E+3sOgQ/Hr4j egDQ== X-Gm-Message-State: ALyK8tJJocWJw4EfLbBSoJAuYZdz7L5TKHLZ+FBp7JE4Y6NpR2lmq/viQORC4PeJGlT2cvXl X-Received: by 10.129.159.134 with SMTP id w128mr4101333ywg.193.1466796449711; Fri, 24 Jun 2016 12:27:29 -0700 (PDT) Received: from hypochilid.home (pool-173-79-93-45.washdc.fios.verizon.net. [173.79.93.45]) by smtp.googlemail.com with ESMTPSA id u75sm3549691ywf.9.2016.06.24.12.27.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jun 2016 12:27:28 -0700 (PDT) From: Joseph Lorenzo Hall To: IETF discussion list , saag@ietf.org Message-ID: <576D899F.7000000@cdt.org> Date: Fri, 24 Jun 2016 15:27:27 -0400 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EUct97ahu119X2lMiMOp8C3qckOwrGWWM" Archived-At: Subject: [saag] side event Wed. 20 July at IETF 96: "Open Debate on the Politics of Encryption" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 19:27:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EUct97ahu119X2lMiMOp8C3qckOwrGWWM Content-Type: multipart/mixed; boundary="XHv8W9GUxMawScpq0Slt4TtNv8KTWEvlR" From: Joseph Lorenzo Hall To: IETF discussion list , saag@ietf.org Message-ID: <576D899F.7000000@cdt.org> Subject: side event Wed. 20 July at IETF 96: "Open Debate on the Politics of Encryption" --XHv8W9GUxMawScpq0Slt4TtNv8KTWEvlR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear IETFers, Wikimedia Germany and the Global Public Policy Insitute will be hosting the following event on Wednesday evening of IETF week. (Yes, it is scheduled during the IETF plenary on Wednesday evening. We hope some of you might make it regardless as it's only 15m away from the IETF venue.) RSVP required. best, Joe ---- Open Debate on the Politics of Encryption In modern democracies, societies are built not only on checks and balances but also on the notion of trust. In the digital age, trust is strengthened through a variety of technologies that provide for online privacy and security. Encryption technologies are one key example. They allow users to securely communicate and do business online, and to protect data on a computer, a phone or in the cloud. However, those technologies are also available for less benevolent purposes, providing criminals with means to protect their communication and data. This has put encryption at the centre of a debate on the tension between online security and the notion of national security. Even after years of struggles - most recently between the FBI and Apple - battle lines remain murky, and key questions unanswered. Are law enforcement agencies really "going dark"? Should (and can) societies make any compromises on the use of encryption technologies? What are the ethical obligations for the technical and academic communities? If multistakeholder institutions, such as the IETF, set standards on encryption that will be adopted broadly, how does multistakeholder governance impact best practices, the development and the implementation of such standards? What effect had the Snowden disclosures on IETF processes? If we accept the broad and easy use of encryption technologies, should government agencies have other tools at hand to fight criminals? And finally, where do we stand on this debate in Germany and what can we do to help define a united European position? On Wednesday, 20 July 2016 - on the occasion of this year's IETF meeting being held in Berlin - we will address these and similar questions in an open debate on the politics of encryption. The discussion will be launched by a conversation between Joe Hall (Center for Democracy & Technology, CDT), Linus Neumann (Chaos Computer Club, CCC) and Christine Runnegar (tbc; Internet Society, ISOC), and moderated by Mirko Hohmann (Global Public Policy Institute, GPPi). All guests and participants are invited to join the debate and to openly discuss the role that civil society and the technical community could and should play in defining our approach to encryption technologies, and more widely in Internet policy and governance. The discussion will be held in English. When: Wednesday, 20 July 2016 Programme: 18:30 - Arrival and welcoming snack 19:00 - Panel discussion 19:45 - Open debate with all guests 20:30 - Food, drinks and networking Where: Wikimedia Germany Tempelhofer Ufer 23/24 - 10963 Berlin Room Mosaik The meeting is the second in a series of events that aims to bring together different actors from civil society and academia who are interested in international internet policy and its impact on the national level. These networking meetings will take place three times per year, in Berlin, Germany. They are organised by several civil society groups and academic institutions, including the Global Internet Governance Academic Network (GigaNet), Medienstadt Leipzig e.V., the WZB Berlin Social Science Center, the Global Public Policy Institute (GPPi), the IGF academy and the German section of the Internet Governance Forum (IGF-D). All stakeholder groups are welcome to join the meetings. This series of events is supported by ICANN and Wikimedia Germany. Please contact us for suggestions regarding potential future topics. Participation is free but registration is required. RSVP via email to: Lorena Jaume-Palasi: l.jaume-palasi@irights-lab.de Julia Pohle: julia.pohle@wzb.eu --=20 Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.or= g] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 --XHv8W9GUxMawScpq0Slt4TtNv8KTWEvlR-- --EUct97ahu119X2lMiMOp8C3qckOwrGWWM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXbYmgAAoJEF+GaYdAqahxoooP/RYGbtiy7q9b2H1EooQrFeeB 2kB8GS0gyvm9pPQrYkoa6KAnVT2PRu2Wp9Wxi1t1wTx1TxWgE/K7nbzyegW6klgT yn9EWHl/xmD8qCJUzcafSHeokWDz8gxiVKwXvBTgTNu7MG5PwC4I6FYXxptVlwkV 7tZM4feflr9Ts63MzGRvw35Bld+O9DjnO3aQRPyhx6bfZ6WLP7vzYGW3paBku2Rs 2rK8pq9gW6EVymLJbyAbQL3S+CpTD2I2goGFdb0W3YJ70qZQ9OXubOs67RIOYuEk 0znFVUGc/Xhbo+FiuuCdQsz+/jECGzmm87K77Bio+wByG9WPHQEpNN3YSt4/gOOk Vv2c9HGh8u5oL/Fnpto/ximzngqRk1aKavHdwbWvPAgTFp1aiH8HNoSmqHAJhure xYlQ+Q7tUmOJRfdOKszYih3FpxHn3/xP/zxAs+vCeVP6npog1SfG0DeRdaz4+Xc0 bMbyj8jLZIJSOJ5xAO0HhTwmwRNb+THzsde7xxhHOB8b7/gisB3wRZh8TS6uFHMs TnSPy+jITiP1lz/b+gh4no/aUTe/lEMDPE9eBPdiZkdWEPctt4HRDitHvsnVsm0M cZLpBEzNcddoXr87USkQBGhJid+Xb2ruHhGn7l2h6RFiFhFdBpIfcXl/nXPUKNvF LSxSmXwxW5ZbXPM56Ehf =aqnl -----END PGP SIGNATURE----- --EUct97ahu119X2lMiMOp8C3qckOwrGWWM-- From nobody Fri Jun 24 12:33:57 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD41612D61A; Fri, 24 Jun 2016 12:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhSakWJCyw7H; Fri, 24 Jun 2016 12:33:48 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D79F12D60B; Fri, 24 Jun 2016 12:33:48 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u5OJXk0t014853; Fri, 24 Jun 2016 20:33:46 +0100 Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u5OJXhFK014722 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2016 20:33:43 +0100 From: "Adrian Farrel" To: "'Joseph Lorenzo Hall'" , "'IETF discussion list'" , References: <576D899F.7000000@cdt.org> In-Reply-To: <576D899F.7000000@cdt.org> Date: Fri, 24 Jun 2016 20:33:37 +0100 Message-ID: <01c101d1ce4f$51d53300$f57f9900$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJYmXL8lUq+68yggOgfjv6xUllnkJ7rayqA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22412.001 X-TM-AS-Result: No--24.046-10.0-31-10 X-imss-scan-details: No--24.046-10.0-31-10 X-TMASE-MatchedRID: gTucSmrmRMMwZW4i0BEeTMOriXY+VMfQt3aeg7g/usAsvosvPNHPCZJg cwWSs+sWbIIOZDUkyx+nVOsT1h4vuHwvP2dtBRFi2os3ueKAsFRD4MJknAihstm/fdXsviYnx0B moRFcUpjkjA/Hqc2Ntea7bWQUrZk7mGicI0nTkWlDP8uRDLPyZpsqkCVjbLpJVqEZG3WWgG7aSc sbR5OsZGZM+DAxYTMpBIGTVJ9QjKXV117NWfL5Akq6xZmdRGuGJPNIV6GF8mvXDvu5MGVGh2eDi OVpb8s7gl39FvIJGDDm07dxH4admyZ/E6AE4WkilXyFJmnnKdcg5jUtKVG0NDZGJFrAKeHOTQ1k BdT+6uSlCi+Pv/Y9AE2ikM2d1IB1Gmw37mpPMKSepOo7UqIl+V7IDKepDQYKQlkeP+Bz8Xw/2cG V4IjttijHbLYODI3pYAbUYegG/0WDAd1DtN1q7T2C05EXD5W8tMSM1a+1JW+67Q3uPo9KIz7Poo NPxp6ahIgWmklAQ4FyY09uwAuzp4DArDNW/6lk8CORMyRE01Rwryoe90UcsAmZ1fM6EQx2l9EOP ISmVW0stj2laSdH8zJSHQNX725is/+w07Y/y4e8coKUcaOOvUMYW8F4Hadcvw7AO3VGI87ZmI5v wsWzuzrjEn+FcxuU49Em7KPP9977OgBbxHXmX8SRIEbPJ/1LeEA/UnKXgYqbKItl61J/ybLn+0V m71Lcq7rFUcuGp/G8QIu4z6HhEH7cGd19dSFd Archived-At: Subject: Re: [saag] side event Wed. 20 July at IETF 96: "Open Debate on the Politics of Encryption" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 19:33:52 -0000 Maybe the SAAG co-chairs could be persuaded to put you on the agenda on = Thursday to give a ten minute report on what happened so that those of = us who will be paying attention to the IETF all week don't need to = completely miss out on this. Adrian > -----Original Message----- > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Joseph Lorenzo = Hall > Sent: 24 June 2016 20:27 > To: IETF discussion list; saag@ietf.org > Subject: side event Wed. 20 July at IETF 96: "Open Debate on the = Politics of > Encryption" >=20 > Dear IETFers, >=20 > Wikimedia Germany and the Global Public Policy Insitute will be = hosting > the following event on Wednesday evening of IETF week. >=20 > (Yes, it is scheduled during the IETF plenary on Wednesday evening. We > hope some of you might make it regardless as it's only 15m away from = the > IETF venue.) >=20 > RSVP required. best, Joe >=20 > ---- >=20 > Open Debate on the Politics of Encryption >=20 > In modern democracies, societies are built not only on checks and > balances but also on the notion of trust. In the digital age, trust is > strengthened through a variety of technologies that provide for online > privacy and security. Encryption technologies are one key example. = They > allow users to securely communicate and do business online, and to > protect data on a computer, a phone or in the cloud. However, those > technologies are also available for less benevolent purposes, = providing > criminals with means to protect their communication and data. This has > put encryption at the centre of a debate on the tension between online > security and the notion of national security. Even after years of > struggles - most recently between the FBI and Apple - battle lines > remain murky, and key questions unanswered. >=20 > Are law enforcement agencies really "going dark"? Should (and can) > societies make any compromises on the use of encryption technologies? > What are the ethical obligations for the technical and academic > communities? If multistakeholder institutions, such as the IETF, set > standards on encryption that will be adopted broadly, how does > multistakeholder governance impact best practices, the development and > the implementation of such standards? What effect had the Snowden > disclosures on IETF processes? If we accept the broad and easy use of > encryption technologies, should government agencies have other tools = at > hand to fight criminals? And finally, where do we stand on this debate > in Germany and what can we do to help define a united European = position? >=20 > On Wednesday, 20 July 2016 - on the occasion of this year's IETF = meeting > being held in Berlin - we will address these and similar questions in = an > open debate on the politics of encryption. The discussion will be > launched by a conversation between Joe Hall (Center for Democracy & > Technology, CDT), Linus Neumann (Chaos Computer Club, CCC) and = Christine > Runnegar (tbc; Internet Society, ISOC), and moderated by Mirko Hohmann > (Global Public Policy Institute, GPPi). >=20 > All guests and participants are invited to join the debate and to = openly > discuss the role that civil society and the technical community could > and should play in defining our approach to encryption technologies, = and > more widely in Internet policy and governance. >=20 > The discussion will be held in English. >=20 > When: > Wednesday, 20 July 2016 >=20 > Programme: >=20 > 18:30 - Arrival and welcoming snack > 19:00 - Panel discussion > 19:45 - Open debate with all guests > 20:30 - Food, drinks and networking >=20 > Where: > Wikimedia Germany > Tempelhofer Ufer 23/24 - 10963 Berlin > Room Mosaik >=20 > The meeting is the second in a series of events that aims to bring > together different actors from civil society and academia who are > interested in international internet policy and its impact on the > national level. These networking meetings will take place three times > per year, in Berlin, Germany. They are organised by several civil > society groups and academic institutions, including the Global = Internet > Governance Academic Network (GigaNet), Medienstadt Leipzig e.V., the = WZB > Berlin Social Science Center, the Global Public Policy Institute = (GPPi), > the IGF academy and the German section of the Internet Governance = Forum > (IGF-D). All stakeholder groups are welcome to join the meetings. This > series of events is supported by ICANN and Wikimedia Germany. >=20 > Please contact us for suggestions regarding potential future topics. >=20 > Participation is free but registration is required. RSVP via email to: >=20 > Lorena Jaume-Palasi: l.jaume-palasi@irights-lab.de > Julia Pohle: julia.pohle@wzb.eu >=20 > -- > Joseph Lorenzo Hall > Chief Technologist, Center for Democracy & Technology = [https://www.cdt.org] > 1401 K ST NW STE 200, Washington DC 20005-3497 > e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key > Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 From nobody Fri Jun 24 12:37:05 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0127F12D60B; Fri, 24 Jun 2016 12:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inLWSd37udFc; Fri, 24 Jun 2016 12:36:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2B712D608; Fri, 24 Jun 2016 12:36:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7789CBE29; Fri, 24 Jun 2016 20:36:54 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBWim5ycWlAF; Fri, 24 Jun 2016 20:36:52 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 117BDBDCC; Fri, 24 Jun 2016 20:36:52 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1466797012; bh=3wAQwGiv+tA3kLI+WvGRoIvf+2A0sLw/YhyDSDOueyw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=G4AMrYKs9zKTU+lt8Se5BkChfrjJbFrwyvqkZ5xRGbm07dnwqk5Ij1nKe+2vvc4Ex zTHjL0TaXLFVQ5my76n+QopNnG08754n4fonmnEaAdEnWTk4zPJ1msltGdgZ4bebQA YrWMtM1yEmWKWepXsluAiyjgBP44f9sjcrroOrMQ= To: adrian@olddog.co.uk, 'Joseph Lorenzo Hall' , 'IETF discussion list' , saag@ietf.org References: <576D899F.7000000@cdt.org> <01c101d1ce4f$51d53300$f57f9900$@olddog.co.uk> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <576D8BD3.1040704@cs.tcd.ie> Date: Fri, 24 Jun 2016 20:36:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <01c101d1ce4f$51d53300$f57f9900$@olddog.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000203090706040404050307" Archived-At: Subject: Re: [saag] side event Wed. 20 July at IETF 96: "Open Debate on the Politics of Encryption" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 19:36:59 -0000 This is a cryptographically signed message in MIME format. --------------ms000203090706040404050307 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sadly, (or maybe gladly), the saag agenda is full, as we stated on the saag list earlier. But a quick open-mic report would be appreciated. An email to the saag list would be even better. S. On 24/06/16 20:33, Adrian Farrel wrote: > Maybe the SAAG co-chairs could be persuaded to put you on the agenda on= Thursday to give a ten minute report on what happened so that those of u= s who will be paying attention to the IETF all week don't need to complet= ely miss out on this. >=20 > Adrian >=20 >> -----Original Message----- >> From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Joseph Lorenzo = Hall >> Sent: 24 June 2016 20:27 >> To: IETF discussion list; saag@ietf.org >> Subject: side event Wed. 20 July at IETF 96: "Open Debate on the Polit= ics of >> Encryption" >> >> Dear IETFers, >> >> Wikimedia Germany and the Global Public Policy Insitute will be hostin= g >> the following event on Wednesday evening of IETF week. >> >> (Yes, it is scheduled during the IETF plenary on Wednesday evening. We= >> hope some of you might make it regardless as it's only 15m away from t= he >> IETF venue.) >> >> RSVP required. best, Joe >> >> ---- >> >> Open Debate on the Politics of Encryption >> >> In modern democracies, societies are built not only on checks and >> balances but also on the notion of trust. In the digital age, trust is= >> strengthened through a variety of technologies that provide for online= >> privacy and security. Encryption technologies are one key example. The= y >> allow users to securely communicate and do business online, and to >> protect data on a computer, a phone or in the cloud. However, those >> technologies are also available for less benevolent purposes, providin= g >> criminals with means to protect their communication and data. This has= >> put encryption at the centre of a debate on the tension between online= >> security and the notion of national security. Even after years of >> struggles - most recently between the FBI and Apple - battle lines >> remain murky, and key questions unanswered. >> >> Are law enforcement agencies really "going dark"? Should (and can) >> societies make any compromises on the use of encryption technologies? >> What are the ethical obligations for the technical and academic >> communities? If multistakeholder institutions, such as the IETF, set >> standards on encryption that will be adopted broadly, how does >> multistakeholder governance impact best practices, the development and= >> the implementation of such standards? What effect had the Snowden >> disclosures on IETF processes? If we accept the broad and easy use of >> encryption technologies, should government agencies have other tools a= t >> hand to fight criminals? And finally, where do we stand on this debate= >> in Germany and what can we do to help define a united European positio= n? >> >> On Wednesday, 20 July 2016 - on the occasion of this year's IETF meeti= ng >> being held in Berlin - we will address these and similar questions in = an >> open debate on the politics of encryption. The discussion will be >> launched by a conversation between Joe Hall (Center for Democracy & >> Technology, CDT), Linus Neumann (Chaos Computer Club, CCC) and Christi= ne >> Runnegar (tbc; Internet Society, ISOC), and moderated by Mirko Hohmann= >> (Global Public Policy Institute, GPPi). >> >> All guests and participants are invited to join the debate and to open= ly >> discuss the role that civil society and the technical community could >> and should play in defining our approach to encryption technologies, a= nd >> more widely in Internet policy and governance. >> >> The discussion will be held in English. >> >> When: >> Wednesday, 20 July 2016 >> >> Programme: >> >> 18:30 - Arrival and welcoming snack >> 19:00 - Panel discussion >> 19:45 - Open debate with all guests >> 20:30 - Food, drinks and networking >> >> Where: >> Wikimedia Germany >> Tempelhofer Ufer 23/24 - 10963 Berlin >> Room Mosaik >> >> The meeting is the second in a series of events that aims to bring >> together different actors from civil society and academia who are >> interested in international internet policy and its impact on the >> national level. These networking meetings will take place three times >> per year, in Berlin, Germany. They are organised by several civil >> society groups and academic institutions, including the Global Interne= t >> Governance Academic Network (GigaNet), Medienstadt Leipzig e.V., the W= ZB >> Berlin Social Science Center, the Global Public Policy Institute (GPPi= ), >> the IGF academy and the German section of the Internet Governance Foru= m >> (IGF-D). All stakeholder groups are welcome to join the meetings. This= >> series of events is supported by ICANN and Wikimedia Germany. >> >> Please contact us for suggestions regarding potential future topics. >> >> Participation is free but registration is required. RSVP via email to:= >> >> Lorena Jaume-Palasi: l.jaume-palasi@irights-lab.de >> Julia Pohle: julia.pohle@wzb.eu >> >> -- >> Joseph Lorenzo Hall >> Chief Technologist, Center for Democracy & Technology [https://www.cdt= =2Eorg] >> 1401 K ST NW STE 200, Washington DC 20005-3497 >> e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key >> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --------------ms000203090706040404050307 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MjQx OTM2NTFaMC8GCSqGSIb3DQEJBDEiBCDOvLD9o34Vtu2keJy1LqOb7f5Lf1keXUE4ok3pHrg4 dzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAm8wXZHi47YdODAkVk8LEaw96RAr8AceIhKcNw9CSU/rbsSDLV9Nwn E1uMLkVrQfl81mm3+0A/Z9hLqLIU+JbovHxllr4+dpO4k1Sn4a9ozmqFoS5puGxGseP6snUZ ILyh6sM4VYJnyWmrSUS0UWEObUI+9OyeTC8K62L98zVQXO//5NwOb8fnyHkeWo2SBvJq/49X vDErTSwpneKitrquPmpMyOWApsVUhO3cEZ1CitNIDbkDIdrDBW+23wcrqON/DJ1w4p5gmqrn yHr64Pw5rxtieqoR3vJFBzKlux/kYrGkkWgo8aXQuu6Y/YTZX0ncvnQViQJI44WSfFU+kpPu AAAAAAAA --------------ms000203090706040404050307-- From nobody Fri Jun 24 12:45:51 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D03512D595 for ; Fri, 24 Jun 2016 12:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owpRycpI9WGe for ; Fri, 24 Jun 2016 12:45:42 -0700 (PDT) Received: from nm12-vm2.bullet.mail.ne1.yahoo.com (nm12-vm2.bullet.mail.ne1.yahoo.com [98.138.91.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9087812D5CE for ; Fri, 24 Jun 2016 12:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1466797541; bh=KbKpTTOKVldyB4hlam2priCKy4+eMUED2k0QGIgV944=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=Y+pLxR6SwGdgfnwaPTCMKH4u2GiskGGe5R1Q0hWnhXPe51kVoKsiozOxhXLvNQhTwHMQCP5GosCF/jNwpeObAlRWd2OZgmzl2AtuuwQryznQjPLF2XTcMH8D0c8A9sAf9Vi7urzsUtq+2W9EQLwUsRJdiMHBHPc1E9vG/V76O9QeiuyKZX6LxT2fkNN1KG7Co3Z9zGJyy99pJUVZD0t/glxFo0lxnfHxsX8fO2CBMsjFQQXpR0Ti7f7dlGbAUs0V1BvI9UkX1aLqFCEQsRs1gZE43zmXvZf7n7Tl1vQ/5oEpkdZzUTNB5i3rrzQaylkA3tODnp3qjyM6jjZKLsP3PA== Received: from [98.138.101.131] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 24 Jun 2016 19:45:41 -0000 Received: from [98.138.88.238] by tm19.bullet.mail.ne1.yahoo.com with NNFMP; 24 Jun 2016 19:45:41 -0000 Received: from [127.0.0.1] by omp1038.mail.ne1.yahoo.com with NNFMP; 24 Jun 2016 19:45:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 772555.71499.bm@omp1038.mail.ne1.yahoo.com X-YMail-OSG: VR_hi6oVM1lcXpzKmb.REs_MahI_Kz23ibpI5kw28KD6q17hnLcuc2EteJ76sIo ARRPIxh6QWgpxGbxuyLGEDLpmnOD.Cn8POU2ZSMNdMp9MOGBhwSLC8ObZy0eW1oU4lkdGRVQ165e 3_hP_0yCWXxrTycNE6BNk0F_hQGREkDE0pRvg0YhDJ_cdgtBs_aWyiVFk1kPQLX5o9eE_.riFa7G GlI28MCX5sa4XjAKQItnxwhtfloS90a.lC6ebCwF2uvAK0DpF._OysvWtxzT47YGU5VMP7JF5JpW zcv6uxn_J2TvlnuyyuZno44iN.QzmrbHBAj0TCHS.lRz90r__SuYZUxw821O2oitzmOu.MFiz6fl gYQJx2IY1ZB.ajOxQdyLMaepgC_IIMJ_upV.Ypdr9_SdotGBpfItA.tYaHzAriBTspyMuqrhXnXu h_qRuv7_FmdwtF91gcaL6NyR6PqT4p9GFkM5S.Yk_84kkNnj40y9HcQPOazwAjOVe0lMmi54IN6u H8D.bD2Z.OPMrTyex4XJZ7KafTD6_K5z__jYFireTNrP1.5WqmqP8wZSo Received: from jws100103.mail.ne1.yahoo.com by sendmailws132.mail.ne1.yahoo.com; Fri, 24 Jun 2016 19:45:41 +0000; 1466797541.230 Date: Fri, 24 Jun 2016 19:45:40 +0000 (UTC) From: To: Joseph Lorenzo Hall , IETF discussion list , "saag@ietf.org" Message-ID: <2015026497.912497.1466797540856.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <576D899F.7000000@cdt.org> References: <576D899F.7000000@cdt.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_912496_498286661.1466797540849" Archived-At: Subject: Re: [saag] side event Wed. 20 July at IETF 96: "Open Debate on the Politics of Encryption" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 19:45:45 -0000 ------=_Part_912496_498286661.1466797540849 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Joe, I would like to RSVP for this.=C2=A0Thanks, Nalini ElkinsInside Products, Inc.www.insidethestack.com(831) 659-8360 From: Joseph Lorenzo Hall To: IETF discussion list ; saag@ietf.org=20 Sent: Friday, June 24, 2016 12:27 PM Subject: side event Wed. 20 July at IETF 96: "Open Debate on the Politics = of Encryption" =20 Dear IETFers, Wikimedia Germany and the Global Public Policy Insitute will be hosting the following event on Wednesday evening of IETF week. (Yes, it is scheduled during the IETF plenary on Wednesday evening. We hope some of you might make it regardless as it's only 15m away from the IETF venue.) RSVP required. best, Joe ---- Open Debate on the Politics of Encryption In modern democracies, societies are built not only on checks and balances but also on the notion of trust. In the digital age, trust is strengthened through a variety of technologies that provide for online privacy and security. Encryption technologies are one key example. They allow users to securely communicate and do business online, and to protect data on a computer, a phone or in the cloud. However, those technologies are also available for less benevolent purposes, providing criminals with means to protect their communication and data. This has put encryption at the centre of a debate on the tension between online security and the notion of national security. Even after years of struggles - most recently between the FBI and Apple - battle lines remain murky, and key questions unanswered. Are law enforcement agencies really "going dark"? Should (and can) societies make any compromises on the use of encryption technologies? What are the ethical obligations for the technical and academic communities? If multistakeholder institutions, such as the IETF, set standards on encryption that will be adopted broadly, how does multistakeholder governance impact best practices, the development and the implementation of such standards? What effect had the Snowden disclosures on IETF processes? If we accept the broad and easy use of encryption technologies, should government agencies have other tools at hand to fight criminals? And finally, where do we stand on this debate in Germany and what can we do to help define a united European position? On Wednesday, 20 July 2016 - on the occasion of this year's IETF meeting being held in Berlin - we will address these and similar questions in an open debate on the politics of encryption. The discussion will be launched by a conversation between Joe Hall (Center for Democracy & Technology, CDT), Linus Neumann (Chaos Computer Club, CCC) and Christine Runnegar (tbc; Internet Society, ISOC), and moderated by Mirko Hohmann (Global Public Policy Institute, GPPi). All guests and participants are invited to join the debate and to openly discuss the role that civil society and the technical community could and should play in defining our approach to encryption technologies, and more widely in Internet policy and governance. The discussion will be held in English. When: Wednesday, 20 July 2016 Programme: 18:30 - Arrival and welcoming snack 19:00 - Panel discussion 19:45 - Open debate with all guests 20:30 - Food, drinks and networking Where: Wikimedia Germany Tempelhofer Ufer 23/24 - 10963 Berlin Room Mosaik The meeting is the second in a series of events that aims to bring together different actors from civil society and academia who are interested in international internet policy and its impact on the national level. These networking meetings will take place three times per year, in Berlin, Germany. They are organised by several civil society groups and academic institutions, including the Global Internet Governance Academic Network (GigaNet), Medienstadt Leipzig e.V., the WZB Berlin Social Science Center, the Global Public Policy Institute (GPPi), the IGF academy and the German section of the Internet Governance Forum (IGF-D). All stakeholder groups are welcome to join the meetings. This series of events is supported by ICANN and Wikimedia Germany. Please contact us for suggestions regarding potential future topics. Participation is free but registration is required. RSVP via email to: Lorena Jaume-Palasi: l.jaume-palasi@irights-lab.de Julia Pohle: julia.pohle@wzb.eu --=20 Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10=C2=A0 1607 5F86 6987 40A9 A871 ------=_Part_912496_498286661.1466797540849 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Joe,

=
I would like to RSVP for this.
 
Thanks,

Nalini Elk= ins
Inside Products, Inc.
www.insidethestack.com
<= div>(831) 659-8360


From: J= oseph Lorenzo Hall <joe@cdt.org>
To: IETF discussion list <ietf@ietf.org>; saag@ietf.= org
Sent: Friday, Jun= e 24, 2016 12:27 PM
Subject: side event Wed. 20 July at IETF 96: "Open Debate on the Politics of = Encryption"

Dear IETFers,

Wikimedia Germany = and the Global Public Policy Insitute will be hosting
the following even= t on Wednesday evening of IETF week.

(Yes, it is scheduled during th= e IETF plenary on Wednesday evening. We
hope some of you might make it r= egardless as it's only 15m away from the
IETF venue.)

RSVP requir= ed. best, Joe

----

Open Debate on the Politics of Encryption<= br>
In modern democracies, societies are built not only on checks andbalances but also on the notion of trust. In the digital age, trust is
= strengthened through a variety of technologies that provide for online
p= rivacy and security. Encryption technologies are one key example. They
a= llow users to securely communicate and do business online, and to
protec= t data on a computer, a phone or in the cloud. However, those
technologi= es are also available for less benevolent purposes, providing
criminals = with means to protect their communication and data. This has
put encrypt= ion at the centre of a debate on the tension between online
security and= the notion of national security. Even after years of
struggles - most r= ecently between the FBI and Apple - battle lines
remain murky, and key q= uestions unanswered.

Are law enforcement agencies really "going dark= "? Should (and can)
societies make any compromises on the use of encrypt= ion technologies?
What are the ethical obligations for the technical and= academic
communities? If multistakeholder institutions, such as the IET= F, set
standards on encryption that will be adopted broadly, how doesmultistakeholder governance impact best practices, the development and
= the implementation of such standards? What effect had the Snowden
disclo= sures on IETF processes? If we accept the broad and easy use of
encrypti= on technologies, should government agencies have other tools at
hand to = fight criminals? And finally, where do we stand on this debate
in German= y and what can we do to help define a united European position?

On W= ednesday, 20 July 2016 - on the occasion of this year's IETF meeting
bei= ng held in Berlin - we will address these and similar questions in an
op= en debate on the politics of encryption. The discussion will be
launched= by a conversation between Joe Hall (Center for Democracy &
Technolo= gy, CDT), Linus Neumann (Chaos Computer Club, CCC) and Christine
Runnega= r (tbc; Internet Society, ISOC), and moderated by Mirko Hohmann
(Global = Public Policy Institute, GPPi).

All guests and participants are invi= ted to join the debate and to openly
discuss the role that civil society= and the technical community could
and should play in defining our appro= ach to encryption technologies, and
more widely in Internet policy and g= overnance.

The discussion will be held in English.

When:
W= ednesday, 20 July 2016

Programme:

18:30 - Arrival and welcomi= ng snack
19:00 - Panel discussion
19:45 - Open debate with all guests=
20:30 - Food, drinks and networking

Where:
Wikimedia Germany<= br>Tempelhofer Ufer 23/24 - 10963 Berlin
Room Mosaik

The meeting = is the second in a series of events that aims to bring
together differen= t actors from civil society and academia who are
interested in internati= onal internet policy and its impact on the
national level. These network= ing meetings will take place three times
per year, in Berlin, Germany. T= hey are organised by several civil
society groups and academic instituti= ons, including the Global Internet
Governance Academic Network (GigaNet)= , Medienstadt Leipzig e.V., the WZB
Berlin Social Science Center, the Gl= obal Public Policy Institute (GPPi),
the IGF academy and the German sect= ion of the Internet Governance Forum
(IGF-D). All stakeholder groups are= welcome to join the meetings. This
series of events is supported by ICA= NN and Wikimedia Germany.

Please contact us for suggestions regardin= g potential future topics.

Participation is free but registration is= required. RSVP via email to:

Lorena Jaume-Palasi: l.jaume-palasi@irights-lab.de
Julia Pohle: julia.pohle@wzb.eu=

--
Joseph Lorenzo Hall
Chief Technologist, Center for De= mocracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-349= 7
e: joe@c= dt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2= 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871


------=_Part_912496_498286661.1466797540849-- From nobody Fri Jun 24 13:31:52 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198ED12D67C for ; Fri, 24 Jun 2016 13:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pZ6NfX4cB5B for ; Fri, 24 Jun 2016 13:31:48 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6CB12D1A9 for ; Fri, 24 Jun 2016 13:31:48 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id r2so130623973oih.2 for ; Fri, 24 Jun 2016 13:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nE/egEvXEG4gYvyanA4nRtqcoUuZOaRb3onpRWRFxwY=; b=qEPot9WgknAS2P0k/7oxc/2qDJbQfrnnkcVzhtvk8eFX+2Aeti8ntfQvY2wumbWjNJ GcaU4MjGpe3+p0cft9AONAPTD3NFaYIZosRvC7bbrj2SIZNFfpYakx0AyFpcpXIe+Cvg 6wtcmKeqQAcRQv0jbUjlD/0iKMmUDQrpikz7U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nE/egEvXEG4gYvyanA4nRtqcoUuZOaRb3onpRWRFxwY=; b=mRMJCg5UUKR43eYwxOhQhzNj1cINLrYa/C2HNrQNZA/T9zyySatADz/6Ydalpw0jTI phV4NQONRIVkBp9t9Ek5vxU5FdlBOChRy/LSXDjT56+E+/p2OijnSJGqRZGZ6wsOOiNj 11lyDAqEdhZY7qEc1HX3ejQiGB4AOk5No90zrBd4+IuEI0qPxGYET2wiYrAnWtRzjsvj lQcUWPJ7yu1PoVxTNCwX7+phaF9VVLJYxsWtqU0trNbUWj/FNhGnitWVMzlf76IgqSgJ AA9vm2XSrZOlwhiGLlu+B5YtoZjN1/iyNtE+KKAHPFkHduINo6rjNsQj3/8WARhuvfCV llSw== X-Gm-Message-State: ALyK8tJfyqjTUC1FHime/3sA11M1joFhHxjFHxiNgB6qOJPa48EkVls0MedocVKn45u5Xa5if3IEObMDndKshgto X-Received: by 10.157.49.125 with SMTP id v58mr4367096otd.97.1466800307654; Fri, 24 Jun 2016 13:31:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.0.200 with HTTP; Fri, 24 Jun 2016 13:31:28 -0700 (PDT) In-Reply-To: <576D8BD3.1040704@cs.tcd.ie> References: <576D899F.7000000@cdt.org> <01c101d1ce4f$51d53300$f57f9900$@olddog.co.uk> <576D8BD3.1040704@cs.tcd.ie> From: Joseph Lorenzo Hall Date: Fri, 24 Jun 2016 16:31:28 -0400 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: adrian@olddog.co.uk, saag@ietf.org Subject: Re: [saag] side event Wed. 20 July at IETF 96: "Open Debate on the Politics of Encryption" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 20:31:51 -0000 Happy to do an email report and supplement from the mic. Apologies about scheduling but you can imagine there are just no good times during IETF week! On Fri, Jun 24, 2016 at 3:36 PM, Stephen Farrell wrote: > > Sadly, (or maybe gladly), the saag agenda is full, as we stated on > the saag list earlier. But a quick open-mic report would be appreciated. > An email to the saag list would be even better. > > S. > > On 24/06/16 20:33, Adrian Farrel wrote: >> Maybe the SAAG co-chairs could be persuaded to put you on the agenda on Thursday to give a ten minute report on what happened so that those of us who will be paying attention to the IETF all week don't need to completely miss out on this. >> >> Adrian >> >>> -----Original Message----- >>> From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Joseph Lorenzo Hall >>> Sent: 24 June 2016 20:27 >>> To: IETF discussion list; saag@ietf.org >>> Subject: side event Wed. 20 July at IETF 96: "Open Debate on the Politics of >>> Encryption" >>> >>> Dear IETFers, >>> >>> Wikimedia Germany and the Global Public Policy Insitute will be hosting >>> the following event on Wednesday evening of IETF week. >>> >>> (Yes, it is scheduled during the IETF plenary on Wednesday evening. We >>> hope some of you might make it regardless as it's only 15m away from the >>> IETF venue.) >>> >>> RSVP required. best, Joe >>> >>> ---- >>> >>> Open Debate on the Politics of Encryption >>> >>> In modern democracies, societies are built not only on checks and >>> balances but also on the notion of trust. In the digital age, trust is >>> strengthened through a variety of technologies that provide for online >>> privacy and security. Encryption technologies are one key example. They >>> allow users to securely communicate and do business online, and to >>> protect data on a computer, a phone or in the cloud. However, those >>> technologies are also available for less benevolent purposes, providing >>> criminals with means to protect their communication and data. This has >>> put encryption at the centre of a debate on the tension between online >>> security and the notion of national security. Even after years of >>> struggles - most recently between the FBI and Apple - battle lines >>> remain murky, and key questions unanswered. >>> >>> Are law enforcement agencies really "going dark"? Should (and can) >>> societies make any compromises on the use of encryption technologies? >>> What are the ethical obligations for the technical and academic >>> communities? If multistakeholder institutions, such as the IETF, set >>> standards on encryption that will be adopted broadly, how does >>> multistakeholder governance impact best practices, the development and >>> the implementation of such standards? What effect had the Snowden >>> disclosures on IETF processes? If we accept the broad and easy use of >>> encryption technologies, should government agencies have other tools at >>> hand to fight criminals? And finally, where do we stand on this debate >>> in Germany and what can we do to help define a united European position? >>> >>> On Wednesday, 20 July 2016 - on the occasion of this year's IETF meeting >>> being held in Berlin - we will address these and similar questions in an >>> open debate on the politics of encryption. The discussion will be >>> launched by a conversation between Joe Hall (Center for Democracy & >>> Technology, CDT), Linus Neumann (Chaos Computer Club, CCC) and Christine >>> Runnegar (tbc; Internet Society, ISOC), and moderated by Mirko Hohmann >>> (Global Public Policy Institute, GPPi). >>> >>> All guests and participants are invited to join the debate and to openly >>> discuss the role that civil society and the technical community could >>> and should play in defining our approach to encryption technologies, and >>> more widely in Internet policy and governance. >>> >>> The discussion will be held in English. >>> >>> When: >>> Wednesday, 20 July 2016 >>> >>> Programme: >>> >>> 18:30 - Arrival and welcoming snack >>> 19:00 - Panel discussion >>> 19:45 - Open debate with all guests >>> 20:30 - Food, drinks and networking >>> >>> Where: >>> Wikimedia Germany >>> Tempelhofer Ufer 23/24 - 10963 Berlin >>> Room Mosaik >>> >>> The meeting is the second in a series of events that aims to bring >>> together different actors from civil society and academia who are >>> interested in international internet policy and its impact on the >>> national level. These networking meetings will take place three times >>> per year, in Berlin, Germany. They are organised by several civil >>> society groups and academic institutions, including the Global Internet >>> Governance Academic Network (GigaNet), Medienstadt Leipzig e.V., the WZB >>> Berlin Social Science Center, the Global Public Policy Institute (GPPi), >>> the IGF academy and the German section of the Internet Governance Forum >>> (IGF-D). All stakeholder groups are welcome to join the meetings. This >>> series of events is supported by ICANN and Wikimedia Germany. >>> >>> Please contact us for suggestions regarding potential future topics. >>> >>> Participation is free but registration is required. RSVP via email to: >>> >>> Lorena Jaume-Palasi: l.jaume-palasi@irights-lab.de >>> Julia Pohle: julia.pohle@wzb.eu >>> >>> -- >>> Joseph Lorenzo Hall >>> Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] >>> 1401 K ST NW STE 200, Washington DC 20005-3497 >>> e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key >>> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 From nobody Fri Jun 24 18:53:54 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA48712D1B8 for ; Fri, 24 Jun 2016 18:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thunk.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijNz_sNG2V4i for ; Fri, 24 Jun 2016 18:53:51 -0700 (PDT) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C86812D0C0 for ; Fri, 24 Jun 2016 18:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=E7mq5B0jl4ir6Ff28EvO4y2ymdUH4HwVeSO8eP5EDR4=; b=JZawgzO5WEpNFXF+Tx8cu6bsQTWrgajIlYVJ7yqUMgTxkcrPKq1J/BkBINCkOdgVMlEvKQO9C7QHGalpYRV1jl5fA4qOf92N0chl8crPt9X5rivVqarAEMlgjlE/E3bOXJodXF00mVtcbydxPWBTec5O0rRcCXhFsoHXVoNR7Ac=; Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.84_2) (envelope-from ) id 1bGcn5-00006W-GT; Sat, 25 Jun 2016 01:53:47 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 3AAA78219C9; Fri, 24 Jun 2016 21:53:46 -0400 (EDT) Date: Fri, 24 Jun 2016 21:53:46 -0400 From: Theodore Ts'o To: Joseph Lorenzo Hall Message-ID: <20160625015346.GK31887@thunk.org> References: <576D899F.7000000@cdt.org> <01c101d1ce4f$51d53300$f57f9900$@olddog.co.uk> <576D8BD3.1040704@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Archived-At: Cc: adrian@olddog.co.uk, saag@ietf.org Subject: Re: [saag] side event Wed. 20 July at IETF 96: "Open Debate on the Politics of Encryption" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 01:53:53 -0000 On Fri, Jun 24, 2016 at 04:31:28PM -0400, Joseph Lorenzo Hall wrote: > Happy to do an email report and supplement from the mic. > > Apologies about scheduling but you can imagine there are just no good > times during IETF week! Is a video of the debate going to be made available? (e.g., on You Tube, etc.)? Thanks, - Ted From nobody Sat Jun 25 03:26:52 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7762812D5D0 for ; Sat, 25 Jun 2016 03:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PXFbuVjPT4D for ; Sat, 25 Jun 2016 03:26:48 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B7F12D1D2 for ; Sat, 25 Jun 2016 03:26:48 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id d185so180047814vkg.0 for ; Sat, 25 Jun 2016 03:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=lT9KGLiIote5sS3hjMtxriwvFVviRAYS1oYJEEr1YZY=; b=Vi5LyeMdVjbPAlGGgFRNUUXRmdnip5vcD4CtAajtv47/Oiz+tk4QtJDIezSEFdcYAj VAkNPbh4OaVW7QEM/RE/EHF6jLMdG5KKQDglhy67Zc3WCbz6lEL0VbchXW+OeCx1Lnun +jtgn+VL3aGdGryPo6JeIuZxqVBIOXeDAfrPI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=lT9KGLiIote5sS3hjMtxriwvFVviRAYS1oYJEEr1YZY=; b=hBTiCH3cbFfrmmpJi4IkTl9Qn8/OtZjGKrXxUqytJMNVtDIxYxv9spPC9tEeHE6OFN izMDurRkfTfavi19JU8uenyyKpEZM8zgF7J3mf3jUDE3bOGcXP7ygn3zPoEhqCvzrBiZ kcHkaBmddhH/cVNhJSDLqvt7vOHiGPJZZEtiKY+jmruNK83DSfjI3YWo0FdT/Lu0+xQB aJGvqYp+C53a6bWidEWGthX9OwhyKj2Oli4ppuD/i+JIzG4bCciXyS6gsEf1hSKRXClI zRKG/45BPpm6xOCp2kr06CNqHr4vCvCBC6fSXLiFcJhb6OFnIpo/zFb21G2oOMmCoYk8 4+gQ== X-Gm-Message-State: ALyK8tKHMC/wNqGG8HN3wg+li4fld2pkWQHoXDsydGflWhykm/nh1LnNE+Qb0EjGorZySHY8hX2CjzrU3Zg8LTVu MIME-Version: 1.0 X-Received: by 10.159.38.39 with SMTP id 36mr4520341uag.30.1466850407711; Sat, 25 Jun 2016 03:26:47 -0700 (PDT) Received: by 10.103.29.71 with HTTP; Sat, 25 Jun 2016 03:26:47 -0700 (PDT) In-Reply-To: <20160625015346.GK31887@thunk.org> References: <576D899F.7000000@cdt.org> <01c101d1ce4f$51d53300$f57f9900$@olddog.co.uk> <576D8BD3.1040704@cs.tcd.ie> <20160625015346.GK31887@thunk.org> Date: Sat, 25 Jun 2016 06:26:47 -0400 Message-ID: From: Joseph Lorenzo Hall To: "Theodore Ts'o" Content-Type: multipart/alternative; boundary=001a113bcdc47d9c21053617b9b1 Archived-At: Cc: "adrian@olddog.co.uk" , "saag@ietf.org" Subject: Re: [saag] side event Wed. 20 July at IETF 96: "Open Debate on the Politics of Encryption" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 10:26:50 -0000 --001a113bcdc47d9c21053617b9b1 Content-Type: text/plain; charset=UTF-8 I am not sure but will update SAAG when I know On Friday, June 24, 2016, Theodore Ts'o wrote: > On Fri, Jun 24, 2016 at 04:31:28PM -0400, Joseph Lorenzo Hall wrote: > > Happy to do an email report and supplement from the mic. > > > > Apologies about scheduling but you can imagine there are just no good > > times during IETF week! > > Is a video of the debate going to be made available? (e.g., on You Tube, > etc.)? > > Thanks, > > - Ted > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 --001a113bcdc47d9c21053617b9b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am not sure but will update SAAG when I know

On Frida= y, June 24, 2016, Theodore Ts'o <ty= tso@mit.edu> wrote:
On Fri, Jun 24= , 2016 at 04:31:28PM -0400, Joseph Lorenzo Hall wrote:
> Happy to do an email report and supplement from the mic.
>
> Apologies about scheduling but you can imagine there are just no good<= br> > times during IETF week!

Is a video of the=C2=A0 debate going to be made available?=C2=A0 (e.g., on = You Tube, etc.)?

Thanks,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 - Ted


--
Joseph Lorenzo Hall
Chief Technologist, Cent= er for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC= 20005-3497
e: joe@cdt= .org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8= D7B 9F6D DBD3 4B10 =C2=A01607 5F86 6987 40A9 A871
--001a113bcdc47d9c21053617b9b1-- From nobody Sun Jun 26 22:07:24 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C008012B062; Sun, 26 Jun 2016 22:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0BfsvdKv6KD; Sun, 26 Jun 2016 22:07:21 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F38812B011; Sun, 26 Jun 2016 22:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6147; q=dns/txt; s=iport; t=1467004040; x=1468213640; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=wekqB0SC/9TLFY8G/r1Pi9M12VjDoEDG8FJ4Fv1CT9o=; b=cB8UnuW+3/chO6PlGgW13kz4ZKkYztR9jI+AuAoUhlgODPjBFpDYxKqh 5gxQknVZbjCoprbp8fcLkNzlHJSxr4Qc/TS4vBpdy5MB14GQ6BuwlQEyS 1xrDUc+RXOxzXpHt1vW1r6CPP1sgXUA6fsM43DyJrsbSqT4R2vPHW2Ss/ 4=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBABbs3BX/xbLJq1chD9SuBiECoYYA?= =?us-ascii?q?oF3AQEBAQEBZieETQEBBCNCJAsYKgICVwYBDAYCAQEQiByuB494AQEBAQEFAQE?= =?us-ascii?q?BAQEBEw6IH4JWgTmCWREBgx2CWgWZAYMugWyJHYFphFSDC4Vcj39UghUmgTc6M?= =?us-ascii?q?ogjgTUBAQE?= X-IronPort-AV: E=Sophos;i="5.26,535,1459814400"; d="asc'?scan'208";a="636405558" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2016 05:07:18 +0000 Received: from [10.61.109.117] (dhcp-10-61-109-117.cisco.com [10.61.109.117]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u5R57HnV019948; Mon, 27 Jun 2016 05:07:17 GMT To: Joseph Lorenzo Hall , IETF discussion list , saag@ietf.org References: <576D899F.7000000@cdt.org> From: Eliot Lear Message-ID: Date: Mon, 27 Jun 2016 07:07:17 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <576D899F.7000000@cdt.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hvKGc30Wj8g9fXMWV4eujueOTNrVJv3FO" Archived-At: Subject: Re: [saag] side event Wed. 20 July at IETF 96: "Open Debate on the Politics of Encryption" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 05:07:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hvKGc30Wj8g9fXMWV4eujueOTNrVJv3FO Content-Type: multipart/mixed; boundary="iPopUogoJ9dipj9ptRfHeI014hGJbRwo8" From: Eliot Lear To: Joseph Lorenzo Hall , IETF discussion list , saag@ietf.org Message-ID: Subject: Re: side event Wed. 20 July at IETF 96: "Open Debate on the Politics of Encryption" References: <576D899F.7000000@cdt.org> In-Reply-To: <576D899F.7000000@cdt.org> --iPopUogoJ9dipj9ptRfHeI014hGJbRwo8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Joe, Thanks for forwarding. I have a question: is this a broad debate or a conversation amongst those who largely agree? As was discussed elsewhere it would be useful to have a variety of points of view on this subject, particularly some from the law enforcement community. The organizers attempted this at WEIS this past month but events in Florida tragically intervened. Eliot On 6/24/16 9:27 PM, Joseph Lorenzo Hall wrote: > Dear IETFers, > > Wikimedia Germany and the Global Public Policy Insitute will be hosting= > the following event on Wednesday evening of IETF week. > > (Yes, it is scheduled during the IETF plenary on Wednesday evening. We > hope some of you might make it regardless as it's only 15m away from th= e > IETF venue.) > > RSVP required. best, Joe > > ---- > > Open Debate on the Politics of Encryption > > In modern democracies, societies are built not only on checks and > balances but also on the notion of trust. In the digital age, trust is > strengthened through a variety of technologies that provide for online > privacy and security. Encryption technologies are one key example. They= > allow users to securely communicate and do business online, and to > protect data on a computer, a phone or in the cloud. However, those > technologies are also available for less benevolent purposes, providing= > criminals with means to protect their communication and data. This has > put encryption at the centre of a debate on the tension between online > security and the notion of national security. Even after years of > struggles - most recently between the FBI and Apple - battle lines > remain murky, and key questions unanswered. > > Are law enforcement agencies really "going dark"? Should (and can) > societies make any compromises on the use of encryption technologies? > What are the ethical obligations for the technical and academic > communities? If multistakeholder institutions, such as the IETF, set > standards on encryption that will be adopted broadly, how does > multistakeholder governance impact best practices, the development and > the implementation of such standards? What effect had the Snowden > disclosures on IETF processes? If we accept the broad and easy use of > encryption technologies, should government agencies have other tools at= > hand to fight criminals? And finally, where do we stand on this debate > in Germany and what can we do to help define a united European position= ? > > On Wednesday, 20 July 2016 - on the occasion of this year's IETF meetin= g > being held in Berlin - we will address these and similar questions in a= n > open debate on the politics of encryption. The discussion will be > launched by a conversation between Joe Hall (Center for Democracy & > Technology, CDT), Linus Neumann (Chaos Computer Club, CCC) and Christin= e > Runnegar (tbc; Internet Society, ISOC), and moderated by Mirko Hohmann > (Global Public Policy Institute, GPPi). > > All guests and participants are invited to join the debate and to openl= y > discuss the role that civil society and the technical community could > and should play in defining our approach to encryption technologies, an= d > more widely in Internet policy and governance. > > The discussion will be held in English. > > When: > Wednesday, 20 July 2016 > > Programme: > > 18:30 - Arrival and welcoming snack > 19:00 - Panel discussion > 19:45 - Open debate with all guests > 20:30 - Food, drinks and networking > > Where: > Wikimedia Germany > Tempelhofer Ufer 23/24 - 10963 Berlin > Room Mosaik > > The meeting is the second in a series of events that aims to bring > together different actors from civil society and academia who are > interested in international internet policy and its impact on the > national level. These networking meetings will take place three times > per year, in Berlin, Germany. They are organised by several civil > society groups and academic institutions, including the Global Internet= > Governance Academic Network (GigaNet), Medienstadt Leipzig e.V., the WZ= B > Berlin Social Science Center, the Global Public Policy Institute (GPPi)= , > the IGF academy and the German section of the Internet Governance Forum= > (IGF-D). All stakeholder groups are welcome to join the meetings. This > series of events is supported by ICANN and Wikimedia Germany. > > Please contact us for suggestions regarding potential future topics. > > Participation is free but registration is required. RSVP via email to: > > Lorena Jaume-Palasi: l.jaume-palasi@irights-lab.de > Julia Pohle: julia.pohle@wzb.eu > --iPopUogoJ9dipj9ptRfHeI014hGJbRwo8-- --hvKGc30Wj8g9fXMWV4eujueOTNrVJv3FO 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 iQEcBAEBCAAGBQJXcLSFAAoJEIe2a0bZ0noztxkIALrLbvOuGcFYLk1hVNjXofaH /ef8e/CQGJ+JEOblpYMQ9FB+y1TFsgexpGEDFdr6vmAk63dlTHnBfRVHbElK3aVL woo1zeL44GkJhizxceeavi1XuFkv/6ZLwNM8x4lOWH1NvFloOMXf/8wEEgNb0IBY Oy5Z7v6Bc5IwGhkqWQswXrWftLaZOC/+/rzbMKrYN0JQrZoURG7mHKPot4ETHgFN IFdeWiW8fYdrXswrecjB48r/QsNZyIMUWW8CDzI5NbjtfqgeQo3nro2QE4AySxJc oCKIX75Vha8D2/XsOD5n1qFqlIsj9OcVMNuABUIixzFFcVMWorCyWBXWKk9I1Vo= =2hjq -----END PGP SIGNATURE----- --hvKGc30Wj8g9fXMWV4eujueOTNrVJv3FO-- From nobody Mon Jun 27 03:15:36 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B3E12D12F for ; Mon, 27 Jun 2016 03:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKuHnRWVOolp for ; Mon, 27 Jun 2016 03:15:31 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4FD12D108 for ; Mon, 27 Jun 2016 03:15:31 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id c2so195394407vkg.1 for ; Mon, 27 Jun 2016 03:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=x9lweG3ULyCT4DHldVePkEm7KESkKSlpxKGyqMP9CYk=; b=EiEBw3pRVPdHt5qx4DxGhDA5HCY9ygbda7ovm6T2nxdqn6VpMJWeU1cWT1cVTxeurC bKcUi4xcW+NmrzJi6H4aBo717t8j7upGJt5D7Gsh9WNmacPoFpkL+xd3Uldlf3h0s968 INs8Mnx3uuPMrtluxHoDEXmohJH4wc/0XHYY8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=x9lweG3ULyCT4DHldVePkEm7KESkKSlpxKGyqMP9CYk=; b=A8NX+YtgyvRQ3B8cHEimNLCsHX9Kpf9rxpd5pfq3zpZM7rmyHEyeMhXoXoWio1rmZG Z7x777LDlJLjVCY11qSxMh/Srz0KTSCjMcRmtnxArRW1uYLtn07aaML4SGb/9tOeJFNh YtYu9bCs2gfci+wjasy5EEGqlB6OmGsPw7r9gM+nW4Bbmn/AgHF10LDSmBVjgKBBYoHX hk3QfQrVBLUuUsZhJtowMd8WumVS4NJvWWKXR702WlfU8w4uXEmbgxUlG45yf660mj6Y m/ZTqX6rwsbu4j7T5m12xNJgFQySMUEpJWptVJvTpeXKhwbd1MuByw8MGoO3e3r53Dxb /Qaw== X-Gm-Message-State: ALyK8tKxQFa6YKi5VQb2LHfqLAW/8TAcuiWR7bD05UGlvtGYH2KQHpuDyE9qbfJmDcnoECSggidZJk5Z20XQoFGO MIME-Version: 1.0 X-Received: by 10.31.10.82 with SMTP id 79mr6666629vkk.67.1467022530531; Mon, 27 Jun 2016 03:15:30 -0700 (PDT) Received: by 10.103.29.71 with HTTP; Mon, 27 Jun 2016 03:15:30 -0700 (PDT) In-Reply-To: References: <576D899F.7000000@cdt.org> Date: Mon, 27 Jun 2016 06:15:30 -0400 Message-ID: From: Joseph Lorenzo Hall To: Eliot Lear Content-Type: multipart/alternative; boundary=001a11457d64cf735305363fccf9 Archived-At: Cc: IETF discussion list , "saag@ietf.org" Subject: Re: [saag] side event Wed. 20 July at IETF 96: "Open Debate on the Politics of Encryption" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 10:15:34 -0000 --001a11457d64cf735305363fccf9 Content-Type: text/plain; charset=UTF-8 I'm not sure how much of a debate it will be, likely not much of one. And I'm not sure Christine as a former prosecutor (but now with ISOC) fits the LE mold. Frankly, I know the GPPI folks here and had offered to do something with them next time I would be in Germany. This is that thing. Feel free to reach out to them if you'd like to suggest someone. On Monday, June 27, 2016, Eliot Lear wrote: > Joe, > > Thanks for forwarding. I have a question: is this a broad debate or a > conversation amongst those who largely agree? As was discussed > elsewhere it would be useful to have a variety of points of view on this > subject, particularly some from the law enforcement community. The > organizers attempted this at WEIS this past month but events in Florida > tragically intervened. > > Eliot > > > > On 6/24/16 9:27 PM, Joseph Lorenzo Hall wrote: > > Dear IETFers, > > > > Wikimedia Germany and the Global Public Policy Insitute will be hosting > > the following event on Wednesday evening of IETF week. > > > > (Yes, it is scheduled during the IETF plenary on Wednesday evening. We > > hope some of you might make it regardless as it's only 15m away from the > > IETF venue.) > > > > RSVP required. best, Joe > > > > ---- > > > > Open Debate on the Politics of Encryption > > > > In modern democracies, societies are built not only on checks and > > balances but also on the notion of trust. In the digital age, trust is > > strengthened through a variety of technologies that provide for online > > privacy and security. Encryption technologies are one key example. They > > allow users to securely communicate and do business online, and to > > protect data on a computer, a phone or in the cloud. However, those > > technologies are also available for less benevolent purposes, providing > > criminals with means to protect their communication and data. This has > > put encryption at the centre of a debate on the tension between online > > security and the notion of national security. Even after years of > > struggles - most recently between the FBI and Apple - battle lines > > remain murky, and key questions unanswered. > > > > Are law enforcement agencies really "going dark"? Should (and can) > > societies make any compromises on the use of encryption technologies? > > What are the ethical obligations for the technical and academic > > communities? If multistakeholder institutions, such as the IETF, set > > standards on encryption that will be adopted broadly, how does > > multistakeholder governance impact best practices, the development and > > the implementation of such standards? What effect had the Snowden > > disclosures on IETF processes? If we accept the broad and easy use of > > encryption technologies, should government agencies have other tools at > > hand to fight criminals? And finally, where do we stand on this debate > > in Germany and what can we do to help define a united European position? > > > > On Wednesday, 20 July 2016 - on the occasion of this year's IETF meeting > > being held in Berlin - we will address these and similar questions in an > > open debate on the politics of encryption. The discussion will be > > launched by a conversation between Joe Hall (Center for Democracy & > > Technology, CDT), Linus Neumann (Chaos Computer Club, CCC) and Christine > > Runnegar (tbc; Internet Society, ISOC), and moderated by Mirko Hohmann > > (Global Public Policy Institute, GPPi). > > > > All guests and participants are invited to join the debate and to openly > > discuss the role that civil society and the technical community could > > and should play in defining our approach to encryption technologies, and > > more widely in Internet policy and governance. > > > > The discussion will be held in English. > > > > When: > > Wednesday, 20 July 2016 > > > > Programme: > > > > 18:30 - Arrival and welcoming snack > > 19:00 - Panel discussion > > 19:45 - Open debate with all guests > > 20:30 - Food, drinks and networking > > > > Where: > > Wikimedia Germany > > Tempelhofer Ufer 23/24 - 10963 Berlin > > Room Mosaik > > > > The meeting is the second in a series of events that aims to bring > > together different actors from civil society and academia who are > > interested in international internet policy and its impact on the > > national level. These networking meetings will take place three times > > per year, in Berlin, Germany. They are organised by several civil > > society groups and academic institutions, including the Global Internet > > Governance Academic Network (GigaNet), Medienstadt Leipzig e.V., the WZB > > Berlin Social Science Center, the Global Public Policy Institute (GPPi), > > the IGF academy and the German section of the Internet Governance Forum > > (IGF-D). All stakeholder groups are welcome to join the meetings. This > > series of events is supported by ICANN and Wikimedia Germany. > > > > Please contact us for suggestions regarding potential future topics. > > > > Participation is free but registration is required. RSVP via email to: > > > > Lorena Jaume-Palasi: l.jaume-palasi@irights-lab.de > > Julia Pohle: julia.pohle@wzb.eu > > > > > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 --001a11457d64cf735305363fccf9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm not sure how much of a debate it will be, likely not much of one. A= nd I'm not sure Christine as a former prosecutor (but now with ISOC) fi= ts the LE mold.

Frankly, I know the GPPI folks here and = had offered to do something with them next time I would be in Germany. This= is that thing. Feel free to reach out to them if you'd like to suggest= someone.

On Monday, June 27, 2016, Eliot Lear <lear@cisco.com> wrote:
Joe,

Thanks for forwarding.=C2=A0 I have a question: is this a broad debate or a=
conversation amongst those who largely agree?=C2=A0 As was discussed
elsewhere it would be useful to have a variety of points of view on this subject, particularly some from the law enforcement community.=C2=A0 The organizers attempted this at WEIS this past month but events in Florida
tragically intervened.

Eliot



On 6/24/16 9:27 PM, Joseph Lorenzo Hall wrote:
> Dear IETFers,
>
> Wikimedia Germany and the Global Public Policy Insitute will be hostin= g
> the following event on Wednesday evening of IETF week.
>
> (Yes, it is scheduled during the IETF plenary on Wednesday evening. We=
> hope some of you might make it regardless as it's only 15m away fr= om the
> IETF venue.)
>
> RSVP required. best, Joe
>
> ----
>
> Open Debate on the Politics of Encryption
>
> In modern democracies, societies are built not only on checks and
> balances but also on the notion of trust. In the digital age, trust is=
> strengthened through a variety of technologies that provide for online=
> privacy and security. Encryption technologies are one key example. The= y
> allow users to securely communicate and do business online, and to
> protect data on a computer, a phone or in the cloud. However, those > technologies are also available for less benevolent purposes, providin= g
> criminals with means to protect their communication and data. This has=
> put encryption at the centre of a debate on the tension between online=
> security and the notion of national security. Even after years of
> struggles - most recently between the FBI and Apple - battle lines
> remain murky, and key questions unanswered.
>
> Are law enforcement agencies really "going dark"? Should (an= d can)
> societies make any compromises on the use of encryption technologies?<= br> > What are the ethical obligations for the technical and academic
> communities? If multistakeholder institutions, such as the IETF, set > standards on encryption that will be adopted broadly, how does
> multistakeholder governance impact best practices, the development and=
> the implementation of such standards? What effect had the Snowden
> disclosures on IETF processes? If we accept the broad and easy use of<= br> > encryption technologies, should government agencies have other tools a= t
> hand to fight criminals? And finally, where do we stand on this debate=
> in Germany and what can we do to help define a united European positio= n?
>
> On Wednesday, 20 July 2016 - on the occasion of this year's IETF m= eeting
> being held in Berlin - we will address these and similar questions in = an
> open debate on the politics of encryption. The discussion will be
> launched by a conversation between Joe Hall (Center for Democracy &= ;
> Technology, CDT), Linus Neumann (Chaos Computer Club, CCC) and Christi= ne
> Runnegar (tbc; Internet Society, ISOC), and moderated by Mirko Hohmann=
> (Global Public Policy Institute, GPPi).
>
> All guests and participants are invited to join the debate and to open= ly
> discuss the role that civil society and the technical community could<= br> > and should play in defining our approach to encryption technologies, a= nd
> more widely in Internet policy and governance.
>
> The discussion will be held in English.
>
> When:
> Wednesday, 20 July 2016
>
> Programme:
>
> 18:30 - Arrival and welcoming snack
> 19:00 - Panel discussion
> 19:45 - Open debate with all guests
> 20:30 - Food, drinks and networking
>
> Where:
> Wikimedia Germany
> Tempelhofer Ufer 23/24 - 10963 Berlin
> Room Mosaik
>
> The meeting is the second in a series of events that aims to bring
> together different actors from civil society and academia who are
> interested in international internet policy and its impact on the
> national level. These networking meetings will take place three times<= br> > per year, in Berlin, Germany. They are organised by several civil
> society groups and academic institutions, including the Global Interne= t
> Governance Academic Network (GigaNet), Medienstadt Leipzig e.V., the W= ZB
> Berlin Social Science Center, the Global Public Policy Institute (GPPi= ),
> the IGF academy and the German section of the Internet Governance Foru= m
> (IGF-D). All stakeholder groups are welcome to join the meetings. This=
> series of events is supported by ICANN and Wikimedia Germany.
>
> Please contact us for suggestions regarding potential future topics. >
> Participation is free but registration is required. RSVP via email to:=
>
> Lorena Jaume-Palasi: l.jaume-palasi@irigh= ts-lab.de
> Julia Pohle: julia.pohle@wzb.eu
>




--
Joseph Lorenzo Hall
Chief Technologist= , Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washingto= n DC 20005-3497
e: joe= @cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3C= A2 8D7B 9F6D DBD3 4B10 =C2=A01607 5F86 6987 40A9 A871
--001a11457d64cf735305363fccf9-- From nobody Wed Jun 29 08:05:22 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D8612B004; Wed, 29 Jun 2016 08:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsgyKN38TREv; Wed, 29 Jun 2016 08:05:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3727012DF0C; Wed, 29 Jun 2016 08:04:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 083BFBE47; Wed, 29 Jun 2016 16:04:50 +0100 (IST) 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 XibsiNzxXeSp; Wed, 29 Jun 2016 16:04:49 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 602CCBE35; Wed, 29 Jun 2016 16:04:49 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1467212689; bh=TfSZdygX5OWgNnjFqar+DzFPh3TrO0bTiCEYiDMd/ys=; h=Subject:References:To:From:Date:In-Reply-To:From; b=1x9y6LGKCmosegqaP7HQ0UNUnl+vf2fVIM1/CRcXJO4CYqj/IycAhAkxblSMQjwTZ RP68WEioh4ArsQc8Rd2BJ70Gxnm6UvML/5NHRfuodVc9ab1HqnI1E86G8UxukLs1h0 gmzP5REKDw+8UN3fj3IXIPGzkOwrwRDtg8a7RzXg= References: <5773E34B.9080503@cs.tcd.ie> To: pkix , 'IETF SMIME' , "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <5773E34B.9080503@cs.tcd.ie> Message-ID: <5773E391.6080308@cs.tcd.ie> Date: Wed, 29 Jun 2016 16:04:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <5773E34B.9080503@cs.tcd.ie> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040806050400030107030207" Archived-At: Subject: [saag] Fwd: Re: [Spasm] WG Review: Some PKIX and SMIME (spasm) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 15:05:08 -0000 This is a cryptographically signed message in MIME format. --------------ms040806050400030107030207 Content-Type: multipart/mixed; boundary="------------040300090202030505070407" This is a multi-part message in MIME format. --------------040300090202030505070407 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI - a late name-change for a proposed WG. S. -------- Forwarded Message -------- Subject: Re: [Spasm] WG Review: Some PKIX and SMIME (spasm) Date: Wed, 29 Jun 2016 16:03:39 +0100 From: Stephen Farrell To: IETF-Announce CC: spasm@ietf.org, IETF-Discussion Hi, During chartering we got a comment that the proposed name of this WG might be considered insensitive. We don't need to have a discussion about that, as it makes little difference otherwise, but we will be changing the name of the proposed working group to: lamps - Limited Additional Mechanisms for PKIX and SMIME Thanks to Michael Jenkins for the suggestion on the current WG mailing list. [1] The secretariat will handle migrating the mailing list in the coming weeks, and the IETF96 agenda will be updated accordingly, assuming that the IESG approve the new working group on the telechat tomorrow. If approved, the announcement of the working group will use the new name, "lamps." There are no other substantive changes to the draft charter. [2] Thanks, S. [1] https://mailarchive.ietf.org/arch/msg/spasm/t4f5LKRJILn0KsLQdzA1fo8B1= lM [2] https://datatracker.ietf.org/doc/charter-ietf-spasm/ On 17/06/16 17:33, The IESG wrote: > A new IETF WG has been proposed in the Security Area. The IESG has not > made any determination yet. The following draft charter was submitted, > and is provided for informational purposes only. Please send your > comments to the IESG mailing list (iesg@ietf.org) by 2016-06-27. >=20 > Some PKIX and SMIME (spasm) > -----------------------------------------------------------------------= > Current status: Proposed WG >=20 > Chairs: > TBD >=20 > Assigned Area Director: > Stephen Farrell >=20 > Security Area Directors: > Stephen Farrell > Kathleen Moriarty > =20 > Mailing list: > Address: spasm@ietf.org > To subscribe: https://www.ietf.org/mailman/listinfo/spasm > Archive: https://www.ietf.org/mail-archive/web/spasm/ >=20 > Charter: https://datatracker.ietf.org/doc/charter-ietf-spasm/ >=20 >=20 > The PKIX and S/MIME Working Groups have been closed for some time. Som= e > updates have been proposed to the X.509 certificate documents produced = > by the PKIX Working Group and the electronic mail security documents=20 > produced by the S/MIME Working Group. >=20 > The SPASM (Some PKIX and S/MIME) Working Group is chartered to make > updates where there is a known constituency interested in real=20 > deployment and there is at least one sufficiently well specified=20 > approach to the update so that the working group can sensibly evaluate = > whether to adopt a proposal. The current charter encompasses updates t= o=20 > satisfy the following needs: >=20 > 1. Specify the way to include an i18n email address as a subject > alternative name and an issuer alternative name. > draft-melnikov-spasm-eai-addresses is a proposal in this space.=20 >=20 > 2. Specify the way to use authenticated encryption in S/MIME.=20 > draft-schaad-rfc5751-bis is a proposal in this space. >=20 > In addition, the SPASM Working Group may investigate other updates to=20 > the documents produced by the PKIX and S/MIME Working Groups, but the=20 > SPASM Working Group shall not adopt any of these potential work items=20 > without rechartering. No such re-chartering is envisaged until one or=20 > more of the above work items have been successfully delivered to the RF= C=20 > editor queue.=20 >=20 > Milestones: >=20 > TBD >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 --------------040300090202030505070407 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KU3Bhc20g bWFpbGluZyBsaXN0ClNwYXNtQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3Bhc20KCg== --------------040300090202030505070407-- --------------ms040806050400030107030207 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2Mjkx NTA0NDlaMC8GCSqGSIb3DQEJBDEiBCCXsFb9b1Hq5GoAOqRD5nc9F/F4pt20WA4GuW+y57EI dTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBGg7dl14m5ucG3d9VWLP+afXxPnODJICaIRYWJenNSuSfRlJXtMtgI //emTgieMmrL/A4yoKkAYMycuzt939T78kUQxjFCwzaL1g5v5Y1ATtIOrP0wchn5GOeOrZtx na7uQtVuEhlt7PsKseZBO+393A/yZIqbrtFXK1zQH+yMj6qxdMy+T/aC73ogNmDXDpfaekdI Je1CnId4f1uvtUJjSe3YGlwky2wk+dvfnCL9eQgg1TYUN8O1ZrFFa52RyrZQH2PgSmj7ABal RqGc+49ZCAASjTR7xnDVrsyAC+rVeA9Vm2j+NMLup/QlsMOeZw0kiJIEb/tODMUmPOQsbfQV AAAAAAAA --------------ms040806050400030107030207-- From nobody Thu Jun 30 02:22:51 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8002B12D940 for ; Thu, 30 Jun 2016 02:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtnXfh9p69mY for ; Thu, 30 Jun 2016 02:22:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97BE812D624 for ; Thu, 30 Jun 2016 02:22:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7D47EBDCA; Thu, 30 Jun 2016 10:22:45 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNB9SKGSSn1H; Thu, 30 Jun 2016 10:22:43 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7E897BE2F; Thu, 30 Jun 2016 10:22:43 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1467278563; bh=I9dYwMaTqBwHFDJAUPBAaZotbcZ+mGtvf6QV+0gWXP8=; h=From:Subject:Cc:To:Date:From; b=SOPxPvr630rX85yQRfmhgo+SYG+WU0/0xcK9Rk9ObnvejACFcaVu9D2AgsJocvGfy Dp+6GtZ3X4UZEWcliIcMDjXOG5fMELKyPWIesvEalMZS40zHsx8DDCAwO9SA1+rgBQ ZuJdOhHsjuYUdkgaD2GYFChPf72z5nZpE/fF09hc= From: Stephen Farrell To: "saag@ietf.org" Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5774E4E3.2030605@cs.tcd.ie> Date: Thu, 30 Jun 2016 10:22:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030809000109010309080304" Archived-At: Subject: [saag] RFC3552bis... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 09:22:49 -0000 This is a cryptographically signed message in MIME format. --------------ms030809000109010309080304 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, RFC3552/BCP72 [1] is about to become a teenager:-) For those of you that don't know it by heart, that's the one that tells folks what to put into their security considerations sections and it dates back to July 2003. Following on from discussion at saag in B-A, partly driven by the work Fernando and others have done on identifiers, but also other chats going back to the STRINT workshop, Kathleen and I have discussed what to do about all that and having re-read the text we reckon that now would be a good time to start work on an RFC3552bis document to replace the current one. In outline, we think the main tasks there we'd like to see happen would be to a) update numerous things that are out of date, b) add text about things that weren't so important in 2003, such as privacy, perhaps borrowing bits from RFC6973 [2] that make sense as BCP-like statements, and c) to make it as understandable and easy to grasp as possible and ideally a good bit shorter. Having figured out what we'd like, and being lazy ADs, we needed some other folks to do the actual work so we asked Yoav Nir and Magnus Westerlund (both cc'd) and we're delighted to say that they've agreed to be editors for this effort. (Thanks again to you both.) The overall plan then is roughly to:- - Kick off discussion now on the saag list (this mail) - Get folks' feedback on changes they'd like (if that gets too voluminous we'll start a new list) - Have a short slot at the saag session in Berlin where the editors can review the plan and get more feedback/comments - The editors will send some mail about tooling (e.g. if they want to use github, they'll say that etc.) - The editors will produce a -00 and we'll iterate on that until done - A more substantive discussion of remaining open issues in November at IETF97 if needed, (which we suspect will be needed:-) - Hopefully we end up ready for IETF LC around the end of the year or early in 2017. - We have what'll quite probably be a fun IETF LC:-) - Mid-2017: BCP72 will become the new RFC. So please do re-read [1,2] and send your comments on what you think needs changing to this list and/or the editors and/or to Kathleen or I as appropriate. Cheers, S&K. [1] https://tools.ietf.org/html/bcp72 [2] https://tools.ietf.org/html/rfc6973 --------------ms030809000109010309080304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MzAw OTIyNDNaMC8GCSqGSIb3DQEJBDEiBCBszMYex6bYt9VLqVifqfDzD5EQxNpfUVGDbAzObSQ/ dDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAZXAeYYDQ0HS7HNXp1i4hSJg3agUVqaR4U+hfJUrXikmHnTmQFTfI+ KW5Kib5fQ6sgziOygoHMm7mGQ5oSK+p2yI9x8hwYunX1tcKYOGunBbML3swujvzBZNQt3g4B AkvO0qSi+3BnDr9soQglUHxwztrOjI2WabkJKFrfstAQLVU/0RdxV5evg7VHBIXDp4tJEvnS o3AdPxikramkvRXDxHeM6D0+rDIStXdxbhuAkvjcNC7Jlj+wBY0OImR78VFk6RsSBuPKemoQ bodl1nnTGriqYnS1gdHPjkVmVvykxB8rGGyUA71M5oVXPrMzYQ1C3RMQQjGLoo/wdWuDrPiD AAAAAAAA --------------ms030809000109010309080304-- From nobody Thu Jun 30 14:00:02 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FA012D0A4 for ; Thu, 30 Jun 2016 14:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLSbRIiLEJmt for ; Thu, 30 Jun 2016 13:59:57 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7ADD12B01C for ; Thu, 30 Jun 2016 13:59:57 -0700 (PDT) Received: from [192.168.0.22] (cable-185-58-93-8.dynamic.telemach.ba [185.58.93.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8157380484; Thu, 30 Jun 2016 22:59:55 +0200 (CEST) To: Stephen Farrell , "saag@ietf.org" References: <5774E4E3.2030605@cs.tcd.ie> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <57758609.8090602@si6networks.com> Date: Thu, 30 Jun 2016 22:50:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <5774E4E3.2030605@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "privsec-program@iab.org" Subject: Re: [saag] RFC3552bis... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 21:00:00 -0000 On 06/30/2016 11:22 AM, Stephen Farrell wrote: > > - Kick off discussion now on the saag list (this mail) > - Get folks' feedback on changes they'd like (if that gets > too voluminous we'll start a new list) As could possibly be expected, we'd like to see additional requirements wrt transient numeric identifiers. Please see: draft-gont-numeric-ids-sec-considerations-00 (Security Considerations for Transient Numeric Identifiers Employed in Network Protocols) In that respect, I wonder if, to keep the problem tractable, this could be worked out in draft-gont-numeric-ids-sec-considerations to have it formally update RFC3552, and then have the bis document pick up what we agreed on and incorporate it in the bis document. FWIW, other wg's have followed this path for bis documents (e.g., TCPM's revision of RFC0793 (!)). Thoughts? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492