From nobody Wed Feb 1 12:33:51 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAA81299EC for ; Wed, 1 Feb 2017 12:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_SOFTFAIL=0.665] 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 1LHe1U2AuaTd for ; Wed, 1 Feb 2017 12:33:48 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA0A1299EB for ; Wed, 1 Feb 2017 12:33:47 -0800 (PST) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d52 with ME id fYZk1u00l17Lgi403YZlXD; Wed, 01 Feb 2017 21:33:45 +0100 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Wed, 01 Feb 2017 21:33:45 +0100 X-ME-IP: 92.170.5.52 To: "saag@ietf.org" References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: Date: Wed, 1 Feb 2017 21:33:42 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [saag] AD sponsoring Effect of Ubiquitous 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: Wed, 01 Feb 2017 20:33:50 -0000 Hi all, > I plan to do my AD review of this shortly and then > start an IETF last call. If you have comments in > the meantime please do send them here. I have a suggestion for Section 1 where I read: In addition to encrypted web site access (HTTP over TLS), other application level transport encryption efforts are underway. This includes a push to encrypt session transport for mail (SMTP - gateway to gateway) and other protocols such as instant messaging (XMPP over TLS). Shouldn't the document separate protocols that use explicit TLS (STARTTLS) and implicit TLS? * XMPP over TLS is for instance only explicit: STARTTLS is used on port 5222 (Section 5 of RFC6120). * HTTP over TLS is only implicit (on port 443). * SMTP over TLS can be explicit (on port 25 or 587) or implicit (on port 465). Same thing for POP3 (explicit on port 110, implicit on port 995) and NNTP (explicit on ports 119 or 433, implicit on port 563) amongst other protocols. The above quoted paragraph seems to mix all these uses. Also note that implicit TLS is recommended per Section 3.2 of RFC 7525: o In cases where an application protocol allows implementations or deployments a choice between strict TLS configuration and dynamic upgrade from unencrypted to TLS-protected traffic (such as STARTTLS), clients and servers SHOULD prefer strict TLS configuration. -- Julien ÉLIE « Ce n'est pas en tournant le dos aux choses qu'on leur fait face. » (Pierre Dac) From nobody Wed Feb 1 14:55:52 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F63D129545 for ; Wed, 1 Feb 2017 14:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58d4I5EgrKqD for ; Wed, 1 Feb 2017 14:55:50 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20311295D5 for ; Wed, 1 Feb 2017 14:55:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2962; q=dns/txt; s=iport; t=1485989749; x=1487199349; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=DR06w8SLGE2NvUGKx1aKfAZktg8qa1XSDfUFWHdQREw=; b=R1Ez5vjvQRpFWOUz+b2I7tHFkxieKknjBg/ToINbN0sjh7YntX1lbzH0 kp1bXKjzunBzqKWq5G5YT4scQpQq7KIZWtE2oKV66xnXvLHk/iOreg+ra 1iGsmitCvVbR0h7Yeqrz4w0/+kfaO3s3aFbj2or9br453vdk4JJ6K1rYh k=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2DgA/ZpJY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhF6ENop7kHaVVIINhiICgwEWAQIBAQEBAQEBYiiEagYYC0IUEAt?= =?us-ascii?q?CAgJXBgEMCAEBiW6tBIIliysBAQEBAQEBAQEBAQEBAQEBAQERD4hQCIJih1OCX?= =?us-ascii?q?wWbXINvggODSohHijiGRZMBJg4jOmETCBUVhn4/iR4BAQE?= X-IronPort-AV: E=Sophos;i="5.33,322,1477958400"; d="asc'?scan'208";a="649312992" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Feb 2017 22:55:45 +0000 Received: from [10.61.71.215] (ams3-vpn-dhcp2007.cisco.com [10.61.71.215]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v11Mti3j020201; Wed, 1 Feb 2017 22:55:44 GMT To: Stephen Farrell , Kathleen Moriarty References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> <307973f8-ffab-8657-ad7a-8bc8557b2555@cs.tcd.ie> <92fa2af5-91ca-8da3-d268-adcd2846af25@cs.tcd.ie> From: Eliot Lear Message-ID: <35a74489-9473-ecee-4039-8d06ae498090@cisco.com> Date: Wed, 1 Feb 2017 23:55:44 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <92fa2af5-91ca-8da3-d268-adcd2846af25@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6l4nsGMsADVigK6XaRDpfqpGfOkqFwL94" Archived-At: Cc: "saag@ietf.org" , Al Morton Subject: Re: [saag] AD sponsoring Effect of Ubiquitous 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: Wed, 01 Feb 2017 22:55:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6l4nsGMsADVigK6XaRDpfqpGfOkqFwL94 Content-Type: multipart/mixed; boundary="dvGA596mIiFEubHrkwV4gVFtOvni5uxh6"; protected-headers="v1" From: Eliot Lear To: Stephen Farrell , Kathleen Moriarty Cc: "saag@ietf.org" , Al Morton Message-ID: <35a74489-9473-ecee-4039-8d06ae498090@cisco.com> Subject: Re: [saag] AD sponsoring Effect of Ubiquitous Encryption References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> <307973f8-ffab-8657-ad7a-8bc8557b2555@cs.tcd.ie> <92fa2af5-91ca-8da3-d268-adcd2846af25@cs.tcd.ie> In-Reply-To: <92fa2af5-91ca-8da3-d268-adcd2846af25@cs.tcd.ie> --dvGA596mIiFEubHrkwV4gVFtOvni5uxh6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Just on this one point: On 1/25/17 11:00 PM, Stephen Farrell wrote: >>> >>> - 2: I'm not at all sure encryption "prevents" load >>> balancing, in fact I'm pretty sure it does not prevent that >> >> This was on the content. Would you prefer to see it reworded/expanded= ? > Yeah, I think saying prevents is just wrong. Encrypting does > prevent some methods of load-balancing from working but not > all methods. Ditto for other features that get changed. I do > think it's important to not overstate the effects, just as > it is to not understate them. > > Being specific probably helps here. For instance, encryption above L3 prevents "stickiness" based on the usual 5-tuple (a common form of load balancing) the port information is not available. The same is the case with load balancing based on TCP sequence #s. And the same is generally true above L4 (e.g, based on application data) when the load balancer resides in between the encryption endpoints (I say 'generally' because the endpoints may provide some information as part of the TLS hello that might prove useful). It's probably worth taking a few minutes to survey what methods are commonly deployed. Eliot --dvGA596mIiFEubHrkwV4gVFtOvni5uxh6-- --6l4nsGMsADVigK6XaRDpfqpGfOkqFwL94 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 iQEcBAEBCAAGBQJYkmdxAAoJEIe2a0bZ0nozTicIAK7AIb4t0z6K92iKNhd4ajJt pnW7QGX3CoZwwCe/tVZ5Y62J0MwhWtjaexcPgDJ1LxyPVbZJdTx2Ga/I86pK+eE5 5W5LIrb68ZeN/OCHB0ZEfgft5QFkvOF/VfQIoKyPgmuo+Pp25YiiAC8s4aNFe7h6 zDuF4rRyGBsd9y4AzqtLGdPajpjhrFWW/Yn0DS7bND00R7u69OpCCPq63AosepsI zjpGeAGvfvaFruucByBo0wfHGscYIz7GOrOtDzTR6U9k1OSbcua8xqvZwtlqjHM0 qlD8JWQBRX7sVaA7oTgrP8FZHmqWCIHiI9dGJoc0SCWGGOlVlm99vDIhRWg+Tfs= =oLqg -----END PGP SIGNATURE----- --6l4nsGMsADVigK6XaRDpfqpGfOkqFwL94-- From nobody Thu Feb 2 13:29:19 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59847129672 for ; Thu, 2 Feb 2017 13:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQ4bWXglTvxI for ; Thu, 2 Feb 2017 13:29:16 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82249129581 for ; Thu, 2 Feb 2017 13:29:16 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id v23so1292415qtb.0 for ; Thu, 02 Feb 2017 13:29:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wFPDhphluZK4nR3o6Wi9OShRS0d0CKtqA1jiKcMUG4U=; b=PDDyW4zfVJnIuOIgu9f/j35trWR6fIJxd3Uovt3ASLmmDEfQu0KJCu7i5WyP9reNTv wCxNWtGpXfVeDhfpVvT4sPK9+47mQ9kWDKP2gxt2kblhTurfcIbBgWSCqjtC00tI84K3 NyL8oje342X+tQiVXvoG+TezUDzvDfhKoTpLyg4OLzhTZtBLHmm//XiwJpUsUFad7VcY lxqQwV1pVF/Y3QnEN45eOHNpLhMJCPRdAWjgvpItDFSO7uNXOyFBpyqRd1ZQQhGNFeZI x8hwyPVklvk9jbdMxHxgQW0lK6TcR/KoubkUyGqp0NlAXeU3CcEm7GHyTO+X+03tjiWU /yGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wFPDhphluZK4nR3o6Wi9OShRS0d0CKtqA1jiKcMUG4U=; b=PathFca+25LPW+17cHY360Nd/IdH6u3Lp2iv0iOuDL42EOBw+1RhCHnrNVTsUCaP9l hms1N8TR7R2PcTI/pu8oyS0j7iH7AzSzG3WPAA60UyaEA3PZEK2a55zK5eBdIJaCC+3k t9yieQHw1L1XYiO72Vbct3KxlIgb04+YZ2wWCBf5cvtMeNTu8k2Q1+37xXwZpaDzCTHH YF5gqS4RTe+kK7Y6FCA9vCE02lNrtg6ITEhu3gG/YdFlKgeJW04TuUV/RVsVc7KizaZS f6dZ6nDzb3LCySmyF118y7vAPmvXCf721j3i3kD9zTyepwL15wXDHEWWJ8OufxBgXQTJ MDVg== X-Gm-Message-State: AIkVDXLW+xJi7QAom8gNp9jhgSOlyZkFBWxvSBni3KAduiziCq5MbM8abek4P+/6lAPiRoHb/FhH4N7ErFBLpA== X-Received: by 10.200.37.141 with SMTP id e13mr9980484qte.226.1486070955604; Thu, 02 Feb 2017 13:29:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Thu, 2 Feb 2017 13:29:14 -0800 (PST) In-Reply-To: References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> From: Kathleen Moriarty Date: Thu, 2 Feb 2017 16:29:14 -0500 Message-ID: To: =?UTF-8?B?SnVsaWVuIMOJTElF?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD sponsoring Effect of Ubiquitous 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: Thu, 02 Feb 2017 21:29:18 -0000 Hi Julien, Thanks for your review. Comments inline On Wed, Feb 1, 2017 at 3:33 PM, Julien =C3=89LIE w= rote: > Hi all, > >> I plan to do my AD review of this shortly and then >> start an IETF last call. If you have comments in >> the meantime please do send them here. > > > I have a suggestion for Section 1 where I read: > > In addition to encrypted web site access (HTTP over TLS), other > application level transport encryption efforts are underway. This > includes a push to encrypt session transport for mail (SMTP - gateway > to gateway) and other protocols such as instant messaging (XMPP over > TLS). > > Shouldn't the document separate protocols that use explicit TLS (STARTTLS= ) > and implicit TLS? > * XMPP over TLS is for instance only explicit: STARTTLS is used on port > 5222 (Section 5 of RFC6120). > * HTTP over TLS is only implicit (on port 443). > * SMTP over TLS can be explicit (on port 25 or 587) or implicit (on port > 465). Same thing for POP3 (explicit on port 110, implicit on port 995) a= nd > NNTP (explicit on ports 119 or 433, implicit on port 563) amongst other > protocols. > > The above quoted paragraph seems to mix all these uses. I just read through the paragraph again and could make this change, as the usage is not stated. This draft doesn't specify best practices, but acks current practices (which can be either explicit or implicit). I just changed the sentences a little to make it clear that SMTP and XMPP are both gateway-to-gatway (keeping this in as laymen's terms as possible) and kept HTTP in the first sentence. I know this doesn't mention implicit or explicit, but is a little better per your recommendation. If you have alternate text options you'd prefer, let us know. NEW: In addition to encrypted web site access (HTTP over TLS), other application level transport encryption efforts are underway. This includes a push to encrypt session gateway-to-gateway transport for mail (SMTP over TLS) and other protocols such as instant messaging (XMPP over TLS). > > > Also note that implicit TLS is recommended per Section 3.2 of RFC 7525: > > o In cases where an application protocol allows implementations or > deployments a choice between strict TLS configuration and dynamic > upgrade from unencrypted to TLS-protected traffic (such as > STARTTLS), clients and servers SHOULD prefer strict TLS > configuration. Sure, and we (security directorate, Stephen & I) make sure that reference shows up in drafts where use of TLS is specified. This draft doesn't define a protocol, so I'm not sure a reference here is actually helpful. Did you see a place where you thought it was a good fit that I am missing? Thank you, Kathleen > > -- > Julien =C3=89LIE > > =C2=AB Ce n'est pas en tournant le dos aux choses qu'on leur fait face. = =C2=BB > (Pierre Dac) > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --=20 Best regards, Kathleen From nobody Thu Feb 2 13:38:28 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DE61299BA for ; Thu, 2 Feb 2017 13:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ns8DIRgKWMT for ; Thu, 2 Feb 2017 13:38:26 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE82F129525 for ; Thu, 2 Feb 2017 13:38:25 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id x49so1558600qtc.2 for ; Thu, 02 Feb 2017 13:38:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5YzzLDab6y7Mawv0NAFI4lQ9c6buzG7Gx5GNW/2vdMw=; b=rt3PCbugu8B3cxmU+4ACGw5D+XJcmAxQcl6trUxsKQ7d1meavXGPmClG0d+bwspaaF 1aYF2ACB1fS1zueXANrYufZUizxWvUdfL03kUV32sIlyqss9Rta4zPDHtfScqpkYoY40 MFU47SB24F54U0MnLJdKGBhZaUzIdvq+TfqkTShdECRSIIOAGfeb/+PMYLx8f8r4PLit SfAtYcaGYjvA8pw72AWGVk156xnkxH3e+OJCbBoiLnfGEzDKPGGWzkytGGMg9RyUQ1OU cFaMXB3Gs9eTxSexwHjCne8Wk99BAijxg3Qaa97hVCpmQ8CrTvDFTFT3KnxSH8UT7C0i kilQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5YzzLDab6y7Mawv0NAFI4lQ9c6buzG7Gx5GNW/2vdMw=; b=qjDng8CZA5luZAABfgTZhTN6cMIpK7wuS57BJEA+hmInnyPxgargV/m8lFuO8IuOVY G/l9oWi564FmjYWDt2Ap6REghSb+aPXDt95NT/rsV7bj2QD8NI9CT3QAQDjfhWHIgLCP BnA/FR6NxAWwMclXRb5U9WgyN2SbvTGTHgQTvxdz35JgCD1eOAaQGzcE5pVFGdXuzgmd 2g4ja+IbczimPMjHW+0hF5xU0H3FDfvcZJn7pQy/dnd9WdJWpBZIeUrAG3ybOlYFX+nV f8B9CXfIm+GilJXEn1f2zXNnqVnwWV1qosg1Ul4uHTIo7USNmMLlr2rMOv/MqYiDiUYR NKow== X-Gm-Message-State: AMke39mkJPZrqTdw6mXSDMycMwvv/gvoX2fQ1t5xQPOeJPItqBy8VGyzCQ0lL5Uq+qSQErOkTHNCWX9ejkSCsg== X-Received: by 10.55.89.196 with SMTP id n187mr10297541qkb.17.1486071504975; Thu, 02 Feb 2017 13:38:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Thu, 2 Feb 2017 13:38:24 -0800 (PST) In-Reply-To: <35a74489-9473-ecee-4039-8d06ae498090@cisco.com> References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> <307973f8-ffab-8657-ad7a-8bc8557b2555@cs.tcd.ie> <92fa2af5-91ca-8da3-d268-adcd2846af25@cs.tcd.ie> <35a74489-9473-ecee-4039-8d06ae498090@cisco.com> From: Kathleen Moriarty Date: Thu, 2 Feb 2017 16:38:24 -0500 Message-ID: To: Eliot Lear , joel jaeggli , "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Al Morton , "saag@ietf.org" Subject: Re: [saag] AD sponsoring Effect of Ubiquitous 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: Thu, 02 Feb 2017 21:38:27 -0000 Hi Eliot, Thanks for your review and suggetsion. Inline. On Wed, Feb 1, 2017 at 5:55 PM, Eliot Lear wrote: > Hi, > > Just on this one point: > > > On 1/25/17 11:00 PM, Stephen Farrell wrote: > >>>> >>>> - 2: I'm not at all sure encryption "prevents" load >>>> balancing, in fact I'm pretty sure it does not prevent that >>> >>> This was on the content. Would you prefer to see it reworded/expanded? >> Yeah, I think saying prevents is just wrong. Encrypting does >> prevent some methods of load-balancing from working but not >> all methods. Ditto for other features that get changed. I do >> think it's important to not overstate the effects, just as >> it is to not understate them. >> >> > Being specific probably helps here. For instance, encryption above L3 > prevents "stickiness" based on the usual 5-tuple (a common form of load > balancing) the port information is not available. The same is the case > with load balancing based on TCP sequence #s. And the same is generally > true above L4 (e.g, based on application data) when the load balancer > resides in between the encryption endpoints (I say 'generally' because > the endpoints may provide some information as part of the TLS hello that > might prove useful). It's probably worth taking a few minutes to survey > what methods are commonly deployed. I just took a look back at this section and the best way to do that might be in a subsection under middle boxes. Now, to survey, operators are likely to be the best to assist with this question to fully understand current deployment patterns. Do you know who might be able to assist here with text or at least the deployment patterns? Maybe Joel or Rich copied have some ideas to get this right? Thanks, Kathleen > > Eliot > -- Best regards, Kathleen From nobody Thu Feb 2 14:00:00 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B3F12958D for ; Thu, 2 Feb 2017 13:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6KpmI6h5-aq for ; Thu, 2 Feb 2017 13:59:58 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4B51299FB for ; Thu, 2 Feb 2017 13:59:57 -0800 (PST) Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 760CD284E4B for ; Thu, 2 Feb 2017 21:59:56 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 2 Feb 2017 16:59:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <01A9C79C-42AD-4EFA-8BE0-E63CB0DDCF7F@dukhovni.org> References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> To: IETF SAAG X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [saag] AD sponsoring Effect of Ubiquitous Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: IETF SAAG List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 21:59:59 -0000 > On Feb 2, 2017, at 4:29 PM, Kathleen Moriarty = wrote: >=20 > NEW: > In addition to encrypted web site access (HTTP over TLS), other > application level transport encryption efforts are underway. This > includes a push to encrypt session gateway-to-gateway transport = for > mail (SMTP over TLS) and other protocols such as instant = messaging > (XMPP over TLS). FWIW, one might note that it appears that the SMTP effort is = substantially farther along than HTTP: https://www.google.com/transparencyreport/saferemail/ = https://nakedsecurity.sophos.com/2016/10/18/halfway-there-firefox-users-no= w-visit-over-50-of-pages-via-https/ and that perhaps another formulation could have been: In addition to encrypted MTA-to-MTA email transmission (SMTP over = TLS), other application level transport encryption efforts are underway. This includes a push to encrypt web site access (HTTP over TLS) and gateway-to-gateway transport for protocols such as instant = messaging (XMPP over TLS). Of course the order is by no means critical, and application = "prominence" is no less valid a sorting criterion than adoption progress. I just = hope that readers don't walk away with the impression that adoption in the non-HTTP space trails adoptions in HTTP. >> Also note that implicit TLS is recommended per Section 3.2 of RFC = 7525: >>=20 >> o In cases where an application protocol allows implementations or >> deployments a choice between strict TLS configuration and = dynamic >> upgrade from unencrypted to TLS-protected traffic (such as >> STARTTLS), clients and servers SHOULD prefer strict TLS >> configuration. >=20 > Sure, and we (security directorate, Stephen & I) make sure that > reference shows up in drafts where use of TLS is specified. This > draft doesn't define a protocol, so I'm not sure a reference here is > actually helpful. Did you see a place where you thought it was a good > fit that I am missing? There are also some advantages in doing STARTTLS. For example, Postfix is often able to detect split TLS session caches behind L4 = load-balancers by observing differences in the server identity reported in the EHLO = reply. This makes for much more effective TLS session caching. The case for "implicit" TLS for MTA-to-MTA SMTP is not very compelling. --=20 Viktor. From nobody Fri Feb 3 10:17:23 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAEB1294AA for ; Fri, 3 Feb 2017 10:17:21 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF6J-r-Eb4KC for ; Fri, 3 Feb 2017 10:17:20 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50071294A2 for ; Fri, 3 Feb 2017 10:17:19 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id v23so46583102qtb.0 for ; Fri, 03 Feb 2017 10:17:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=5gqJiV/OOhrMqKuy+uvJ+AX5po3yPJ5EB7cqwSRb6zc=; b=AHCrFQUe86Ih199ucrs+e1HThmPregWZHODR6h/LMyrPe9H7nwgjq3DmWEwNwmBv+K I8cj6eCKr7adxshZ0QeT7rHdXtVBNSVqlU7SRmBZ7n5BbvQCMfeslwsj3sG1NPdmpEGx zfmdEILo/Ht7dTnxB43lLMaUpiGqmiWWtUQ0qjvy+T+nhTH6dQmjvNc40YPokABq1In4 pO/HoqjxP+vSIItixaUrbnhO+lJSYtDYYWteaXWJe6V/1tV0wembbVIw5qsdvYKmaj5O /Nr3KKEccNGEp++eqCthOfKoN+SePgoizSJ+4QZ6cXZs2ULu0BfTbvbs11HlIXVqxaL9 ohgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=5gqJiV/OOhrMqKuy+uvJ+AX5po3yPJ5EB7cqwSRb6zc=; b=SBFSrHYQpi9tyBUHzIwv+hTM4vTE+7/gn8bSNN565kgZbHXV5MuHb+bIUF1uQK64Xx bfV8zXJh0SKvU3BAqXYH3da2OYGBUMwKgUi40XCQgVQxU1NVAcwSz0R3zlPQPcPDu+5c rpnqRgFmhByrCKz05cg6e/dMQ45yzkG/x08fcrRpuzvA8kYGEIglReqtJBq5XCaRvO7C q0nGmF6ZMedHQB6harECKYN8I2EFd6S0isrI83cKfHwVYi2K8E3NDwjox7d51EPgu9H1 pe1959Ac1YsDcwBBhKqesotIxEI0/AE/XisEUyvNSsR6/Tx/FTGqubBz2ERc1UYIba5a ukZw== X-Gm-Message-State: AIkVDXJ4u4/2VVgDYMstSSfceytVmuEQF77AQ6Mob/SFmwOltVltHTppwYoHLFt5tyslpncZ19ZZT+zMVoIDuA== X-Received: by 10.200.39.130 with SMTP id w2mr14018708qtw.280.1486145838704; Fri, 03 Feb 2017 10:17:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Fri, 3 Feb 2017 10:17:18 -0800 (PST) In-Reply-To: <01A9C79C-42AD-4EFA-8BE0-E63CB0DDCF7F@dukhovni.org> References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> <01A9C79C-42AD-4EFA-8BE0-E63CB0DDCF7F@dukhovni.org> From: Kathleen Moriarty Date: Fri, 3 Feb 2017 13:17:18 -0500 Message-ID: To: IETF SAAG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [saag] AD sponsoring Effect of Ubiquitous 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, 03 Feb 2017 18:17:22 -0000 Hello, Thanks for the additional comments, inline. On Thu, Feb 2, 2017 at 4:59 PM, Viktor Dukhovni wrote: > >> On Feb 2, 2017, at 4:29 PM, Kathleen Moriarty wrote: >> >> NEW: >> In addition to encrypted web site access (HTTP over TLS), other >> application level transport encryption efforts are underway. This >> includes a push to encrypt session gateway-to-gateway transport for >> mail (SMTP over TLS) and other protocols such as instant messaging >> (XMPP over TLS). > > FWIW, one might note that it appears that the SMTP effort is substantially > farther along than HTTP: > > https://www.google.com/transparencyreport/saferemail/ > https://nakedsecurity.sophos.com/2016/10/18/halfway-there-firefox-users-now-visit-over-50-of-pages-via-https/ > > and that perhaps another formulation could have been: > > In addition to encrypted MTA-to-MTA email transmission (SMTP over TLS), > other application level transport encryption efforts are underway. > This includes a push to encrypt web site access (HTTP over TLS) and > gateway-to-gateway transport for protocols such as instant messaging > (XMPP over TLS). I think the first sentence saying 'underway' is probably causing your reaction, I suspect, and that's fair. > > Of course the order is by no means critical, and application "prominence" > is no less valid a sorting criterion than adoption progress. I just hope > that readers don't walk away with the impression that adoption in the > non-HTTP space trails adoptions in HTTP. Sure, fair point. What about the following that considers your point. In addition to encrypted web site access (HTTP over TLS), other well-deployed application level transport encryption efforts. This includes mail transfer agent (MTA)-to-MTA session encryption transport for email (SMTP over TLS) and gateway-to-gateway for instant messaging (XMPP over TLS). > > >>> Also note that implicit TLS is recommended per Section 3.2 of RFC 7525: >>> >>> o In cases where an application protocol allows implementations or >>> deployments a choice between strict TLS configuration and dynamic >>> upgrade from unencrypted to TLS-protected traffic (such as >>> STARTTLS), clients and servers SHOULD prefer strict TLS >>> configuration. >> >> Sure, and we (security directorate, Stephen & I) make sure that >> reference shows up in drafts where use of TLS is specified. This >> draft doesn't define a protocol, so I'm not sure a reference here is >> actually helpful. Did you see a place where you thought it was a good >> fit that I am missing? > > There are also some advantages in doing STARTTLS. For example, Postfix > is often able to detect split TLS session caches behind L4 load-balancers > by observing differences in the server identity reported in the EHLO reply. > This makes for much more effective TLS session caching. > > The case for "implicit" TLS for MTA-to-MTA SMTP is not very compelling. Sure, but I don't see a reason to add text on implicit TLS into this section, do you? If you have info on load balancers and could help with text per Eliot's question in this thread, that would be much appreciated. Thank you, Kathleen > > -- > Viktor. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- Best regards, Kathleen From nobody Fri Feb 3 10:33:20 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7738B12968A for ; Fri, 3 Feb 2017 10:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3lUiZFu85UW for ; Fri, 3 Feb 2017 10:33:17 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2917D1293FB for ; Fri, 3 Feb 2017 10:33:17 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7AA46433419; Fri, 3 Feb 2017 18:33:16 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 647D3433414; Fri, 3 Feb 2017 18:33:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1486146796; bh=9KXg3VPgieuEMvWdDTGMHQG35x46Ztag5o2eCJfjRUI=; l=1868; h=From:To:CC:Date:References:In-Reply-To:From; b=Vua9xuZAPs/gVhP0DltpU6jocr8ikNWWG3UuMFULFt+TooX+RDt6/l63oBU7NTdw7 iXrHmPNKBlC8pr9lQnsqwS0/n/7Y+tHvcAgoTw4drbpadcMHH5xNphUJVHbIo+rK3V YBkTxHNI2SYKOlR51U1NuaS8d8kmPE4xylpYF83E= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 604481FC8D; Fri, 3 Feb 2017 18:33:16 +0000 (GMT) Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 3 Feb 2017 10:33:15 -0800 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1178.000; Fri, 3 Feb 2017 13:33:15 -0500 From: "Salz, Rich" To: Kathleen Moriarty , Eliot Lear , joel jaeggli Thread-Topic: [saag] AD sponsoring Effect of Ubiquitous Encryption Thread-Index: AQHSczg1xf6mKcbGzkeCWVGDeOi44aFFTWOAgASjy4CAACj5AIALD90AgAF8uQCAAQiT8A== Date: Fri, 3 Feb 2017 18:33:15 +0000 Message-ID: <0bd77e3e3c1b485b965637eaf289d1ce@usma1ex-dag1mb3.msg.corp.akamai.com> References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> <307973f8-ffab-8657-ad7a-8bc8557b2555@cs.tcd.ie> <92fa2af5-91ca-8da3-d268-adcd2846af25@cs.tcd.ie> <35a74489-9473-ecee-4039-8d06ae498090@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.57] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Al Morton , "saag@ietf.org" Subject: Re: [saag] AD sponsoring Effect of Ubiquitous 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, 03 Feb 2017 18:33:18 -0000 PiA+IEJlaW5nIHNwZWNpZmljIHByb2JhYmx5IGhlbHBzIGhlcmUuICBGb3IgaW5zdGFuY2UsIGVu Y3J5cHRpb24gYWJvdmUgTDMNCj4gPiBwcmV2ZW50cyAic3RpY2tpbmVzcyIgYmFzZWQgb24gdGhl IHVzdWFsIDUtdHVwbGUgKGEgY29tbW9uIGZvcm0gb2YNCj4gPiBsb2FkDQo+ID4gYmFsYW5jaW5n KSB0aGUgcG9ydCBpbmZvcm1hdGlvbiBpcyBub3QgYXZhaWxhYmxlLiAgVGhlIHNhbWUgaXMgdGhl DQo+ID4gY2FzZSB3aXRoIGxvYWQgYmFsYW5jaW5nIGJhc2VkIG9uIFRDUCBzZXF1ZW5jZSAjcy4g IEFuZCB0aGUgc2FtZSBpcw0KPiA+IGdlbmVyYWxseSB0cnVlIGFib3ZlIEw0IChlLmcsIGJhc2Vk IG9uIGFwcGxpY2F0aW9uIGRhdGEpIHdoZW4gdGhlIGxvYWQNCj4gPiBiYWxhbmNlciByZXNpZGVz IGluIGJldHdlZW4gdGhlIGVuY3J5cHRpb24gZW5kcG9pbnRzIChJIHNheQ0KPiA+ICdnZW5lcmFs bHknIGJlY2F1c2UgdGhlIGVuZHBvaW50cyBtYXkgcHJvdmlkZSBzb21lIGluZm9ybWF0aW9uIGFz IHBhcnQNCj4gPiBvZiB0aGUgVExTIGhlbGxvIHRoYXQgbWlnaHQgcHJvdmUgdXNlZnVsKS4gIEl0 J3MgcHJvYmFibHkgd29ydGggdGFraW5nDQo+ID4gYSBmZXcgbWludXRlcyB0byBzdXJ2ZXkgd2hh dCBtZXRob2RzIGFyZSBjb21tb25seSBkZXBsb3llZC4NCj4gDQo+IEkganVzdCB0b29rIGEgbG9v ayBiYWNrIGF0IHRoaXMgc2VjdGlvbiBhbmQgdGhlIGJlc3Qgd2F5IHRvIGRvIHRoYXQgbWlnaHQg YmUgaW4gYQ0KPiBzdWJzZWN0aW9uIHVuZGVyIG1pZGRsZSBib3hlcy4gIE5vdywgdG8gc3VydmV5 LCBvcGVyYXRvcnMgYXJlIGxpa2VseSB0byBiZQ0KPiB0aGUgYmVzdCB0byBhc3Npc3Qgd2l0aCB0 aGlzIHF1ZXN0aW9uIHRvIGZ1bGx5IHVuZGVyc3RhbmQgY3VycmVudCBkZXBsb3ltZW50DQo+IHBh dHRlcm5zLg0KPiANCj4gRG8geW91IGtub3cgd2hvIG1pZ2h0IGJlIGFibGUgdG8gYXNzaXN0IGhl cmUgd2l0aCB0ZXh0IG9yIGF0IGxlYXN0IHRoZQ0KPiBkZXBsb3ltZW50IHBhdHRlcm5zPyAgTWF5 YmUgSm9lbCBvciBSaWNoIGNvcGllZCBoYXZlIHNvbWUgaWRlYXMgdG8gZ2V0IHRoaXMNCj4gcmln aHQ/DQoNClNvcnJ5IGZvciB0aGUgZGVsYXkgaW4gcmVzcG9uZGluZy4NCg0KRm9yIGJldHRlciBv ciB3b3JzZSwgdGhlIFNOSSB2YWx1ZSBpbiBUTFMgaGVsbG8gaXMgcGxhaW50ZXh0IGFuZCBJIGtu b3cgc29tZSBib3hlcyB1c2UgdGhhdCBmb3IgTEIgc3RpY2tpbmVzcy4NCg0KQmV5b25kIHRoYXQs IEkgZG9uJ3QgaGF2ZSBtdWNoIHRvIG9mZmVyLiAgSSB0aGluayB3ZSBzaG91bGQgZ2V0IGZvbGtz IGZyb20gc29tZSBvZiB0aGUgSFcgY29tcGFuaWVzIHRvIG9mZmVyIHNvbWUgdGV4dD8NCg== From nobody Fri Feb 3 11:08:20 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557C41296CC for ; Fri, 3 Feb 2017 11:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4UQ21ZqI_wP for ; Fri, 3 Feb 2017 11:08:17 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C611296B8 for ; Fri, 3 Feb 2017 11:08:15 -0800 (PST) Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 46158284E4B for ; Fri, 3 Feb 2017 19:08:14 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 3 Feb 2017 14:08:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> <01A9C79C-42AD-4EFA-8BE0-E63CB0DDCF7F@dukhovni.org> To: IETF SAAG X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [saag] AD sponsoring Effect of Ubiquitous Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: IETF SAAG List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 19:08:19 -0000 > On Feb 3, 2017, at 1:17 PM, Kathleen Moriarty = wrote: >=20 >> ... perhaps another formulation could have been: >>=20 >> In addition to encrypted MTA-to-MTA email transmission (SMTP over = TLS), >> other application level transport encryption efforts are = underway. >> This includes a push to encrypt web site access (HTTP over TLS) = and >> gateway-to-gateway transport for protocols such as instant = messaging >> (XMPP over TLS). >=20 > I think the first sentence saying 'underway' is probably causing your > reaction, I suspect, and that's fair. >=20 >> Of course the order is by no means critical, and application = "prominence" >> is no less valid a sorting criterion than adoption progress. I just = hope >> that readers don't walk away with the impression that adoption in the >> non-HTTP space trails adoptions in HTTP. >=20 > Sure, fair point. What about the following that considers your point. >=20 > In addition to encrypted web site access (HTTP over TLS), other > well-deployed application level transport encryption efforts. This > includes mail transfer agent (MTA)-to-MTA session encryption > transport for email (SMTP over TLS) and gateway-to-gateway for > instant messaging (XMPP over TLS). Some words must not have made it from thought to keyboard in the above. Would you care to amend the second clause of the first sentence? >> There are also some advantages in doing STARTTLS. For example, = Postfix >> is often able to detect split TLS session caches behind L4 = load-balancers >> by observing differences in the server identity reported in the EHLO = reply. >> This makes for much more effective TLS session caching. >>=20 >> The case for "implicit" TLS for MTA-to-MTA SMTP is not very = compelling. >=20 > Sure, but I don't see a reason to add text on implicit TLS into this > section, do you? Not especially, all I am saying is that we should not be overly disparaging STARTTLS, it has some merit. > If you have info on load balancers and could help with text per > Eliot's question in this thread, that would be much appreciated. Sadly, I don't have anything profound to say about load-balancers. I've just had to work around the limitations of a small number of variants. The observation about split TLS session caches is that in a na=C3=AFve implementation each actual server behind a load-balancer will have its own rTLS session cache and/or its own session ticket decryption keys. This rather breaks session resumption, especially for clients that cache sessions for more than just a quick burst of connections (short-term "sticky" LB may work for those). The gmail MX hosts are load-balanced, but they have shared session ticket keys, and a fixed EHLO response server id: S: 250-mx.google.com at your service, [] this is one example of a working unified server TLS cache, despite the presence of load-balancers. With outlook.com, for example, on making two connections I get: 1. S: 250-SNT004-MC10F16.hotmail.com (3.21.0.266) Hello [] 2. S: 250-SNT004-MC8F2.hotmail.com (3.21.0.266) Hello [] For better or worse, Postfix will assume a split cache, and only reuse TLS sessions when hitting the same server. After 5 more connections I again see: ... 7. S: 250-SNT004-MC10F16.hotmail.com (3.21.0.266) Hello [] So, under load, session re-use may kick in after a client accumulates = session tickets from sufficiently many outlook.com (aka hotmail.com) peers. --=20 Viktor. From nobody Fri Feb 3 13:12:30 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33A8129526 for ; Fri, 3 Feb 2017 13:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_SOFTFAIL=0.665] 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 XIqAqStj0aRU for ; Fri, 3 Feb 2017 13:12:27 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA761294FB for ; Fri, 3 Feb 2017 13:12:26 -0800 (PST) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d32 with ME id gMCP1u00917Lgi403MCPmu; Fri, 03 Feb 2017 22:12:24 +0100 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Fri, 03 Feb 2017 22:12:24 +0100 X-ME-IP: 92.170.5.52 To: "saag@ietf.org" References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <4a3e58c7-aaeb-4ff7-6139-9ec8919f64ff@trigofacile.com> Date: Fri, 3 Feb 2017 22:12:23 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [saag] AD sponsoring Effect of Ubiquitous 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, 03 Feb 2017 21:12:29 -0000 Hi Kathleen, >> Also note that implicit TLS is recommended per Section 3.2 of RFC 7525: >> >> o In cases where an application protocol allows implementations or >> deployments a choice between strict TLS configuration and dynamic >> upgrade from unencrypted to TLS-protected traffic (such as >> STARTTLS), clients and servers SHOULD prefer strict TLS >> configuration. > > Sure, and we (security directorate, Stephen & I) make sure that > reference shows up in drafts where use of TLS is specified. This > draft doesn't define a protocol, so I'm not sure a reference here is > actually helpful. Did you see a place where you thought it was a good > fit that I am missing? Maybe in Section 2: The EFF reported [EFF2014] several network service providers taking steps to prevent the use of SMTP over TLS by breaking StartTLS, preventing the negotiation process resulting in fallback to the use of clear text. A reference to Section 3.2 of RFC 7525 could be added (about SSL Stripping). Incidentally, shouldn't "StartTLS" be written "STARTTLS"? Also, Section 7 mentions a similar attack: There has already been documented cases of service providers preventing STARTTLS [NoEncrypt] to prevent session encryption negotiation on some session to inject a super cookie. -- Julien ÉLIE « Quand tu auras lu ces lignes, le papyrus s'autodétruira. » (Astérix) From nobody Fri Feb 3 13:18:53 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9231129996 for ; Fri, 3 Feb 2017 13:18:52 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Kvz1TzOEfHM for ; Fri, 3 Feb 2017 13:18:51 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4AD129556 for ; Fri, 3 Feb 2017 13:18:51 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id k15so54935186qtg.3 for ; Fri, 03 Feb 2017 13:18:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SJyt3Ci5pOwf1XYxjZTumZaKkYqT3GvHWR5B2LcrsLg=; b=sL8eXk+RlAmuf+14PHThErV6qcU6qAspUOXBmojUiJCL6zxuuWSebuRTl16hx+uWnC bYow00armDKt3IvxV43KyyjirHfVE78j1Hidcx+BMeKS2KbCBbj3nhj+xgoPJRaW64CQ +WyG+DYRQV8LAjIHincV7ZFrJb3xZ3AWGW9VFthylkChf1UtJ8DrfrMOPLHdBjc7qK11 zcmwiB7S53cITF0hlBupgAs/3KhPFk8Ojm3LNh4DO95Ndj9nhcIPZstmt7bKOyvBIOmt oi511V2QzFJ5EuOx8IdRcdpsUohkCgRmmJ7qVoUbPSuwj2zR2DX5VBRuq5B3bta85tQ4 u6DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SJyt3Ci5pOwf1XYxjZTumZaKkYqT3GvHWR5B2LcrsLg=; b=mJatJ09owKAwYrPPKDJl4BLfOsBeDzPItdrW6fVZ6YxIVuCdC91mB7QtqKVOBI6JKx qZULYD+Rgh48EAmhSHDCqF8hmv5+EUtz6hV+BtOl9G6G6CkbuL9wzoknjai1nKL8iWNH uTGMxx4ATCZMjrA9tPYx+04XHp+/shDye3pYE3KjIWeXIswWlNcMmfW/Ry+s6CV8q8OQ P+FX6+e+UOzRjC8uWlGkMJgntFLxrEr0Ld2X9o08bLkvX8VPWFfTAsw3ZQuEjxDtDtdK 9n0SIZvY0tr94fzA3welP2VMZymUwKwgpehoJzSzA5DhDto46Fpy5BXnoyMpeP6UcMW2 051w== X-Gm-Message-State: AIkVDXIYq5RJSFUm9RZcZv5XMK2Lx5R9WEG7S3Nxv7iaqLndk2Ob/g1r34c1lcx9x6ZHkHC/Lzks7V8/s6vjXA== X-Received: by 10.55.161.71 with SMTP id k68mr15970589qke.185.1486156730408; Fri, 03 Feb 2017 13:18:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Fri, 3 Feb 2017 13:18:49 -0800 (PST) In-Reply-To: <4a3e58c7-aaeb-4ff7-6139-9ec8919f64ff@trigofacile.com> References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> <4a3e58c7-aaeb-4ff7-6139-9ec8919f64ff@trigofacile.com> From: Kathleen Moriarty Date: Fri, 3 Feb 2017 16:18:49 -0500 Message-ID: To: =?UTF-8?B?SnVsaWVuIMOJTElF?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD sponsoring Effect of Ubiquitous 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, 03 Feb 2017 21:18:53 -0000 Thanks, Julien. inline On Fri, Feb 3, 2017 at 4:12 PM, Julien =C3=89LIE w= rote: > Hi Kathleen, > >>> Also note that implicit TLS is recommended per Section 3.2 of RFC 7525: >>> >>> o In cases where an application protocol allows implementations or >>> deployments a choice between strict TLS configuration and dynamic >>> upgrade from unencrypted to TLS-protected traffic (such as >>> STARTTLS), clients and servers SHOULD prefer strict TLS >>> configuration. >> >> >> Sure, and we (security directorate, Stephen & I) make sure that >> reference shows up in drafts where use of TLS is specified. This >> draft doesn't define a protocol, so I'm not sure a reference here is >> actually helpful. Did you see a place where you thought it was a good >> fit that I am missing? > > > Maybe in Section 2: > > The EFF reported [EFF2014] several network service providers taking > steps to prevent the use of SMTP over TLS by breaking StartTLS, > preventing the negotiation process resulting in fallback to the use > of clear text. > > A reference to Section 3.2 of RFC 7525 could be added (about SSL Strippin= g). > Incidentally, shouldn't "StartTLS" be written "STARTTLS"? Done and thanks for the suggestion. I thought you were looking for more, but this works well. > > > Also, Section 7 mentions a similar attack: > > There has already been documented cases of service providers > preventing STARTTLS [NoEncrypt] to prevent session encryption > negotiation on some session to inject a super cookie. OK, since the reference is earlier, I didn't insert it here. Thank you, Kahtleen > > -- > Julien =C3=89LIE > > =C2=AB Quand tu auras lu ces lignes, le papyrus s'autod=C3=A9truira. =C2= =BB > (Ast=C3=A9rix) > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --=20 Best regards, Kathleen From nobody Fri Feb 3 13:20:18 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567A512948B for ; Fri, 3 Feb 2017 13:20:17 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhl8pUzCbd_w for ; Fri, 3 Feb 2017 13:20:16 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1524212945D for ; Fri, 3 Feb 2017 13:20:16 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id k15so54999779qtg.3 for ; Fri, 03 Feb 2017 13:20:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iMLqtkKtTtgy5VxHyWGaW4F43OkY29CjHZGC993x4Ks=; b=sjmYfMn4xTkLVtW1Yz6y0wuXULR5ToXIT/aeI8UxvRT2g7EzhMFqWLBaHDyPIpBw1d GBiGMHv99SBeY7nn7fvTld4tw6McY6rLDH/g7mOu5idNjL7B34w/BXuq8iY9ZJ+dGICG ZDjYU0X92ifQ1jT8xG208Qn30KzkFeb3CIfHcx4C3uox58SiLWdrutwmrdaEI/cxoROj SQEJnxIRdmR8MZ9oXHU+dvyVg4wwabhoksFFLOKyhD6ZfCCBO4fmgCxl6ZxoUe5mVzpx 08d+q0wQZU+QtXTfZGztC91xu53iwfQf5KJ+vqMwUPLOxmbbV4eWHg9nk3NsmB6RgjnV K7wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iMLqtkKtTtgy5VxHyWGaW4F43OkY29CjHZGC993x4Ks=; b=uVykOhg0GyhkVzPJw4QI9CSWOHPktRp5s1Ps1e7eTajb/DCBNxgW0xFWQGWL54IoVK kwlnGkb+LTXPvXjLE9uyppkeBL5FvBzne5tLx/ARy8X+VVPr9wnnin5jrqIvCIBZZMgK 4bjDiDoHMnWW7dJ+XXwGGsJKyCKeMNYY19DOf510srBFbJSUSDIFw9a6OaAOEzuBAyxK LQtM0vxRWaALg4mpEqknbmwZ9L3OCRT6ZiwanzbhJO2HQseR+p9v9E3ViIQFO4T2IGch 7D0jjuE1MmmZIWof65hDTCUFvgb0ZE72+uYnAFesbiHk1S+j5jQi3hnFcETK4svDhEbc LV2w== X-Gm-Message-State: AIkVDXLUJh+lrf6zljNoUsIgSqxPEsw8ZJwkpgTF6PRf1+fzTG3pc3jnM6Jo7QSFfqNLlx33uceIW4hNhP/f+Q== X-Received: by 10.200.55.230 with SMTP id e35mr15299567qtc.30.1486156815224; Fri, 03 Feb 2017 13:20:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Fri, 3 Feb 2017 13:20:14 -0800 (PST) In-Reply-To: <0bd77e3e3c1b485b965637eaf289d1ce@usma1ex-dag1mb3.msg.corp.akamai.com> References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> <307973f8-ffab-8657-ad7a-8bc8557b2555@cs.tcd.ie> <92fa2af5-91ca-8da3-d268-adcd2846af25@cs.tcd.ie> <35a74489-9473-ecee-4039-8d06ae498090@cisco.com> <0bd77e3e3c1b485b965637eaf289d1ce@usma1ex-dag1mb3.msg.corp.akamai.com> From: Kathleen Moriarty Date: Fri, 3 Feb 2017 16:20:14 -0500 Message-ID: To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Al Morton , "saag@ietf.org" Subject: Re: [saag] AD sponsoring Effect of Ubiquitous 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, 03 Feb 2017 21:20:17 -0000 Hi Rich and others with load balancer experience. On Fri, Feb 3, 2017 at 1:33 PM, Salz, Rich wrote: >> > Being specific probably helps here. For instance, encryption above L3 >> > prevents "stickiness" based on the usual 5-tuple (a common form of >> > load >> > balancing) the port information is not available. The same is the >> > case with load balancing based on TCP sequence #s. And the same is >> > generally true above L4 (e.g, based on application data) when the load >> > balancer resides in between the encryption endpoints (I say >> > 'generally' because the endpoints may provide some information as part >> > of the TLS hello that might prove useful). It's probably worth taking >> > a few minutes to survey what methods are commonly deployed. >> >> I just took a look back at this section and the best way to do that might be in a >> subsection under middle boxes. Now, to survey, operators are likely to be >> the best to assist with this question to fully understand current deployment >> patterns. >> >> Do you know who might be able to assist here with text or at least the >> deployment patterns? Maybe Joel or Rich copied have some ideas to get this >> right? > > Sorry for the delay in responding. > > For better or worse, the SNI value in TLS hello is plaintext and I know some boxes use that for LB stickiness. > > Beyond that, I don't have much to offer. I think we should get folks from some of the HW companies to offer some text? OK, thank you. If you know of someone to ask, please let me know (direct is fine) and I'll reach out. -- Best regards, Kathleen From nobody Fri Feb 3 13:28:53 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9663512955F for ; Fri, 3 Feb 2017 13:28:52 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUH43D2EtOIf for ; Fri, 3 Feb 2017 13:28:50 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E5EE1294ED for ; Fri, 3 Feb 2017 13:28:50 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id w20so50610255qtb.1 for ; Fri, 03 Feb 2017 13:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=mnXFopzya6NSqK4x0KmVDnN+aRATUmmZtdYLRDrBNDs=; b=MLhtPNtOd6YW0u7beEPnr3cHjOWKaRAcELZZm3+BNeO9vuSAD0FN6IDJCnDhYt5g++ zMse9PfDVfZZVdHxTde8Hvu23djs4/2OhH63VH2+lYA8MF62uAsryFgmggskjHdrCHTp QFfFl+HGC9Ob0PfLcaAvsQIlLh6nsjJz2BJ5Cu1pVDILYc/PUU3qWOnmxg7xSWpLJUk8 I3aoB432OsgPul8favFVVj8rdBOgv4HQCSbBe5Oj7qAvHh2KQcXicyuV1oV/fPUlioaY xOx9YJ+PQum8TJ64HE2vx0T8eM71g0AveYCcf2/jfgN/n0fVzOa0+boXabu4bjwdwfVw oADQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=mnXFopzya6NSqK4x0KmVDnN+aRATUmmZtdYLRDrBNDs=; b=paiyH/sRQSt3zyqjCg+2MhinBkjMmXbWCi2hFkzcx9Vhh5uqUPwJLyk4LEIqBcJdId TZg2eDdH0V8VzFQE16UQGn8LMLSUPsJDLxnGV072mQlKLzZ9NLcOVQ+ktWk0vGpQ7a2R lBsJEBrZwACdaZOnhAsoKDvxjXUkfghSrHX2catFlyuMWZEZXVzUsXhVUUrujo9MB41v ZkIzCVyJF9L9ix834hmhLHJD3k3/BH//bXRulVEHO+LtKbIgJ/rrD7ZT1Zs2a9FV8SuV uBXa+lJi+Poj07ZEbLQNrEFYn8xVtferJxPNCGtXyskXl8sXUbvNk4LuhjkEW+pNRQ0C Sj9A== X-Gm-Message-State: AMke39n7cjfSKOCUtPH68K1LuWCjo9si/YBxgXZ2ax5NO4oSfP9jENZHQN+IfOMQVkNSVPn3qVjrMxn/Rbae/A== X-Received: by 10.55.198.149 with SMTP id s21mr16297516qkl.196.1486157329105; Fri, 03 Feb 2017 13:28:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Fri, 3 Feb 2017 13:28:48 -0800 (PST) In-Reply-To: References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> <01A9C79C-42AD-4EFA-8BE0-E63CB0DDCF7F@dukhovni.org> From: Kathleen Moriarty Date: Fri, 3 Feb 2017 16:28:48 -0500 Message-ID: To: IETF SAAG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] AD sponsoring Effect of Ubiquitous 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, 03 Feb 2017 21:28:52 -0000 Hi Viktor, Thanks again, response inline. On Fri, Feb 3, 2017 at 2:08 PM, Viktor Dukhovni wr= ote: > >> On Feb 3, 2017, at 1:17 PM, Kathleen Moriarty wrote: >> >>> ... perhaps another formulation could have been: >>> >>> In addition to encrypted MTA-to-MTA email transmission (SMTP over T= LS), >>> other application level transport encryption efforts are underway. >>> This includes a push to encrypt web site access (HTTP over TLS) and >>> gateway-to-gateway transport for protocols such as instant messagin= g >>> (XMPP over TLS). >> >> I think the first sentence saying 'underway' is probably causing your >> reaction, I suspect, and that's fair. >> >>> Of course the order is by no means critical, and application "prominenc= e" >>> is no less valid a sorting criterion than adoption progress. I just ho= pe >>> that readers don't walk away with the impression that adoption in the >>> non-HTTP space trails adoptions in HTTP. >> >> Sure, fair point. What about the following that considers your point. >> >> In addition to encrypted web site access (HTTP over TLS), other >> well-deployed application level transport encryption efforts. This >> includes mail transfer agent (MTA)-to-MTA session encryption >> transport for email (SMTP over TLS) and gateway-to-gateway for >> instant messaging (XMPP over TLS). > > Some words must not have made it from thought to keyboard in the above. > Would you care to amend the second clause of the first sentence? Oh, you are right, thanks. How about: In addition to encrypted web site access (HTTP over TLS), other well-deployed application level transport encryption efforts such as mail transfer agent (MTA)-to-MTA session encryption transport for email (SMTP over TLS) and gateway-to-gateway for instant messaging (XMPP over TLS). It makes for a longer sentence than I'd like, but covers the points. > >>> There are also some advantages in doing STARTTLS. For example, Postfix >>> is often able to detect split TLS session caches behind L4 load-balance= rs >>> by observing differences in the server identity reported in the EHLO re= ply. >>> This makes for much more effective TLS session caching. >>> >>> The case for "implicit" TLS for MTA-to-MTA SMTP is not very compelling. >> >> Sure, but I don't see a reason to add text on implicit TLS into this >> section, do you? > > Not especially, all I am saying is that we should not be overly > disparaging STARTTLS, it has some merit. Oh sure, I agree. > >> If you have info on load balancers and could help with text per >> Eliot's question in this thread, that would be much appreciated. > > Sadly, I don't have anything profound to say about load-balancers. > I've just had to work around the limitations of a small number of > variants. OK, I'll try a bit harder to round up experts to chime in with text. > > The observation about split TLS session caches is that in a na=C3=AFve > implementation each actual server behind a load-balancer will have > its own rTLS session cache and/or its own session ticket decryption > keys. This rather breaks session resumption, especially for clients > that cache sessions for more than just a quick burst of connections > (short-term "sticky" LB may work for those). > > The gmail MX hosts are load-balanced, but they have shared session > ticket keys, and a fixed EHLO response server id: > > S: 250-mx.google.com at your service, [] > > this is one example of a working unified server TLS cache, despite > the presence of load-balancers. > > With outlook.com, for example, on making two connections I get: > > 1. S: 250-SNT004-MC10F16.hotmail.com (3.21.0.266) Hello [] > > 2. S: 250-SNT004-MC8F2.hotmail.com (3.21.0.266) Hello [] > > For better or worse, Postfix will assume a split cache, and only reuse > TLS sessions when hitting the same server. After 5 more connections I > again see: > > ... > > 7. S: 250-SNT004-MC10F16.hotmail.com (3.21.0.266) Hello [] > > So, under load, session re-use may kick in after a client accumulates ses= sion > tickets from sufficiently many outlook.com (aka hotmail.com) peers. I can glean some from here, but not enough for a section, so I'll look to see if I can find an expert or two specific to load balancers. Thank you, Kathleen > > -- > Viktor. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --=20 Best regards, Kathleen From nobody Fri Feb 3 13:39:35 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234E9129561 for ; Fri, 3 Feb 2017 13:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCbyNERhd6mA for ; Fri, 3 Feb 2017 13:39:31 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BBCA12948C for ; Fri, 3 Feb 2017 13:39:31 -0800 (PST) Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 698C5284E4B for ; Fri, 3 Feb 2017 21:39:30 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: <4a3e58c7-aaeb-4ff7-6139-9ec8919f64ff@trigofacile.com> Date: Fri, 3 Feb 2017 16:39:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> <4a3e58c7-aaeb-4ff7-6139-9ec8919f64ff@trigofacile.com> To: IETF SAAG X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [saag] AD sponsoring Effect of Ubiquitous Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: IETF SAAG List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 21:39:33 -0000 > On Feb 3, 2017, at 4:12 PM, Julien =C3=89LIE = wrote: >=20 > Maybe in Section 2: >=20 > The EFF reported [EFF2014] several network service providers taking > steps to prevent the use of SMTP over TLS by breaking StartTLS, > preventing the negotiation process resulting in fallback to the use > of clear text. >=20 > A reference to Section 3.2 of RFC 7525 could be added (about SSL = Stripping). > Incidentally, shouldn't "StartTLS" be written "STARTTLS"? >=20 >=20 > Also, Section 7 mentions a similar attack: >=20 > There has already been documented cases of service providers > preventing STARTTLS [NoEncrypt] to prevent session encryption > negotiation on some session to inject a super cookie. Note that STARTTLS is both a mechanism for engaging the use of TLS and a means to provide both TLS and cleartext service at a single transport endpoint. When STARTTLS is used opportunistically, it is of course subject to a "STARTTLS stripping" downgrade attack. However, downgrade attacks are not limited to STARTTLS. For services such as POP and IMAP there are often separate non-TLS ports, and suitable application (auto?)configuration may still fallback to cleartext (on an alternate port) in the apparent absence of TLS service. So the question of whether TLS is "strict" or "opportunistic", is logically separate from whether it is "implicit" (TLS, then application protocol) or "explicit" (application protocol, then STARTTLS). Opportunistic TLS is of course subject to downgrades, absent downgrade- resistant out-of-band capability signalling (e.g. DANE TLSA RRs). Given downgrade-resistant signalling, there are no downgrade issues with "STARTTLS" that are absent in "implicit TLS". We should not confuse correlation (some opportunistic services use STARTTLS) with causation (STARTTLS is not secure against active attack). What falls to active attack is opportunistic use of TLS in the absence of downgrade-resistant capability signalling. STARTTLS is just a way of providing both the cleartext and encrypted service on a single port. Applications can and do employ downgrade-resistant STARTTLS via local policy, DANE, (STS, ...). --=20 Viktor. From nobody Fri Feb 3 13:47:08 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A8D129575 for ; Fri, 3 Feb 2017 13:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17ubjFCTzZFU for ; Fri, 3 Feb 2017 13:47:06 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3373212954B for ; Fri, 3 Feb 2017 13:47:06 -0800 (PST) Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 5805D284E4B for ; Fri, 3 Feb 2017 21:47:05 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 3 Feb 2017 16:47:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <82948D5F-EE2B-46CE-A2A5-0C52E1829B40@dukhovni.org> References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> <01A9C79C-42AD-4EFA-8BE0-E63CB0DDCF7F@dukhovni.org> To: IETF SAAG X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [saag] AD sponsoring Effect of Ubiquitous Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: IETF SAAG List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 21:47:08 -0000 > On Feb 3, 2017, at 4:28 PM, Kathleen Moriarty = wrote: >=20 >>> Sure, fair point. What about the following that considers your = point. >>>=20 >>> In addition to encrypted web site access (HTTP over TLS), other >>> well-deployed application level transport encryption efforts. This >>> includes mail transfer agent (MTA)-to-MTA session encryption >>> transport for email (SMTP over TLS) and gateway-to-gateway for >>> instant messaging (XMPP over TLS). >>=20 >> Some words must not have made it from thought to keyboard in the = above. >> Would you care to amend the second clause of the first sentence? >=20 > Oh, you are right, thanks. How about: >=20 > In addition to encrypted web site access (HTTP over TLS), other > well-deployed application level transport encryption efforts such = as > mail transfer agent (MTA)-to-MTA session encryption > transport for email (SMTP over TLS) and gateway-to-gateway for > instant messaging (XMPP over TLS). >=20 > It makes for a longer sentence than I'd like, but covers the points. There's a missing verb or other words in the second clause. So it remains unclear what you're saying, the shorter version was otherwise fine by me. --=20 Viktor. From nobody Fri Feb 3 18:18:53 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146591295EF for ; Fri, 3 Feb 2017 18:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTjteCxmPyAh for ; Fri, 3 Feb 2017 18:18:50 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D6C127735 for ; Fri, 3 Feb 2017 18:18:50 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id s186so8766618qkb.1 for ; Fri, 03 Feb 2017 18:18:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=Gc4ByuORE5J9yd3P8O0jHKTQzcwCIiuzZNAFj654Oc0=; b=CpYORg09NoMrkcfeAQvKXZPNnlDee3/Xh7NDjLcA+TeEn9eoRPTB91XHZqJ/vzNNJC Alo4FIaR//dR/iUBVksyNa9mYWiLo/52n9jhXxsWFWYCX6tHk+ji5FUgNd0PU4l1EZbw MlBfF22m2yJlhXV5rwiApmGC/GwEnHDcDCuUycpuIb8qZuROZLXXXcuuNZceMASR5KdQ S9pp141UjKPTMjTWxe1FCoejw/34dX38pUvuhWWRFn0IAL/UZLraiu2euVaBD31DWrdj AUNvFHBOKB7H/edAK2WmlM78Ie5VcCldEEFP4P8aGGm7EOFmNQdx72ha5FHJvf9R/d5p Ok8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to; bh=Gc4ByuORE5J9yd3P8O0jHKTQzcwCIiuzZNAFj654Oc0=; b=ahUxcjFYZlYPU4GaLTc7lAc5Mab0Oz6ojT0yKKhHoUxJ0iW5D+FzCWW9kFDAVKLX71 CQ+tXGoteLSxCJ8Qfz6O0xcRA7JrwNaOPVNOHQOoroH9I7ekjnycyegIxryoHX7M3SH2 VCSElWp8MhFzg6IWzV7bBqdt5WsMu553POycLIR0TzkR/SZIBeJy0v/P+qMSSiROGjIj 5r1JiBu6+GS8wP9sUY0cLOdUH8tirkoyJqVI2BTZ1XjBk1KeG1tqe19+yMTmkmlb0nxJ YqzTPxDy1eOl+IUOfMghWNGz9XJyabmNBkotGW1vg2TRg+l66LkiQSsXKf8U5TyShehp K3rA== X-Gm-Message-State: AMke39mzisHDc8KYeSVkIimW8fEtfGiyRocIv0TL49FgIfKtj/62m0dCdUJdHIe84loKzg== X-Received: by 10.55.24.221 with SMTP id 90mr106806qky.296.1486174729335; Fri, 03 Feb 2017 18:18:49 -0800 (PST) Received: from [192.168.1.8] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id k18sm26130855qtc.12.2017.02.03.18.18.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 18:18:48 -0800 (PST) From: kathleen.moriarty.ietf@gmail.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Fri, 3 Feb 2017 21:18:48 -0500 Message-Id: <897A9CA0-1635-4604-9192-ED0617CFEC94@gmail.com> References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> <01A9C79C-42AD-4EFA-8BE0-E63CB0DDCF7F@dukhovni.org> <82948D5F-EE2B-46CE-A2A5-0C52E1829B40@dukhovni.org> In-Reply-To: <82948D5F-EE2B-46CE-A2A5-0C52E1829B40@dukhovni.org> To: IETF SAAG X-Mailer: iPhone Mail (14D27) Archived-At: Subject: Re: [saag] AD sponsoring Effect of Ubiquitous 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, 04 Feb 2017 02:18:52 -0000 Please excuse typos, sent from handheld device=20 > On Feb 3, 2017, at 4:47 PM, Viktor Dukhovni wrote= : >=20 >=20 >> On Feb 3, 2017, at 4:28 PM, Kathleen Moriarty wrote: >>=20 >>>> Sure, fair point. What about the following that considers your point. >>>>=20 >>>> In addition to encrypted web site access (HTTP over TLS), other >>>> well-deployed application level transport encryption efforts. This >>>> includes mail transfer agent (MTA)-to-MTA session encryption >>>> transport for email (SMTP over TLS) and gateway-to-gateway for >>>> instant messaging (XMPP over TLS). >>>=20 >>> Some words must not have made it from thought to keyboard in the above. >>> Would you care to amend the second clause of the first sentence? >>=20 >> Oh, you are right, thanks. How about: >>=20 >> In addition to encrypted web site access (HTTP over TLS), other >> well-deployed application level transport encryption efforts such as >> mail transfer agent (MTA)-to-MTA session encryption >> transport for email (SMTP over TLS) and gateway-to-gateway for >> instant messaging (XMPP over TLS). >>=20 >> It makes for a longer sentence than I'd like, but covers the points. >=20 > There's a missing verb or other words in the second clause. So it > remains unclear what you're saying, the shorter version was otherwise > fine by me. Yes, I did see that, thanks. I preferred the combined sentences over any ve= rb I came up with at the time. I may tweak it again. Thank you, Kathleen=20 >=20 > --=20 > Viktor. >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Sat Feb 4 09:58:01 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFD712967A for ; Sat, 4 Feb 2017 09:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 3JU41zuAQD4i for ; Sat, 4 Feb 2017 09:57:59 -0800 (PST) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (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 5D53212967E for ; Sat, 4 Feb 2017 09:57:59 -0800 (PST) Received: by mail-qt0-x244.google.com with SMTP id w20so9789913qtb.1 for ; Sat, 04 Feb 2017 09:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5ES2wLapsh5l28Cg+PmyEZTyJ6/A2MsGj1fDZQyenBE=; b=G0D6M7xUqYxMsCYgSTU/CFg+y+sXC7wHJpTCA/iC8BDOt8NijxSLagr4Yn+Jvw9cek Xwls6ynhMkaoHfNRwXaJuIg/eBaft1HYqDu8UlSKbgYw9TY0+WeM4byn9sUpWPH8HqFj oLW/pbB8CX20sPLSeLwkCcIHYuatG48Lqk4z1JO873cAbK2kxaVs+9uZ3aEnT1Hzf/ev 10nrB5TAnGmyjjM7j1yssOZoVqTvDslinHaYjEseFCU7f0AGgB5OOrfTK50vH6fKwZ+p 1JZoon9G7hS3oNMCW01yuqgNW07SiIQMdu/kWp765WG53U4b+MJOYVaEgnEBAiCRvtN2 goPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5ES2wLapsh5l28Cg+PmyEZTyJ6/A2MsGj1fDZQyenBE=; b=rTptE5o8As+4XtKBi3GLyBWqBlS+WOjACRfQXfy42whgsM5udn6lQtKSxeDD+zfJ7N bURHvDeyO4i7w4eVfpJPw/wx0fc8FYo0SBYXZmmBkUjdliEUN27tHeaU1YRjZZfiErrp H1W2VS6vW4hZ+ri1SHTJrAOuzG+xab6TYuz2UBMrBt6cbFCMFabBImiUgPlFIjkH/rIo ttam+hmFoLDTp4HyydyXCZclZKxNGlL+yGgxhiBHi1qRqPBnBdqJipel5h3h0XFchmMN 0+eiRWr9ZBw6fPwMTBjjhqPP8lZxEZLYAl/7QUm6EzRdkWO+xo5fhiutJLec5VsTwn0q Cm/g== X-Gm-Message-State: AMke39mRzjx/WaGvlVjd+m5hnuTCvYlmb5RVgjGAP3w2cmoanZ3DX7qMFJPeaSv8KOIF3Q== X-Received: by 10.200.36.41 with SMTP id c38mr2846537qtc.57.1486231078541; Sat, 04 Feb 2017 09:57:58 -0800 (PST) Received: from ?IPv6:2607:fb90:682b:13b6:cc9:144e:7870:10e9? ([2607:fb90:682b:13b6:cc9:144e:7870:10e9]) by smtp.gmail.com with ESMTPSA id d52sm28118758qtc.2.2017.02.04.09.57.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 04 Feb 2017 09:57:58 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Margaret Cullen In-Reply-To: <897A9CA0-1635-4604-9192-ED0617CFEC94@gmail.com> Date: Sat, 4 Feb 2017 12:57:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <305A999E-BAA0-4F1F-BF06-2A41472BFDE3@gmail.com> References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> <01A9C79C-42AD-4EFA-8BE0-E63CB0DDCF7F@dukhovni.org> <82948D5F-EE2B-46CE-A2A5-0C52E1829B40@dukhovni.org> <897A9CA0-1635-4604-9192-ED0617CFEC94@gmail.com> To: kathleen.moriarty.ietf@gmail.com X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF SAAG Subject: Re: [saag] AD sponsoring Effect of Ubiquitous 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, 04 Feb 2017 17:58:00 -0000 > On Feb 3, 2017, at 4:28 PM, Kathleen Moriarty = wrote: >=20 > Oh, you are right, thanks. How about: >=20 > In addition to encrypted web site access (HTTP over TLS), other > well-deployed application level transport encryption efforts such as > mail transfer agent (MTA)-to-MTA session encryption > transport for email (SMTP over TLS) and gateway-to-gateway for > instant messaging (XMPP over TLS). >=20 > It makes for a longer sentence than I'd like, but covers the points. Do you mean =E2=80=9CIn addition to encrypted web site access (HTTP over = TLS), _there are_ other well-deployed application level transport = encryption efforts? Margaret From return-hd6ixwbvxdfrj5jkmhwwarrnz6@temporary-address.scs.stanford.edu Fri Feb 10 15:12:42 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3831D1295D5; Fri, 10 Feb 2017 15:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44VbmDnoyhRl; Fri, 10 Feb 2017 15:12:40 -0800 (PST) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C830F129401; Fri, 10 Feb 2017 15:12:37 -0800 (PST) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v1ANCbnL007884; Fri, 10 Feb 2017 15:12:37 -0800 (PST) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v1ANCb8i010273; Fri, 10 Feb 2017 15:12:37 -0800 (PST) From: David Mazieres To: trans@ietf.org, saag@ietf.org, ilc@ietf.org Date: Fri, 10 Feb 2017 15:12:37 -0800 Message-ID: <87poip3aje.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [saag] Internet-level Consensus - new list and possible BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ilc@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 23:22:29 -0000 Several applications depend on Internet-wide consensus to secure an append-only log, provide tamper-resistant timestamps, and atomically commit transactions across mutually distrustful parties with no preexisting relationship. Examples include: * The IETF trans working group is specifying data structures and operational mechanisms for providing secure logging and auditing of TLS server certificates, but lacks a mechanism for determining consensus among logs (or consensus about whether or not a resource should be logged). These functions are currently served by an experimental gossip protocol that can potentially be strengthened through global consensus. * The Stellar payment network, is used by remittance companies to trade currencies and send payments across the Internet. * UCSD's SPAM (Secure PAckage Manager) project relies on a secure global log both to enable revocation of previously published vulnerable software packages and to guarantee that a particular software release has been publicly available for audit (somewhat like certificate transparency). * Stellar has an ongoing secure naming project that aims to allow domain name owners to assign human-readable names to end-user public keys without retaining the ability to lie about those public keys undetected. We have just created a new IETF mailing mailing list to discuss such applications, the mechanisms that can meet their consensus needs, and a potential role of the IETF in devising a stable specification for an Internet-level consensus mechanism. The home page for the list is here: https://www.ietf.org/mailman/listinfo/ilc If there is interest in the topic, we would like to organize a BoF in Chicago. Please join the discussion on the list if you might be interested in participating. David From nobody Mon Feb 13 03:51:50 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135BE1295FC for ; Mon, 13 Feb 2017 03:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTHvNcVzP8ix for ; Mon, 13 Feb 2017 03:51:47 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 0662B129509 for ; Mon, 13 Feb 2017 03:51:46 -0800 (PST) Received: from [192.168.91.173] ([195.149.223.239]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LeuUB-1c35Xs3LZ9-00qf36 for ; Mon, 13 Feb 2017 12:51:43 +0100 To: saag From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <16c236b7-dd80-1e27-8de9-16f05558d38e@gmx.net> Date: Mon, 13 Feb 2017 12:51:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ub4Vwe5a8oA4qKHxoQ7HNwGvXpbFWcIPc" X-Provags-ID: V03:K0:O/EgKz9hbcr62ebx/LMJ4lMydEDgUKgA5W2URS2MwOwzltZHwjo 9+kW0MeX3qC8x8lJyLEyZv+DqtHLSdWxi1qjL1KeWXWetV2Y/l94l11ldbbfvFJrFl+rsLT KcFhOMzUg94Q1X3MFtyWyt+3nhIkGfuCN7umaOosV13LZEed17ge1CcByttsvcm6ob5IUdi kF+FA+xPjdvx1QhtDOK5Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:KU6ffav+l7c=:P7WEohMb+Usvj8mudONI/m uz6WEPZj7C+ej9Zp8fgWYxVEcpkpuLsPq8IOXyDWLX5LeUxtl4AjT08+jjtE0XFaDKT/COfFJ 0lL8vnLgvfMwk9i+UhgKqLkfuTGWjmKTY66kIDOr6XHhuXnaDzbpMhg3eodSBLcW55BiQnXGZ e+bjrXt97JHRHfJYo0l7SW/O9na5P5+mpJmfIRqwnyGYxBrddGc9QbGSElDq7/UVv02bAtWr2 waUuCqb91VtCMpWhM8GkuzOE+n9oqWshxzYaimNas2DqFeTwS5AAfuLY1iVTbpSr/OvBViqi5 5Fg2tTR9d0R3L+u8q+Azi1FnCtBxhBgKcclkxW0vzkTWGAHQ1wQkoSnaEwOjrTSRRzpnK/9va 7FbmpadIG10FleqY0iGO8V4fqsRn6wiLVmhSEb/8MZ0u1Jl9WSc3v7GNV5zShM3HJ1cJ63spC iVRtnTxoOQx04SdCyjVe/WnPq/QITuYhVXHgm6IL0KiBr5TSvPNUCpivSsFgkr3R9RQ+e2n7y IAbCgj3h+4mB0FWahaMgtNi6RlCBDafooG4aXyzOSJhUSRk67mJ+A3kuVirBQhJ3DbVfNlZ3R 8OmoOl56RLNw9wFssk/zYRd1qLlM3P56v1DQTP9u0pwwMPt6KRLpM25SzmunsKBXx7jrcxqF2 jBtcHPf26TvhJlXy4+sxdtR0AVjG06Rh9S1+J3b9ha19D50d4tAtr+pjmb0B55UBpIJjPf3d7 yw28Idbtq97Fo2IdkB0/UfTGb805Qun7J9p7y1iXukejeQuQHId4ZTrdI8U= Archived-At: Subject: [saag] BOFs about IoT firmware update and TEE configuration X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 11:51:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ub4Vwe5a8oA4qKHxoQ7HNwGvXpbFWcIPc Content-Type: multipart/mixed; boundary="PddLjt4IwV7Jqw9HDVBcl8gRXCweGMswL"; protected-headers="v1" From: Hannes Tschofenig To: saag Message-ID: <16c236b7-dd80-1e27-8de9-16f05558d38e@gmx.net> Subject: BOFs about IoT firmware update and TEE configuration --PddLjt4IwV7Jqw9HDVBcl8gRXCweGMswL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, we have proposed two security-relevant BOFs for the upcoming meeting. They are listed on the BOF Wiki page at https://trac.tools.ietf.org/bof/trac/wiki but I still wanted to briefly introduce them to you ** =E2=80=9CFirmware Update Description (FUD)=E2=80=9D Last year we had a workshop organized by the IAB on firmware updates for IoT devices (see https://www.iab.org/activities/workshops/iotsu/) where we talked about various challenges and gaps. As a follow-up to the workshop we would like to initiate some standardization activity in this area. The mailing list can be found at https://www.ietf.org/mailman/listinfo/fud ** =E2=80=9CA Protocol for Dynamic Trusted Execution Environment Enableme= nt (TEEP)=E2=80=9D This BOF is about an application layer security protocol that allows to configure security credentials and software running on a Trusted Execution Environment (TEE). Today, TEEs are, for example, found home routers, set-top boxes, smart phones, tablets, wearables, etc. Unfortunately, there have been mostly proprietary protocols used in this environment. With this BOF we are making an attempt to standardize such a protocol. A strawman proposal of such a protocol has been published with https://tools.ietf.org/html/draft-pei-opentrustprotocol-03. The mailing list can be found at: https://www.ietf.org/mailman/listinfo/teep Ciao Hannes --PddLjt4IwV7Jqw9HDVBcl8gRXCweGMswL-- --ub4Vwe5a8oA4qKHxoQ7HNwGvXpbFWcIPc 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYoZ3OAAoJEGhJURNOOiAtPhEH/1G0Mdppj6Cz/BCySQs9oDtd YS1sbgXHObbz+mgB7OT0xorc/TBwFbMyu6gNjE+8Rqz//elzDmwWAVZ7jZ2gBlp0 iVuVMu0tsQw730HqSezY9xwcArptbR1/Tewua67ysoS0F5CX0hut5V5gQPMervsQ PDPcqP+s4CMjZXlk4khnWpOliyXXnhMLAT27d8/hZ4IU6kBEHH1u1b2Pr9CWUfEU BFR71l9cayou2kZupZU4glVxNuK+GOfVe1/T2TyyjqqVuWECo8Z8379YpAuYoTEx YT6wBZq21WOvW2SCfMxqzH0FuBZ3oJSI4Jk1AseTOna+KwH8OiM2eHo2iwSW7s0= =1iJt -----END PGP SIGNATURE----- --ub4Vwe5a8oA4qKHxoQ7HNwGvXpbFWcIPc-- From nobody Mon Feb 13 05:29:31 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93F2129576 for ; Mon, 13 Feb 2017 05:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 9Nb0I8gIEc28 for ; Mon, 13 Feb 2017 05:29:27 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500FB129657 for ; Mon, 13 Feb 2017 05:29:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6724; q=dns/txt; s=iport; t=1486992563; x=1488202163; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=o/kiaOklIUtfHf5MRjQkhPwUA8NXKY53Ut6kOjliXBE=; b=C7WtthJpe6/VnffmyBXKCJzgyIIcXKV85OQX2iBzWSHm/wjjSSPgjARS VbxyDrKLHGJfZ+vTJTmpk/m8d/2p8v8At05Stot3vYycum8l/9hXEu8YM z15L/CpY8BLfv6tdM80uSfrT9DmlZmvmzOzt2zw0G+p0kTP4I2xhqb0qJ A=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmCACFs6FY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDMDJ1+DWYp6kHofkAqFLIIMHwEKgkKDNgKDJRYBAgEBAQEBAQF?= =?us-ascii?q?iKIRqAQEEAQEhSxsLBBQqAgInMAYBDAYCAQGJZg6uDoIlK4sXAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBDgoFiFEIgmKHWoJfBZtyg3OCB3WLJYF7iESGRogsimkmCSi?= =?us-ascii?q?BACAUCBUVPYZEPzUBiiwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,156,1484006400"; d="asc'?scan'208,217";a="652451379" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2017 13:29:21 +0000 Received: from [10.61.213.107] ([10.61.213.107]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v1DDTKKl020816; Mon, 13 Feb 2017 13:29:21 GMT To: Hannes Tschofenig , saag References: <16c236b7-dd80-1e27-8de9-16f05558d38e@gmx.net> From: Eliot Lear Message-ID: Date: Mon, 13 Feb 2017 14:29:20 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <16c236b7-dd80-1e27-8de9-16f05558d38e@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kllqoAeNUrcKresAsLQlScEJBo7gPFHsq" Archived-At: Subject: Re: [saag] BOFs about IoT firmware update and TEE configuration X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 13:29:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kllqoAeNUrcKresAsLQlScEJBo7gPFHsq Content-Type: multipart/mixed; boundary="0TcNTkLlsfDnfiQP6wP5tImTPkONgFm6W"; protected-headers="v1" From: Eliot Lear To: Hannes Tschofenig , saag Message-ID: Subject: Re: [saag] BOFs about IoT firmware update and TEE configuration References: <16c236b7-dd80-1e27-8de9-16f05558d38e@gmx.net> In-Reply-To: <16c236b7-dd80-1e27-8de9-16f05558d38e@gmx.net> --0TcNTkLlsfDnfiQP6wP5tImTPkONgFm6W Content-Type: multipart/alternative; boundary="------------9AA0DB300F38DAEE70C03BCD" This is a multi-part message in MIME format. --------------9AA0DB300F38DAEE70C03BCD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hannes, Can you say a few words about how TEE compares to draft-ietf-anima-bootstrap-keyinfra (et al) which has been in development in a WG for quite some time? Eliot On 2/13/17 12:51 PM, Hannes Tschofenig wrote: > Hi all, > > we have proposed two security-relevant BOFs for the upcoming meeting. > They are listed on the BOF Wiki page at > https://trac.tools.ietf.org/bof/trac/wiki but I still wanted to briefly= > introduce them to you > > ** =E2=80=9CFirmware Update Description (FUD)=E2=80=9D > > Last year we had a workshop organized by the IAB on firmware updates fo= r > IoT devices (see https://www.iab.org/activities/workshops/iotsu/) where= > we talked about various challenges and gaps. > > As a follow-up to the workshop we would like to initiate some > standardization activity in this area. > > The mailing list can be found at > https://www.ietf.org/mailman/listinfo/fud > > > ** =E2=80=9CA Protocol for Dynamic Trusted Execution Environment Enable= ment (TEEP)=E2=80=9D > > This BOF is about an application layer security protocol that allows to= > configure security credentials and software running on a Trusted > Execution Environment (TEE). Today, TEEs are, for example, found home > routers, set-top boxes, smart phones, tablets, wearables, etc. > Unfortunately, there have been mostly proprietary protocols used in thi= s > environment. > > With this BOF we are making an attempt to standardize such a protocol. = A > strawman proposal of such a protocol has been published with > https://tools.ietf.org/html/draft-pei-opentrustprotocol-03. > > The mailing list can be found at: > https://www.ietf.org/mailman/listinfo/teep > > > > > Ciao > Hannes > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------9AA0DB300F38DAEE70C03BCD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hannes,

Can you say a few words about how TEE compares to draft-ietf-anima-bootstrap-keyinfra (et al) which has been in development in a WG for quite some time?

Eliot


On 2/13/17 12:51 PM, Hannes Tschofenig= wrote:
Hi all,

we have proposed two security-relevant BOFs for the upcoming meeting.
They are listed on the BOF Wiki page at
https://trac.tools.ietf.org/bof/trac/wiki but I still wa=
nted to briefly
introduce them to you

** =E2=80=9CFirmware Update Description (FUD)=E2=80=9D

Last year we had a workshop organized by the IAB on firmware updates for
IoT devices (see https://www.iab.org/activities/worksh=
ops/iotsu/) where
we talked about various challenges and gaps.

As a follow-up to the workshop we would like to initiate some
standardization activity in this area.

The mailing list can be found at
https://www.ietf.org/mailman/listinfo/fud


** =E2=80=9CA Protocol for Dynamic Trusted Execution Environment Enableme=
nt (TEEP)=E2=80=9D

This BOF is about an application layer security protocol that allows to
configure security credentials and software running on a Trusted
Execution Environment (TEE). Today, TEEs are, for example, found home
routers, set-top boxes, smart phones, tablets, wearables, etc.
Unfortunately, there have been mostly proprietary protocols used in this
environment.

With this BOF we are making an attempt to standardize such a protocol. A
strawman proposal of such a protocol has been published with
https://tools.ietf.org/html/draft-pei-opent=
rustprotocol-03.

The mailing list can be found at:
https://www.ietf.org/mailman/listinfo/teep




Ciao
Hannes





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

--------------9AA0DB300F38DAEE70C03BCD-- --0TcNTkLlsfDnfiQP6wP5tImTPkONgFm6W-- --kllqoAeNUrcKresAsLQlScEJBo7gPFHsq 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 iQEcBAEBCAAGBQJYobSxAAoJEIe2a0bZ0noztMQIAKPsbpCz+Khg9Lyd24l2tXzh OE+zDJUXgSFk6wWMV5h3P0y0bsjmPyADwN2qbF236ZrLQ38rGepiGC+lZK0pHdBd tLEvp4cysPN2D7MK2310E6RkGxdBtOp6NQFgivC7cCdu7G/wUzdV8IPBr4JW/EYQ Dr7AYp8hEWiE6IpnDw/XtdWCC7Nv5eKl+wfM2u+hbsmqHgtRnasuugScz9MgOeAX KjCHhXL8Q7XrGb145Cm8RqwFJgwfCUjgUcHDONelhSxXvoGV01etcEv3dZjmDGMn 9sdn1cyWV894k+v6Y3XoZwIAGfMChq1Rt3mSLh9IBrFynhQjshFAs9u4m9uYQN8= =Fw/8 -----END PGP SIGNATURE----- --kllqoAeNUrcKresAsLQlScEJBo7gPFHsq-- From nobody Mon Feb 13 07:40:38 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5781F129406 for ; Mon, 13 Feb 2017 07:40:37 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQWJaGgopFFw for ; Mon, 13 Feb 2017 07:40:35 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 9959C128E18 for ; Mon, 13 Feb 2017 07:40:35 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id v23so86436975qtb.0 for ; Mon, 13 Feb 2017 07:40:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=W3QlfDvUa59tIsG+1aJlwS6yQO1j+JD0bz9dDiY2KCM=; b=qjWtmrno+Z8aNsddMRq4twS7AMSOy4PRprS4479DMAL9Vm+4ichDaIH3cAugXg9QKV PfxSdU7XhlhKEFp9aHiA1HsEj6pQiPLyMIeYFPBkOGNLp+lXEANPlmcoOdtEcYUfJlYE gT3s84ahITCzCLXdfGhWPUHMmDDhpypCuqt1rP/907OgCL1miNn71wWo1Dnbdl5itEvN O94FyrA6mCJViNRwN41gdsmPyVBCQx0V+JW5ogu1xJWzmgskAJedPE4aCI9JW/ahmXAw Ph5LV/o+xgRtHUE8Jhkd3U2NFwuUzyweeOvjjf3/+7a8bQtag1FYcOKOs7AbCdJuad4W HKvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=W3QlfDvUa59tIsG+1aJlwS6yQO1j+JD0bz9dDiY2KCM=; b=Gn3w9c+Dy11sIjt/urnJC9R/G7k53Zy62LfWXYGVjryUMgBPDkLJCwvRHYNSUha/8u T8XM2D1h2ZDza4pMdYl+XS2rnHaIB6DWC8EuSFy3IWVsQ3hROJ6iUfk4Gmd7vNj0bjli M6rdxrh9RuD2NSS8qKJ75h5c3t4f74o2HQZazD5KhFqXfqXMm7We0XvC6PHAV7bC4Fcl hrgEei9LlBCQHjHL76TxXjTn3WryP5vbpGvuYRwFIh9+OYE9yulStLmaDkVTnBXmHBq/ TDhhlsciMbxE1VqOl2JyvCyFfPUR/cZVRsiU0uZmCpqDkuqjaY+NaHcLpfB1VHwawmjy Dx4g== X-Gm-Message-State: AMke39ln0SLBJMhjU98nPGzs41TjsuLh49GOk6yFWuUcw88jGlmzZtF3n6NGCu+OGzvO0eEQLpiw94ffz2ac9g== X-Received: by 10.200.49.106 with SMTP id h39mr24082758qtb.257.1487000428336; Mon, 13 Feb 2017 07:40:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Mon, 13 Feb 2017 07:40:28 -0800 (PST) From: Kathleen Moriarty Date: Mon, 13 Feb 2017 10:40:28 -0500 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] AD review of draft-gutmann-scep X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 15:40:37 -0000 Hello, I reviewed the following draft in a request to AD sponsor, https://datatracker.ietf.org/doc/draft-gutmann-scep/ Additional comments are welcome on the draft. I don't think there is a better suited list to discuss, so I am posting the review here. Major: 1. I see the draft is marked as a proposed standard, but previous drafts for SCEP are marked as HISTORIC with the reason explained in the introduction of https://tools.ietf.org/html/draft-nourse-scep-23. Can you explain why this is marked as standards track? I'd like to figure out the best fit. Nits: 1. Introduction: The following opinion sentence is not necessary as worded: While implementers are encouraged to investigate one of the more comprehensive alternative certificate management protocols in addition to the protocol defined in this specification, anyone wishing to deploy them should proceed with caution, and consider support and interoperability issues before committing to their use. I think it'll raise objections because of the opinion aspect, which isn't really appropriate for a standards document. 2. Section 2.1.3: s/the them/them/ If the CA certificate(s) have not previously been acquired by the client through some other means, the client MUST retrieve the them before any PKI operation (Section 3) can be started. 3. Section 2.1.3 Is SHA-1 still really need for legacy reasons or can that be eliminated? 4. Section 2.8 Are you really still seeing use of 3DES and SHA-1 or is this old text? 5. Section 4.4 s/Whe the client/When the client/ -- Best regards, Kathleen From nobody Mon Feb 13 07:46:09 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D371296EA for ; Mon, 13 Feb 2017 07:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gllJLLtt0oBs for ; Mon, 13 Feb 2017 07:46:01 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 B48E0129454 for ; Mon, 13 Feb 2017 07:46:01 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id w20so86283046qtb.1 for ; Mon, 13 Feb 2017 07:46:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=asnbh1bNv1vhJ6dxScV7dlutYv7njH+5Tfl0XCnpIhc=; b=AwjL9Yar/bluVW5qfmLiCx71UTQjCeNxvPq0jhWuugKAGTiYZpyrbUbJDpOtXmxoez tKU+iiF1Iqdr6b3QjNAc+KfcioUWRv9KQi5Mti+TWu5czMA9U5Hw5V2/DOsKWoCTWxvy Q31VPiIJaKdihMbOi1APc9XGn1OHURx+H8Rkfxxr77Xyqo33PXCe5PJKFwgghEZsaXO5 tksQzyEugHpsclQqst2J8dE7rNh0nCefInsAJtXwf0yyVcR1NgrGeqGT4BP1kCzNivY4 f+OdKc21ZkQVUHhiASylE0rhFOlyW/ikQz9AMpY+x2rD2GlJq9fFiK3yueOrvTLDZ2g/ 6vfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=asnbh1bNv1vhJ6dxScV7dlutYv7njH+5Tfl0XCnpIhc=; b=DSHs4lFmkwJBWmjm6iAx2D0c0wywsa7EhwBWc4RZC5/t/CXaGkzofEeofrs7dmOd+o AQdqLLN/IoxbWcaIm3SuPKI70OM+wsTFxWIN+3IUCJuZvfFLt+wP5cRwkwTYtvTcWWk6 LwALA/tDR/bqpphEHscqHXCiQXd+ozy+PO308w33rekKYnO0GgzBQKWFqFesrG6pH4Hi jH4ERAGjzjFessJhiw9oULOYemHTxqNnwN0PUwWJ6KEU2gi4WVJW5xIsqQdVoAEgDH9r t/ZKvEn54dvyZNmqfsf7cUSeI5SUjhHYdMQc4zXnG81W8jZrXUuxn6yRn7ZPnitLgDcZ 2znQ== X-Gm-Message-State: AMke39kcITnx3aMFvztegxzf+2zMqG+G+ttAxpZzUuawjVLcRrwWnfDOqfgCm8NarhQup82q4HBFZS0tQyy19A== X-Received: by 10.237.41.36 with SMTP id s33mr20299189qtd.139.1487000760784; Mon, 13 Feb 2017 07:46:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Mon, 13 Feb 2017 07:45:59 -0800 (PST) In-Reply-To: <305A999E-BAA0-4F1F-BF06-2A41472BFDE3@gmail.com> References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> <01A9C79C-42AD-4EFA-8BE0-E63CB0DDCF7F@dukhovni.org> <82948D5F-EE2B-46CE-A2A5-0C52E1829B40@dukhovni.org> <897A9CA0-1635-4604-9192-ED0617CFEC94@gmail.com> <305A999E-BAA0-4F1F-BF06-2A41472BFDE3@gmail.com> From: Kathleen Moriarty Date: Mon, 13 Feb 2017 10:45:59 -0500 Message-ID: To: Margaret Cullen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF SAAG Subject: Re: [saag] AD sponsoring Effect of Ubiquitous 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, 13 Feb 2017 15:46:07 -0000 On Sat, Feb 4, 2017 at 12:57 PM, Margaret Cullen wro= te: >> On Feb 3, 2017, at 4:28 PM, Kathleen Moriarty wrote: >> >> Oh, you are right, thanks. How about: >> >> In addition to encrypted web site access (HTTP over TLS), other >> well-deployed application level transport encryption efforts such as >> mail transfer agent (MTA)-to-MTA session encryption >> transport for email (SMTP over TLS) and gateway-to-gateway for >> instant messaging (XMPP over TLS). >> >> It makes for a longer sentence than I'd like, but covers the points. > > Do you mean =E2=80=9CIn addition to encrypted web site access (HTTP over = TLS), _there are_ other well-deployed application level transport encryptio= n efforts? Yes, thank you, Margaret! > > Margaret > > --=20 Best regards, Kathleen From nobody Mon Feb 13 08:26:31 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7972212952C; Mon, 13 Feb 2017 08:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQB_938jp82p; Mon, 13 Feb 2017 08:26:24 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D46C129441; Mon, 13 Feb 2017 08:26:24 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2ED4A200A3; Mon, 13 Feb 2017 11:47:46 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5BB7E6381A; Mon, 13 Feb 2017 11:26:23 -0500 (EST) From: Michael Richardson To: Hannes Tschofenig In-Reply-To: <16c236b7-dd80-1e27-8de9-16f05558d38e@gmx.net> References: <16c236b7-dd80-1e27-8de9-16f05558d38e@gmx.net> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: anima-bootstrap , saag Subject: Re: [saag] BOFs about IoT firmware update and TEE configuration X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 16:26:26 -0000 Hannes Tschofenig wrote: > ** =E2=80=9CFirmware Update Description (FUD)=E2=80=9D > Last year we had a workshop organized by the IAB on firmware updates = for > IoT devices (see https://www.iab.org/activities/workshops/iotsu/) whe= re > we talked about various challenges and gaps. > As a follow-up to the workshop we would like to initiate some > standardization activity in this area. > The mailing list can be found at > https://www.ietf.org/mailman/listinfo/fud It's a terrible TLA. Too good not to keep. > ** =E2=80=9CA Protocol for Dynamic Trusted Execution Environment Enab= lement (TEEP)=E2=80=9D > This BOF is about an application layer security protocol that allows = to > configure security credentials and software running on a Trusted > Execution Environment (TEE). Today, TEEs are, for example, found home > routers, set-top boxes, smart phones, tablets, wearables, etc. > Unfortunately, there have been mostly proprietary protocols used in t= his > environment. > With this BOF we are making an attempt to standardize such a protocol= . A > strawman proposal of such a protocol has been published with > https://tools.ietf.org/html/draft-pei-opentrustprotocol-03. > The mailing list can be found at: > https://www.ietf.org/mailman/listinfo/teep okay. We (ANIMA bootstrap DT) need BOF time to talk about what we are doing, and = how we leverage TPMs. This is additional existing work. -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Mon Feb 13 08:51:01 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52561294DC for ; Mon, 13 Feb 2017 08:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dzse9e0xH_0a for ; Mon, 13 Feb 2017 08:50:57 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17811129441 for ; Mon, 13 Feb 2017 08:50:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8BDA8BEB5 for ; Mon, 13 Feb 2017 16:50:54 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5M4gw7wnYQf for ; Mon, 13 Feb 2017 16:50:54 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CC827BEB0 for ; Mon, 13 Feb 2017 16:50:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1487004654; bh=TwihPUoKi40CKZU2fFquuA88rMsGKKk4Fq8MT5qCMWI=; h=Subject:References:To:From:Date:In-Reply-To:From; b=mw+xloxLKOpwJL1vtvrUjXeOnGrk57CA+3qBQ+FtRXaUFHe/Z/FtjNg9UfvvO6/Kr PEJl+cYE8qgve2W0ULCpoOW3Td6VZ6PUX30o/Hr0oPqg74fAg2++TPf2o9gWJNs4X3 JVSwHf28zCBgJ63rgFfXaCb50yB/ktbYBT0HadfA= References: <148700405095.24965.11757083307121031800.idtracker@ietfa.amsl.com> To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <148700405095.24965.11757083307121031800.idtracker@ietfa.amsl.com> Message-ID: Date: Mon, 13 Feb 2017 16:50:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148700405095.24965.11757083307121031800.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qLIvIw6VlKQhg1EXcwGglEf43lAXQ6egg" Archived-At: Subject: [saag] Fwd: Last Call: (Effect of Pervasive Encryption) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 16:51:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qLIvIw6VlKQhg1EXcwGglEf43lAXQ6egg Content-Type: multipart/mixed; boundary="dHGFbbTLGS4GwvGLtPQBQ2xMiwvtBWfLW"; protected-headers="v1" From: Stephen Farrell To: "saag@ietf.org" Message-ID: Subject: Fwd: Last Call: (Effect of Pervasive Encryption) to Informational RFC References: <148700405095.24965.11757083307121031800.idtracker@ietfa.amsl.com> In-Reply-To: <148700405095.24965.11757083307121031800.idtracker@ietfa.amsl.com> --dHGFbbTLGS4GwvGLtPQBQ2xMiwvtBWfLW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, As previously discussed here, I've started the IETF LC for this. Further comments, if you have any, are probably better directed to ietf@ietf.org, though of course I'd also consider any sent here. Cheers, S. -------- Forwarded Message -------- Subject: Last Call: (Effect of Pervasive Encryption) to Informational RFC Date: Mon, 13 Feb 2017 08:40:50 -0800 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce CC: Paul Hoffman , paul.hoffman@vpnc.org, draft-mm-wg-effect-encrypt@ietf.org, stephen.farrell@cs.tcd.ie The IESG has received a request from an individual submitter to consider the following document: - 'Effect of Pervasive Encryption' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-03-13. Exceptionally, comments may be= sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Increased use of encryption impacts operations for security and network management causing a shift in how these functions are performed. In some cases, new methods to both monitor and protect data will evolve. In other cases, the ability to monitor and troubleshoot could be eliminated. This draft includes a collection of current security and network management functions that may be impacted by the shift to increased use of encryption. This draft does not attempt to solve these problems, but rather document the current state to assist in the development of alternate options to achieve the intended purpose of the documented practices. The file can be obtained via https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ballot/ No IPR declarations have been submitted directly on this I-D. I-D nits notes that there is one use of a 2119 MUST (which can be lowercased I guess) and the reference to [SACM] in 5.7 has no matching entry in section 12, but we can fix those later. This is an AD-sponsored last call. The relevant AD (Stephen Farrell) will be escaping the IESG in March, so there may not be time to get this document approved by the IESG before then, e.g., if there is substantive discussion during/after IETF LC. Warren Kumari, (one of the incoming ADs) has agreed to pick this up should that be necessary. But better to get it over the line if we do turn out to have IETF consensus for it now. --dHGFbbTLGS4GwvGLtPQBQ2xMiwvtBWfLW-- --qLIvIw6VlKQhg1EXcwGglEf43lAXQ6egg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYoePtAAoJEC88hzaAX42iaTwH/RqHM63EDSpi4Bfvklz4YBVc Dpc+w1I2gbMBuWftfRGd5C7N3yjk9rkg5EDn70CLl400c78DnRFJy2X+yTGuzyFO iIwloeJAmmifVBZxiFa2/z2VGHs8HQ+gDuQHr8wst0J9mHvQEOhL85HtqokZhJel BMt5w06QSQKuc8G1IcPLz9quS415Z4zPq09CLu7DqfZnEzZRmpJkuGqy1MTiVe3/ DNZMJUSVxUYrop6N5UzgIM6Ng7ZBIz61GHVVD4UaaNR0pksZ8r0O6JngOZk1K1jZ Kgt/kFvFuOyOGeCAxBFmXdsDTmWtE0GhJmI49dlVZQNrZdBk7pZSmf+nRzDAuss= =2JmO -----END PGP SIGNATURE----- --qLIvIw6VlKQhg1EXcwGglEf43lAXQ6egg-- From nobody Tue Feb 14 20:46:07 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46E6129591 for ; Tue, 14 Feb 2017 20:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlb1z5Szx4nm for ; Tue, 14 Feb 2017 20:46:02 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA5E1294D1 for ; Tue, 14 Feb 2017 20:46:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1487133961; x=1518669961; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=F7jIpitkp7FcBUSEqXRamNGAMpFynpJqgE3YeSh6Iew=; b=doyMDwf6Vg6NWilMK0PNtZdyCnxxseleP6HJhtrfJ/GrhEGS+1ItgDIN DzsNQ3e10gALzcJSlkTX+OiNaDeVb9Okdg7jiQ8S12h804hV68v6eE8Cv Ug+Q20x7NuAKV9FQBuQNALK9hhfutCMe3BMwaAaXxUHTnrwrSUY1gc8+O t9v4lqdojXGTbv80Dyu5c0dbKapcTDE/DqGgyS7ikFlJcFixwcDw2KKTi 9oknijzYjCkBGTepn1asZrMKnfDQZuCXD54yrJXuJ572pGabSKLu2ttqd 0kp74EcJoPEbIcucMxsaUl1kFiLFYz+/eZuJaItPCZfiFGfamUVNFzxhf w==; X-IronPort-AV: E=Sophos;i="5.35,164,1483959600"; d="scan'208";a="135238488" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-d.UoA.auckland.ac.nz) ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 15 Feb 2017 17:45:59 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.25) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 15 Feb 2017 17:45:58 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Wed, 15 Feb 2017 17:45:58 +1300 From: Peter Gutmann To: Kathleen Moriarty , "saag@ietf.org" Thread-Topic: AD review of draft-gutmann-scep Thread-Index: AQHShg+C3gGYfe6mt0G2Dw8NHsWhxKFpgFPU Date: Wed, 15 Feb 2017 04:45:58 +0000 Message-ID: <1487133954201.79896@cs.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] AD review of draft-gutmann-scep 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 Feb 2017 04:46:05 -0000 Kathleen Moriarty writes:=0A= =0A= >1. I see the draft is marked as a proposed standard, but previous drafts f= or=0A= >SCEP are marked as HISTORIC with the reason explained in the introduction = of=0A= >https://tools.ietf.org/html/draft-nourse-scep-23. Can you explain why this= is=0A= >marked as standards track? I'd like to figure out the best fit.=0A= =0A= That's a political thing, I'll reply off-list.=0A= =0A= >The following opinion sentence is not necessary as worded:=0A= >=0A= > While=0A= > implementers are encouraged to investigate one of the more=0A= > comprehensive alternative certificate management protocols in=0A= > addition to the protocol defined in this specification, anyone=0A= > wishing to deploy them should proceed with caution, and consider=0A= > support and interoperability issues before committing to their use.=0A= >=0A= >I think it'll raise objections because of the opinion aspect, which isn't= =0A= >really appropriate for a standards document.=0A= =0A= That's not an opinion, it's just a statement of fact, the alternatives to S= CEP=0A= have proven so hard to deploy that... well, see above. All it's doing is= =0A= explaining why SCEP continues to exist despite there being supposed=0A= replacements. It's actually a lot milder than what it should say, which is= =0A= that we have 15 years of experience in these things being almost impossible= to=0A= deploy in an interoperable manner.=0A= =0A= >3. Section 2.1.3=0A= >Is SHA-1 still really need for legacy reasons or can that be eliminated?= =0A= >=0A= >4. Section 2.8=0A= >Are you really still seeing use of 3DES and SHA-1 or is this old text?=0A= =0A= The MTI algorithms throughout most of the document's lifetime was MD5 and= =0A= single DES. When I took over editing in 2015 I added AES (although several= =0A= implementations had already added it by themselves back then despite it not= =0A= being in the spec) and later SHA-256, and a handful of further vendors have= =0A= now added support for AES. SHA-256 is less common. Many (most?) though on= ly=0A= go up to 3DES and SHA-1. The spec didn't allow AES and SHA-256 until 2015,= =0A= and since the major use of SCEP is in embedded, rollout is going to take ye= ars=0A= if not a decade or more. Deprecating 3DES or SHA-1 at this point would mak= e=0A= probably the majority of all SCEP implementations non-compliant with the sp= ec.=0A= =0A= >2. Section 2.1.3: s/the them/them/=0A= >=0A= >5. Section 4.4=0A= >s/Whe the client/When the client/=0A= =0A= Thanks, fixed.=0A= =0A= Peter.= From nobody Sat Feb 18 08:17:22 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684641294AD for ; Sat, 18 Feb 2017 08:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7psZCZSFWdOr for ; Sat, 18 Feb 2017 08:17:20 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 9A8381294A1 for ; Sat, 18 Feb 2017 08:17:19 -0800 (PST) Received: from [192.168.91.175] ([195.149.223.239]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M4Gyx-1cOPl31d91-00rtCT; Sat, 18 Feb 2017 17:17:14 +0100 To: Eliot Lear , saag References: <16c236b7-dd80-1e27-8de9-16f05558d38e@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <1da45f12-7999-6a9e-3649-2ffea4d50511@gmx.net> Date: Sat, 18 Feb 2017 17:17:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3rGUct50h63CBaJ7r2lItJ806xAQPxJ6p" X-Provags-ID: V03:K0:RuooEaQghX8wc/5SkFnFYXZLwEFuLgYDlQ/+9QPuRdT6T/ahcJ3 3yj3VbhFaUdXItSyl2YHDEsqKZseHi9d1dj11LEZXIKbGqhzjNU6cELIhqMudbiv0TSrZ0D ESzHNFtkJ0+uxoNm1Swgjr5v7lXy7qVw8tDEg80K7AL/TA5aWH/IxOiZmMtZvlAXhc3mv2o jtECxmcLc7X/Lq4tE3Pww== X-UI-Out-Filterresults: notjunk:1;V01:K0:39deIRF2L8I=:qshQDiYRY2e3ll+2h4ckF3 S7GwCit/IRwuwnAb65fJmG6hoDfLpvY2wTOJ4cVBEw7JCIO//e6wV1/1smQCP0kBJnHzVPLTh XIxW85KhMEhiHVvafB8UzPs4ZwctB7F25iMneP1GEgZQhp7lfkS0lkOpeZNUL0H8NIZKO6VAr /TP1KilRKjzqyySlX0avFhJKlueQi7TQrQvNCjJx7YsX/kA0MPukSBszSWFsr9VdReED9oCYW iuT1wjGKT77kYSV/w/+KJdiobYZLaFUqzjI/H8oZa5QaXBRD4OsaWtc3RiRu0MwNrDDELxODf nhejOYRJW4HT9P7xSRJj9++/64ItcwrVIA3FVqbZHUeNvDhG5Glc7Geg3z8M8JVVvN46+GeA7 45jm1p+qZgOJR80beGTbrXwVkBtrmUMtQFUFfYq+CxVZjTAc9YYZRcrapAmRqVPyEhd+r8y9r vDHdduW/OothHra9LCI/omnFre/LAPhPTi61gmPB2bQhX1nnEHGsaE2XDz/8GKWSdK2Rd5WXr I//+QZr/2q2klgCeGsp8ZxVHkoYlitMi6TI1Pw9oao3Z9w/AUdaXnofxAh4gHn+ZRxENLPabO Q0p4ymIW0CYXzjk9tIKwqT3SygUw1zO6xwCKV6mXXqKFERuHXNF0cogpClpxaFFwUSXtifwks TeJwsZt+OK5ERP3pk/b7hcn24L+FxRl9jUlZKTk71B6B3dBJdEq9nQV9o7GSHQeG5t48h5Zqm kZ1/5jquxxcVzrLSsf6K7KFNxWqwhqTak96DeWCTItIJHBCC3pTCzakVz4E= Archived-At: Subject: Re: [saag] BOFs about IoT firmware update and TEE configuration 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 Feb 2017 16:17:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3rGUct50h63CBaJ7r2lItJ806xAQPxJ6p Content-Type: multipart/mixed; boundary="qimJs0Lhel5Eircb0Lif8jD2djoKVxVei"; protected-headers="v1" From: Hannes Tschofenig To: Eliot Lear , saag Message-ID: <1da45f12-7999-6a9e-3649-2ffea4d50511@gmx.net> Subject: Re: [saag] BOFs about IoT firmware update and TEE configuration References: <16c236b7-dd80-1e27-8de9-16f05558d38e@gmx.net> In-Reply-To: --qimJs0Lhel5Eircb0Lif8jD2djoKVxVei Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Eliot, I actually don't know since I never understood the ANIMA work all that well due to its fuzzy scope. I suspect that you can answer the question better than I do. Ciao Hannes On 02/13/2017 02:29 PM, Eliot Lear wrote: > Hannes, >=20 > Can you say a few words about how TEE compares to > draft-ietf-anima-bootstrap-keyinfra (et al) which has been in > development in a WG for quite some time? >=20 > Eliot >=20 >=20 > On 2/13/17 12:51 PM, Hannes Tschofenig wrote: >> Hi all, >> >> we have proposed two security-relevant BOFs for the upcoming meeting. >> They are listed on the BOF Wiki page at >> https://trac.tools.ietf.org/bof/trac/wiki but I still wanted to briefl= y >> introduce them to you >> >> ** =E2=80=9CFirmware Update Description (FUD)=E2=80=9D >> >> Last year we had a workshop organized by the IAB on firmware updates f= or >> IoT devices (see https://www.iab.org/activities/workshops/iotsu/) wher= e >> we talked about various challenges and gaps. >> >> As a follow-up to the workshop we would like to initiate some >> standardization activity in this area. >> >> The mailing list can be found at >> https://www.ietf.org/mailman/listinfo/fud >> >> >> ** =E2=80=9CA Protocol for Dynamic Trusted Execution Environment Enabl= ement (TEEP)=E2=80=9D >> >> This BOF is about an application layer security protocol that allows t= o >> configure security credentials and software running on a Trusted >> Execution Environment (TEE). Today, TEEs are, for example, found home >> routers, set-top boxes, smart phones, tablets, wearables, etc. >> Unfortunately, there have been mostly proprietary protocols used in th= is >> environment. >> >> With this BOF we are making an attempt to standardize such a protocol.= A >> strawman proposal of such a protocol has been published with >> https://tools.ietf.org/html/draft-pei-opentrustprotocol-03. >> >> The mailing list can be found at: >> https://www.ietf.org/mailman/listinfo/teep >> >> >> >> >> Ciao >> Hannes >> >> >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 --qimJs0Lhel5Eircb0Lif8jD2djoKVxVei-- --3rGUct50h63CBaJ7r2lItJ806xAQPxJ6p 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYqHOIAAoJEGhJURNOOiAt0r4H/3diWkL5tXPFOMHmq7EemKi5 /npTS1Od9WVX1LTAhocA/a10INtXxhVuhyZQz1vkpBfJMMuSJBqziQMQ5TIW3wJS ScjkEkQY6sPDOl4agX9UYQv8lJtDdvQM2VMJ0uPDUZOoMTiP9+pTFs5N9h7Jhu/k Tq27jQND6w1I7MWPYeLz671TlzYOSQdPDXygPFDqmQm/ybNnUXXNOBfEoO295Qpg 4QHjewryfpGKDGAB1fzQ71UoW7ZUUgxZ5MulCPMsk3E4ftrF1LrpFCDWmFuckr9b Bmz5YWu38jqeXq4nW9eSx8ziBpEKJxW8PIxXRyRWTFocgwMCl/yh92p7UDWk5+s= =9gEO -----END PGP SIGNATURE----- --3rGUct50h63CBaJ7r2lItJ806xAQPxJ6p-- From nobody Sun Feb 19 11:46:39 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7941294E2 for ; Sun, 19 Feb 2017 11:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9lBXwjMVvOA for ; Sun, 19 Feb 2017 11:46:36 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A13D31294F1 for ; Sun, 19 Feb 2017 11:46:36 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id q127so4139972ywg.0 for ; Sun, 19 Feb 2017 11:46:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=Y7jwFL7gtKxeJyobGi09t/ic4TLg8IgZAqqZ3alTOpM=; b=HUq/V9d6ZI7PsTUQ5Rsdds2B3b455PyjvRESis9ZCVyYbyvWNGK9E/ufr1KQYExALj h5lP/uTidjT4Gub448Lhv93WThlzsaLPa26yXfdRh+ImJ3xND7To7bLB/8qzjWdbzTHx JeMkdfFbtxxBDcI/g44PX9EMBrwE9Le0HJ1Et99F5rOfmYCXwlhuVlr6wMKtYvs/dxET eyv6hC6Pb35K1d/k/c2QGVavb5PfvbS4qeydG+YK9w9Sd1fo+ffK5O61Bqem6hLny+QP 5gse4dNtxntjCyc1uFwA/qq4y/pJO9gupGIuQkaVoAK/U9dwPRxLFB+OFMFOZFK7do0W YEMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Y7jwFL7gtKxeJyobGi09t/ic4TLg8IgZAqqZ3alTOpM=; b=rX81J5vNx2vEuKmm4BM3xEqwremiUErnQwCJB1KgfxyOJrOtzqah7LphW9DS7ZoGPg SZHgWsZlSDliKcS3qJYGfJKx9o8C8bZFqy3iTbBA6pgbBOdUbpj7FSVqgrwciDbWvinA MkaXzx1R55mGMOt07j5rLN1JyojFgGpwZSCTbZJmQsdQKUH19AvezIiSHbruV2V9HUwT BXBSn5esVck/dNMD9g3jX4UPMy8Ew67ijudGuiN3brGHrPWOCR3el95CDM7szCGaWyzt zBvdNFgetJ3PNs/JoLq5GWgypRZf4ytWuLq0kc2/v2JcKHOFuhrcMgs186LZQPGw95sq n9AA== X-Gm-Message-State: AMke39l/BmwmmRS7UCHBndnrPKuc0L3O7U2DfC08OyKIb8c2JFJ9g4EQWwEV0THny2QGyDWZ2xd17RWpMVlZLw== X-Received: by 10.13.231.129 with SMTP id q123mr13527847ywe.202.1487533595677; Sun, 19 Feb 2017 11:46:35 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.17.140 with HTTP; Sun, 19 Feb 2017 11:46:35 -0800 (PST) From: Phillip Hallam-Baker Date: Sun, 19 Feb 2017 14:46:35 -0500 X-Google-Sender-Auth: Dzq3S2hHQbt0yAECwXBCcipigEc Message-ID: To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0763928fdae10548e767a8 Archived-At: Subject: [saag] Securing the full TLS handshake including SNI 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 Feb 2017 19:46:38 -0000 --94eb2c0763928fdae10548e767a8 Content-Type: text/plain; charset=UTF-8 All, I have been looking at various ways to protect the TLS handshake including the domain name of the site being accessed. To do this, it is necessary to put 'some form' of key into the DNS record for the host. While many people have suggested schemes in the past, these have all been based on the legacy RSA exchanges and in ways I find unconvincing. Not least because TLS is a protocol with 25 years history and has been patched and repatched many times. I would prefer to use a scheme that has the following properties 1) Only use DH/ECDH key exchange. 2) Enables use of hardware host keys 3) Provides perfect forward secrecy by default. 4) Has integrated support for client auth. The type of approach I like best is the one used in the noise protocol which underpins Signal, etc. The wonderful thing about DH is that it is composable to as many keys as you need. So the basic idea is to have each of the parties identified by a key: * KH - The Host is identified by a host key that is distributed through a DNS TXT record. * KS - The Service is identified by a WebPKI certificate (EV / OV or DV) * KC - The Client SHOULD be identified by a client key. * EC - An ephemeral mix-in is supplied by the client. * ES - An ephemeral mix-in is supplied by the service. Let A(k1, k2...) be a function that creates an agreed key from k1, k2, etc. Let KDF (x,p) be a key derivation function for purpose p. A brief sketch of the protocol would be: Client obtains KH from the DNS, creates A(KH, EC) Client encrypts initial contact message under KDF (A (KH, EC),p1) this contains * Client cert (if used) (contains KC) * DNS name of Service to be contacted * sundry flags Service reply is encrypted under KDF (A (KH, EC), p2). This contains * Service certificate + chain (contains KS) * ES * Opaque identifier (for fast restart) * sundry flags The rest of the conversation is encrypted under KDF (A(KH, EC) + A (KS, KC, ES),p) where p = p1 or p2 depending on the direction. The reason for not using a quintuple exchange for the service exchange is that this approach allows different curves to be used for the host and service level agreement. It is very likely that 25519 is sufficient for the host level but there are definitely cases where 448 is needed for the service level. I have not looked into how to squeeze this into TLS data frames but that is just bit shuffling. While I can't see a case for moving away from X.509 for the service cert, it might well be that we would want to use a different cert for the client part. In particular, I can see the use of some form of blinding or annonymization being layered in. Note that with EC, multi-key exchanges don't actually take more time than two key. The private keys add and the public keys multiply. So there is only one modular exponentiation or other costly operation. One odd feature of this exchange is that practically every part of it is already specified by IETF docs. I built it from code I already had to implement KDFs etc. One possibility that I like a lot is that we can have client authentication at the transport level for free. Which is useful for SMTPS / IMAPS / etc. That does not do away with the need for application level authentication of course, but we have the option of a transport binding. I would like to see an option that allows a client to prove that they are the same client that contacted earlier and that this be unlinkable across DNS domains. Easy enough in DH//ECDH. If x is a device bound key, we can use KDF (x + H(Domain), p3). Thoughts? --94eb2c0763928fdae10548e767a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All= ,

I have been looking at = various ways to protect the TLS handshake including the domain name of the = site being accessed. To do this, it is necessary to put 'some form'= of key into the DNS record for the host.

While many people have suggested schemes in the past, thes= e have all been based on the legacy RSA exchanges and in ways I find unconv= incing. Not least because TLS is a protocol with 25 years history and has b= een patched and repatched many times.=C2=A0

I would prefer to use a scheme that has the following = properties

=
1) Only use DH= /ECDH key exchange.
2) Enables use of hardware host keys
3) Provides perfect forward secrecy by default.<= /div>
4) Has integrat= ed support for client auth.

The type of approach I like best is the one used in the noise protocol w= hich underpins Signal, etc. The wonderful thing about DH is that it is comp= osable to as many keys as you need. So the basic idea is to have each of th= e parties identified by a key:

* KH - The Host is identified by a host key that is distributed throu= gh a DNS TXT record.
* KS - The Service is identified by a WebPKI certificate (EV / OV or = DV)
* KC - The = Client SHOULD be identified by a client key.
* EC - An ephemeral mix-in is supplied by the= client.
* ES -= An ephemeral mix-in is supplied by the service.

Let A(k1, k2...) be a function that creates an agre= ed key from k1, k2, etc.
Let KDF (x,p) be a key derivation function for purpose p.

A brief sketch of the protocol= would be:

=
Client obtains= KH from the DNS, creates A(KH, EC)

Client encrypts initial contact message under KDF (A (KH, EC),p1= ) this contains
=C2=A0 =C2=A0* Client cert (if used) (contains KC)
=C2=A0 =C2=A0* DNS name of Service to = be contacted
= =C2=A0 =C2=A0* sundry flags

Service reply is encrypted under KDF (A (KH, EC), p2). This contains=
=C2=A0 =C2=A0*= Service certificate + chain (contains KS)
=C2=A0 =C2=A0* ES
=C2=A0 =C2=A0* Opaque identifier (for fast r= estart)
=C2=A0 = =C2=A0* sundry flags

The = rest of the conversation is encrypted under KDF (A(KH, EC) + A (KS, KC, ES)= ,p) where p =3D p1 or p2 depending on the direction.

The reason for not using a quintuple exchange f= or the service exchange is that this approach allows different curves to be= used for the host and service level agreement. It is very likely that 2551= 9 is sufficient for the host level but there are definitely cases where 448= is needed for the service level.

I have not looked into how to squeeze this into TLS data frames = but that is just bit shuffling.


Whi= le I can't see a case for moving away from X.509 for the service cert, = it might well be that we would want to use a different cert for the client = part. In particular, I can see the use of some form of blinding or annonymi= zation being layered in.=C2=A0

Note that with EC, multi-key exchanges don't actually take more t= ime than two key. The private keys add and the public keys multiply. So the= re is only one modular exponentiation or other costly operation.

One odd feature of this exchange is= that practically every part of it is already specified by IETF docs. I bui= lt it from code I already had to implement KDFs etc.


One possibility that I like a lot is that we can have cli= ent authentication at the transport level for free. Which is useful for SMT= PS / IMAPS / etc. That does not do away with the need for application level= authentication of course, but we have the option of a transport binding.

I would like to see an opt= ion that allows a client to prove that they are the same client that contac= ted earlier and that this be unlinkable across DNS domains. Easy enough in = DH//ECDH. If x is a device bound key, we can use KDF (x + H(Domain), p3).


Thoughts?
--94eb2c0763928fdae10548e767a8-- From nobody Mon Feb 20 06:58:10 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D05129507 for ; Mon, 20 Feb 2017 06:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0FMkwVAKcpC for ; Mon, 20 Feb 2017 06:58:07 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA98312950E for ; Mon, 20 Feb 2017 06:58:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4791; q=dns/txt; s=iport; t=1487602686; x=1488812286; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=ZdSKCOj2oOeEy4/G2nJaU3CVpkcq4wmiXEJfn9PENdg=; b=fz1prFfylP06mnsUKlzyp5HFdH/qsSmC8LBgMcL2Wi/xJ/48wepyrp03 5ucUc984NnRXjI6DS6SLonZ+2aPwphZ7k8THiCKEWk5XwnHP81VMZdHGm ezvfCl9H4Os8aE2nAkvIyiwqm6GwfBAAQkFFNOBzpLtPC/m9XuIvx/b3F Q=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAgCbA6tY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIDJ1+DW4oIcpEilTSCDB8LgkKDNgKCexgBAgEBAQEBAQFiKIR?= =?us-ascii?q?xAQEEAQEhSAMHFAsYKgICJzAGAQwGAgEBiWsOrXCCJotPAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBEQoFiFGCaodagl8FiRiBV5EVg3eCCHWLKYF7iESGS4gzim8fOIEAIBQ?= =?us-ascii?q?IFxU+hkk/NQGLEAEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,186,1484006400"; d="asc'?scan'208";a="649829148" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Feb 2017 14:58:04 +0000 Received: from [10.61.253.231] ([10.61.253.231]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v1KEw4Dm022864; Mon, 20 Feb 2017 14:58:04 GMT To: Hannes Tschofenig , saag References: <16c236b7-dd80-1e27-8de9-16f05558d38e@gmx.net> <1da45f12-7999-6a9e-3649-2ffea4d50511@gmx.net> From: Eliot Lear Message-ID: Date: Mon, 20 Feb 2017 15:58:04 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <1da45f12-7999-6a9e-3649-2ffea4d50511@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FViEGpamc8Na5N8Mh8rMJ4WWwKm8PPfGA" Archived-At: Subject: Re: [saag] BOFs about IoT firmware update and TEE configuration 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, 20 Feb 2017 14:58:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FViEGpamc8Na5N8Mh8rMJ4WWwKm8PPfGA Content-Type: multipart/mixed; boundary="KB8XNt3aBQjwS7JxWnTqF7uxI49PD9ccN"; protected-headers="v1" From: Eliot Lear To: Hannes Tschofenig , saag Message-ID: Subject: Re: [saag] BOFs about IoT firmware update and TEE configuration References: <16c236b7-dd80-1e27-8de9-16f05558d38e@gmx.net> <1da45f12-7999-6a9e-3649-2ffea4d50511@gmx.net> In-Reply-To: <1da45f12-7999-6a9e-3649-2ffea4d50511@gmx.net> --KB8XNt3aBQjwS7JxWnTqF7uxI49PD9ccN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Hannes, First, Max, Michael, Michael, and Kent are far more the experts than I am on this, but here is a brief summary: The purpose of draft-ietf-anima-bootstrap-keyinfra is to provide a trusted introduction between devices and the network such that you start in the following state: Device has a manufacturer certificate (802.1AR iDevID) and a manufacturer trust root, and the local network can in some way authenticate the manufacturer, and perhaps visa versa. The end state is that the device has a local (802.1 LDevID) and a local trust anchor. To accomplish this, a flow is defined to get to the point where the device will register with a local registrar using EST (either EST or EST/CoAP). Now perhaps you could explain a little about the TEE draft you're doing? If there's some overlap perhaps there's a chance to consolidate the work.= Eliot On 2/18/17 5:17 PM, Hannes Tschofenig wrote: > Hi Eliot, > > I actually don't know since I never understood the ANIMA work all that > well due to its fuzzy scope. I suspect that you can answer the question= > better than I do. > > Ciao > Hannes > > On 02/13/2017 02:29 PM, Eliot Lear wrote: >> Hannes, >> >> Can you say a few words about how TEE compares to >> draft-ietf-anima-bootstrap-keyinfra (et al) which has been in >> development in a WG for quite some time? >> >> Eliot >> >> >> On 2/13/17 12:51 PM, Hannes Tschofenig wrote: >>> Hi all, >>> >>> we have proposed two security-relevant BOFs for the upcoming meeting.= >>> They are listed on the BOF Wiki page at >>> https://trac.tools.ietf.org/bof/trac/wiki but I still wanted to brief= ly >>> introduce them to you >>> >>> ** =E2=80=9CFirmware Update Description (FUD)=E2=80=9D >>> >>> Last year we had a workshop organized by the IAB on firmware updates = for >>> IoT devices (see https://www.iab.org/activities/workshops/iotsu/) whe= re >>> we talked about various challenges and gaps. >>> >>> As a follow-up to the workshop we would like to initiate some >>> standardization activity in this area. >>> >>> The mailing list can be found at >>> https://www.ietf.org/mailman/listinfo/fud >>> >>> >>> ** =E2=80=9CA Protocol for Dynamic Trusted Execution Environment Enab= lement (TEEP)=E2=80=9D >>> >>> This BOF is about an application layer security protocol that allows = to >>> configure security credentials and software running on a Trusted >>> Execution Environment (TEE). Today, TEEs are, for example, found home= >>> routers, set-top boxes, smart phones, tablets, wearables, etc. >>> Unfortunately, there have been mostly proprietary protocols used in t= his >>> environment. >>> >>> With this BOF we are making an attempt to standardize such a protocol= =2E A >>> strawman proposal of such a protocol has been published with >>> https://tools.ietf.org/html/draft-pei-opentrustprotocol-03. >>> >>> The mailing list can be found at: >>> https://www.ietf.org/mailman/listinfo/teep >>> >>> >>> >>> >>> Ciao >>> Hannes >>> >>> >>> >>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag --KB8XNt3aBQjwS7JxWnTqF7uxI49PD9ccN-- --FViEGpamc8Na5N8Mh8rMJ4WWwKm8PPfGA 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 iQEcBAEBCAAGBQJYqwP9AAoJEIe2a0bZ0nozMqAH/3NekqssRAyus5345EPTMUev TtV3egSjy3gZkzMA4vRbJswsvfV+NATc+Kwo5KJGt/bXD0NfJpS+0BGc4AjE3cHO e48sfrXJGoilcUogNwTq93ksL9OsigerOwNguVf92HSryRWRPUFFvM4hGK37ZEuG NB6iNk1XXOOXpBN7wsiqA6jp3fJOuPGsCp6xz/vlOxM7kOjXSl8uLtAiqaeIZ9R3 6Q6RXUrPDMPM/Tpf8B6gswEa2lmX3xN4doyrJtb1DyIAmzlvgmcOO/VvqFnE31wU 3jfIGS9XXdXHwuftz/XQSKwj2AD7SibzxtL7ygfl3B9ku0XMgFWcq0aQsGoDMbw= =N3Gr -----END PGP SIGNATURE----- --FViEGpamc8Na5N8Mh8rMJ4WWwKm8PPfGA-- From nobody Tue Feb 21 08:00:06 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB499129C3B for ; Tue, 21 Feb 2017 08:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7EjQVBbS-LI for ; Tue, 21 Feb 2017 08:00:04 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 80D25129C44 for ; Tue, 21 Feb 2017 08:00:04 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 16D46200064; Tue, 21 Feb 2017 16:00:04 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id F3106200005; Tue, 21 Feb 2017 16:00:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1487692803; bh=20yAlVKo6EpCAk3t38GaKHF4Ydlnv1p//dPGGnXISpc=; l=5552; h=From:To:Date:References:In-Reply-To:From; b=fISmnIgII6yJ/XKg0VaLTrlh6hQt5d8wnemugO6za8bfcmAqLSC7ruAO4mUum8UDg FTrKEYacvntLuM87DyTLrIsIyKe1GkFVr/sqx07c3Z4JM2T3HXYk2ZgHakh6KnxCpi MRvCBsJrx7h9+uW256GxeyWYkpqms4HRrGwBjlHo= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id CB97698084; Tue, 21 Feb 2017 16:00:03 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 21 Feb 2017 11:00:03 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Tue, 21 Feb 2017 11:00:03 -0500 From: "Salz, Rich" To: Phillip Hallam-Baker , "saag@ietf.org" Thread-Topic: [saag] Securing the full TLS handshake including SNI Thread-Index: AQHSiujm2Zk+UNVso0CEqBJvfLPhVqFzoF8g Date: Tue, 21 Feb 2017 16:00:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.178] Content-Type: multipart/alternative; boundary="_000_f5f23a9041944acd941e180487cda2e9usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Securing the full TLS handshake including SNI X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 16:00:06 -0000 --_000_f5f23a9041944acd941e180487cda2e9usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VExTIDEuMyBhbHJlYWR5IGhhcyB0aGUgY29uY2VwdCBvZiBlbmNyeXB0ZWQgZXh0ZW5zaW9ucyBp biB0aGUgaGFuZHNoYWtlLiAgV2hhdCBpZiB5b3UgcHV0IHRoZSDigJxyZWFs4oCdIFNOSSBpbnNp ZGUgYW4gZW5jcnlwdGVkIGV4dGVuc2lvbi4gIFRoaXMgcmVxdWlyZXMgdGhlIHRydWUgb3JpZ2lu IGFuZCB0aGUg4oCcZnJvbnRpbmfigJ0gb3JpZ2luIHRvIGhhdmUgYSB0cnVzdCByZWxhdGlvbnNo aXAsIGJ1dCB0aGF0IGNhbiBwcm9iYWJseSB3b3JrIGZvciBtb3N0LCBub3QgYWxsLCBvZiB0aGUg ZGVscG95bWVudHMgdG9kYXkuICBUaGVuIGFsbCB5b3UgbmVlZCB0byBkbyBpcyB3cml0ZSB1cCBh biBJLUQgZGVmaW5pbmcgdGhpcyDigJx0cnVlIFNOSSBleHRlbnNpb24u4oCdDQoNCkRpc2NsYWlt ZXI6IHRoaXMgaXMgbm90IG15IGlkZWEuDQoNCi0tDQpTZW5pb3IgQXJjaGl0ZWN0LCBBa2FtYWkg VGVjaG5vbG9naWVzDQpNZW1iZXIsIE9wZW5TU0wgRGV2IFRlYW0NCklNOiByaWNoc2FsekBqYWJi ZXIuYXQgVHdpdHRlcjogUmljaFNhbHoNCg== --_000_f5f23a9041944acd941e180487cda2e9usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VExTIDEuMyBhbHJlYWR5IGhhcyB0aGUgY29u Y2VwdCBvZiBlbmNyeXB0ZWQgZXh0ZW5zaW9ucyBpbiB0aGUgaGFuZHNoYWtlLiZuYnNwOyBXaGF0 IGlmIHlvdSBwdXQgdGhlIOKAnHJlYWzigJ0gU05JIGluc2lkZSBhbiBlbmNyeXB0ZWQgZXh0ZW5z aW9uLiZuYnNwOyBUaGlzIHJlcXVpcmVzIHRoZQ0KIHRydWUgb3JpZ2luIGFuZCB0aGUg4oCcZnJv bnRpbmfigJ0gb3JpZ2luIHRvIGhhdmUgYSB0cnVzdCByZWxhdGlvbnNoaXAsIGJ1dCB0aGF0IGNh biBwcm9iYWJseSB3b3JrIGZvciBtb3N0LCBub3QgYWxsLCBvZiB0aGUgZGVscG95bWVudHMgdG9k YXkuJm5ic3A7IFRoZW4gYWxsIHlvdSBuZWVkIHRvIGRvIGlzIHdyaXRlIHVwIGFuIEktRCBkZWZp bmluZyB0aGlzIOKAnHRydWUgU05JIGV4dGVuc2lvbi7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRpc2NsYWltZXI6 IHRoaXMgaXMgbm90IG15IGlkZWEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLSZuYnNwOw0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlNlbmlvciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dpZXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWVtYmVyLCBPcGVuU1NMIERldiBUZWFtPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklNOiByaWNoc2FsekBqYWJiZXIuYXQgVHdpdHRlcjog UmljaFNhbHo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_f5f23a9041944acd941e180487cda2e9usma1exdag1mb1msgcorpak_-- From nobody Wed Feb 22 00:16:05 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380AC129444; Wed, 22 Feb 2017 00:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2X4MjTJdMGc; Wed, 22 Feb 2017 00:16:02 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 D8E4B1293DF; Wed, 22 Feb 2017 00:16:01 -0800 (PST) Received: from [192.168.91.176] ([195.149.223.239]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0McluX-1cxhzU1hZZ-00Hwhb; Wed, 22 Feb 2017 09:15:53 +0100 To: Eliot Lear References: <16c236b7-dd80-1e27-8de9-16f05558d38e@gmx.net> <1da45f12-7999-6a9e-3649-2ffea4d50511@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <6916bccf-9273-5d2f-af44-ef38d1394223@gmx.net> Date: Wed, 22 Feb 2017 09:15:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hI3RQLufgaom59dRQ5OT2PbenT4FMi15U" X-Provags-ID: V03:K0:rPfhlBOQXuW1/sBqGJetnwkqASvv7ooZhztJ6Fe8uiZuTXxu2Tn Mq8eoAr8JGqA+rLE/yWHRuBxPXBHklnhvwLm6h9x2IJJ3GKeneFhJznxOFyJI26H2XyWnyE Keaz1v7XTnpiAYvHBjmVGIKfDSgScm2q0C2TBNmKKCW+lj4HENu06TRR8Rw9xb64vLTzMtv LpcONFbvkDJSSGI1ch4rA== X-UI-Out-Filterresults: notjunk:1;V01:K0:AnxnEiUV/70=:oLTq4Co8mpvE/SEyvs7hr4 s6PSNpHovxZfk3GIc3mdCIvTj3WmIKnU/GFmbtUHOh9KAfwIBitXfrqTdB+WVBEG7TQJyOg7T W9LecCPjxvAAZivS7uK4qN2vM+LZHFnyZYCbTMLMmqNFK2zWJW+pEgRDwHzLj79040T92eHdF i9s36+o+y6oT8NsR7R0JY481ZvEv4zArAjinztdzOQmgpfimrjcR0xLX6TOMyr/HRPEqIpbnK VUptSwh8I1Dv+3n8qjzUhTUlNk3H5Cx9JHd5lNeuY4LH/nWAo13Lt6RqvTnAzz5D5uB7KKK7B yYwYLt9853a6Nb/nlT80bP+dZDERqI/kL3InKCp1irXH8TzTvExOoHq2od/aazg7jvs/g0tPg abWbyrZL0iwCI5ppelBO15hYLve+K6DdgWNAP1havGOUKiC/DbITO7GcEuvp0FwaR4DKb2xTN irDcPw2vGVtTxa1ESC4k5MCQ9kvJcNYXUO1sPbTGx9JrOSxN6yS6qegREAdI4kY1kg1FwlKEw WJnMWXc/vCNtKLAfuy0H0j1pjlUgHnsIfiLNzpuafn+U29yO/uoK1RbBp0QJKDIW/XgLHXGfZ RoWzvNmWuttqqT3cGkK/1HRBGwP1JpTKr1U8+pXDVF9lFHyzWK3pSgChPexklmxaTQcHQBRtG 2oQHmUM2rmHH3PnoWwDzn+CfB/J1lXDle+EXZHjtotMFRll7DwFrN2+pahzDwRdz7yDSfVRBU DEebpjRS7gEQgdttjbxaWU4zB9qgydvCMgpH04wA4anEeYtNzYqjEAdwci4IqPrxZZ4M3EdG5 o770733oPF1ZGr5fKCFBMiMDRo5ChKvoeu3gPUJhxdFqxia7+NaVSrcO/ER2aIhd1OU10QfhN 0l7UijgLBabR0YiEAcRpafJlVt5ShJt0Yr6K6pqhjw3TJ2eDDdWHEtYnNJ1E4IpOhqTRPYWI8 pKeo9xnDmSYLUTfPK6tMxduY3ElO/vW3nGR+/p+OO2E0CTtrrK8HzcuPlS64VeEELSnDbBcbl Jw== Archived-At: Cc: teep@ietf.org, saag Subject: Re: [saag] BOFs about IoT firmware update and TEE configuration 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 Feb 2017 08:16:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hI3RQLufgaom59dRQ5OT2PbenT4FMi15U Content-Type: multipart/mixed; boundary="tgoFtEm62oTxQPHXPleDH6mlVnnE5I9PD"; protected-headers="v1" From: Hannes Tschofenig To: Eliot Lear Cc: saag , teep@ietf.org Message-ID: <6916bccf-9273-5d2f-af44-ef38d1394223@gmx.net> Subject: Re: [saag] BOFs about IoT firmware update and TEE configuration References: <16c236b7-dd80-1e27-8de9-16f05558d38e@gmx.net> <1da45f12-7999-6a9e-3649-2ffea4d50511@gmx.net> In-Reply-To: --tgoFtEm62oTxQPHXPleDH6mlVnnE5I9PD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Eliot, (I put the TEEP mailing list on CC since they may be interested in this conversation as well.) The use case for TEEP is a bit different. The idea is to configure software running on a trusted execution environment. While the currently proposed solution assumes a PKI and the use of asymmetric key cryptography it does not use 802.1AR certificates. There is no notion of a local network since it does not matter. The document also does not talk about how the messages are conveyed but HTTP is more likely for the smart phone/tablet use cases. I created a slide deck for presentation at the T2TRG meeting at the Berlin IETF but unfortunately there was no time. Nevertheless, here is the slide deck: https://github.com/t2trg/2016-ietf96/blob/master/slides/70_OTrP-IETF93.pd= f Does this provide enough information about the intention? Ciao Hannes On 02/20/2017 03:58 PM, Eliot Lear wrote: > Hi Hannes, >=20 > First, Max, Michael, Michael, and Kent are far more the experts than I > am on this, but here is a brief summary: >=20 > The purpose of draft-ietf-anima-bootstrap-keyinfra is to provide a > trusted introduction between devices and the network such that you star= t > in the following state: >=20 > Device has a manufacturer certificate (802.1AR iDevID) and a > manufacturer trust root, and the local network can in some way > authenticate the manufacturer, and perhaps visa versa. The end state i= s > that the device has a local (802.1 LDevID) and a local trust anchor. T= o > accomplish this, a flow is defined to get to the point where the device= > will register with a local registrar using EST (either EST or EST/CoAP)= =2E >=20 > Now perhaps you could explain a little about the TEE draft you're doing= ? >=20 > If there's some overlap perhaps there's a chance to consolidate the wor= k. >=20 > Eliot >=20 >=20 >=20 > On 2/18/17 5:17 PM, Hannes Tschofenig wrote: >> Hi Eliot, >> >> I actually don't know since I never understood the ANIMA work all that= >> well due to its fuzzy scope. I suspect that you can answer the questio= n >> better than I do. >> >> Ciao >> Hannes >> >> On 02/13/2017 02:29 PM, Eliot Lear wrote: >>> Hannes, >>> >>> Can you say a few words about how TEE compares to >>> draft-ietf-anima-bootstrap-keyinfra (et al) which has been in >>> development in a WG for quite some time? >>> >>> Eliot >>> >>> >>> On 2/13/17 12:51 PM, Hannes Tschofenig wrote: >>>> Hi all, >>>> >>>> we have proposed two security-relevant BOFs for the upcoming meeting= =2E >>>> They are listed on the BOF Wiki page at >>>> https://trac.tools.ietf.org/bof/trac/wiki but I still wanted to brie= fly >>>> introduce them to you >>>> >>>> ** =E2=80=9CFirmware Update Description (FUD)=E2=80=9D >>>> >>>> Last year we had a workshop organized by the IAB on firmware updates= for >>>> IoT devices (see https://www.iab.org/activities/workshops/iotsu/) wh= ere >>>> we talked about various challenges and gaps. >>>> >>>> As a follow-up to the workshop we would like to initiate some >>>> standardization activity in this area. >>>> >>>> The mailing list can be found at >>>> https://www.ietf.org/mailman/listinfo/fud >>>> >>>> >>>> ** =E2=80=9CA Protocol for Dynamic Trusted Execution Environment Ena= blement (TEEP)=E2=80=9D >>>> >>>> This BOF is about an application layer security protocol that allows= to >>>> configure security credentials and software running on a Trusted >>>> Execution Environment (TEE). Today, TEEs are, for example, found hom= e >>>> routers, set-top boxes, smart phones, tablets, wearables, etc. >>>> Unfortunately, there have been mostly proprietary protocols used in = this >>>> environment. >>>> >>>> With this BOF we are making an attempt to standardize such a protoco= l. A >>>> strawman proposal of such a protocol has been published with >>>> https://tools.ietf.org/html/draft-pei-opentrustprotocol-03. >>>> >>>> The mailing list can be found at: >>>> https://www.ietf.org/mailman/listinfo/teep >>>> >>>> >>>> >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> saag mailing list >>>> saag@ietf.org >>>> https://www.ietf.org/mailman/listinfo/saag >=20 >=20 --tgoFtEm62oTxQPHXPleDH6mlVnnE5I9PD-- --hI3RQLufgaom59dRQ5OT2PbenT4FMi15U 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYrUi4AAoJEGhJURNOOiAtom4H/2S+RAAW78CNJNbORhOKmLY0 R1pz5nrHwrLJ1xzJvXi3sZU+DWGQ9B0KJBVpc6aBVWDWc0aP0TBplVus1i2XBcVw ZONxoASry/nhPHnkmb3TvadPqC+ySHrPqY4LmApFVSaZXEFewg2876dqHU1FIDOF b0pHpbwb1MCoCpV1Pcn4439rRrHqonu5HSiXUAdSaNOFJLiRouP9fp8NpWrT7ds/ GYl/ObniosN1mDba/usPrulGqZ8kHIoVagLkxFSM9po/MbFkexOh7ZToznyaBWNs QyfkMMCXAKAJSzHq6pC2diTmQbpuawI6LLeJ5uOPtkLfNoVpyI83phJEXuZzg5g= =04Ms -----END PGP SIGNATURE----- --hI3RQLufgaom59dRQ5OT2PbenT4FMi15U-- From nobody Wed Feb 22 00:33:22 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B6F12968C; Wed, 22 Feb 2017 00:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsDzJzgzS8ZD; Wed, 22 Feb 2017 00:33:18 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16EB91294C0; Wed, 22 Feb 2017 00:33:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6259; q=dns/txt; s=iport; t=1487752398; x=1488961998; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=z0zgPGN+l8lyuUIKJtQKocrsa5RSJ6zTIduiMyjFfG4=; b=D9x5VJovmpfe61aT5bk8S9++dl5kqe/kKs+kiMnTdE+WZMXkuHOwfKks YSTGpJBgT8xR/JtoE6PfjLYEqVnfh2hcDCtCnnn0vFddmh5o3oqUhsfsE 9/HpQ09PcxlHGu77Zq+hni0jB08n+UViUoq65x5gVl+CgLc/SEvJxRKb9 g=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AQAfTK1Y/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIDJ1+DW4oIcpBolTSCDR8NgkCDNgKDMxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?xAQECAgEBIUgDBwQQCxgqAgInMAYNBgIBAReHbQOBag6ueIImi0cBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQERCgWIUYFhgQmHWoJfBYkZgVeRG4N3ggh1iy2Be4hJhkuINYZ?= =?us-ascii?q?UhBwfOIEAIRQIFxU+hko/NQGKOQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,193,1484006400"; d="asc'?scan'208";a="692437999" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2017 08:33:15 +0000 Received: from [10.61.198.238] ([10.61.198.238]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v1M8XFl2030938; Wed, 22 Feb 2017 08:33:15 GMT To: Hannes Tschofenig References: <16c236b7-dd80-1e27-8de9-16f05558d38e@gmx.net> <1da45f12-7999-6a9e-3649-2ffea4d50511@gmx.net> <6916bccf-9273-5d2f-af44-ef38d1394223@gmx.net> From: Eliot Lear Message-ID: <42690b82-8d20-a524-cf0a-ed665fa1610f@cisco.com> Date: Wed, 22 Feb 2017 09:33:14 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <6916bccf-9273-5d2f-af44-ef38d1394223@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6vLu85G6JLGLgaTmTlHiG6sfFAtMw1F2T" Archived-At: Cc: teep@ietf.org, saag Subject: Re: [saag] BOFs about IoT firmware update and TEE configuration 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 Feb 2017 08:33:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6vLu85G6JLGLgaTmTlHiG6sfFAtMw1F2T Content-Type: multipart/mixed; boundary="HhouLaCg7Tboxi57CHrgT3gmavpvqSUvP"; protected-headers="v1" From: Eliot Lear To: Hannes Tschofenig Cc: saag , teep@ietf.org Message-ID: <42690b82-8d20-a524-cf0a-ed665fa1610f@cisco.com> Subject: Re: [saag] BOFs about IoT firmware update and TEE configuration References: <16c236b7-dd80-1e27-8de9-16f05558d38e@gmx.net> <1da45f12-7999-6a9e-3649-2ffea4d50511@gmx.net> <6916bccf-9273-5d2f-af44-ef38d1394223@gmx.net> In-Reply-To: <6916bccf-9273-5d2f-af44-ef38d1394223@gmx.net> --HhouLaCg7Tboxi57CHrgT3gmavpvqSUvP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Great start, thanks! Will contact you offline to further discuss. Eliot On 2/22/17 9:15 AM, Hannes Tschofenig wrote: > Hi Eliot, > > > (I put the TEEP mailing list on CC since they may be interested in this= > conversation as well.) > > The use case for TEEP is a bit different. > > The idea is to configure software running on a trusted execution > environment. While the currently proposed solution assumes a PKI and th= e > use of asymmetric key cryptography it does not use 802.1AR certificates= =2E > There is no notion of a local network since it does not matter. The > document also does not talk about how the messages are conveyed but HTT= P > is more likely for the smart phone/tablet use cases. > > > I created a slide deck for presentation at the T2TRG meeting at the > Berlin IETF but unfortunately there was no time. Nevertheless, here is > the slide deck: > https://github.com/t2trg/2016-ietf96/blob/master/slides/70_OTrP-IETF93.= pdf > > Does this provide enough information about the intention? > > Ciao > Hannes > > On 02/20/2017 03:58 PM, Eliot Lear wrote: >> Hi Hannes, >> >> First, Max, Michael, Michael, and Kent are far more the experts than I= >> am on this, but here is a brief summary: >> >> The purpose of draft-ietf-anima-bootstrap-keyinfra is to provide a >> trusted introduction between devices and the network such that you sta= rt >> in the following state: >> >> Device has a manufacturer certificate (802.1AR iDevID) and a >> manufacturer trust root, and the local network can in some way >> authenticate the manufacturer, and perhaps visa versa. The end state = is >> that the device has a local (802.1 LDevID) and a local trust anchor. = To >> accomplish this, a flow is defined to get to the point where the devic= e >> will register with a local registrar using EST (either EST or EST/CoAP= ). >> >> Now perhaps you could explain a little about the TEE draft you're doin= g? >> >> If there's some overlap perhaps there's a chance to consolidate the wo= rk. >> >> Eliot >> >> >> >> On 2/18/17 5:17 PM, Hannes Tschofenig wrote: >>> Hi Eliot, >>> >>> I actually don't know since I never understood the ANIMA work all tha= t >>> well due to its fuzzy scope. I suspect that you can answer the questi= on >>> better than I do. >>> >>> Ciao >>> Hannes >>> >>> On 02/13/2017 02:29 PM, Eliot Lear wrote: >>>> Hannes, >>>> >>>> Can you say a few words about how TEE compares to >>>> draft-ietf-anima-bootstrap-keyinfra (et al) which has been in >>>> development in a WG for quite some time? >>>> >>>> Eliot >>>> >>>> >>>> On 2/13/17 12:51 PM, Hannes Tschofenig wrote: >>>>> Hi all, >>>>> >>>>> we have proposed two security-relevant BOFs for the upcoming meetin= g. >>>>> They are listed on the BOF Wiki page at >>>>> https://trac.tools.ietf.org/bof/trac/wiki but I still wanted to bri= efly >>>>> introduce them to you >>>>> >>>>> ** =E2=80=9CFirmware Update Description (FUD)=E2=80=9D >>>>> >>>>> Last year we had a workshop organized by the IAB on firmware update= s for >>>>> IoT devices (see https://www.iab.org/activities/workshops/iotsu/) w= here >>>>> we talked about various challenges and gaps. >>>>> >>>>> As a follow-up to the workshop we would like to initiate some >>>>> standardization activity in this area. >>>>> >>>>> The mailing list can be found at >>>>> https://www.ietf.org/mailman/listinfo/fud >>>>> >>>>> >>>>> ** =E2=80=9CA Protocol for Dynamic Trusted Execution Environment En= ablement (TEEP)=E2=80=9D >>>>> >>>>> This BOF is about an application layer security protocol that allow= s to >>>>> configure security credentials and software running on a Trusted >>>>> Execution Environment (TEE). Today, TEEs are, for example, found ho= me >>>>> routers, set-top boxes, smart phones, tablets, wearables, etc. >>>>> Unfortunately, there have been mostly proprietary protocols used in= this >>>>> environment. >>>>> >>>>> With this BOF we are making an attempt to standardize such a protoc= ol. A >>>>> strawman proposal of such a protocol has been published with >>>>> https://tools.ietf.org/html/draft-pei-opentrustprotocol-03. >>>>> >>>>> The mailing list can be found at: >>>>> https://www.ietf.org/mailman/listinfo/teep >>>>> >>>>> >>>>> >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> saag mailing list >>>>> saag@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/saag >> --HhouLaCg7Tboxi57CHrgT3gmavpvqSUvP-- --6vLu85G6JLGLgaTmTlHiG6sfFAtMw1F2T 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 iQEcBAEBCAAGBQJYrUzKAAoJEIe2a0bZ0nozIEgIAM/IZCtehAPetYs2lLHz/O2f V/Qv+6CuAxu0vbGVKOOiQ66yMDcc9Wln7Dkt7vJjMrVRZ7RWnsLkUGZ1JE7LHE02 G2e43Qa+WuCn6W7ffiYHlyvKgbW+W2BL2Db5V9eedfyex5tcoHx3jE95kpXWGkvt MJjsmOkc/gHuVJFvDT0hzuKOOrqIdIiG7D9QV/VsyfpbUVBpoZI3hfVXULOyXEFd 7A0dmhUEv545i8pyCihkErNRNLFRFpCWhS+yVkii36sJE8Yr79DxCr6EzUDVTd1C znembIxxYwwOMmVZZ3oSBJpaLXdDvV35Pk/ZMM+UVj85PpltwUFf78tQfl+mjg4= =//oj -----END PGP SIGNATURE----- --6vLu85G6JLGLgaTmTlHiG6sfFAtMw1F2T-- From nobody Thu Feb 23 08:20:13 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135C2129962 for ; Thu, 23 Feb 2017 08:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-RJAIw3oxPD for ; Thu, 23 Feb 2017 08:20:10 -0800 (PST) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51703129864 for ; Thu, 23 Feb 2017 08:20:10 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id a5so10090063ybb.2 for ; Thu, 23 Feb 2017 08:20:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZQ2l87t8Yl8k6iIjVWmUuLRPSHUlNEowpyXb9u9xY3A=; b=nScvaGM8IejdyHQjgElEXI7fymep8a7/GunzjnAzJNS/mMmgsXeqs69L7yNP528hsS EbbSlcuxnXKzF7Av/JDnsCEqRs/sI56AXA/F9G3p6HfXJoFUhTkNU/n6IkxjAS5rvvxX Wol2BXSAO4IYqJsSJ02vb0yZZx+EIitPSb0y/lEl/OycQmu4yQ6Lz8hNJIEFiZA8gxWA byOFpwUzTbqhD46A+pJIdSfGnPlTML0NUUAaEEFCvOrOSl7o5c2WwQbzxvPuHPmRSFOR FKfGde9sBc3Wccqbp49BQi7DkqP4Hw4cxB5siNqFpQiqDrU/J02t1Nag+CK8R4AYX1yT 3WMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ZQ2l87t8Yl8k6iIjVWmUuLRPSHUlNEowpyXb9u9xY3A=; b=UOS5YtO5iM4Mb5qzQTphQ0Hn/TDyxtI0+UaZcL+xSGKVyBxc6zED85iWy8yky1CVSX 2WQOr5GN1ya2yYP6qVvyvTN6UScW+VZMTj+JPb/tm9CVQ8P+z4j38NTeBp/PWHPmMyAj HwuE/Lrz3OVxadz9y2DXTuWaw+/Wvok2FfmbYXveUIiKE+UjWw9vvHxek2QBIiXW6r9x p6M7fzzDoAHn7y8mtrGT/Dm/489tbbroyyFXT6nIZSOwNQNV78hDgnkxVAaT+2DoNd/l j3beWcGBZyCxI6vnFhaEFwbWkVC01W0uF0tFX/qD/0WRekPgvdGLVHSLZRDPTNUBaYOX GvHQ== X-Gm-Message-State: AMke39k5MuJk8BE2MHTKSChwtcw+E+VHuOuEfJxmz+DlhtvLrVZVW2sBkOuxSQIvYvIlWwxFNLmBF8agOdANBw== X-Received: by 10.37.36.86 with SMTP id k83mr20335680ybk.130.1487866809544; Thu, 23 Feb 2017 08:20:09 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.17.140 with HTTP; Thu, 23 Feb 2017 08:20:09 -0800 (PST) In-Reply-To: References: From: Phillip Hallam-Baker Date: Thu, 23 Feb 2017 11:20:09 -0500 X-Google-Sender-Auth: GltThhkaOQbxbQCDmlJMEfVdLkc Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a113d46eca819cb054934fce2 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Securing the full TLS handshake including SNI 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 Feb 2017 16:20:12 -0000 --001a113d46eca819cb054934fce2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 21, 2017 at 11:00 AM, Salz, Rich wrote: > TLS 1.3 already has the concept of encrypted extensions in the handshake. > What if you put the =E2=80=9Creal=E2=80=9D SNI inside an encrypted extens= ion. This > requires the true origin and the =E2=80=9Cfronting=E2=80=9D origin to hav= e a trust > relationship, but that can probably work for most, not all, of the > delpoyments today. Then all you need to do is write up an I-D defining > this =E2=80=9Ctrue SNI extension.=E2=80=9D > > > =E2=80=8BHow to shoehorn the result into TLS was the least complicated bit = AFAIK. The tricky bit would be that you need to decide how you want DNS Discovery to work. I think the answer is to do DNS-SD for everything and assume that the recursive resolver knows to pull the entire discovery chains for the relevant records.=E2=80=8B --001a113d46eca819cb054934fce2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Tue, Feb 21, 2017 at 11:00 AM, Salz, Rich <rsalz@akamai.com> = wrote:

TLS 1.3 already has the c= oncept of encrypted extensions in the handshake.=C2=A0 What if you put the = =E2=80=9Creal=E2=80=9D SNI inside an encrypted extension.=C2=A0 This requir= es the true origin and the =E2=80=9Cfronting=E2=80=9D origin to have a trust rela= tionship, but that can probably work for most, not all, of the delpoyments = today.=C2=A0 Then all you need to do is write up an I-D defining this =E2= =80=9Ctrue SNI extension.=E2=80=9D



=E2=80=8BHow to sho= ehorn the result into TLS was the least complicated bit AFAIK.

The tricky bit would be that you need= to decide how you want DNS Discovery to work. I think the answer is to do = DNS-SD for everything and assume that the recursive resolver knows to pull = the entire discovery chains for the relevant records.=E2=80=8B

=C2=A0
--001a113d46eca819cb054934fce2-- From nobody Thu Feb 23 12:34:47 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DB2129A2F for ; Thu, 23 Feb 2017 12:34:46 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3-ESnDIK4NR for ; Thu, 23 Feb 2017 12:34:44 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F419129879 for ; Thu, 23 Feb 2017 12:34:44 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id s186so2504655qkb.1 for ; Thu, 23 Feb 2017 12:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8mS1GwNONkPuEpNqyG/pJIpY7R1+JiwAFeyCcSsSU/8=; b=mIaVpvnLqT+JvzSNx1x7t4zshLTWa2ZZyZn9mJzlargTRoJb6KYxNCUy3TIlAewpe2 j1raW0B1ZYCrKtMjvP+9H9XRDNfSpp6t4ohpVFKToXRgU56BvNqOL4xkhCM/Knhj37FA q6HTLZX9S5ZiNp7WVoXVYLPDnod8vcOluDelkGe5OlD4syWd82tU1qQs4TsDV4jizvcb L69abcXxvXLzRwZgLzGO25ufMu+m9ywi7Bs7RbfNWCmEEEtp+5OKuY4TqG8Cc0FbwONT rUq+QZn4G2cSz/7FZOTO97d6aHfDg8k4FdcGKtB2mpEEUFbPnKe9CcmifdL0tnLGqDlc M2pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8mS1GwNONkPuEpNqyG/pJIpY7R1+JiwAFeyCcSsSU/8=; b=VAJhDsvIdva1x3f3wXqEXjO6gu25gc3TY+ecDWFlYhUFhb+mFZppKwOHchLI9B+TGJ t07CTgTwqEVGQ8ebpod2OViPHVBFhH9HDK8s4qMk6B2A5mzkowsmZQaPnwKs7v49KNoT cy3B1eRHBfFfeo6R6SYrJHvhP6ta5Xq8dW/4u/qpwSWwEfywbYKoBSiJr40+UG+9fKn4 VAPq1L32lruz8wCS/oEBobT7ABdy0YsCuucjc4J8FxlKOJkLhW66x9wpUQeh1yzj9aNx vWiNr9ba9Ail+q6qmJ5lBLLPzdqrflG1pVW1TAj8lHTXiymqGEpGY7N8POcepGjgfx+N etHA== X-Gm-Message-State: AMke39l4cuLW8E8KRgpen0XmyKuwAsTNIhxwffDIlnR6KfEBJXIEilJrg23vzsQfNBGWC7/bQ1IcUg3veWAo+g== X-Received: by 10.55.215.149 with SMTP id t21mr41080524qkt.196.1487882083559; Thu, 23 Feb 2017 12:34:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.77 with HTTP; Thu, 23 Feb 2017 12:34:43 -0800 (PST) In-Reply-To: <1487133954201.79896@cs.auckland.ac.nz> References: <1487133954201.79896@cs.auckland.ac.nz> From: Kathleen Moriarty Date: Thu, 23 Feb 2017 15:34:43 -0500 Message-ID: To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD review of draft-gutmann-scep 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 Feb 2017 20:34:46 -0000 Hi Peter, On Tue, Feb 14, 2017 at 11:45 PM, Peter Gutmann wrote: > Kathleen Moriarty writes: > >>1. I see the draft is marked as a proposed standard, but previous drafts for >>SCEP are marked as HISTORIC with the reason explained in the introduction of >>https://tools.ietf.org/html/draft-nourse-scep-23. Can you explain why this is >>marked as standards track? I'd like to figure out the best fit. > > That's a political thing, I'll reply off-list. OK, I've heard a bit on this now and think HISTORIC is the best option to go forward. From what I understand, while there are a number of existing implementations, there are no new ones in development. This is just documenting for the existing, so historic is appropriate. Should any of the prior authors be listed as authors/editors? It would seem that they should be. > >>The following opinion sentence is not necessary as worded: >> >> While >> implementers are encouraged to investigate one of the more >> comprehensive alternative certificate management protocols in >> addition to the protocol defined in this specification, anyone >> wishing to deploy them should proceed with caution, and consider >> support and interoperability issues before committing to their use. >> >>I think it'll raise objections because of the opinion aspect, which isn't >>really appropriate for a standards document. > > That's not an opinion, it's just a statement of fact, the alternatives to SCEP > have proven so hard to deploy that... well, see above. All it's doing is > explaining why SCEP continues to exist despite there being supposed > replacements. It's actually a lot milder than what it should say, which is > that we have 15 years of experience in these things being almost impossible to > deploy in an interoperable manner. > >>3. Section 2.1.3 >>Is SHA-1 still really need for legacy reasons or can that be eliminated? >> >>4. Section 2.8 >>Are you really still seeing use of 3DES and SHA-1 or is this old text? > > The MTI algorithms throughout most of the document's lifetime was MD5 and > single DES. When I took over editing in 2015 I added AES (although several > implementations had already added it by themselves back then despite it not > being in the spec) and later SHA-256, and a handful of further vendors have > now added support for AES. SHA-256 is less common. Many (most?) though only > go up to 3DES and SHA-1. The spec didn't allow AES and SHA-256 until 2015, > and since the major use of SCEP is in embedded, rollout is going to take years > if not a decade or more. Deprecating 3DES or SHA-1 at this point would make > probably the majority of all SCEP implementations non-compliant with the spec. In light of news today, it would be good to deprecate SHA-1. > >>2. Section 2.1.3: s/the them/them/ >> >>5. Section 4.4 >>s/Whe the client/When the client/ > > Thanks, fixed. Thank you, Kathleen > > Peter. -- Best regards, Kathleen From nobody Thu Feb 23 12:35:03 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC6412A15E for ; Thu, 23 Feb 2017 12:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCZ4vNmFd_a0 for ; Thu, 23 Feb 2017 12:35:00 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D9512A2AC for ; Thu, 23 Feb 2017 12:34:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 62858300254 for ; Thu, 23 Feb 2017 15:34:54 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uluXAEkT6ACT for ; Thu, 23 Feb 2017 15:34:53 -0500 (EST) Received: from [192.168.2.107] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id AE93B300250 for ; Thu, 23 Feb 2017 15:34:53 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Thu, 23 Feb 2017 15:34:52 -0500 To: IETF SAAG X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [saag] Google announces the first SHA-1 collision 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 Feb 2017 20:35:02 -0000 https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html From nobody Thu Feb 23 14:05:38 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B026129B6A for ; Thu, 23 Feb 2017 14:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhK5B52C85-a for ; Thu, 23 Feb 2017 14:05:35 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0460129B5F for ; Thu, 23 Feb 2017 14:05:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 30101300436 for ; Thu, 23 Feb 2017 17:05:34 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iobCJsYM4ecK for ; Thu, 23 Feb 2017 17:05:33 -0500 (EST) Received: from [192.168.2.107] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 3A68930024D for ; Thu, 23 Feb 2017 17:05:33 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 23 Feb 2017 17:05:31 -0500 References: To: IETF SAAG In-Reply-To: Message-Id: <6DFDAE9C-E6DF-4826-9380-5D90F6705A5B@vigilsec.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [saag] Google announces the first SHA-1 collision 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 Feb 2017 22:05:36 -0000 > = https://security.googleblog.com/2017/02/announcing-first-sha1-collision.ht= ml The blog says: "Today, 10 years after of SHA-1 was first introduced, we = are announcing =E2=80=A6=E2=80=9D SHA-1 is specified in FIPS PUB 180, which is dated 11 May 1993. That is = a lot more than 10 years. Russ= From nobody Thu Feb 23 14:16:25 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDB1129BA4 for ; Thu, 23 Feb 2017 14:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEqukU55nFv2 for ; Thu, 23 Feb 2017 14:16:23 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C1D129B9E for ; Thu, 23 Feb 2017 14:16:22 -0800 (PST) Received: (qmail 27705 invoked from network); 23 Feb 2017 22:16:21 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 23 Feb 2017 22:16:21 -0000 Date: 23 Feb 2017 22:15:59 -0000 Message-ID: <20170223221559.9360.qmail@ary.lan> From: "John Levine" To: saag@ietf.org In-Reply-To: <6DFDAE9C-E6DF-4826-9380-5D90F6705A5B@vigilsec.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [saag] Google announces the first SHA-1 collision 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 Feb 2017 22:16:24 -0000 In article <6DFDAE9C-E6DF-4826-9380-5D90F6705A5B@vigilsec.com> you write: >> https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html > >The blog says: "Today, 10 years after of SHA-1 was first introduced, we are announcing …†> >SHA-1 is specified in FIPS PUB 180, which is dated 11 May 1993. That is a lot more than 10 years. The first cracks against SHA1 were published in 2005. That is also more than 10 years ago. https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html From nobody Thu Feb 23 17:14:21 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5FB129407 for ; Thu, 23 Feb 2017 17:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gy14C-Jzrjk for ; Thu, 23 Feb 2017 17:14:18 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52DB41293F3 for ; Thu, 23 Feb 2017 17:14:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6A297BE3E; Fri, 24 Feb 2017 01:14:15 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2o_kFwgo9Xl; Fri, 24 Feb 2017 01:14:14 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 802DABE38; Fri, 24 Feb 2017 01:14:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1487898853; bh=nkm4wdz0FRTo5lfgS0vCgXseqRFQF3wLbi+R5HynCZo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=NCkVJx5pQc6rSxTrX4GJKIi3jXI/v++c98/mVC9QxZzBkk43ibDWI8ZDOx4j+sen3 3xBaN1wTKp4QnnegivlkDFXfrK5HFgOKwX+pFN0WL0AMrO5Q8gsBLIPx01SvtDuVQ4 yo5w04NY09l4JORa2Eh8jvKbRHDvQSD2NqYEBBzA= To: John Levine , saag@ietf.org References: <20170223221559.9360.qmail@ary.lan> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 24 Feb 2017 01:14:12 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170223221559.9360.qmail@ary.lan> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hAXq1MtwFfODHtdKWIJLNU3bb27OhDpFv" Archived-At: Subject: Re: [saag] Google announces the first SHA-1 collision 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 Feb 2017 01:14:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hAXq1MtwFfODHtdKWIJLNU3bb27OhDpFv Content-Type: multipart/mixed; boundary="E6ealAjE4AW526gqPhAxu0F6k7QKxIrha"; protected-headers="v1" From: Stephen Farrell To: John Levine , saag@ietf.org Message-ID: Subject: Re: [saag] Google announces the first SHA-1 collision References: <20170223221559.9360.qmail@ary.lan> In-Reply-To: <20170223221559.9360.qmail@ary.lan> --E6ealAjE4AW526gqPhAxu0F6k7QKxIrha Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 23/02/17 22:15, John Levine wrote: > In article <6DFDAE9C-E6DF-4826-9380-5D90F6705A5B@vigilsec.com> you writ= e: >>> https://security.googleblog.com/2017/02/announcing-first-sha1-collisi= on.html >> >> The blog says: "Today, 10 years after of SHA-1 was first introduced, w= e are announcing =E2=80=A6=E2=80=9D >> >> SHA-1 is specified in FIPS PUB 180, which is dated 11 May 1993. That = is a lot more than 10 years. >=20 > The first cracks against SHA1 were published in 2005. That is also > more than 10 years ago. Failings in reportage aside, this is still an interesting and fine result and one that should be welcomed - reality being a fine thing:-) IMO - well done to the authors! The timeline here I think does re-enforce the approach we collectively took (at the behest of folks including Russ at the time) for moving away from sha-1. But I'm sure there're lessons we can all learn from yet another existence proof that all crypto algorithms do have a best-before-date even when we don't know quite what's the right value for that;-) S. >=20 > https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --E6ealAjE4AW526gqPhAxu0F6k7QKxIrha-- --hAXq1MtwFfODHtdKWIJLNU3bb27OhDpFv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYr4jkAAoJEC88hzaAX42iC+QH+gPTX3zzpKOZ9SGVVUsecG7t 3jfnMI9Gl5Skmrg4mFJBthiAQfUAwyztVHN6NioZPsK2GzDvv+lAZ+QUh60oiaTQ pAZhpjHAxxLrPwXnHVLqXKbETZnDtnO50eapxE1KXGITue7ohRVDuBxdC2m4TbBn mJTHMMhElnvECC3ozEuDh0UiF1oL2OZMVEhoaupodaBhk4TIkGQgihfLNVKp39Lb jbAqZtllqEpAIBLVQdoYF36B/BCNhQl0jBUk7/UUgKelwocm2/W8D8ajNtBv0T7z am1YpCgIQG+EiPN8Sndec791WaPxzulGtyGilxpmmGg9cmPGvosZxu0C+6iGfVI= =zOie -----END PGP SIGNATURE----- --hAXq1MtwFfODHtdKWIJLNU3bb27OhDpFv-- From nobody Fri Feb 24 08:59:25 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA36128B38 for ; Fri, 24 Feb 2017 08:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPg9AzuKC1we for ; Fri, 24 Feb 2017 08:59:21 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88368128B37 for ; Fri, 24 Feb 2017 08:59:21 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8924EE032 for ; Fri, 24 Feb 2017 12:21:19 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8C5CE6381A for ; Fri, 24 Feb 2017 11:59:18 -0500 (EST) From: Michael Richardson To: saag@ietf.org In-Reply-To: References: <20170223221559.9360.qmail@ary.lan> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] Google announces the first SHA-1 collision 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 Feb 2017 16:59:23 -0000 --=-=-= Content-Type: text/plain Stephen Farrell wrote: > The timeline here I think does re-enforce the approach we collectively > took (at the behest of folks including Russ at the time) for moving > away from sha-1. But I'm sure there're lessons we can all learn from > yet another existence proof that all crypto algorithms do have a > best-before-date even when we don't know quite what's the right value > for that;-) The other lesson is that it appears that the HMAC-SHA1 construct (like HMAC-MD5) remains unaffected by the attack. My other impression is that the collisions are longer than the original. I am most concerned about the git use of SHA-1 (and other at-rest uses of SHA-1, such as inside certificates). I am less concerned about the the session uses, and I think that the PRF uses of SHA-1 are probably immune. Our move towards AEAD methods means that we are increasingly not using SHA-1 (or any SHA-x). It seems to me that most urgent thing is to capture the experiences (and best practices) we have had in the past 3-5 years on the SHA1->SHA2 switchover, and make sure that our SHA2 based infrastructure is ready for the next switchover. [I think that the push to SHA2 has hurt security at times by training users to click through warnings, or causing people to use http when https started to fail] -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAliwZmYACgkQgItw+93Q 3WWjOAf/VyGmu/0f6Ri8RgcuAFfoMl0/1KEphVPSRfZEawyyvxC63+IOWlHkMyKU NFTz39kxDD8CElc9M/rNnocIIzHkKeoEqEGuut/zMB6JptDpq9BykNr+v5ueWtvI EP7Vs1+PGfv11Tb/DPZRUXNLIpzjxAyTmODkfDblMnlhZbTpBhk2052UgSp2y1aX 76Mrg/CF/PrYtAMFCD+NyQTSfmWCeAN4tlP8f/N5ePjRxudcKBlHNmRu4drpIyeQ z+tNaSArYNMcXpSUAld4hBvShmqxVWBTmdclSZiDTZDpi1zoSGNp5LvREWqbjKRg t5r/ml2JQ+/0bvnX1BA5MIf1v3ZyPg== =eWk6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 24 09:02:17 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7971293F2 for ; Fri, 24 Feb 2017 09:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 kxALvHPdi3oC for ; Fri, 24 Feb 2017 09:02:14 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 6553F1293F0 for ; Fri, 24 Feb 2017 09:02:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 7207DAC1; Fri, 24 Feb 2017 17:02:13 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnPYmto0VAMH; Fri, 24 Feb 2017 17:02:13 +0000 (UTC) Received: from [192.168.20.89] (CPEf4cc552207f0-CM00fc8dce0fa0.cpe.net.cable.rogers.com [99.230.129.191]) by mail.networkradius.com (Postfix) with ESMTPSA id E1FBF2E1; Fri, 24 Feb 2017 17:02:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <16195.1487955558@obiwan.sandelman.ca> Date: Fri, 24 Feb 2017 12:02:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <64885A7E-1480-4ACA-B72C-8E309A101955@deployingradius.com> References: <20170223221559.9360.qmail@ary.lan> <16195.1487955558@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: saag@ietf.org Subject: Re: [saag] Google announces the first SHA-1 collision 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 Feb 2017 17:02:16 -0000 On Feb 24, 2017, at 11:59 AM, Michael Richardson = wrote: > I am most concerned about the git use of SHA-1 Linus seems to think it's OK: http://marc.info/?l=3Dgit&m=3D148787047422954 More discussion here: https://news.ycombinator.com/item?id=3D13719368 Alan DeKok. From nobody Sun Feb 26 13:24:34 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73728129452 for ; Sun, 26 Feb 2017 13:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAErnELzIeyP for ; Sun, 26 Feb 2017 13:24:31 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 716EE129451 for ; Sun, 26 Feb 2017 13:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1488144271; x=1519680271; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cpw9yqaKeppe6uJLdP/qRw7gpW8C+48jcyR8aue+4C0=; b=d0gPF3XL/hhonFPTeU+zZGInw7E355VxO3bVi4kZZefC8t9J9aFdbFK5 x6IvD0cyX1F+Iwk9YNPVqW5vsuLKIyE/fTRBPVcjUqb9jfBmqfr3GstSj dPZACMrLCyjcrN6YVFIVnANsy6k/yz3cySVdtkolVQh93giE69I5WUTTF gw1HM8PtsSkPgNjYux5wdo5CPPa2Rhz2pBrWjkjbCsCblUrdnSu8gqHWp wFeVIZ0KkD7b9UfHt8ZT9HYWv5JZ371ir9yBMcNb3L81aO0zqlH895fUv I2wapmidzzETmogPiA5b+SC97IwgXfRumabR5zsyA5U/jjMZnu88Q8csC g==; X-IronPort-AV: E=Sophos;i="5.35,210,1483959600"; d="scan'208";a="137566811" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from uxcn13-ogg-d.uoa.auckland.ac.nz ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Feb 2017 10:24:28 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.25) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.25) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 27 Feb 2017 10:24:28 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Mon, 27 Feb 2017 10:24:28 +1300 From: Peter Gutmann To: Kathleen Moriarty Thread-Topic: AD review of draft-gutmann-scep Thread-Index: AQHShg+C3gGYfe6mt0G2Dw8NHsWhxKFpgFPUgAzCJ4CABZ6XLQ== Date: Sun, 26 Feb 2017 21:24:27 +0000 Message-ID: <1488144253202.68446@cs.auckland.ac.nz> References: <1487133954201.79896@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD review of draft-gutmann-scep 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, 26 Feb 2017 21:24:33 -0000 Kathleen Moriarty writes:=0A= =0A= >OK, I've heard a bit on this now and think HISTORIC is the best option to = go=0A= >forward. From what I understand, while there are a number of existing=0A= >implementations, there are no new ones in development. This is just=0A= >documenting for the existing, so historic is appropriate.=0A= =0A= Sure, that works for me. The reason why I was hoping for standards-track i= s=0A= that it's referenced in a number of other (non-IETF) standards, and I don't= =0A= know whether their attitude to downrefs is the same as the IETF one. Can y= ou=0A= reference a non-standards-track doc (i.e. historic-status) from a standards= -=0A= track one?=0A= =0A= >Should any of the prior authors be listed as authors/editors? It would se= em=0A= >that they should be.=0A= =0A= I think so too, but there's more politics involved. I'll reply off-list.= =0A= =0A= (If anyone else is interested in the reasons I'm happy to give them, it's j= ust=0A= best not to create a public record of it).=0A= =0A= >In light of news today, it would be good to deprecate SHA-1.=0A= =0A= The problem with doing that, if it's done as a MUST NOT (it's already a MUS= T=0A= SHA-2, MAY SHA-1), is that it would instantly make pretty much every=0A= implementation of SCEP in existence non-compliant. In addition it's not=0A= really an issue, I've got the following draft text ready to add to the=0A= security considerations:=0A= =0A= -- Snip --=0A= =0A= Use of SHA-1=0A= =0A= Virtually all of the large numbers of devices that use SCEP today default t= o=0A= SHA-1, with many supporting only SHA-1 with no ability to upgrade them. Th= is=0A= hash algorithm is no longer regarded as secure in all situations, but as us= ed=0A= in SCEP it's still safe. =0A= =0A= There are three reasons for this, the first being that attacking SCEP would= =0A= require creating a SHA-1 collision in close to real time, which won't be=0A= feasible for a very long time.=0A= =0A= The second reason is that the signature over the message doesn't serve any= =0A= critical cryptographic purpose: The PKCS #10 data itself is authenticated= =0A= through its own signature, protected by encryption, and the overall request= is=0A= authorised by the (encrypted) password. The sole exception to this will be= =0A= the small number of implementations that support the Renewal operation, whi= ch=0A= may be authorised purely through a signature, but presumably any=0A= implementation recent enough to support Renewal also supports SHA-2. Any= =0A= legacy implementation that supports the historic core SCEP protocol would n= ot=0A= be affected.=0A= =0A= The third reason is that SCEP uses the same key for encryption and signing,= so=0A= that even if an attacker were able to capture an outgoing Renewal request t= hat=0A= didn't include a password (in other words one that was only authorised thro= ugh=0A= a signature), forge the SHA-1 hash in real time, and forward the forged=0A= request to the CA, they couldn't decrypt the returned certificate, which is= =0A= protected with the same key that was used to generate the signature. While= =0A= points out that SCEP uses unnecessa= ry=0A= cryptography in places, the additional level of security provided by the ex= tra=0A= crypto makes it immune to any issues with SHA-1.=0A= =0A= This doesn't mean that SCEP implementations should continue to use SHA-1 in= =0A= perpetuity, merely that there's no need for a panicked switch to SHA-2.=0A= =0A= -- Snip --=0A= =0A= Peter.= From nobody Sun Feb 26 18:57:41 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DE4129AA9 for ; Sun, 26 Feb 2017 18:57:40 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kA8dnMunkNR for ; Sun, 26 Feb 2017 18:57:39 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d: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 E52D4129AA7 for ; Sun, 26 Feb 2017 18:57:38 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id n127so78491238qkf.0 for ; Sun, 26 Feb 2017 18:57:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=m8d9M5ybhq00vnxw/5VzqWsQJqM179H15Gfhe1NKIO8=; b=HeRKG7Y/loeOm2mFPUQmBZgteKIdyUa8HJbtZzKXDIQjuOzbRdz9thvMNLj9NbWE9n dfJNOHYl8Sww8QHcaemA8OskD0sDSO9J4Su/5xOmIXTt+aGf1ATGCjxPhlBvTgGwXI3I Y3zhV+mMIm6Djz/zsPbj/mtz5M594r+V3Y5xCzsm8UKifLxOCFzudVTLO1o8JynJisGo La/nRYv84j6Q+UK+PxUL+3ko0hQtWtuUuFugJBk2JKuMa22jvnapP8sRrISTBMFYp3rI Rfdc6IC1wi7PdW86w7MBWp9Nbme+HKY5Hb6No2PFr0v9g4oxnb8S9eT0boXr3UGaamWo MGIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=m8d9M5ybhq00vnxw/5VzqWsQJqM179H15Gfhe1NKIO8=; b=RoQQT6L8MlkKtysPG/xbNhVIjTOnOwu9FFidT8Nc3nuybM0iqIMGK0ofO9biyV1xzF hOvE5RQ916Zv/gKpBy5a7pBcY3wDa1sBDGSq9ZiNYQ55SCRoUcIsyZrUliXUi1sPqcef 7hAnxTjWNFo3wRajokA+uWDi2q1HclUK/nlRY9CIYj+TMz/f8lumulB6kkWBFvl+Kn93 VjqryaKcZ5cyujKz5NU3XVCqmV4TA8i4zKQ10VGhOnBX0HlObi3xsXf/E6AYtUw7HdiU CkWXPR2V4FN7S9dL3sQo8bzHgope6wO7tFczjyqkPUexPCp780Rc0bZIW43HJzIJFH5B GVEQ== X-Gm-Message-State: AMke39laZQd7eYw5lC+xZVW6J+JQx7q8gAGqe3MRFVnJOxofjBIYD7cqFG8bwoijBAqrmA== X-Received: by 10.200.46.35 with SMTP id r32mr13273309qta.56.1488164258034; Sun, 26 Feb 2017 18:57:38 -0800 (PST) Received: from [192.168.1.8] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id y26sm5453795qty.25.2017.02.26.18.57.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Feb 2017 18:57:37 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (14D27) In-Reply-To: <1488144253202.68446@cs.auckland.ac.nz> Date: Sun, 26 Feb 2017 21:57:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <61D68AE9-C97D-4E59-AED7-3DC59EF7FC55@gmail.com> References: <1487133954201.79896@cs.auckland.ac.nz> <1488144253202.68446@cs.auckland.ac.nz> To: Peter Gutmann Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD review of draft-gutmann-scep 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 Feb 2017 02:57:40 -0000 Hi Peter, Please excuse typos, sent from handheld device=20 > On Feb 26, 2017, at 4:24 PM, Peter Gutmann wro= te: >=20 > Kathleen Moriarty writes: >=20 >> OK, I've heard a bit on this now and think HISTORIC is the best option to= go >> forward. =46rom what I understand, while there are a number of existing >> implementations, there are no new ones in development. This is just >> documenting for the existing, so historic is appropriate. >=20 > Sure, that works for me. The reason why I was hoping for standards-track i= s > that it's referenced in a number of other (non-IETF) standards, and I don'= t > know whether their attitude to downrefs is the same as the IETF one. Good, thanks. > Can you > reference a non-standards-track doc (i.e. historic-status) from a standard= s- > track one? Yes, we just have to call it out during IETF last call. >=20 >> Should any of the prior authors be listed as authors/editors? It would s= eem >> that they should be. >=20 > I think so too, but there's more politics involved. I'll reply off-list. Ok, thanks. >=20 > (If anyone else is interested in the reasons I'm happy to give them, it's j= ust > best not to create a public record of it). >=20 >> In light of news today, it would be good to deprecate SHA-1. >=20 > The problem with doing that, if it's done as a MUST NOT (it's already a MU= ST > SHA-2, MAY SHA-1), is that it would instantly make pretty much every > implementation of SCEP in existence non-compliant. In addition it's not > really an issue, I've got the following draft text ready to add to the > security considerations: >=20 Thanks for the text below. I was meaning to send a note saying it didn't ma= tter with the draft going historic, but think your text would be a helpful a= ddition. I'll look at your other message. Thank you, Kathleen=20 > -- Snip -- >=20 > Use of SHA-1 >=20 > Virtually all of the large numbers of devices that use SCEP today default t= o > SHA-1, with many supporting only SHA-1 with no ability to upgrade them. T= his > hash algorithm is no longer regarded as secure in all situations, but as u= sed > in SCEP it's still safe. =20 >=20 > There are three reasons for this, the first being that attacking SCEP woul= d > require creating a SHA-1 collision in close to real time, which won't be > feasible for a very long time. >=20 > The second reason is that the signature over the message doesn't serve any= > critical cryptographic purpose: The PKCS #10 data itself is authenticated > through its own signature, protected by encryption, and the overall reques= t is > authorised by the (encrypted) password. The sole exception to this will b= e > the small number of implementations that support the Renewal operation, wh= ich > may be authorised purely through a signature, but presumably any > implementation recent enough to support Renewal also supports SHA-2. Any > legacy implementation that supports the historic core SCEP protocol would n= ot > be affected. >=20 > The third reason is that SCEP uses the same key for encryption and signing= , so > that even if an attacker were able to capture an outgoing Renewal request t= hat > didn't include a password (in other words one that was only authorised thr= ough > a signature), forge the SHA-1 hash in real time, and forward the forged > request to the CA, they couldn't decrypt the returned certificate, which i= s > protected with the same key that was used to generate the signature. Whil= e > points out that SCEP uses unnecess= ary > cryptography in places, the additional level of security provided by the e= xtra > crypto makes it immune to any issues with SHA-1. >=20 > This doesn't mean that SCEP implementations should continue to use SHA-1 i= n > perpetuity, merely that there's no need for a panicked switch to SHA-2. >=20 > -- Snip -- >=20 > Peter. From nobody Tue Feb 28 10:37:17 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9B212967B for ; Tue, 28 Feb 2017 10:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnTqzTvHJ6Ac for ; Tue, 28 Feb 2017 10:37:14 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45778129665 for ; Tue, 28 Feb 2017 10:37:14 -0800 (PST) Received: (qmail 11374 invoked from network); 28 Feb 2017 19:37:12 +0100 Received: from p5dec2bb4.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.43.180) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 28 Feb 2017 19:37:12 +0100 From: "Mirja Kuehlewind (IETF)" Content-Type: multipart/alternative; boundary="Apple-Mail=_B8A3845E-10C2-4AFF-91B4-D4A1C53AB655" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 28 Feb 2017 19:37:10 +0100 References: <41397ABC-92F8-41B4-867A-60835DB3D38B@kuehlewind.net> To: saag@ietf.org Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Spencer Dawkins at IETF Subject: [saag] Fwd: [tsv-area] Draft agenda uploaded X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 18:37:16 -0000 --Apple-Mail=_B8A3845E-10C2-4AFF-91B4-D4A1C53AB655 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi! I=E2=80=99m forwarding the announcement of the tsv-area meeting draft = agenda because we have a couple of privacy related presentation this = time including someone from the Tor project talking about requirements = for protocols.=20 I=E2=80=99d like to already apologize for any conflicts with sec wg = meetings. We tried out best best but it=E2=80=99s basically impossible = to de-conflict with all tsv and sec sessions=E2=80=A6 Hope to see you there! Mirja and Spencer > Anfang der weitergeleiteten Nachricht: >=20 > Von: "Mirja Kuehlewind (IETF)" > Betreff: Draft agenda uploaded > Datum: 28. Februar 2017 um 19:29:42 MEZ > An: tsv-area@ietf.org >=20 > Hi all, >=20 > we are happy to announce that we just uploaded the draft agenda for = the tsv-area meeting and we have a number of very interesting talks this = time! See >=20 > https://www.ietf.org/proceedings/98/agenda/agenda-98-tsvarea-00 >=20 > =E2=80=94=E2=80=94 > TSVAREA @ IETF-98 (Chicago) >=20 > Monday, March 27, 2017 > Afternoon session I 13:00-15:00 > Room: Vevey 1/2 >=20 > * Administrativa - TSV ADs > - Note Well, Blue Sheets, Jabber Scribes, Agenda Bashing > - TSV Overview and status > 10 minutes >=20 > * Beneficial Functions of Middleboxes = (draft-dolson-plus-middlebox-benefits) - Dave Dolson > 10 minutes + 15 minutes Q&A >=20 > * Transport-Independent Path Layer State Management = (draft-trammell-plus-statefulness) - Brian Trammell, remote > 10 minutes + 15 minutes Q&A >=20 > * Tackling privacy and confidentiality of communications: EU's = ePrivacy Regulation - Diego Naranjo (European Digital Rights - = https://edri.org), remote > 15 minutes + 15 minutes Q&A >=20 > * Tor's Perspective on Privacy and Traffic Analysis Resistance for = Encrypted Protocols - Mike Perry=20 > 15 minutes + 15 minutes Q&A > =E2=80=94=E2=80=94 >=20 > As always both the scheduled slot as well as your agenda are only = preliminary. Especially we are still considering a way to add another = agenda item which might lead to some changes in the timing. >=20 > See you all in Chicago! > Your friendly transport ADs >=20 >=20 >=20 --Apple-Mail=_B8A3845E-10C2-4AFF-91B4-D4A1C53AB655 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi!

I=E2=80= =99m forwarding the announcement of the tsv-area meeting draft agenda = because we have a couple of privacy related presentation this time = including someone from the Tor project talking about requirements for = protocols. 

I=E2=80=99d like to already apologize for any conflicts with = sec wg meetings. We tried out best best but it=E2=80=99s basically = impossible to de-conflict with all tsv and sec sessions=E2=80=A6

Hope to see you = there!
Mirja and Spencer


Anfang der weitergeleiteten Nachricht:

Von: = "Mirja Kuehlewind (IETF)" = <ietf@kuehlewind.net>
Betreff: = Draft agenda = uploaded
Datum: = 28. Februar 2017 um 19:29:42 = MEZ
An: = tsv-area@ietf.org

Hi = all,

we are happy to announce that we just = uploaded the draft agenda for the tsv-area meeting and we have a number = of very interesting talks this time! See

https://www.ietf.org/proceedings/98/agenda/agenda-98-tsvarea-00=

=E2=80=94=E2=80=94
TSVAREA= @ IETF-98 (Chicago)

Monday, March 27, = 2017
Afternoon session I 13:00-15:00
Room: = Vevey 1/2

* Administrativa - TSV ADs
- Note Well, Blue Sheets, Jabber Scribes, Agenda Bashing
- TSV Overview and status
10 minutes

* Beneficial Functions of Middleboxes = (draft-dolson-plus-middlebox-benefits) - Dave Dolson
10 = minutes + 15 minutes Q&A

* = Transport-Independent Path Layer State Management = (draft-trammell-plus-statefulness) - Brian Trammell, remote
10 minutes + 15 minutes Q&A

* = Tackling privacy and confidentiality of communications: EU's ePrivacy = Regulation - Diego Naranjo (European Digital Rights - https://edri.org), = remote
15 minutes + 15 minutes Q&A

* Tor's Perspective on Privacy and Traffic Analysis = Resistance for Encrypted Protocols - Mike Perry
15 = minutes + 15 minutes Q&A
=E2=80=94=E2=80=94

As always both the scheduled slot as well as = your agenda are only preliminary. Especially we are still considering a = way to add another agenda item which might lead to some changes in the = timing.

See you all in Chicago!
Your friendly transport ADs




= --Apple-Mail=_B8A3845E-10C2-4AFF-91B4-D4A1C53AB655--