From nobody Tue Mar 3 13:56:44 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749BA1ACDA2 for ; Tue, 3 Mar 2015 13:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiydQSPnPceq for ; Tue, 3 Mar 2015 13:56:42 -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 2A6541ACD95 for ; Tue, 3 Mar 2015 13:56:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EE3C8BEEB for ; Tue, 3 Mar 2015 21:56:40 +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 VVDe97BXB1Gr for ; Tue, 3 Mar 2015 21:56:40 +0000 (GMT) Received: from webmail.scss.tcd.ie (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BDDF8BEDE for ; Tue, 3 Mar 2015 21:56:40 +0000 (GMT) Received: from 81.57.243.48 (SquirrelMail authenticated user sfarrel6) by webmail.scss.tcd.ie with HTTP; Tue, 3 Mar 2015 21:56:40 -0000 Message-ID: Date: Tue, 3 Mar 2015 21:56:40 -0000 From: stephen.farrell@cs.tcd.ie To: saag@ietf.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 21:56:43 -0000 Hiya, A protocol that can run over TLS can be allocated two ports (like HTTP with 80 and 443) or one port and use STARTTLS or similar. Ted has a discuss [1] on a document about port number allocations and asked if the security ADs cared. We think the answer is that we don't (one can muck up or do ok either way) and we also don't think that the security area actually has a consensus that one or two ports is generally "more secure". If you think we're wrong and there is a clear consensus on then please respond in the next day or so. If you don't think there's consensus silence is fine. (As if that'll stop you:-) Cheers, S. PS: We're just asking as it might help folks resolve or work around some potential repeated arguments on the topic. And we're not saying whether we actually favour one or two port approaches:-) [1] https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ballot/#ted-lemon From nobody Tue Mar 3 14:06:09 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6951B1ACDC4 for ; Tue, 3 Mar 2015 14:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1ujLqHu9q2N for ; Tue, 3 Mar 2015 14:06:05 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D53C1A89AF for ; Tue, 3 Mar 2015 14:06:05 -0800 (PST) Received: by wesu56 with SMTP id u56so42682767wes.10 for ; Tue, 03 Mar 2015 14:06:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=p33p9o2JJHduuOsaQKtM4GxXRDdCHXY4Mw+TtIeK+1g=; b=xjoIZ5ryMRr3+7oe6X8ViPPu9GjsZfSULI6bkjd7LR5aCsT/T/pl0EsHDIRYlJOdPw ZGfED6O6wP/96Je6JNH/MpCvXdP+3Mw6JVOrVwd5a0Cfbhd2W97UDsraPCBlx+DND+Mh bNYlQH5Qn6w1Ki9/jIlUQIMCymJTGspJZ8YhsmWNgc9Eqk1YcWhCWlvmR2kZvffyx5LW XN1yge+MnkYVdHu+SQWyT4a3UbZTawLg2pBHmqHxU1ivdMXsFUMsH+TUk8y2zTn81XPt TLLJQPS6TDHXz9LbzknTGI2mXiA7CdEo4hs04EuhbpSc2cYny/ixs9fYHeJo7eH17eeT Dvfw== X-Received: by 10.194.122.196 with SMTP id lu4mr1806431wjb.154.1425420364343; Tue, 03 Mar 2015 14:06:04 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by mx.google.com with ESMTPSA id hl8sm3117972wjb.38.2015.03.03.14.06.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Mar 2015 14:06:03 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=utf-8 From: Yoav Nir X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 4 Mar 2015 00:06:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: stephen.farrell@cs.tcd.ie X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 22:06:07 -0000 > On Mar 3, 2015, at 11:56 PM, stephen.farrell@cs.tcd.ie wrote: >=20 >=20 > Hiya, >=20 > A protocol that can run over TLS can be allocated two ports > (like HTTP with 80 and 443) or one port and use STARTTLS or > similar. >=20 > Ted has a discuss [1] on a document about port number allocations > and asked if the security ADs cared. We think the answer is that > we don't (one can muck up or do ok either way) and we also don't > think that the security area actually has a consensus that one > or two ports is generally "more secure". If you think we're wrong > and there is a clear consensus on then please respond in the next > day or so. If you don't think there's consensus silence is fine. > (As if that'll stop you:-) >=20 > Cheers, > S. >=20 > PS: We're just asking as it might help folks resolve or work > around some potential repeated arguments on the topic. And we're > not saying whether we actually favour one or two port approaches:-) >=20 > [1] > = https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ballot/#ted-lem= on I don=E2=80=99t think we should prefer things either way. There is a lot = to say about the security of the web and the security of Internet email, = but I don=E2=80=99t think any of the issues these protocols have is = rooted in HTTP using two ports or SMTP using one. With two ports, firewalls have an easier time either forcing or denying = encryption (assuming that the applications have fall-back behavior), but = firewalls have managed fine with SMTP for twenty years. I don=E2=80=99t = think this is an issue either way. Of course, assigning one port instead = of two saves on a scarce resource, but that is not a security = consideration. Yoav From nobody Tue Mar 3 14:08:36 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF911ACDEB for ; Tue, 3 Mar 2015 14:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5Hf0-2DbpfG for ; Tue, 3 Mar 2015 14:08:23 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014C11ACDF3 for ; Tue, 3 Mar 2015 14:08:15 -0800 (PST) Received: by lbvp9 with SMTP id p9so5152966lbv.10 for ; Tue, 03 Mar 2015 14:08:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vTcG6ibJ/JAVnwZr4MWgW9h9v82+4DZMzwda1rt9GQg=; b=x9rKELSr6I8CvFgjJEq24yxbUUIefpklha1GhbSitmVKU3KM16bxp+Y1o1/eV7E3QJ QSSkMxUVCIPlifJi+r0JYEOzMAp2O5VMxOBhFLZwMNzxUNnyyI7CyO3Janh2ig65AfeG Zz5T0MACCKFQMF5W2tyPlRhonldYsajAheZ6LQJPO2y3dQFcsiH0Vkhl7UesSac+GHJn 8SpSqODSEOeIGl/cb9gQGNgqzwe2qOr6kkxgtomf5epPAuH9hpk+B5yYs/4TVYzFYfW/ ZZLdFZzgWJmdiz3cuILRS1qEA7AbqzIno4l7gSOwYaxhjwWRS/sZc9a5QDTGcOwHzwp9 JG/g== MIME-Version: 1.0 X-Received: by 10.152.178.197 with SMTP id da5mr940851lac.56.1425420493357; Tue, 03 Mar 2015 14:08:13 -0800 (PST) Received: by 10.112.167.101 with HTTP; Tue, 3 Mar 2015 14:08:13 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Mar 2015 17:08:13 -0500 Message-ID: From: Kathleen Moriarty To: Yoav Nir Content-Type: multipart/alternative; boundary=001a11340c682988b70510699283 Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 22:08:27 -0000 --001a11340c682988b70510699283 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 3, 2015 at 5:06 PM, Yoav Nir wrote: > > > On Mar 3, 2015, at 11:56 PM, stephen.farrell@cs.tcd.ie wrote: > > > > > > Hiya, > > > > A protocol that can run over TLS can be allocated two ports > > (like HTTP with 80 and 443) or one port and use STARTTLS or > > similar. > > > > Ted has a discuss [1] on a document about port number allocations > > and asked if the security ADs cared. We think the answer is that > > we don't (one can muck up or do ok either way) and we also don't > > think that the security area actually has a consensus that one > > or two ports is generally "more secure". If you think we're wrong > > and there is a clear consensus on then please respond in the next > > day or so. If you don't think there's consensus silence is fine. > > (As if that'll stop you:-) > > > > Cheers, > > S. > > > > PS: We're just asking as it might help folks resolve or work > > around some potential repeated arguments on the topic. And we're > > not saying whether we actually favour one or two port approaches:-) > > > > [1] > > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ballot/#ted-le= mon > > I don=E2=80=99t think we should prefer things either way. There is a lot = to say > about the security of the web and the security of Internet email, but I > don=E2=80=99t think any of the issues these protocols have is rooted in H= TTP using > two ports or SMTP using one. > > With two ports, firewalls have an easier time either forcing or denying > encryption (assuming Great point. > that the applications have fall-back behavior), but firewalls have manage= d > fine with SMTP for twenty years. I don=E2=80=99t think this is an issue e= ither way. > Of course, assigning one port instead of two saves on a scarce resource, > but that is not a security consideration. > > Yoav > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --=20 Thanks, Kathleen --001a11340c682988b70510699283 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 3, 2015 at 5:06 PM, Yoav Nir <ynir.ietf@gmail.com&g= t; wrote:

> On Mar 3, 2015, at 11:56 PM, stephen.farrell@cs.tcd.ie wrote:
>
>
> Hiya,
>
> A protocol that can run over TLS can be allocated two ports
> (like HTTP with 80 and 443) or one port and use STARTTLS or
> similar.
>
> Ted has a discuss [1] on a document about port number allocations
> and asked if the security ADs cared. We think the answer is that
> we don't (one can muck up or do ok either way) and we also don'= ;t
> think that the security area actually has a consensus that one
> or two ports is generally "more secure". If you think we'= ;re wrong
> and there is a clear consensus on then please respond in the next
> day or so. If you don't think there's consensus silence is fin= e.
> (As if that'll stop you:-)
>
> Cheers,
> S.
>
> PS: We're just asking as it might help folks resolve or work
> around some potential repeated arguments on the topic. And we're > not saying whether we actually favour one or two port approaches:-) >
> [1]
> https://datatracker.ietf.org/doc/draft= -ietf-tsvwg-port-use/ballot/#ted-lemon

I don=E2=80=99t think we should prefer things either way. There is a= lot to say about the security of the web and the security of Internet emai= l, but I don=E2=80=99t think any of the issues these protocols have is root= ed in HTTP using two ports or SMTP using one.

With two ports, firewalls have an easier time either forcing or denying enc= ryption (assuming

Great point.
= =C2=A0
that the applications have fall-= back behavior), but firewalls have managed fine with SMTP for twenty years.= I don=E2=80=99t think this is an issue either way. Of course, assigning on= e port instead of two saves on a scarce resource, but that is not a securit= y consideration.

Yoav


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



--
=

Thanks,
= Kathleen
--001a11340c682988b70510699283-- From nobody Tue Mar 3 14:20:58 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69191ACDF1 for ; Tue, 3 Mar 2015 14:20:56 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3aGWUh6RAki for ; Tue, 3 Mar 2015 14:20:56 -0800 (PST) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) (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 03DF21ACDFE for ; Tue, 3 Mar 2015 14:20:54 -0800 (PST) Received: by oiav1 with SMTP id v1so2302079oia.9 for ; Tue, 03 Mar 2015 14:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uTLIUFkWIEolyZNu1d5PQ6lqYAOfaKlAMaPaL8uE2gU=; b=L/n4KtZDeTZcPEOphag+zy7/irWq4/TaMu1V9JA23Y3W16Klb6krKKlNdx0E9wVJbw TiAaWAmKwbbZanAYl+/h9PpS7zfK2TqEBx+Cv11tAanhURVz4W5g90ishla4IifqXZgA i8IBX7ELcfdKWGoVIvzdqFaax/Y1IrbnUmbAfs2omn78aHynIxFPJNNYs3lHMNwK7GU9 8jD18ZmNBu+H5LSaPS1oFsyQQW0aXWTvUEEr06gok+0rNvqPm9asiew7LyLn6C0n+k9w ZOL4oHcrMq2CxhPFz6LzdUwOTDXkQC7czu7Z45hWtzxyud65Zywpa8dTSK42HXVaOY/E i6mA== MIME-Version: 1.0 X-Received: by 10.202.75.8 with SMTP id y8mr858837oia.12.1425421208460; Tue, 03 Mar 2015 14:20:08 -0800 (PST) Received: by 10.202.225.135 with HTTP; Tue, 3 Mar 2015 14:20:08 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Mar 2015 14:20:08 -0800 Message-ID: From: Martin Thomson To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 22:20:57 -0000 On 3 March 2015 at 14:06, Yoav Nir wrote: > Of course, assigning one port instead of two saves on a scarce resource, but that is not a security consideration. Of course, you can save the same number of ports and more of other things by not having the non-secure option at all. From nobody Tue Mar 3 14:39:40 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561501A0262 for ; Tue, 3 Mar 2015 14:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJpKsKx61Ps2 for ; Tue, 3 Mar 2015 14:39:38 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C921A01D8 for ; Tue, 3 Mar 2015 14:39:38 -0800 (PST) Received: from [10.20.30.109] (142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t23MdUS1050922 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2015 15:39:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245] claimed to be [10.20.30.109] Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman X-Priority: 3 (Normal) In-Reply-To: Date: Tue, 3 Mar 2015 14:39:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stephen Farrell X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: saag@ietf.org Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 22:39:39 -0000 On Mar 3, 2015, at 1:56 PM, stephen.farrell@cs.tcd.ie wrote: > (one can muck up or do ok either way) Quite true. > and we also don't > think that the security area actually has a consensus that one > or two ports is generally "more secure". Also quite true. Thus, the document in question is quite wrong when it talks about = "insecure ports". What the document author calls "insecure ports" are in = fact ports that might have a STARTTLS-style upgrade on them. These are = discussed in a few places in the document, all with pejorative language. = Efforts to get this changed to reflect the lack of consensus got = confusing text added. On Mar 3, 2015, at 2:06 PM, Yoav Nir wrote: > Of course, assigning one port instead of two saves on a scarce = resource, but that is not a security consideration. Ports are not a scarce resource, and the document does not argument that = they are. That took *many* people to convince the author. --Paul Hoffman= From nobody Tue Mar 3 18:28:37 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231B11A8F41 for ; Tue, 3 Mar 2015 18:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybU_8wHfTtiB for ; Tue, 3 Mar 2015 18:28:34 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143BE1A1EFE for ; Tue, 3 Mar 2015 18:28:34 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5D6C020012; Tue, 3 Mar 2015 21:37:11 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id ACA5F63784; Tue, 3 Mar 2015 21:28:32 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 91B1E63770; Tue, 3 Mar 2015 21:28:32 -0500 (EST) From: Michael Richardson To: stephen.farrell@cs.tcd.ie In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: saag@ietf.org Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 02:28:36 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable stephen.farrell@cs.tcd.ie wrote: > A protocol that can run over TLS can be allocated two ports (like HTTP > with 80 and 443) or one port and use STARTTLS or similar. > Ted has a discuss [1] on a document about port number allocations and > asked if the security ADs cared. We think the answer is that we don't > (one can muck up or do ok either way) and we also don't think that the > security area actually has a consensus that one or two ports is I think that it's mostly about how firewall administrators and middle-box designers react. I think that two ports encourage the firewall maker/administrator to consid= er that they can (and should?) mess with the contents. As for SMTP doing fine --- in many cases firewalls have terminated SMTP at the firewall and then relayed things. Probably the rise of spam has changed the policy towards doing that over the decades, but I think it is instructi= ve to realize that whenever we have had different ports for encrypted and non-encrypted, the non-encrypted port has had it's traffic, uhm, molested by middle boxes. (dictionary.com: molested: 1. to bother, interfere with, or annoy. 2.to make indecent sexual advances to. 3. to assault sexually. Yes, I think it's the= right term) Speaking on this topic: had we a port-80 mechanism for HTTPS in 2.0, we wou= ld then very very urgently need to write a BCP on captive portals, because once the browser is sure that foo.com is secure, the captive portal will definitely be seen as a MITM, and nothing will work. If we anticipate that we'd like that option in the future, we need to only slightly urgently write that BCP and find a way to force it out there (as i= n, "ABC, XYZ Government and BIGCORP.com will not procure hotel rooms in hotels that are not RFC-CAPTIVE-PORTAL compliant"). We already see this as an impediment to DNSSEC deployment (because hijacking DNS is also done by really stupid captive portals). So: I am in favour of a single port for all new protocols. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVPZtzYCLcPvd0N1lAQJdZQf+O20qX4mggMKT1yr/K+ZMYcuHZAuoj7Df xHiaj0asWfiMV0kZ2H8HraHlrpsyX8aCSYOlh4DGdDe6/iSbt7aAi3TVydfl0pWn LqYu6CHAQs7spdrrP8kvHbzILDXLIkIgOU7bARqHeCLf3VLpOtE8dwf3xPi+5iT3 ln4fnTjNk8EXo7G6ZIPShR71IJ9w6G8EslA6Bzi4wXj/hEvK5Gpj7zwro6CHtIUs tyWzrztn7PxuS/YDiShN7d4ux5cAQFJp9jZfv2EInlZihoVpJvyGbwbJHbZhIisN iO0rpwTA0gPci2zPzT/GqplTlbxtRZOCRUO+n+RZ+X62Iti/xvJRNA== =cttc -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 3 23:26:44 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2561A06FD for ; Tue, 3 Mar 2015 23:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8Vug4MZWCXX for ; Tue, 3 Mar 2015 23:26:41 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (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 161841A06E9 for ; Tue, 3 Mar 2015 23:26:41 -0800 (PST) Received: by lbiz12 with SMTP id z12so14426217lbi.12 for ; Tue, 03 Mar 2015 23:26:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pNnM+wJ4TBI04sZ4OExnKIFppq+TduVmCApIlN09Yvo=; b=QjeBBoh4CevSXivv3dsEpsoVXt3YfYThVpX1lw+NW2wuMUTveUJ9zAMq4i8SeVgEJ2 DwkxYnmXuJ71BETv2DAh3XwaPEodJNNNF2b/PSrStvjm/fNlhOxF0CtBSKCw8YU28Luh quQNRnTtZAn1H2SJJDudsV5kDdJx5A/6tWmV2nyeltlufBs2NDRWH9baVbbrR/9COQ3m y9tRJRI5e59dbKQvZKOUAAHbs+ilq3IU6ZXlEX1WJJi4ttZCi5hl5Y88O7CbZoDyqqD1 gflxp6Rk9FOCMMNmTO5wtzlgTHxAJbbs+KZcYWYkLXOYbLJLiIbUCTpkGokiZLRlmU4e jJjg== X-Gm-Message-State: ALoCoQkf7qXE7ZxXY1B4Sm6ldEYmMSx/BO0z7QJYvsyX4TxFYkbBi6MWMiKqUcAp8R2OUJ9gl7XJ X-Received: by 10.152.6.2 with SMTP id w2mr2286725law.6.1425453999491; Tue, 03 Mar 2015 23:26:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.21.71 with HTTP; Tue, 3 Mar 2015 23:25:59 -0800 (PST) X-Originating-IP: [50.5.83.246] In-Reply-To: <23700.1425436112@sandelman.ca> References: <23700.1425436112@sandelman.ca> From: "Scott R. Corzine" Date: Wed, 4 Mar 2015 02:25:59 -0500 Message-ID: To: Michael Richardson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 07:26:42 -0000 On Tue, Mar 3, 2015 at 9:28 PM, Michael Richardson wrote: > I think that it's mostly about how firewall administrators and middle-box > designers react. End users, client and server administrators can benefit from encrypted-only ports when their policy is encryption only (more common beyond SMTP). Their traffic will be encrypted or will fail, they won't risk inadvertently falling back unnoticed to the cleartext connection that is the default state. Configuration errors, incorrect troubleshooting, bugs, and attackers all have potential to cause this. Example: Using only 636/LDAPS in a Directory Services configuration where we don't ever want non-encrypted traffic to be possible. Some software can't fully protect connections to 389/LDAP that "require" STARTTLS from clients with default configurations leaking non-encrypted data. Disabling 389 completely and only serving 636 at the server solves this risk (at the cost of failing incorrect configurations). A client only using 636 also has its traffic protected. It's much easier to verify that 389 isn't listening than that it's always handling STARTTLS correctly. So there can be benefits to having two ports (or encrypted-only ports). > I think that two ports encourage the firewall maker/administrator to consider > that they can (and should?) mess with the contents. > > As for SMTP doing fine --- in many cases firewalls have terminated SMTP at > the firewall and then relayed things. Probably the rise of spam has changed > the policy towards doing that over the decades, but I think it is instructive > to realize that whenever we have had different ports for encrypted and > non-encrypted, the non-encrypted port has had it's traffic, uhm, molested by > middle boxes. Looking at the list of two port protocols I'm pretty sure that this is wrong (excluding devices affecting ALL non-encrypted traffic including one port ones). -Scott- From nobody Wed Mar 4 10:17:25 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26801AC3C5 for ; Wed, 4 Mar 2015 10:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9W9cS9tv1EO for ; Wed, 4 Mar 2015 10:17:22 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A7DD1AC3B7 for ; Wed, 4 Mar 2015 10:17:22 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t24IGcZo000911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Mar 2015 10:16:38 -0800 (PST) Message-ID: <54F74C05.40104@isi.edu> Date: Wed, 04 Mar 2015 10:16:37 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: stephen.farrell@cs.tcd.ie, saag@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 18:17:24 -0000 Hi, all, It might be useful to also check RFC2595, Sec 7 on this point. I.e., that establishes rough consensus on this point (as it is an RFC of this area), and is PS. It would be especially helpful if anyone could point to something PS or higher that contradicts that analysis. Joe On 3/3/2015 1:56 PM, stephen.farrell@cs.tcd.ie wrote: > > Hiya, > > A protocol that can run over TLS can be allocated two ports > (like HTTP with 80 and 443) or one port and use STARTTLS or > similar. > > Ted has a discuss [1] on a document about port number allocations > and asked if the security ADs cared. We think the answer is that > we don't (one can muck up or do ok either way) and we also don't > think that the security area actually has a consensus that one > or two ports is generally "more secure". If you think we're wrong > and there is a clear consensus on then please respond in the next > day or so. If you don't think there's consensus silence is fine. > (As if that'll stop you:-) > > Cheers, > S. > > PS: We're just asking as it might help folks resolve or work > around some potential repeated arguments on the topic. And we're > not saying whether we actually favour one or two port approaches:-) > > [1] > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ballot/#ted-lemon > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Wed Mar 4 10:22:17 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B551AC3D8 for ; Wed, 4 Mar 2015 10:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDdaXRZ59Baq for ; Wed, 4 Mar 2015 10:22:14 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57811AC3D5 for ; Wed, 4 Mar 2015 10:22:14 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t24IKwvf002387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Mar 2015 10:20:59 -0800 (PST) Message-ID: <54F74D0A.1000208@isi.edu> Date: Wed, 04 Mar 2015 10:20:58 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Paul Hoffman , Stephen Farrell References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: saag@ietf.org Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 18:22:15 -0000 One point of clarification: On 3/3/2015 2:39 PM, Paul Hoffman wrote: > Ports are not a scarce resource, and the document does not argument > that they are. That took *many* people to convince the author. The current text, that incorporates LC comments, is here. I.e., this statement is correct in the use of the term "scarce" was changed to "limited" between versions -04 and -05. The basic statement about their being limited and needing conservation remains. Joe --- 6. Conservation Assigned port numbers are a limited resource that is globally shared by the entire Internet community. As of 2014, approximately 5850 TCP and 5570 UDP port numbers have been assigned out of a total range of 49151. As a result of past conservation, current port use is small and the current rate of assignment avoids the need for transition to larger number spaces. This conservation also helps avoid the need for IANA to rely on port number reclamation, which is practically impossible even though procedurally permitted [RFC6335]. --- From nobody Wed Mar 4 10:34:58 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF0F1AC3D0 for ; Wed, 4 Mar 2015 10:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NN9A5kb9M5kd for ; Wed, 4 Mar 2015 10:34:54 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FCCE1AC3B7 for ; Wed, 4 Mar 2015 10:34:54 -0800 (PST) Received: from [10.20.30.109] (142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t24IYqwi011219 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Mar 2015 11:34:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245] claimed to be [10.20.30.109] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: <54F74C05.40104@isi.edu> Date: Wed, 4 Mar 2015 10:34:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <15F03ED6-FB61-43D2-AEC7-6C45AA93ADA7@vpnc.org> References: <54F74C05.40104@isi.edu> To: saag X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 18:34:55 -0000 On Mar 4, 2015, at 10:16 AM, Joe Touch wrote: > It might be useful to also check RFC2595, Sec 7 on this point. Your reference to this document is disturbing for many reasons. > I.e., that establishes rough consensus on this point (as it is an RFC = of > this area), and is PS. Mainly that. RFC 2595 is about IMAP and POP (and the stillborn ACAP), = not about any other protocols. It is also 15 years old and security = operations have changed significantly since that time. If SAAG folks think that a bullet-by-bullet discussion of that section = is useful here on SAAG, I'm happy to engage. --Paul Hoffman= From nobody Wed Mar 4 10:44:13 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8E21A87F2 for ; Wed, 4 Mar 2015 10:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMrELr0DY5CB for ; Wed, 4 Mar 2015 10:44:10 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578BC1A1B8C for ; Wed, 4 Mar 2015 10:44:08 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t24IhaUk009105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Mar 2015 10:43:36 -0800 (PST) Message-ID: <54F75258.50103@isi.edu> Date: Wed, 04 Mar 2015 10:43:36 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Paul Hoffman , saag References: <54F74C05.40104@isi.edu> <15F03ED6-FB61-43D2-AEC7-6C45AA93ADA7@vpnc.org> In-Reply-To: <15F03ED6-FB61-43D2-AEC7-6C45AA93ADA7@vpnc.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 18:44:12 -0000 On 3/4/2015 10:34 AM, Paul Hoffman wrote: > On Mar 4, 2015, at 10:16 AM, Joe Touch wrote: >> It might be useful to also check RFC2595, Sec 7 on this point. > > Your reference to this document is disturbing for many reasons. > >> I.e., that establishes rough consensus on this point (as it is an RFC of >> this area), and is PS. > > Mainly that. RFC 2595 is about IMAP and POP (and the stillborn ACAP), not about any other protocols. The entire doc is about STARTTLS (the current PS protocol for using a single port for both secure and insecure variants concurrently). Sec 7 specifically addresses using STARTTLS for other protocols. > It is also 15 years old and security operations have changed > significantly since that time. And it also has not been revised or updated. If it's as inaccurate and outdated as you claim, it seems that this group has some very immediate work to do. Joe From nobody Wed Mar 4 10:46:35 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EFC1A8869 for ; Wed, 4 Mar 2015 10:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pAIq-bAWckw for ; Wed, 4 Mar 2015 10:46:32 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4C51A8727 for ; Wed, 4 Mar 2015 10:46:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2283; q=dns/txt; s=iport; t=1425494792; x=1426704392; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=L4B3gGtl+Gmf9ir+Ei9cYd1Y9XxcRjE++mOZymc7IC0=; b=F5DtL4H1JoDMjs2T3KOUjvrppH6cnZlm6PC4qLHQ5MQzqgNa6xJoo84E yKtoSdJz9p8KzdcYlCNWHxxDTiww3j8ZUHzl5LGWhpsXR9zjjFNJa6u7n y88lPFkqVcSX7zxnR84m1lufkqgVZ3DuX+P3Oq6xS5TlN8f9StulQVVGr Q=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CVBQBNUvdU/xbLJq1ag1Ragwu+CQyEYoENAoF6AQEBAQEBfIQQAQEEAQEBIEsKEQsYCRYLAgIJAwIBAgEVMAcMBgIBAYgrDb1gmiIBAQEBBgEBAQEBGQSLEoR1gmiBQwEEkWOBLlGFaYEagyWCMox3I4NvPTGCQwEBAQ X-IronPort-AV: E=Sophos;i="5.09,689,1418083200"; d="asc'?scan'208";a="365029707" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 04 Mar 2015 18:46:29 +0000 Received: from [10.61.107.12] (dhcp-10-61-107-12.cisco.com [10.61.107.12]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t24IkTB1032058; Wed, 4 Mar 2015 18:46:29 GMT Message-ID: <54F75300.3060509@cisco.com> Date: Wed, 04 Mar 2015 19:46:24 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: stephen.farrell@cs.tcd.ie, saag@ietf.org References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="plunBsBi2Npjwsf84ll6IB4hkbiFhLwCF" Archived-At: Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 18:46:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --plunBsBi2Npjwsf84ll6IB4hkbiFhLwCF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stephen, Yoav raises a good point, but I think the major piece of advice is this: know what to expect before you connect: avoid downgrade attacks. Eliot On 3/3/15 10:56 PM, stephen.farrell@cs.tcd.ie wrote: > Hiya, > > A protocol that can run over TLS can be allocated two ports > (like HTTP with 80 and 443) or one port and use STARTTLS or > similar. > > Ted has a discuss [1] on a document about port number allocations > and asked if the security ADs cared. We think the answer is that > we don't (one can muck up or do ok either way) and we also don't > think that the security area actually has a consensus that one > or two ports is generally "more secure". If you think we're wrong > and there is a clear consensus on then please respond in the next > day or so. If you don't think there's consensus silence is fine. > (As if that'll stop you:-) > > Cheers, > S. > > PS: We're just asking as it might help folks resolve or work > around some potential repeated arguments on the topic. And we're > not saying whether we actually favour one or two port approaches:-) > > [1] > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ballot/#ted-= lemon > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --plunBsBi2Npjwsf84ll6IB4hkbiFhLwCF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJU91MEAAoJEIe2a0bZ0nozTtcIAKfMZqIiDl7zgTkt6voKSzSq w1qWB1pAK/TFSJJQgtVggfP8oUPwHbRz0ObV9OeEzT2CPWIFUl1mY6JOwvcjmWVl rL8y5I69CBIGKM4wA8RRoLTBay2DTutmZSKZ07DkILETfKP7POeRc0NCCi7blXgq RavwpRTvrX/B8QSYhkQq+I+Cta8tA7JeVatc0cvn4CRE+Lp43IA9Z0vj4XYXSMQi zAQGWssk5mJ4iNII5F0trOnicIqFv362LcvPpZM9J+nfkDskZud/PLfecEK2ssfI /bKs/Mv61QH1InGxAUKwEzjdhLNbn83sRA5IFyOmzYGyh7qEW4K5+Cjt//FOJI4= =Aocm -----END PGP SIGNATURE----- --plunBsBi2Npjwsf84ll6IB4hkbiFhLwCF-- From nobody Wed Mar 4 10:50:37 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E811A872A for ; Wed, 4 Mar 2015 10:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Aw6MLHOIqPW for ; Wed, 4 Mar 2015 10:50:35 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F01E1A6F1D for ; Wed, 4 Mar 2015 10:50:35 -0800 (PST) Received: from [10.20.30.109] (142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t24IoY4W011713 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2015 11:50:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245] claimed to be [10.20.30.109] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: <54F75258.50103@isi.edu> Date: Wed, 4 Mar 2015 10:50:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54F74C05.40104@isi.edu> <15F03ED6-FB61-43D2-AEC7-6C45AA93ADA7@vpnc.org> <54F75258.50103@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: saag Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 18:50:36 -0000 On Mar 4, 2015, at 10:43 AM, Joe Touch wrote: > If it's as inaccurate and outdated as you claim, it seems that this > group has some very immediate work to do. If you're the only person who cares about this RFC, or even remembers = that it exists, then "very immediate" seems a bit hyperbolic. FWIW, I was one of the contributors to the RFC in question, so saying = that it is mostly forgotten is not an insult to the work we did then. --Paul Hoffman From nobody Wed Mar 4 10:57:14 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4761A1ACE18 for ; Wed, 4 Mar 2015 10:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRFo_Or4MlNU for ; Wed, 4 Mar 2015 10:57:12 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB6771ACE11 for ; Wed, 4 Mar 2015 10:57:11 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t24IugUj013830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Mar 2015 10:56:42 -0800 (PST) Message-ID: <54F75569.4020203@isi.edu> Date: Wed, 04 Mar 2015 10:56:41 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Paul Hoffman References: <54F74C05.40104@isi.edu> <15F03ED6-FB61-43D2-AEC7-6C45AA93ADA7@vpnc.org> <54F75258.50103@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: saag Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 18:57:13 -0000 On 3/4/2015 10:50 AM, Paul Hoffman wrote: > On Mar 4, 2015, at 10:43 AM, Joe Touch wrote: >> If it's as inaccurate and outdated as you claim, it seems that this >> group has some very immediate work to do. > > If you're the only person who cares about this RFC, or even remembers > that it exists, then "very immediate" seems a bit hyperbolic. It's PS and it's a security area doc. If it's not cared about or recalled, perhaps it might be useful for SAAG to consider a Roadmap doc, as was done for TCP in transport. I would hope that SAAG would focus "immediately" on widely deployed security protocols that are inaccurate and outdated as a matter of course. But that's just me. YMMV. Joe From nobody Wed Mar 4 11:25:18 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F391A87AF for ; Wed, 4 Mar 2015 11:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FiV8ULjo70j for ; Wed, 4 Mar 2015 11:25:12 -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 1DADD1A8762 for ; Wed, 4 Mar 2015 11:25:11 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6FA4F282FC0; Wed, 4 Mar 2015 19:25:10 +0000 (UTC) Date: Wed, 4 Mar 2015 19:25:10 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150304192510.GZ1260@mournblade.imrryr.org> References: <54F74C05.40104@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54F74C05.40104@isi.edu> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 19:25:16 -0000 On Wed, Mar 04, 2015 at 10:16:37AM -0800, Joe Touch wrote: > It might be useful to also check RFC2595, Sec 7 on this point. > > I.e., that establishes rough consensus on this point (as it is an RFC of > this area), and is PS. > > It would be especially helpful if anyone could point to something PS or > higher that contradicts that analysis. The main thing that resonates from Section 7 is the comment abourt URI schemes. When each client knows whether TLS channel security is or is not appopriate for a particular service, but some location service needs to return a usable URI that works for multiple clients, things work better when channel security is not explicitly part of the URI. Thus "imap://" or "ldap://" is in some cases better than "imaps://" or "ldaps://", because the client using the URI can then apply appropriate policy. For services with strict separation of TLS and non TLS by port and URI scheme, the location service cannot return URIs that are channel security neutral, and clients then have to request a security policy specific version of the service location. Of course sometimes the service dispensing the URI knows more about which security policy is appropriate than its clients. What we're missing is URI schemes that mandate the use of TLS on "STARTTLS" ports. For example: ldaps://ldap.example.com:398/... would not work because "ldaps" is LDAP inside SSL *without* STARTTLS. On the other hand: ldap://ldap.example.com:389/ cannot express mandatory TLS, and leaves it up to the client (sometimes that's the right thing to do). If there were a URI scheme for required STARTTLS: ldaptls://ldap.example.com:389/ then the consolidated port would provide maximum flexibility: ldap://ldap.example.com:389/ (URI consumer decides) ldaptls://ldap.example.com:389/ (URI producer decides) with split ports the decision is always at the URI producer. For example, because HTTP/HTTPS have split ports, the proposed URI DNS RRtype has messy security interactions with HTTP. Unlike "A" records, the URI payload carries security policy via the URI scheme. (Redirection would still merit appropriate security considerations, but the hypothetical picture is simpler). -- Viktor. From nobody Wed Mar 4 11:37:48 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334B81A7017 for ; Wed, 4 Mar 2015 11:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79DVOnV94C9r for ; Wed, 4 Mar 2015 11:37:41 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB75B1A1A62 for ; Wed, 4 Mar 2015 11:37:41 -0800 (PST) Received: from [10.20.30.109] (142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t24Jbe1P015638 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Mar 2015 12:37:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245] claimed to be [10.20.30.109] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: <20150304192510.GZ1260@mournblade.imrryr.org> Date: Wed, 4 Mar 2015 11:37:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <259F4708-F619-48A4-8E86-E23ADFCFCE24@vpnc.org> References: <54F74C05.40104@isi.edu> <20150304192510.GZ1260@mournblade.imrryr.org> To: saag@ietf.org X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 19:37:43 -0000 On Mar 4, 2015, at 11:25 AM, Viktor Dukhovni = wrote: > The main thing that resonates from Section 7 is the comment abourt > URI schemes. =20 Note that this not fully relevant to this thread, because most protocols = that use ports don't have URI schemes. Your observations on the problems = with foo: vs. foos: are good, but not as a reason for suggesting to = application developers to not have a second port. Also note that some applications that resolve pop: and imap: URI = actually try to do STARTTLS regardless. This should be up to the = application specifications and developers, not the port list = maintainers. --Paul Hoffman= From nobody Wed Mar 4 12:22:11 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C911ACE68 for ; Wed, 4 Mar 2015 12:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.899 X-Spam-Level: X-Spam-Status: No, score=-103.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCqXRPJkTCA3 for ; Wed, 4 Mar 2015 12:22:08 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id A6E111ACE65 for ; Wed, 4 Mar 2015 12:22:07 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 37C339A4042 for ; Wed, 4 Mar 2015 15:21:57 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id mpjnjfJPs0Ey for ; Wed, 4 Mar 2015 15:21:35 -0500 (EST) Received: from [10.0.1.3] (pfs0.iad.rg.net [198.180.150.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id ECC979A402E for ; Wed, 4 Mar 2015 15:21:34 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary=Apple-Mail-113-516694373 Date: Wed, 4 Mar 2015 15:21:32 -0500 Message-Id: To: IETF SAAG Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: Subject: [saag] Call for Papers: IAB/ISOC Workshop on Coordinating Attack Response at Internet Scale X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 20:22:10 -0000 --Apple-Mail-113-516694373 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Internet Architecture Board (IAB) and Internet Society (ISOC) workshop = on Coordinating Attack Response at Internet Scale (CARIS) June 19, 2015, Intercontinental Hotel in Berlin, hosted by the 27th = annual FIRST Conference Workshop Information: https://www.iab.org/activities/workshops/caris/=20 Numerous incident response efforts exist to mitigate the effects of = attacks. Some are operator driven focused on specific attack types, = while others are closed analysis and sharing groups spanning many attack = types. Many of the operator driven models work with members to mitigate = the effects of such attacks for all users, but how to contribute = information to these efforts is not always known or easy to discover. = Sharing within closed community analysis centers is only practical for = very large organizations as a result of resource requirements even to be = able to use shared data. Without coordination, these efforts are not = only duplicated, but leave out protections for small and medium sized = organizations. These organizations may be part of the supply chain for = larger organizations, a common pathway for successful attacks. This workshop aims to bring together operators, researchers, CSIRT team = members, service providers, vendors, information sharing and analysis = center members to discuss approaches to coordinate attack response at = Internet scale.=20 The day-long workshop will include a mix of invited and selected = speakers with opportunities to collaborate throughout, taking full = advantage of the tremendous value of having these diverse communities = with common goals in one room. Submission Instructions: Attendance at the workshop is by invitation only. There is no fee to = attend the workshop. For existing attack-mitigation working groups, the survey at = https://internetsociety2.wufoo.com/forms/caris-workshop-organisation-templ= ate/ should be completed by those organizations whose mitigation efforts = or use case analyses apply. The data gathered through this = questionnaire, including how to participate or contribute to your attack = mitigation working group, will be shared with all of the participants at = the workshop to better enable collaboration with your effort.=20 Alternatively, submit a 2-page research paper that includes some key = insight or challenge relevant to the broader group. This may include = research topics around attack mitigation or information = sharing/exchange, success stories from your CSIRT, lessons learned, or a = deep dive on a particular topic such as privacy or trust. Submissions accepted at: = https://easychair.org/conferences/?conf=3Dcaris2015 Final Submission Deadline: 3 April 2015 Notification Deadline: 1 May 2015 Workshop Date: 19 June 2015 All attendees are required to complete the survey or submit a 2-page = research paper to the CARIS program committee via EasyChair. Accepted = submissions will be published on the IAB website at:=20 https://www.iab.org/activities/workshops/caris/=20 Attendees will be selected based on these submissions to ensure the = workshop will be beneficial to all and has the potential to impact the = coordination of attack response at Internet scale. Sponsored by the Internet Architecture Board and the Internet Society. http://www.iab.org/ http://www.internetsociety.org/ --Apple-Mail-113-516694373 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Internet Architecture Board (IAB) and Internet Society = (ISOC) workshop on
Coordinating = Attack Response at Internet Scale (CARIS)

June 19, 2015, Intercontinental = Hotel in Berlin, hosted by the 27th annual FIRST = Conference


Numerous incident response efforts = exist to mitigate the effects of attacks.  Some = are  operator driven focused on specific attack types, while = others are closed analysis and sharing groups spanning many attack = types.  Many of the operator driven models work with members to = mitigate the effects of such attacks for all users, but how to = contribute information to these efforts is not always known or easy to = discover.  Sharing within closed community analysis centers is only = practical for very large organizations as a result of resource = requirements even to be able to use shared data.  Without = coordination, these efforts are not only duplicated, but leave out = protections for small and medium sized organizations.  These = organizations may be part of the supply chain for larger organizations, = a common pathway for successful attacks.

This = workshop aims to bring together operators, researchers, CSIRT team = members, service providers, vendors, information sharing and analysis = center members to discuss approaches to coordinate attack response at = Internet scale. 

The day-long workshop will include a mix = of invited and selected speakers with opportunities to collaborate = throughout, taking full advantage of the tremendous value of having = these diverse communities with common goals in one room.


Submission Instructions:

Attendance at the workshop is by invitation = only. There is no fee to attend the workshop.

For existing = attack-mitigation working groups, the survey at

https://internetsociety2.wufoo.com/forms/caris-workshop-= organisation-template/ should be completed by those = organizations whose mitigation efforts or use case analyses apply. The = data gathered through this questionnaire, including how to participate = or contribute to your attack mitigation working group, will be shared = with all of the participants at the workshop to better enable = collaboration with your effort. 

Alternatively, submit a 2-page = research paper that includes some key insight or challenge relevant to = the broader group.  This may include research topics around attack = mitigation or information sharing/exchange, success stories from your = CSIRT, lessons learned, or a deep dive on a particular topic such as = privacy or trust.

Submissions accepted at: https://easychair.org/conferences/?conf=3Dcaris20= 15
Final = Submission Deadline: 3 April 2015
Notification Deadline: 1 May 2015
Workshop Date: = 19 June 2015

All = attendees are required to complete the survey or submit a 2-page = research paper to the CARIS program committee via EasyChair.  = Accepted submissions will be published on the IAB website = at: 

Attendees will be selected = based on these submissions to ensure the workshop will be beneficial to = all and has the potential to impact the coordination of attack response = at Internet scale.

Sponsored by the Internet Architecture Board = and the Internet Society.

=

= --Apple-Mail-113-516694373-- From nobody Wed Mar 4 15:56:25 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804651A00C3 for ; Wed, 4 Mar 2015 15:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jg3wls91XmeL for ; Wed, 4 Mar 2015 15:56:23 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9BAF1A00F6 for ; Wed, 4 Mar 2015 15:56:23 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id t24NtwCO014917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Mar 2015 15:55:58 -0800 (PST) Message-ID: <54F79B8D.8080101@isi.edu> Date: Wed, 04 Mar 2015 15:55:57 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kathleen Moriarty , Yoav Nir References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 23:56:24 -0000 On 3/3/2015 2:08 PM, Kathleen Moriarty wrote: > > > On Tue, Mar 3, 2015 at 5:06 PM, Yoav Nir > wrote: > > With two ports, firewalls have an easier time either forcing or > denying encryption (assuming > > Great point. How do you know what's on either port until you look with DPI? Multiple ports used this way just propagates the myth that blocking a port is a type of security. Joe From nobody Wed Mar 4 15:59:58 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AA61A0113 for ; Wed, 4 Mar 2015 15:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_F3sUCsA5Oz for ; Wed, 4 Mar 2015 15:59:55 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4FCF1A00C3 for ; Wed, 4 Mar 2015 15:59:55 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t24NxiVm018554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Mar 2015 15:59:45 -0800 (PST) Message-ID: <54F79C70.1070809@isi.edu> Date: Wed, 04 Mar 2015 15:59:44 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Scott R. Corzine" , Michael Richardson References: <23700.1425436112@sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 23:59:56 -0000 On 3/3/2015 11:25 PM, Scott R. Corzine wrote: > On Tue, Mar 3, 2015 at 9:28 PM, Michael Richardson > wrote: >> I think that it's mostly about how firewall administrators and middle-box >> designers react. > > End users, client and server administrators can benefit from > encrypted-only ports when their policy is encryption only (more common > beyond SMTP). Their traffic will be encrypted or will fail, they won't > risk inadvertently falling back unnoticed to the cleartext connection > that is the default state. Configuration errors, incorrect > troubleshooting, bugs, and attackers all have potential to cause this. Using a single port doesn't prohibit this requirement. A client that doesn't want a downgrade attack simply doesn't accept that as a response. A server that doesn't want to support "no encryption" doesn't allow it. Either way, it's all just configuration. Anything can be configured incorrectly. Joe From nobody Wed Mar 4 16:24:55 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C241A01D8 for ; Wed, 4 Mar 2015 16:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EDZ4c2rTTcg for ; Wed, 4 Mar 2015 16:24:49 -0800 (PST) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (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 4FA7F1A0105 for ; Wed, 4 Mar 2015 16:24:49 -0800 (PST) Received: by qgaj5 with SMTP id j5so2727558qga.12 for ; Wed, 04 Mar 2015 16:24:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PaM7FxnL3mwyZkoLxzR9jSMWUqPiI3yq8Bj3JzxO9hA=; b=GqUGxx764weieIqK4yzWRDXopYVm+LA6TgLLuaFMgQyl6XcZfFydF77X2AHxcrZWrI CJm9ViD+fgoh01nGTo4EbvHNBb/zDbzMG+7fWqXENT4/Ayy2M/WIL1NNdegHzazLegYW 2qQHrL5IbIXs73QkabfHFhtHJn3qoOV8giwIIArs7q5tRFzY/jxEqGWoKaYD8JMTfZKl ff8pNxz9VxbVst91gvefpCmbY7b+pXZkh/2m5BIR/QwUBaVllwYjmlXIUZIrRT+OvfTm RcQgjcG7pA2DlZWWcOZyRn5b5Wm2z2ZyxN0Gn4zTrENpAW+CE0sqne97/lAbCmz0Buym eTXw== X-Gm-Message-State: ALoCoQkCjJ3H8nLhYHaMhFdUzk434GBIOxO2ZbqDpZDTyg9McZA5UIBU5tLo1GUDZyoy2vQajZdU MIME-Version: 1.0 X-Received: by 10.55.15.25 with SMTP id z25mr12429530qkg.87.1425515088604; Wed, 04 Mar 2015 16:24:48 -0800 (PST) Received: by 10.96.121.104 with HTTP; Wed, 4 Mar 2015 16:24:48 -0800 (PST) X-Originating-IP: [50.206.82.175] In-Reply-To: <54F79C70.1070809@isi.edu> References: <23700.1425436112@sandelman.ca> <54F79C70.1070809@isi.edu> Date: Wed, 4 Mar 2015 16:24:48 -0800 Message-ID: From: Joseph Salowey To: Joe Touch Content-Type: multipart/alternative; boundary=001a1147537e7a83b605107f98a1 Archived-At: Cc: "Scott R. Corzine" , Michael Richardson , "saag@ietf.org" Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 00:24:54 -0000 --001a1147537e7a83b605107f98a1 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 4, 2015 at 3:59 PM, Joe Touch wrote: > > > On 3/3/2015 11:25 PM, Scott R. Corzine wrote: > > On Tue, Mar 3, 2015 at 9:28 PM, Michael Richardson > > wrote: > >> I think that it's mostly about how firewall administrators and > middle-box > >> designers react. > > > > End users, client and server administrators can benefit from > > encrypted-only ports when their policy is encryption only (more common > > beyond SMTP). Their traffic will be encrypted or will fail, they won't > > risk inadvertently falling back unnoticed to the cleartext connection > > that is the default state. Configuration errors, incorrect > > troubleshooting, bugs, and attackers all have potential to cause this. > > Using a single port doesn't prohibit this requirement. A client that > doesn't want a downgrade attack simply doesn't accept that as a > response. A server that doesn't want to support "no encryption" doesn't > allow it. > > Either way, it's all just configuration. Anything can be configured > incorrectly. > > [JAS] I've definitely seen many instances where the insecure port is left open (and allowed through the firewall) because of bad configuration. However, I see more implementation issues with changing the security parameters on an existing connection. Configuration problems are easier to correct than implementation problems. This is somewhat orthogonal to the one port/two port discussion since you can try to change security parameters on an existing connection in either case. The single port case always has this possibility. If you're careful then its often not difficult to get right, but we are not always careful. > Joe > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a1147537e7a83b605107f98a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 4, 2015 at 3:59 PM, Joe Touch <touch@isi.edu> wr= ote:


On 3/3/2015 11:25 PM, Scott R. Corzine wrote:
> On Tue, Mar 3, 2015 at 9:28 PM, Michael Richardson
> <mcr+ietf@sandelman.ca> wrote:
>> I think that it's mostly about how firewall administrators and= middle-box
>> designers react.
>
> End users, client and server administrators can benefit from
> encrypted-only ports when their policy is encryption only (more common=
> beyond SMTP). Their traffic will be encrypted or will fail, they won&#= 39;t
> risk inadvertently falling back unnoticed to the cleartext connection<= br> > that is the default state. Configuration errors, incorrect
> troubleshooting, bugs, and attackers all have potential to cause this.=

Using a single port doesn't prohibit this requirement. A client = that
doesn't want a downgrade attack simply doesn't accept that as a
response. A server that doesn't want to support "no encryption&quo= t; doesn't
allow it.

Either way, it's all just configuration. Anything can be configured
incorrectly.


[JAS] I've definitely seen many instances where = the insecure port is left open (and allowed through the firewall) because o= f bad configuration.=C2=A0 However, I see more implementation issues with c= hanging the security parameters on an existing connection. Configuration pr= oblems are easier to correct than implementation problems.=C2=A0 This is so= mewhat orthogonal to the one port/two port discussion since you can try to = change security parameters on an existing connection in either case.=C2=A0 = The single port case always has this possibility.=C2=A0 If you're caref= ul then its often not difficult to get right, but we are not always careful= .=C2=A0
=C2=A0
Joe



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

--001a1147537e7a83b605107f98a1-- From nobody Wed Mar 4 22:27:28 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5346D1B29C2 for ; Wed, 4 Mar 2015 22:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDgMKaTWhn2W for ; Wed, 4 Mar 2015 22:27:26 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69841B29C1 for ; Wed, 4 Mar 2015 22:27:25 -0800 (PST) Received: by wggx12 with SMTP id x12so51271606wgg.6 for ; Wed, 04 Mar 2015 22:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/tVPjAYqVZ2Sf3yLUXTzZlkZGcnMqPZagL5B6uenJq4=; b=emWxK3uIFqpryDLiXWQG31t0epMa2EvvfAu6kUotXqsjVMi1SxNIIhpDp/3Hx2HMEz dZz5crNx/ijjuhM/fE4Qz3oTPYQ0RhKHmQwFR7+INhtn2mJs9DjSIl1/f7hOe5VD1PyD JhQl54iyBJR1euRgvw6HFElLHvk9aoNHc2jC/XtusRAAfc7vaodxOKisfdUgNFJwKOAc kGuIiL74Fp42JDn5+5dUfbfjwi86CuD0tpi+C6c6MQIE5EjgaXzOpSCawbJiLXRaRe46 8gtBhcL7qGTBd+EFy0BITDobHOTNsCCm5hidNw3giaa/rrkypu23tLwLJZv/UP3yNvDl gvVg== X-Received: by 10.181.5.43 with SMTP id cj11mr61363031wid.61.1425536844626; Wed, 04 Mar 2015 22:27:24 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by mx.google.com with ESMTPSA id gi9sm13098781wib.21.2015.03.04.22.27.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Mar 2015 22:27:23 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <54F79B8D.8080101@isi.edu> Date: Thu, 5 Mar 2015 08:27:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54F79B8D.8080101@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 06:27:27 -0000 > On Mar 5, 2015, at 1:55 AM, Joe Touch wrote: >=20 >=20 >=20 > On 3/3/2015 2:08 PM, Kathleen Moriarty wrote: >>=20 >>=20 >> On Tue, Mar 3, 2015 at 5:06 PM, Yoav Nir > > wrote: >>=20 >> With two ports, firewalls have an easier time either forcing or >> denying encryption (assuming=20 >>=20 >> Great point. >=20 > How do you know what's on either port until you look with DPI? You don=92t. But it does block misconfigured endpoints from = communicating in the way the firewall administrator doesn=92t want. = Malicious actors can try to tunnel their traffic over DNS queries or = ICMP or TCP port 443. Blocking a port is about enforcing correct = configuration, not about preventing the communications altogether. Yoav From nobody Wed Mar 4 23:19:55 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D6E1B2A04 for ; Wed, 4 Mar 2015 23:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRRTmjOKbxCa for ; Wed, 4 Mar 2015 23:19:51 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5C441B29FE for ; Wed, 4 Mar 2015 23:19:51 -0800 (PST) Received: from [192.168.1.11] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id t257JH5l011030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Mar 2015 23:19:23 -0800 (PST) Message-ID: <54F80375.9060802@isi.edu> Date: Wed, 04 Mar 2015 23:19:17 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yoav Nir References: <54F79B8D.8080101@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 07:19:53 -0000 On 3/4/2015 10:27 PM, Yoav Nir wrote: > >> On Mar 5, 2015, at 1:55 AM, Joe Touch wrote: >> >> >> >> On 3/3/2015 2:08 PM, Kathleen Moriarty wrote: >>> >>> >>> On Tue, Mar 3, 2015 at 5:06 PM, Yoav Nir >> > wrote: >>> >>> With two ports, firewalls have an easier time either forcing or >>> denying encryption (assuming >>> >>> Great point. >> >> How do you know what's on either port until you look with DPI? > > You dont. But it does block misconfigured endpoints from > communicating in the way the firewall administrator doesnt want. The only "way" port blocking blocks is the use of default ports. With dynamic DNS and other endpoint coordination tools, that's not a significant impediment to consenting endpoints that want to get around a blocked port. > Malicious actors can try to tunnel their traffic over DNS queries or > ICMP or TCP port 443. Actors can - and do - do this already. They're not all malicious just because they don't use ports in the default way. Registered ports are only the default; ultimately, ports are meaningful only to the endpoints. > Blocking a port is about enforcing correct > configuration, not about preventing the communications altogether. The only communication blocked by ports is that which makes the default assumptions. The real issue, AFAICT, is why an insecure port is even appropriate anymore. Performance is a consideration, but consenting endpoints should be able to figure that out via negotiation. Joe From nobody Wed Mar 4 23:29:26 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211971A03F9 for ; Wed, 4 Mar 2015 23:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgKbrrZzhUTi for ; Wed, 4 Mar 2015 23:29:24 -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 141871A0395 for ; Wed, 4 Mar 2015 23:29:23 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D8F2F282FCC; Thu, 5 Mar 2015 07:29:22 +0000 (UTC) Date: Thu, 5 Mar 2015 07:29:22 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150305072922.GM1260@mournblade.imrryr.org> References: <54F79B8D.8080101@isi.edu> <54F80375.9060802@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54F80375.9060802@isi.edu> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 07:29:25 -0000 On Wed, Mar 04, 2015 at 11:19:17PM -0800, Joe Touch wrote: > The real issue, AFAICT, is why an insecure port is even appropriate > anymore. Performance is a consideration, but consenting endpoints should > be able to figure that out via negotiation. Because the "secure" port is often unusable when the security requirements are all or nothing, as we're well aware from the opportunistic security discussions. The only way to make the "secure" port be the only one, is to in fact relax the definition of security to subsume a range of security levels from (possibly cleartext) to fully authenticated and encrypted. The cleartext outcome might be possible by skipping STARTTLS, or by negotiating a NULL cipher. Or might be prohibited but authenticaiton would still be optional. So for most applications the only way to have just one port is to drink the opportunistic security cool-aid. Only a small fraction of applications which must be unconditionally fully protected for all peers can be always "secure". -- Viktor. From nobody Thu Mar 5 09:20:49 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E6B1A1EF1 for ; Thu, 5 Mar 2015 09:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ytMQ_WyTFDu for ; Thu, 5 Mar 2015 09:20:47 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C6F91A212D for ; Thu, 5 Mar 2015 09:14:44 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t25HEhcH032630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 5 Mar 2015 12:14:43 -0500 Received: from bofh.nohats.ca (vpn-234-103.phx2.redhat.com [10.3.234.103]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t25HEh67023151 for ; Thu, 5 Mar 2015 12:14:43 -0500 Message-ID: <54F88F03.4040005@redhat.com> Date: Thu, 05 Mar 2015 12:14:43 -0500 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: saag@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 17:20:48 -0000 On 03/03/2015 05:20 PM, Martin Thomson wrote: > On 3 March 2015 at 14:06, Yoav Nir wrote: >> Of course, assigning one port instead of two saves on a scarce resource, but that is not a security consideration. > > Of course, you can save the same number of ports and more of other > things by not having the non-secure option at all. +1 I think someone on thie list wrote some RFC about pervasive monitoring and desiring crypto for all new protocols This should be a legacy problem only. Paul From nobody Thu Mar 5 09:39:17 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA6D1A1BCB for ; Thu, 5 Mar 2015 09:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nir_hHSXDnZN for ; Thu, 5 Mar 2015 09:39:15 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D41B1A1B07 for ; Thu, 5 Mar 2015 09:39:15 -0800 (PST) Received: from [192.168.1.11] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id t25HcvX0011357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Mar 2015 09:39:00 -0800 (PST) Message-ID: <54F894B2.8090603@isi.edu> Date: Thu, 05 Mar 2015 09:38:58 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Paul Wouters , saag@ietf.org References: <54F88F03.4040005@redhat.com> In-Reply-To: <54F88F03.4040005@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 17:39:16 -0000 On 3/5/2015 9:14 AM, Paul Wouters wrote: > On 03/03/2015 05:20 PM, Martin Thomson wrote: >> On 3 March 2015 at 14:06, Yoav Nir wrote: >>> Of course, assigning one port instead of two saves on a scarce resource, but that is not a security consideration. >> >> Of course, you can save the same number of ports and more of other >> things by not having the non-secure option at all. > > +1 > > I think someone on thie list wrote some RFC about pervasive monitoring and desiring crypto for all new protocols > > This should be a legacy problem only. FWIW, there are three issues with legacy protocols: 1. a protocol that is currently unprotected and asks for a new protected port there are no concerns here, AFAICT 2. a protocol that is currently protected and asks for a new unprotected port there ought to be substantial concerns here, and AFAICT this ought to be strongly discouraged 3. a protocol that is currently protected one way, and asks for a new protected port for a different method in general, ports should include enough support for version negotiation that this should not be needed however, if there's a substantive security concern, it also ought to be no issue (i.e., OK) So I don't think there should be any legacy issues either. Joe From nobody Thu Mar 5 16:47:21 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173041A884B for ; Thu, 5 Mar 2015 16:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.267 X-Spam-Level: X-Spam-Status: No, score=-100.267 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrQdk-rDAHNv for ; Thu, 5 Mar 2015 16:47:15 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 8194E1A8A25 for ; Thu, 5 Mar 2015 16:47:15 -0800 (PST) Received: (qmail 26125 invoked by uid 0); 6 Mar 2015 00:47:08 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy6.mail.unifiedlayer.com with SMTP; 6 Mar 2015 00:47:08 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id 00mw1q0182UhLwi010n101; Thu, 05 Mar 2015 17:47:05 -0700 X-Authority-Analysis: v=2.1 cv=bPeFfpOZ c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=cmpKiNEfRqcA:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=SojtekhEa5wA:10 a=emO1SXQWCLwA:10 a=L6IORkpKAAAA:8 a=WcQ5s9TIAAAA:8 a=Q9mbptxJexHBIqSZomAA:9 a=QEXdDO2ut3YA:10 a=bKdYVz2rPwIA:10 a=uTVMEwClKE8A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=jCICH0lWt8TuPAHlFeQ/8h5YcWEptxmi/DQwEpZK3IE=; b=Ut3qdjtceK6vfAHbTgP0NeN1leEe12eh9ia0YJwq+PiELrej4gVTUoYl0FlXGR2eevA6o+jiNiN00mhHyb3whGkc2eAb0oiAz1zKY4J2QEUcCeZ+oYwD3D8uhSt8fhOU; Received: from [216.113.160.66] (port=34667 helo=[10.244.137.7]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YTfof-0002xY-6M for saag@ietf.org; Thu, 05 Mar 2015 17:08:33 -0700 Message-ID: <54F8EFFA.9070807@KingsMountain.com> Date: Thu, 05 Mar 2015 16:08:26 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: IETF Security Area Advisory Group Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.160.66 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 00:47:19 -0000 Overall, in summary, I remain in the single-port camp. FWIW, we IETF have been struggling with this topic since at least 1996/1997 when the original LDAP/SMTP/IMAP/POP STARTTLS work began, and there's detailed discussions in the various archives (where they still exist). E.g., we (RLBob and I) made arguments for this (single-port per app protocol, and policy signaling) back in the early "STARTTLS" days [1][2] on ietf-asid@umich.edu. Also, it was discussed on ietf-apps-tls@imc.org, eg.. Serious design flaw in STARTLS documents http://www.imc.org/ietf-apps-tls/mail-archive/msg00155.html Man In The Middle Attacks and STARTTLS http://www.imc.org/ietf-apps-tls/mail-archive/msg00259.html (..there's likely yet more..) MITM and downgrade attacks are a threat whether one is using a {secure, nonsecure} port pair or a single port, so I don't buy that argument as a major reason to disfavor a single port approach. As has been noted in this thread here on this list, a non-trivial aspect of the problem is signaling security policy. That's discussed some in [3] (it leverages Chris Newman's work) though unfortunately (in some ways) the proposal didn't get traction. =JeffH [1] [unfortunately, AFAICT, there are no online archives of the ietf-asid@umich.edu list, so here's copies-by-value..] Subject: LDAP URLs and security From: Jeff Hodges Date: Tue, 06 May 1997 14:38:12 -0700 To: ietf-asid@umich.edu Cc: bob.morgan@stanford.edu, Jeff.Hodges@stanford.edu [ The following is a proposal about handling of security in LDAP URLs that is clearly applicable to all URL schemes, not just LDAP. We will be promoting it as such in the appropriate venues. There is also a separate rant to follow about how this relates to LDAP over TLS. - RL "Bob" and Jeff ] Here are some comments on the LDAP URL spec, related to URLs and security. In the "Security Considerations" section it says: The LDAP URL format does not provide a way to specify credentials to use when resolving the URL. Therefore, it is expected that such requests will be unauthenticated, unless some out-of-band mechanism is used. We think the spec can, and must, do better than this. The assumption that accesses based on URLs are unauthenticated fails to meet obvious requirements, and in fact doesn't consider the capabilities of TLS as embedded in the ldaps: scheme. It also doesn't meet the security expectations for new IETF protocols. The current spec is consistent with the practice with other URL schemes, which assume that URLs by default are used in a no-authentication, no-security environment. We think it is time to change this practice, and to assume instead that clients interpreting URLs should attempt to use the security services that are available to them, falling back to "anonymous" only if there is nothing better. This allows all URLs to provide views into content that are appropriate for the authorization level of the requesting client. IOHO the current practice with URLs has come from their original design assumptions: (1) they were primarily for use with HTTP, a profoundly security-impaired protocol, and with other protocols that provided only username/password authentication; (2) a "world-wide" perspective, where the likelihood that a client will have an authentication relationship with a server is minimal; (3) a "billboard" perspective, where URLs are handled directly by users who find them in public sources like web pages and TV commercials. All of these assumptions are no longer valid as the use of URLs expands to new protocols and new uses. (1) more and more protocols, including LDAP, have strong security mechanisms built in, mechanisms that we strongly encourage users to use instead of username/password; (2) the growth of public-key-based security systems implies that a user may be able to have a useful security association with a server it has never contacted before; moreover, protocols like LDAP may have more application within an organization, where security associations are likely to be available; (3) URLs are being used in new ways, such as being embedded in config files, where it is often a requirement that connections made based on them be secure connections; in some situations the most common use of a protocol may be with URL-initiated connections. At this site we have heard loud and clear from users that we must provide access controls on directory information. We're already doing this with crude mechanisms like domain-based filtering. As we put more sensitive information into the directory to enable more kinds of applications, this requirement becomes even more important. The model is that an unauthenticated read of an entry will get a limited subset of attributes; an authenticated access of the entry can get to more, based on the authorization of the client. Thus we expect authenticated access to be the rule, not the exception, for those users who are able to authenticate. The fact that LDAP supports authenticated access is one of its key features, for us. We also expect that LDAP URLs will be commonly used: embedded in web pages, entered in config files, as attributes in the directory itself. It is a requirement that accesses using these URLs be authenticated. These observations lead us to believe that as we define URL schemes for new protocols we should assume the use of strong authentication and strong security rather than assuming their absence. The key idea is that a client interpreting a URL should have some ability to figure out whether it can establish a secure, authenticated connection to the server host in question, and what mechanism it should use to do so. Policies might be something like: for server foo, use mechanism X for servers in domain foo.bar, use mechanism X, falling back to mechanism Y always use the TLS mechanism (equivalent to a ldaps: URL) use the last security mechanism used with the indicated server etc. There's a point made about server behavior too. When using an authentication mechanism, it may be that a client can authenticate itself to the server, but the server has no authorization info for that client. For the scheme we propose here to work, servers should give such sessions at least as much privilege as they give "anonymous" bind sessions. We note that this issue has an important relation to how LDAP over TLS is handled. We'll discuss that in a separate message. A third message (to follow in a few days) will present proposed modifications to draft-ietf-asid-ldapv3-url-02.txt and draft-ietf-asid-ldapv3-protocol-04.txt. - RL "Bob" Morgan Jeff Hodges Stanford [2] Subject: LDAP URLs and LDAP over TLS From: Jeff Hodges Date: Tue, 06 May 1997 14:51:18 -0700 To: ietf-asid@umich.edu Cc: bob.morgan@stanford.edu, Jeff.Hodges@stanford.edu In an another note we attempted to justify why the default behavior when interpreting ldap:// URLs should be to establish secure, authenticated connections if possible. This suggestion is related to the still unresolved (yes?) question about whether LDAP over TLS should run on a separate port. The current LDAP URL draft specifies a "ldaps:" scheme in addition to a "ldap:" scheme. The feature that we're promoting, having the default URL provide some non-trivial security, would in fact be provided by the ldaps: scheme, at least based on the current default behavior of SSL implementations. This would be an attractive aspect of ldaps:. But the URL usage that we envision exposes, we believe, the fatal flaw of the separate port scheme. What we'd like to be able to do is specify a single URL that clients will use to establish secure connections, if possible, across the entire range of clients. But the current SSL/TLS-on-separate-port schemes specify that there's a "regular" port on which TLS *cannot* be used, and a foo-over-TLS port on which TLS *must* be used. If this usage is embedded in a ldap: scheme and an ldaps: scheme, then a ldap: URL would exclude clients that want to use TLS-based security, and an ldaps: URL would exclude clients that don't do TLS. So we can't have a universal, secure URL, which is a big lose. One approach to dealing with this is just to provide both kinds of URLs in all locations (eg on web pages), and let users decide which to use. In fact that is the situation we're in with http: and https: now. We're sure we've all seen web pages that say "click here to use our secure version". In fact trying to provide the same content, or more precisely, differing views into the same content, via http: and https: is a tremendous pain, and shows the failure of this approach. Another approach is to specify that clients should interpret all such URLs as being ldap(s):, which is to say they should try the scheme they prefer first no matter what the URL says. This might work, but it depends on clients being able to recover gracefully, and quickly, when they try the wrong port first, which given current practice seems to be asking a lot. Another approach is based on the observation that, while SASL-based authentication can be used over a TLS connection, if needed, the current definition of the "regular" port prohibits TLS, so the TLS port provides the more complete service. So if we just specify that all new clients must use TLS and the TLS port, any client can use any available security mechanism. This seems like a radical approach, but maybe it has its defenders. Lastly, we can, as John Myers has suggested, provide a way to negotiate the use of TLS on the regular port. This would enable TLS and non-TLS clients to use the same port and the same URL with whatever security scheme they prefer. The cost is a modification to the application protocol to do this, and probably an extra protocol round-trip to do the negotiation. It would still be possible to have a separate TLS-specific port even if this feature were added; presumably the question would be whether the possible confusion of having two different ways of using TLS would be worth it. It may be obvious that we're in favor of the last approach. - RL "Bob" Morgan Jeff Hodges Stanford [3] Subject: LDAP URLs and security: proposed URL mods From: Jeff.Hodges@stanford.edu Date: Wed, 14 May 1997 11:03:43 -0700 To: ietf-asid@umich.edu Cc: Jeff.Hodges@stanford.edu, Bob.Morgan@stanford.edu Below are our suggested modifications to.. draft-ietf-asid-ldapv3-url-02.txt. ..for supporting security policy expression in LDAP URLs and for establishing conventions for client security behavior when no explicit policy is expressed in a URL. This proposal depends on "LDAP over TLS" being available on the standard LDAP port. We feel that there are inherent issues with a scheme which maps transport layer security and non-TLS-secured connections to separate ports, even if the separate ports can be expressed in the URL. A prime component of the issues being at what level should one negotiate application security: at the application level or at the bare transport level? We feel it should be the former. Thanks, Jeff Hodges RL "Bob" Morgan Stanford -------------------------------------------------------------------------- Changes to draft-ietf-asid-ldapv3-url-02.txt... 3. URL Definition [revised section] An LDAP URL begins with the protocol prefix "ldap" and is defined by the following grammar, which is based on the BNF defined in RFC 822 [9]: ldapurl = "ldap://" ldapsession "/" ldapquery ldapsession = [ [ dn ] [ ldaptls ] [ ldapsasl ] [ ldapsimple ] "@" ] hostport ; adapted from Section 5 of RFC 1738 [5] dn = distinguishedName ; from Section 3 of [1] ; adapted from [7]... ldapsasl = ";AUTH=" ( "*" / enc_auth_type ) ldaptls = ";TLS" ldapsimple = ";SMPL" enc_auth_type = 1*achar ; see [10] for possible values achar = uchar / "&" / "=" / "~" ; see [8] for "uchar" definition ldapquery = [dn ["?" [attributes] ["?" [scope] ["?" [filter]]]]] attributes = attrdesc *("," attrdesc) scope = "base" / "one" / "sub" attrdesc = AttributeDescription ; from Section 4.1.5 of [2] filter = filter ; from Section 4 of [4] The dn is an LDAP Distinguished Name using the string format described in [1]. In the ldapsession construct, it identifies the name of the directory object the client should bind as. In the ldapquery production, it identifies the base object of the LDAP search. See Section 4, below, for a discussion of the semantics of the ldapsession construct. The attributes construct is used to indicate which attributes should be returned from the entry or entries. Individual attrdesc names are as defined for AttributeDescription in [2]. If the attributes part is omitted, all attributes of the entry or entries should be requested. The scope construct is used to specify the scope of the search to per- form in the given LDAP server. The allowable scopes are "base" for a base object search, "one" for a one-level search, or "sub" for a subtree search. If scope is omitted, a scope of "base" is assumed. The filter is used to specify the search filter to apply to entries within the specified scope during the search. It has the format speci- fied in [4]. If filter is omitted, a filter of "(objectClass=*)" is assumed. If the entry or entries reside in the X.500 namespace, they should be reachable from any LDAP server that is providing front-end access to the X.500 directory. If the hostport part of the URL is missing, the URL can be resolved by contacting any X.500-back-ended LDAP server. Note that any URL-illegal characters (e.g., spaces) and the reserved character '?' occurring inside a dn, filter, or other element of an LDAP URL MUST be escaped using the % method described in RFC 1738 [5]. 4. LDAP URL User, Authentication, and Security Mechanisms [new section] A distinguished name and/or authentication mechanism(s) may be supplied (see the ldapsession construct in section 3, above). After making the connection to the LDAP server, the ldapsession construct is used in determining whether a StartTLS and Bind operations should be carried out (see [2]). The distinguished name, if supplied, MAY be used in authentication operations. If no distinguished name or authentication and/or security mechanisms are supplied, the program interpreting the URL SHOULD consult local policy information to determine if an authenticated connection can be made to the server, and what security mechanism and credentials to use. [this concept will be discussed further in a "Generic URL" ID to be released soon] If so, it SHOULD attempt to make such a connection, requesting appropriate credentials from the mechanism and using StartTLS and Bind operations as necessary. If policy does not indicate that a security mechanism can be used, then a Bind Operation specifying the simple authentication option and zero length password MUST be utilized (this results in an "anonymous session"). Authorization is not explicitly specified as a part of LDAP, but is a feature of many implementations. A server SHOULD treat a session that is authenticated but unauthorized as having at least the same privileges as an anonymous session. The default URL thus can offer privileged access to authorized users, and unprivileged anonymous access to others. Authentication and security mechanisms can be expressed by including an ldapsession construct in the URL. ";TLS" indicates that the client SHOULD request the server to start TLS on the connection (by performing a StartTLS Operation). ";AUTH=" indicates the client SHOULD request appropriate credentials from that mechanism and use them in a Bind Operation with the specified authentication mechanism. ";SMPL" indicates that the client SHOULD request a password, and if not specified in the URL, a name from the user, and then use them in a Bind Operation with the "simple" authentication choice. If no distinguished name is specified, a one SHOULD be obtained from the mechanism or requested from the user as appropriate. Some possible combinations of ";TLS", ";AUTH=", and ";SMPL" may be inappropriate, but none are specifically excluded (see section 5). The string ";AUTH=*" indicates that the client SHOULD select an appropriate SASL mechanism. The client may determine the SASL mechanisms supported by the server by reading the supportedSASLMechanisms of the server's rootDSE. It may combine these options with local policy information, if any, in order make that choice. If no user name is specified and no appropriate authentication mechanisms are available, the client SHOULD cease processing the URL without initiating a connection. Note that if unsafe or reserved characters such as " " or ";" are present in the user name or authentication mechanism, they MUST be encoded as described in RFC 1738 [8]. 5. Security Considerations [revised section] Security considerations discussed in the LDAP specification [2] and the URL specification [8] are relevant. The LDAP URL format allows the specification of a client identity, plus security and authentication methods. A client SHOULD NOT utilize a simple password form of authentication over an insecure connection without first alerting the user about the connection's insecurity. A client MAY attempt to achieve TLS and/or SASL security during a session started from resolving an "ldap:" URL regardless of the absence of either of the TLS or AUTH keywords. Client implementors SHOULD be careful when selecting an authentication mechanism if ";AUTH=*" is specified without a user name. Clients SHOULD NOT fall back to a simple authentication component of the Bind operation if the connection is insecure. Clients who do so are vulnerable to an active attacker masquerading as the server and does not declare support for any of the stronger security and authentication mechanisms. The LDAP URL format allows the specification of an arbitrary LDAP search operation to be performed when evaluating the LDAP URL. Following an LDAP URL may cause unexpected results, for example, the retrieval of large amounts of data, the initiation of a long-lived search, etc. The security implications of resolving an LDAP URL are the same as those of resolving an LDAP search query, and are discussed in the protocol specification [2]. [new references] [7] IMAP URL Scheme, C. Newman, draft-newman-url-imap-07.txt, May 1997. [8] Berners-Lee, Masinter, McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of Minnesota, December 1994, [9] D. Crocker, "Standard of the Format of ARPA-Internet Text Messages", STD 11, RFC 822, August 1982. [10] J. Myers, "Simple Authentication and Security Layer (SASL)", draft-myers-auth-sasl-10.txt, April 1997 From nobody Fri Mar 6 07:30:43 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAB71A0006 for ; Fri, 6 Mar 2015 07:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWhu7Q4kCK8T for ; Fri, 6 Mar 2015 07:30:39 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25B81A003A for ; Fri, 6 Mar 2015 07:30:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 840D2BEBB for ; Fri, 6 Mar 2015 15:30:38 +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 rBFWdtqNZkzH for ; Fri, 6 Mar 2015 15:30:38 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 40325BEB5 for ; Fri, 6 Mar 2015 15:30:36 +0000 (GMT) Message-ID: <54F9C81D.3000106@cs.tcd.ie> Date: Fri, 06 Mar 2015 15:30:37 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: saag@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 15:30:41 -0000 Thanks folks, I think you've re-enforced my perception that this is not something on which we have consensus. It clearly is something where folks feel strongly, and want to convince others, but that is not the same. If someone wants to write a draft on the topic, then I'm sure we can make space for discussion of that at a future saag session (not Dallas, that's kinda full already) and we could take it from there. Ta, S. On 03/03/15 21:56, stephen.farrell@cs.tcd.ie wrote: > > Hiya, > > A protocol that can run over TLS can be allocated two ports > (like HTTP with 80 and 443) or one port and use STARTTLS or > similar. > > Ted has a discuss [1] on a document about port number allocations > and asked if the security ADs cared. We think the answer is that > we don't (one can muck up or do ok either way) and we also don't > think that the security area actually has a consensus that one > or two ports is generally "more secure". If you think we're wrong > and there is a clear consensus on then please respond in the next > day or so. If you don't think there's consensus silence is fine. > (As if that'll stop you:-) > > Cheers, > S. > > PS: We're just asking as it might help folks resolve or work > around some potential repeated arguments on the topic. And we're > not saying whether we actually favour one or two port approaches:-) > > [1] > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ballot/#ted-lemon > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Fri Mar 6 07:44:06 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894581ACEBA for ; Fri, 6 Mar 2015 07:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zICohkzLYCRG for ; Fri, 6 Mar 2015 07:43:58 -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 8BECD1ACEAF for ; Fri, 6 Mar 2015 07:43:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 54588BEB3 for ; Fri, 6 Mar 2015 15:43:56 +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 cYeN3jxlQ-l2 for ; Fri, 6 Mar 2015 15:43:56 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2F2FBBEAF for ; Fri, 6 Mar 2015 15:43:56 +0000 (GMT) Message-ID: <54F9CB3D.4000200@cs.tcd.ie> Date: Fri, 06 Mar 2015 15:43:57 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "saag@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] tram draft - anyone willing to help out? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 15:44:04 -0000 Hiya, There's a draft in IESG eval that attracted a bunch of perhaps fundamental discusses and comments [1] about its security properties. I think this may be one where the authors could do with a bit more help from the security mafia^H^H^H^H^Hcommunity. (I looked at their wg list and only see a v. thin smattering of names I'd recognise from this list.) So if you're willing and have a little time, please let me know and/or get in touch with the authors. And btw - this might not seem so important but I'd worry it may end up being a major source of system level vulnerabilities for WebRTC deployments if we get it wrong and many sites don't deploy usefully good security for this bit of the WebRTC story. Thanks in advance, S. [1] https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ballot/ From nobody Fri Mar 6 09:16:04 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066571A1A1E for ; Fri, 6 Mar 2015 09:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNQaSIlBfVke for ; Fri, 6 Mar 2015 09:15:58 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126A31A1A2E for ; Fri, 6 Mar 2015 09:15:40 -0800 (PST) Received: from [192.168.131.143] ([80.92.121.102]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LwGDy-1XPB443f5y-018753; Fri, 06 Mar 2015 18:15:27 +0100 Message-ID: <54F9E0AC.7000403@gmx.net> Date: Fri, 06 Mar 2015 18:15:24 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Stephen Farrell , "saag@ietf.org" References: <54F9CB3D.4000200@cs.tcd.ie> In-Reply-To: <54F9CB3D.4000200@cs.tcd.ie> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pK31XVaq3XDDhTKIXggiFNVWepWFaWP7T" X-Provags-ID: V03:K0:G6q+wtVFOUo/YPNQmuYtNXrPCtDzt7xfrXlVAhaE1ENvfzFRjkG vQYTrg7Zz6yw4WVc8ELOfLw12PN0czJ8K9BwWw+00Eaw4zpZ0gcC8eTWC9JhRAf2sfZLM8g Ba1FwmXXWVZCnolHcFWKqvft49cmM2AoWnSKLtyOEv0W5kmH6upDlMWMljESjocbgiqBTRa oruS4Jyk9UJ9oAoSE0Y4w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [saag] tram draft - anyone willing to help out? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 17:16:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pK31XVaq3XDDhTKIXggiFNVWepWFaWP7T Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Maybe folks in the OAuth working group could help since the document abstract talks about an OAuth 2.0 solution. On 03/06/2015 04:43 PM, Stephen Farrell wrote: > btw - this might not seem so important but I'd worry it may > end up being a major source of system level vulnerabilities for > WebRTC deployments if we get it wrong and many sites don't deploy > usefully good security for this bit of the WebRTC story. --pK31XVaq3XDDhTKIXggiFNVWepWFaWP7T Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU+eCsAAoJEGhJURNOOiAtSygH/04lD3H43WJVc/DBFtJ68ruR 0VEL75BjkNeIcKNv7FnsIEu6I698SZ3XhflQyg+ADuJJYHfA00B0DzHXky9ERhXt SzbqYshgGts2fXv9x/xpYpmCtoJ0JoEgH0jf6mxa+REbRr1NSJeUdvOotHPd4ypt K+z5m6j2uMknJb+UjgHmo+EXQXlEws5UiyBVt6LOXrOHjneAbj2wf89LbDf89zB5 7BZw0iLsjS7AF4FHwmkiGL98m/1rZwY2sNh9nKtT6UeiiPG4LS6hgmCfVl03JbjN wOXKSzhOcGO+EXol5TNQf7APnYFYaU67iwxzO0m9o+9Wf2PSThOa2XQ7O56AWtc= =v9mC -----END PGP SIGNATURE----- --pK31XVaq3XDDhTKIXggiFNVWepWFaWP7T-- From nobody Fri Mar 6 17:41:35 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB61B1A8795 for ; Fri, 6 Mar 2015 17:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P--WM4jrAfHe for ; Fri, 6 Mar 2015 17:41:32 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6CE1A8790 for ; Fri, 6 Mar 2015 17:41:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=878; q=dns/txt; s=iport; t=1425692493; x=1426902093; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=13VPwyziOBTic1UIX4AICgTU4Gt10zH3RcNjUgztqGo=; b=GvgGJyFabXhw8epZKiwRlFZYTbONWniBkVOkSoXsRc8VRxgmBtJrls9t 775wLwWMM41OmNXAfc8zSdwvJW4e8Fq9uNLEIr47/e++3JSKlT7oQAcZA HJXrQD7dstZh+qgM90eQEzYi5fTy+L/ge1PvZm52mcKZeGDb2oe6S6j// o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CtBgBGVvpU/4cNJK1cgwZSWgS/OoI2hXACgTJNAQEBAQEBfIQPAQEBBDo/DAQCAQgRBAEBAQoUCQcyFAkIAgQBDQUIE4gUDc45AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLF4QdAQEeMQIFBoMRgRQBBJAHnTwjg25vAYEKOX8BAQE X-IronPort-AV: E=Sophos;i="5.11,355,1422921600"; d="scan'208";a="401607235" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP; 07 Mar 2015 01:41:32 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t271fVNi032566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 7 Mar 2015 01:41:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Fri, 6 Mar 2015 19:41:31 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Hannes Tschofenig , Stephen Farrell , "saag@ietf.org" Thread-Topic: [saag] tram draft - anyone willing to help out? Thread-Index: AQHQWDFDkl2dNZLUiUai2wQDlT6H450QPilw Date: Sat, 7 Mar 2015 01:41:30 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366B0A97@xmb-rcd-x10.cisco.com> References: <54F9CB3D.4000200@cs.tcd.ie> <54F9E0AC.7000403@gmx.net> In-Reply-To: <54F9E0AC.7000403@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.75.237] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Simon Perreault \(sperreault@jive.com\)" , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [saag] tram draft - anyone willing to help out? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 01:41:34 -0000 Hi Hannes, This draft is already reviewed in OAuth WG sometime back by you (https://www.ietf.org/mail-archive/web/oauth/current/msg13325.html). Thanks and Regards, -Tiru > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Friday, March 06, 2015 10:45 PM > To: Stephen Farrell; saag@ietf.org > Subject: Re: [saag] tram draft - anyone willing to help out? >=20 > Maybe folks in the OAuth working group could help since the document > abstract talks about an OAuth 2.0 solution. >=20 > On 03/06/2015 04:43 PM, Stephen Farrell wrote: > > btw - this might not seem so important but I'd worry it may end up > > being a major source of system level vulnerabilities for WebRTC > > deployments if we get it wrong and many sites don't deploy usefully > > good security for this bit of the WebRTC story. From nobody Mon Mar 9 08:31:15 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C2D1A8AD1 for ; Mon, 9 Mar 2015 08:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZMOPR8ZZF1b for ; Mon, 9 Mar 2015 08:31:11 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 1897D1A8FD4 for ; Mon, 9 Mar 2015 08:24:59 -0700 (PDT) Received: by lbjb6 with SMTP id b6so36562993lbj.9 for ; Mon, 09 Mar 2015 08:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=CX2RWBQsN6XZLvbuqgLQXaQeuqXsa0zYQnJdEwcEefY=; b=wMOGbFhBLF6Vx813ElKG92bhH5kvXefw1bS452pvA35uRxUY9aUGXeQ34Mb8j7rfma Tl0VARWWaM8YKWPYWfQh4APg81EtZzQstqXKtIWyN2Y8jdmrisqzJP1/VbUfLVJcL2KJ iXo0IRK09BNTE3o1SQAkWSU3mtVXvx0HAcaTRwHas6ORaOJd9SoGrDxu3kJhHCoymOt9 OkyDELO2QwyGxD/xM4ZyXK79rUjc+n7WmNV+mZDK13+yNKlH5oYMLLL/y2nqI0dum5Td QmLextkN9MFnbAISfegL6i7/97SdZ/HNavm6kVMMMr1RImv+X1K64CxZJkQEebTHnim4 Ldpw== MIME-Version: 1.0 X-Received: by 10.152.87.199 with SMTP id ba7mr20705893lab.75.1425914697615; Mon, 09 Mar 2015 08:24:57 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Mon, 9 Mar 2015 08:24:57 -0700 (PDT) Date: Mon, 9 Mar 2015 11:24:57 -0400 Message-ID: From: Kathleen Moriarty To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=001a11c34e46080de80510dca319 Archived-At: Cc: "MORTON, ALFRED C \(AL\)" Subject: [saag] Review and contribution requested X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 15:31:13 -0000 --001a11c34e46080de80510dca319 Content-Type: text/plain; charset=UTF-8 Al Morton and I put together the attached draft and are seeking collaboration between folks with security and operations expertise to develop it further. We intentionally left spaces for contributions from those with expertise in the types of monitoring listed (and ones we didn't think of). If you have experience with some of the types of monitoring covered and the text needs updating, please let us know that as well. Here is the link to the new draft: http://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ Abstract Increased use of encryption will impact 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 more drastic circumstances, the ability to monitor may 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. -- Thank you, Kathleen --001a11c34e46080de80510dca319 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Al Morton and I put together the attached draft and are se= eking collaboration between folks with security and operations expertise to= develop it further.=C2=A0 We intentionally left spaces for contributions f= rom those with expertise in the types of monitoring listed (and ones we did= n't think of).=C2=A0 If you have experience with some of the types of m= onitoring covered and the text needs updating, please let us know that as w= ell.

Here is the link to the new draft:
= 
Abstract

   Increased use of encryption will impact 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 more drastic circumstances, the ability to
   monitor may 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.

=
--

Thank= you,
Kathleen
--001a11c34e46080de80510dca319-- From nobody Mon Mar 9 14:27:43 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F418D1AC40D; Mon, 9 Mar 2015 14:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0XQ4UGG_VlM; Mon, 9 Mar 2015 14:27:26 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF9F1ACD42; Mon, 9 Mar 2015 14:27:23 -0700 (PDT) Received: by widem10 with SMTP id em10so10425977wid.2; Mon, 09 Mar 2015 14:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=MyNg4zjxnX0MX4NPxcTJyDggXW0RwbyTjphNdxqARSQ=; b=HJakZFeNINmu/hCsdbbtgP5nEBuRKrtXHYVSEXQer33K2t046vSpZasJCASdfrw+QZ FYW2X5Ua+kCpQri4VZDKIKz89mQBzQxF4uks9Or1hfTNKPe1ScmOADJEt9qxzFOzkhE9 aMXle/RhelGKFDNQ/GRCghvwNYPRQMvBl+Y/ajy6pxmWRcZfDW7hAIYJh2emAINm2SxI YYyJ3cBtA8iBBAXcFxVEhoOVaYFmhl1cVawwbvuI04bjiMoXOKvPQQry5cKoAWr6f3EX SrSbXcOFCFtm2UGbgOjPus9Ts3bVoKTeQrVD105oDn7lc4Wib7HKF3OHR32bT44eoWfq Kqlg== MIME-Version: 1.0 X-Received: by 10.194.192.167 with SMTP id hh7mr62171415wjc.151.1425936442636; Mon, 09 Mar 2015 14:27:22 -0700 (PDT) Received: by 10.194.68.39 with HTTP; Mon, 9 Mar 2015 14:27:20 -0700 (PDT) Date: Mon, 9 Mar 2015 17:27:20 -0400 Message-ID: From: Daniel Migault To: Time Zone Data Distribution Service , saag@ietf.org, apps-discuss@ietf.org, int-area@ietf.org, ops-area@ietf.org, ietf-privacy@ietf.org Content-Type: multipart/alternative; boundary=047d7b8743f822bd630510e1b31f Archived-At: Subject: [saag] [Tzdist] WGLC2 for draft-ietf-tzdist-service-06.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:27:30 -0000 --047d7b8743f822bd630510e1b31f Content-Type: text/plain; charset=UTF-8 Dear Friends and Colleagues, This is the second Working Group Last Call (WGLC) for draft-ietf-tzdist-service-06 [1]. Feel free to make any comment before March 23. During the first WGLC of draft-ietf-tzdist-service-05.txt we received consequent feed backs and remarks from cross areas. We believe these remarks have been addressed in this new version. [1] http://tools.ietf.org/html/draft-ietf-tzdist-service-06 Best Regards Daniel and Eliot ---------- Forwarded message ---------- From: Date: Mon, Mar 9, 2015 at 5:10 PM Subject: [Tzdist] I-D Action: draft-ietf-tzdist-service-06.txt To: i-d-announce@ietf.org Cc: tzdist@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Time Zone Data Distribution Service Working Group of the IETF. Title : Time Zone Data Distribution Service Authors : Michael Douglass Cyrus Daboo Filename : draft-ietf-tzdist-service-06.txt Pages : 54 Date : 2015-03-09 Abstract: This document defines a time zone data distribution service that allows reliable, secure and fast delivery of time zone data and leap second rules to client systems such as calendaring and scheduling applications or operating systems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tzdist-service/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tzdist-service-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tzdist-service-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Tzdist mailing list Tzdist@ietf.org https://www.ietf.org/mailman/listinfo/tzdist -- Daniel Migault Ericsson --047d7b8743f822bd630510e1b31f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Friends and Colleagues,

<= /div>This is the second Working Group Last Call (WGLC) for=20 draft-i= etf-tzdist-service-06 [1]. Feel free to make any comment before March 23.

During the first WGLC of draft-ietf-tzdist-service-05.txt we re= ceived consequent feed backs and remarks from cross areas. We believe these= remarks have been addressed in this new version.

[1] http://tools.ietf.org/html/draft-ietf-tzdist-service-06

Best Regards

Daniel and Eliot


---------- Forwarded message --= --------
From: <= internet-drafts@ietf.org>= ;
Date: Mon, Mar 9, 2015 at 5:10 PM
Subject: [Tzdist] I-D Acti= on: draft-ietf-tzdist-service-06.txt
To: i-d-announce@ietf.org
Cc: tzdist@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Time Zone Data Distribution Service = Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Time Zone Data Distribution Service
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich= ael Douglass
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Cyrus Daboo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tzdist-service-06.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 54
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-03-09

Abstract:
=C2=A0 =C2=A0This document defines a time zone data distribution service th= at
=C2=A0 =C2=A0allows reliable, secure and fast delivery of time zone data an= d leap
=C2=A0 =C2=A0second rules to client systems such as calendaring and schedul= ing
=C2=A0 =C2=A0applications or operating systems.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tzdist-service/<= /a>

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tzdist-service-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tzdist-ser= vice-06


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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



--
Daniel Migault
Ericsson
--047d7b8743f822bd630510e1b31f-- From nobody Tue Mar 10 05:14:17 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53771ACD20 for ; Tue, 10 Mar 2015 05:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1FEUQCpOQeA for ; Tue, 10 Mar 2015 05:14:13 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2503C1AC529 for ; Tue, 10 Mar 2015 05:14:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0FAKXf/lTGmAcV/2dsb2JhbABcgkMhIlJaBIMGggiqfQ0BAQEBAQaSd4VxAhyBEU0BAQEBAQF8hA8BAQEBAxIRCj4OEAIBCA0EBAEBCx0DAgICMBQJCAIEAQ0FCBqIDQEMnE6KS5wVAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4YKhQ2EPS0EBgGCaC+BFgWQD4Nkhwk5gm+CSYxpI4FbghNvAQGBQn8BAQE X-IronPort-AV: E=Sophos; i="5.11,374,1422939600"; d="scan'208,217"; a="94224761" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Mar 2015 08:14:04 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 10 Mar 2015 08:14:03 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Tue, 10 Mar 2015 13:14:01 +0100 From: "Romascanu, Dan (Dan)" To: Kathleen Moriarty , "saag@ietf.org" Thread-Topic: [saag] Review and contribution requested Thread-Index: AQHQWn4eYyDXOIXy3UyFmaK/ZWLxsZ0VojQw Date: Tue, 10 Mar 2015 12:14:00 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C9BD281@AZ-FFEXMB04.global.avaya.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C9BD281AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "MORTON, ALFRED C \(AL\)" Subject: Re: [saag] Review and contribution requested X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 12:14:16 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9BD281AZFFEXMB04globa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldoYXQgaGlkZXMgdW5kZXIgOC4gT3BlcmF0aW9uYWwgTW9uaXRvcmluZyB0aGF0IHdh cyBub3QgY292ZXJlZCBhbHJlYWR5IGluIDIsMyw0Pw0KDQpUaGFua3MgYW5kIFJlZ2FyZHMsDQoN CkRhbg0KDQoNCkZyb206IHNhYWcgW21haWx0bzpzYWFnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBLYXRobGVlbiBNb3JpYXJ0eQ0KU2VudDogTW9uZGF5LCBNYXJjaCAwOSwgMjAxNSA1 OjI1IFBNDQpUbzogc2FhZ0BpZXRmLm9yZw0KQ2M6IE1PUlRPTiwgQUxGUkVEIEMgKEFMKQ0KU3Vi amVjdDogW3NhYWddIFJldmlldyBhbmQgY29udHJpYnV0aW9uIHJlcXVlc3RlZA0KDQpBbCBNb3J0 b24gYW5kIEkgcHV0IHRvZ2V0aGVyIHRoZSBhdHRhY2hlZCBkcmFmdCBhbmQgYXJlIHNlZWtpbmcg Y29sbGFib3JhdGlvbiBiZXR3ZWVuIGZvbGtzIHdpdGggc2VjdXJpdHkgYW5kIG9wZXJhdGlvbnMg ZXhwZXJ0aXNlIHRvIGRldmVsb3AgaXQgZnVydGhlci4gIFdlIGludGVudGlvbmFsbHkgbGVmdCBz cGFjZXMgZm9yIGNvbnRyaWJ1dGlvbnMgZnJvbSB0aG9zZSB3aXRoIGV4cGVydGlzZSBpbiB0aGUg dHlwZXMgb2YgbW9uaXRvcmluZyBsaXN0ZWQgKGFuZCBvbmVzIHdlIGRpZG4ndCB0aGluayBvZiku ICBJZiB5b3UgaGF2ZSBleHBlcmllbmNlIHdpdGggc29tZSBvZiB0aGUgdHlwZXMgb2YgbW9uaXRv cmluZyBjb3ZlcmVkIGFuZCB0aGUgdGV4dCBuZWVkcyB1cGRhdGluZywgcGxlYXNlIGxldCB1cyBr bm93IHRoYXQgYXMgd2VsbC4NCg0KSGVyZSBpcyB0aGUgbGluayB0byB0aGUgbmV3IGRyYWZ0Og0K aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tbS13Zy1lZmZlY3QtZW5jcnlw dC88aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX2Rh dGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRG1tLTJEd2ctMkRlZmZlY3QtMkRlbmNyeXB0 XyZkPUF3TUZhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1JNGR6R3hSMzFPY05YQ0pmUXp2 bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBCc0ZBJm09US1IZlZLS0dkZ1RZSXQzemFLbEtyVEVCazhCNWhJ V3pncHkzdFlsVlk5QSZzPVRwTDhKS3gyTk5GUXdROHJscEdDN0xadWhzVW5YbkphbVJUYVdkSUlr TEUmZT0+DQoNCg0KQWJzdHJhY3QNCg0KDQoNCiAgIEluY3JlYXNlZCB1c2Ugb2YgZW5jcnlwdGlv biB3aWxsIGltcGFjdCBvcGVyYXRpb25zIGZvciBzZWN1cml0eSBhbmQNCg0KICAgbmV0d29yayBt YW5hZ2VtZW50IGNhdXNpbmcgYSBzaGlmdCBpbiBob3cgdGhlc2UgZnVuY3Rpb25zIGFyZQ0KDQog ICBwZXJmb3JtZWQuICBJbiBzb21lIGNhc2VzLCBuZXcgbWV0aG9kcyB0byBib3RoIG1vbml0b3Ig YW5kIHByb3RlY3QNCg0KICAgZGF0YSB3aWxsIGV2b2x2ZS4gIEluIG1vcmUgZHJhc3RpYyBjaXJj dW1zdGFuY2VzLCB0aGUgYWJpbGl0eSB0bw0KDQogICBtb25pdG9yIG1heSBiZSBlbGltaW5hdGVk LiAgVGhpcyBkcmFmdCBpbmNsdWRlcyBhIGNvbGxlY3Rpb24gb2YNCg0KICAgY3VycmVudCBzZWN1 cml0eSBhbmQgbmV0d29yayBtYW5hZ2VtZW50IGZ1bmN0aW9ucyB0aGF0IG1heSBiZQ0KDQogICBp bXBhY3RlZCBieSB0aGUgc2hpZnQgdG8gaW5jcmVhc2VkIHVzZSBvZiBlbmNyeXB0aW9uLiAgVGhp cyBkcmFmdA0KDQogICBkb2VzIG5vdCBhdHRlbXB0IHRvIHNvbHZlIHRoZXNlIHByb2JsZW1zLCBi dXQgcmF0aGVyIGRvY3VtZW50IHRoZQ0KDQogICBjdXJyZW50IHN0YXRlIHRvIGFzc2lzdCBpbiB0 aGUgZGV2ZWxvcG1lbnQgb2YgYWx0ZXJuYXRlIG9wdGlvbnMgdG8NCg0KICAgYWNoaWV2ZSB0aGUg aW50ZW5kZWQgcHVycG9zZSBvZiB0aGUgZG9jdW1lbnRlZCBwcmFjdGljZXMuDQoNCi0tDQoNClRo YW5rIHlvdSwNCkthdGhsZWVuDQo= --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9BD281AZFFEXMB04globa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPldoYXQgaGlkZXMgdW5kZXIgOC4gT3BlcmF0aW9uYWwgTW9uaXRvcmluZyB0aGF0 IHdhcyBub3QgY292ZXJlZCBhbHJlYWR5IGluIDIsMyw0Pw0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgYW5k IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5EYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNhYWcgW21h aWx0bzpzYWFnLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkthdGhsZWVu IE1vcmlhcnR5PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWFyY2ggMDksIDIwMTUgNToyNSBQ TTxicj4NCjxiPlRvOjwvYj4gc2FhZ0BpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gTU9SVE9OLCBB TEZSRUQgQyAoQUwpPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtzYWFnXSBSZXZpZXcgYW5kIGNvbnRy aWJ1dGlvbiByZXF1ZXN0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QWwgTW9ydG9uIGFuZCBJIHB1dCB0b2dldGhlciB0aGUgYXR0YWNoZWQg ZHJhZnQgYW5kIGFyZSBzZWVraW5nIGNvbGxhYm9yYXRpb24gYmV0d2VlbiBmb2xrcyB3aXRoIHNl Y3VyaXR5IGFuZCBvcGVyYXRpb25zIGV4cGVydGlzZSB0byBkZXZlbG9wIGl0IGZ1cnRoZXIuJm5i c3A7IFdlIGludGVudGlvbmFsbHkgbGVmdCBzcGFjZXMgZm9yIGNvbnRyaWJ1dGlvbnMgZnJvbSB0 aG9zZSB3aXRoIGV4cGVydGlzZSBpbiB0aGUgdHlwZXMNCiBvZiBtb25pdG9yaW5nIGxpc3RlZCAo YW5kIG9uZXMgd2UgZGlkbid0IHRoaW5rIG9mKS4mbmJzcDsgSWYgeW91IGhhdmUgZXhwZXJpZW5j ZSB3aXRoIHNvbWUgb2YgdGhlIHR5cGVzIG9mIG1vbml0b3JpbmcgY292ZXJlZCBhbmQgdGhlIHRl eHQgbmVlZHMgdXBkYXRpbmcsIHBsZWFzZSBsZXQgdXMga25vdyB0aGF0IGFzIHdlbGwuPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlIGlzIHRoZSBsaW5r IHRvIHRoZSBuZXcgZHJhZnQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cC0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEbW0tMkR3 Zy0yRGVmZmVjdC0yRGVuY3J5cHRfJmFtcDtkPUF3TUZhUSZhbXA7Yz1CRnBXUXc4YnN1S3BsMVNn aVpINjRRJmFtcDtyPUk0ZHpHeFIzMU9jTlhDSmZRenZsc2lMUWZ1Y0JYUnVjUHZkcnBocEJzRkEm YW1wO209US1IZlZLS0dkZ1RZSXQzemFLbEtyVEVCazhCNWhJV3pncHkzdFlsVlk5QSZhbXA7cz1U cEw4Skt4Mk5ORlF3UThybHBHQzdMWnVoc1VuWG5KYW1SVGFXZElJa0xFJmFtcDtlPSI+aHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tbS13Zy1lZmZlY3QtZW5jcnlwdC88L2E+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImxpbmUt aGVpZ2h0OjE0LjRwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5B YnN0cmFjdDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJsaW5lLWhlaWdodDoxNC40 cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgSW5jcmVh c2VkIHVzZSBvZiBlbmNyeXB0aW9uIHdpbGwgaW1wYWN0IG9wZXJhdGlvbnMgZm9yIHNlY3VyaXR5 IGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MTQu NHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgbmV0d29yayBtYW5hZ2VtZW50IGNhdXNpbmcgYSBzaGlmdCBpbiBob3cgdGhlc2UgZnVuY3Rp b25zIGFyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6 MTQuNHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgcGVyZm9ybWVkLiZuYnNwOyBJbiBzb21lIGNhc2VzLCBuZXcgbWV0aG9kcyB0byBib3Ro IG1vbml0b3IgYW5kIHByb3RlY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9 ImxpbmUtaGVpZ2h0OjE0LjRwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IGRhdGEgd2lsbCBldm9sdmUuJm5ic3A7IEluIG1vcmUgZHJhc3Rp YyBjaXJjdW1zdGFuY2VzLCB0aGUgYWJpbGl0eSB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbW9uaXRvciBtYXkgYmUgZWxpbWluYXRlZC4m bmJzcDsgVGhpcyBkcmFmdCBpbmNsdWRlcyBhIGNvbGxlY3Rpb24gb2Y8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGN1cnJlbnQgc2VjdXJpdHkg YW5kIG5ldHdvcmsgbWFuYWdlbWVudCBmdW5jdGlvbnMgdGhhdCBtYXkgYmU8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGltcGFjdGVkIGJ5IHRo ZSBzaGlmdCB0byBpbmNyZWFzZWQgdXNlIG9mIGVuY3J5cHRpb24uJm5ic3A7IFRoaXMgZHJhZnQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGRv ZXMgbm90IGF0dGVtcHQgdG8gc29sdmUgdGhlc2UgcHJvYmxlbXMsIGJ1dCByYXRoZXIgZG9jdW1l bnQgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJsaW5lLWhlaWdodDox NC40cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBjdXJyZW50IHN0YXRlIHRvIGFzc2lzdCBpbiB0aGUgZGV2ZWxvcG1lbnQgb2YgYWx0ZXJu YXRlIG9wdGlvbnMgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImxpbmUt aGVpZ2h0OjE0LjRwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IGFjaGlldmUgdGhlIGludGVuZGVkIHB1cnBvc2Ugb2YgdGhlIGRvY3VtZW50 ZWQgcHJhY3RpY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhh bmsgeW91LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+S2F0aGxlZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9BD281AZFFEXMB04globa_-- From nobody Tue Mar 10 05:21:14 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970001ACD3D for ; Tue, 10 Mar 2015 05:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynvJEKsjLHzr for ; Tue, 10 Mar 2015 05:21:09 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2556B1ACD20 for ; Tue, 10 Mar 2015 05:21:07 -0700 (PDT) Received: by qgdq107 with SMTP id q107so1150660qgd.6 for ; Tue, 10 Mar 2015 05:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t7h5l4hH4urDdZwz183mHQ2lD/Q1ym8k/z7Yhw0sORE=; b=oCrPaHiUKQki2Be4VnAitgiRBLy9iLa4W/mpYRofSiPtiw4/IsvtuCSSGsuB8a0zai z8dR0zB4G8w/AwLyH7xs3Mvowe4TzI76YaYwPXO8y+2VbF6TenuB7DsJRn/qx8eXvpJj /mHlmOHBYWSwemDdRr0CcDVaHaDicQDWV/5gF5/IjomhYjimLItPhprViF1kOdI9j+rL lOX8sWGNLvmw5XOu2RmOIC+aGw1E0O5+Ew0PXnDXoD9DDUIIxmgBzesDeYjhXEH+p+nB MrrAKt5nukMWYGYEt5TQFAZC3h72+FxaboOHFj52apITC2lKNfd1luyZd4uy8/kbRucc PfAA== X-Received: by 10.55.23.34 with SMTP id i34mr29383234qkh.6.1425990066379; Tue, 10 Mar 2015 05:21:06 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id f102sm252529qki.1.2015.03.10.05.21.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Mar 2015 05:21:05 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-CFE07152-DCDF-48B3-97D5-DAE9E095EEE9 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C9BD281@AZ-FFEXMB04.global.avaya.com> Date: Tue, 10 Mar 2015 08:21:02 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <9904FB1B0159DA42B0B887B7FA8119CA5C9BD281@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" Archived-At: Cc: "saag@ietf.org" , "MORTON, ALFRED C \(AL\)" Subject: Re: [saag] Review and contribution requested X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 12:21:11 -0000 --Apple-Mail-CFE07152-DCDF-48B3-97D5-DAE9E095EEE9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Dan, Sent from my iPhone > On Mar 10, 2015, at 8:14 AM, "Romascanu, Dan (Dan)" w= rote: >=20 > Hi, > =20 > What hides under 8. Operational Monitoring that was not covered already in= 2,3,4? This is a placeholder in case there are additional types of monitoring that n= eed to be added. It might be something similar to the incident response sec= tion that would be referenced from other places in the draft. If there is n= othing to add in that section, we can remove it. Your operational experience is far greater than mine and it seems operators h= ave quite a range of experience as well, you feedback and contributions are a= ppreciated if you see gaps or things we didn't get quite right. Thank you, Kathleen > =20 > Thanks and Regards, > =20 > Dan > =20 > =20 > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Kathleen Moriarty > Sent: Monday, March 09, 2015 5:25 PM > To: saag@ietf.org > Cc: MORTON, ALFRED C (AL) > Subject: [saag] Review and contribution requested > =20 > Al Morton and I put together the attached draft and are seeking collaborat= ion between folks with security and operations expertise to develop it furth= er. We intentionally left spaces for contributions from those with expertis= e in the types of monitoring listed (and ones we didn't think of). If you h= ave experience with some of the types of monitoring covered and the text nee= ds updating, please let us know that as well. > =20 > Here is the link to the new draft: > http://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/=20 > =20 > Abstract > =20 > Increased use of encryption will impact 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 more drastic circumstances, the ability to > monitor may 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. > =20 > -- > =20 > Thank you, > Kathleen --Apple-Mail-CFE07152-DCDF-48B3-97D5-DAE9E095EEE9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Dan,


Sent from my iPhone

On Mar 10, 2015, at 8:14 AM, "Romascanu, Dan (Dan)" <dromasca@avaya.com> wrote:

Hi,

 

What hides under 8. Operational Monitoring that was not covered already in 2,3,4?


This is a placeholder in case there are additional types of monitoring that need to be added.  It might be something similar to the incident response section that would be referenced from other places in the draft.  If there is nothing to add in that section, we can remove it.

Your operational experience is far greater than mine and it seems operators have quite a range of experience as well, you feedback and contributions are appreciated if you see gaps or things we didn't get quite right.

Thank you,
Kathleen

 

Thanks and Regards,

 

Dan

 

 

From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Kathleen Moriarty
Sent: Monday, March 09, 2015 5:25 PM
To: saag@ietf.org
Cc: MORTON, ALFRED C (AL)
Subject: [saag] Review and contribution requested

 

Al Morton and I put together the attached draft and are seeking collaboration between folks with security and operations expertise to develop it further.  We intentionally left spaces for contributions from those with expertise in the types of monitoring listed (and ones we didn't think of).  If you have experience with some of the types of monitoring covered and the text needs updating, please let us know that as well.

 

Here is the link to the new draft:

 

Abstract
 
   Increased use of encryption will impact 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 more drastic circumstances, the ability to
   monitor may 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.

 

--

 

Thank you,

Kathleen

--Apple-Mail-CFE07152-DCDF-48B3-97D5-DAE9E095EEE9-- From nobody Tue Mar 10 09:29:35 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592D91A1EF4 for ; Tue, 10 Mar 2015 09:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.538 X-Spam-Level: * X-Spam-Status: No, score=1.538 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqheyRdUmmXD for ; Tue, 10 Mar 2015 09:29:29 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16431A1E0F for ; Tue, 10 Mar 2015 09:29:28 -0700 (PDT) Received: from pc-cznic4.localnet (unknown [IPv6:2001:67c:1220:80c:2a92:4aff:feca:f18d]) by mail.nic.cz (Postfix) with ESMTPSA id 1E53813FE0C for ; Tue, 10 Mar 2015 17:29:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1426004966; bh=qkBZc+Ef+4/cbuXB69aTM293jebNIb2jBMSfh+cPn/M=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=T1AZSh/zRf7Vrc1z2hqfDVVgXn/FQUe+F0pci3z7QJHfy4NS931ZJQolrP8oIN1aJ oKpCHzq9w602l6PJ0kv4HFGclj2tHat5clUqX0fEPs/AOkTVP543zOfMWv/KGwU0r6 pfd1CQLnMS/WInpr0dNBYsYOFJMWTvI2JbPZa0Gg= From: Jan =?utf-8?B?VsSNZWzDoWs=?= To: saag@ietf.org Date: Tue, 10 Mar 2015 17:29:25 +0100 Message-ID: <2070793.lmylhNrOvK@pc-cznic4> Organization: CZ.NIC Labs User-Agent: KMail/4.14.4 (Linux/4.0.0-0.rc1.git0.1.fc22.x86_64; KDE/4.14.5; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Subject: [saag] review request, draft-jvcelak-nsec5-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 16:29:30 -0000 Hello list, me and Sharon Goldberg put together the attached draft. We are looking for feedback from people with security and DNS expertise. We are particularly interested in your opinions on the transition mechanisms and the extent of the required protocol modifications. We will have a short presentation of the draft in Dallas. So I'll be happy to answer any questions here, or we can talk in person later. Links: https://devpub.labs.nic.cz/jvcelak/nsec5/draft-jvcelak-nsec5-00.txt https://devpub.labs.nic.cz/jvcelak/nsec5/draft-jvcelak-nsec5-00.html https://devpub.labs.nic.cz/jvcelak/nsec5/draft-jvcelak-nsec5-00.xml Abstract The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence and the NSEC3 for hashed authenticated denial of existence. The NSEC RR allows for the entire zone contents to be enumerated if a server is queried for carefully chosen domain names; N queries suffice to enumerate a zone containing N names. The NSEC3 RR adds domain-name hashing, which makes the zone enumeration harder, but not impossible. This document introduces NSEC5, which provides an cryptographically- proven mechanism that prevents zone enumeration. NSEC5 has the additional advantage of not requiring private zone-signing keys to be present on all authoritative servers for the zone. Best regards, Jan From nobody Wed Mar 11 16:03:56 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6226C1A892B for ; Wed, 11 Mar 2015 16:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSZwLxiIiT82 for ; Wed, 11 Mar 2015 16:03:51 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE281A88F4 for ; Wed, 11 Mar 2015 16:03:50 -0700 (PDT) Received: by qgdq107 with SMTP id q107so14054019qgd.7 for ; Wed, 11 Mar 2015 16:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:references:to; bh=pAMutInQkViPTUB4RL06g8ECnk1J+Mactwdo4A/gmBo=; b=iDI+eGsIQXMTSuVdr7gCai+QpXu/gDLX78yZwGwTr2svE0b+rvCZ1oieTUXuoF/UhT Sx9w9oIwN+cQt5jFDPnPcTgRTjZVqR1mpM0CvlWtAoUhXg+hMC0k+WuUBJDq6pam7v8o rH8ybw+ZUSJX+vaLlnnq84EWKHo3m9UiHiH49QKcUmdtHVrxm2MTzYqCZt5Nn3a5r1Ls DVv9QZgnNkt5JRrR+xPN3qoG2bMVZOx/Ss8g/aIMBHtoBJql4SdgcJNYU/FhoUsIZAWQ Y465hJLxS6SRX078N+I8GH54B+OjWqcvr7SRzPu2bB2zMomxRfpE3XeGhcx0rBqNNcB/ bVSg== X-Received: by 10.140.94.97 with SMTP id f88mr49169241qge.38.1426115030030; Wed, 11 Mar 2015 16:03:50 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id n41sm3583262qkh.3.2015.03.11.16.03.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Mar 2015 16:03:49 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-35E98D6F-7B56-419C-A783-56200E8983EB Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: <4B3D2CEE-BEB9-4BD3-A305-E1D79F8C5FD3@gmail.com> Date: Wed, 11 Mar 2015 19:03:49 -0400 References: To: saag@ietf.org X-Mailer: iPhone Mail (11D257) Archived-At: Subject: [saag] Fwd: ubiquitous encryption draft feedback X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 23:03:55 -0000 --Apple-Mail-35E98D6F-7B56-419C-A783-56200E8983EB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Forwarding as requested. Wes has some good comments, Al or I will respond s= oon. Thanks, Kathleen Sent from my iPhone Begin forwarded message: > Resent-From: > From: "George, Wes" > Date: March 11, 2015 at 4:39:58 PM EDT > Resent-To: > To: "draft-mm-wg-effect-encrypt@tools.ietf.org" > Subject: ubiquitous encryption draft feedback >=20 > Hi -=20 >=20 > I think that the section discussing middle boxes decrypting (MiTM) traffic= to monitor it (4.2) needs a few bolsters-=20 > I'm not sure whether IETF will find the support to actively condemn this b= ehavior (i.e. NOT RECOMMENDED), but a discussion of the considerations aroun= d what happens if it's done (or more accurately, done carelessly) would be a= ppropriate for such a document. This is somewhat difficult because it gets i= nto areas that IETF has typically shied away from because it has an intersec= tion between policy, law, and use of technology. However, I still think it's= appropriate since IMO first blood was already drawn by wading into the perv= asive monitoring debate, which has a similar overlap.=20 >=20 > Section 4 of the draft makes brief mention of the fact that this might be d= one outside of the enterprise (e.g. In an SP network) but I would break the l= ink between DLP monitoring and SPs, and instead briefly discuss this in the s= ection on other reasons SPs monitor traffic (in section 2) such as for perfo= rmance/capacity management or performance optimizations based on the underly= ing transport media e.g. Improving performance on high-latency and capacity c= onstrained Satellite or mobile connections. The ETSI OWA has covered that se= t of problems in reasonable detail both in their group and in httpbis when a= dvocating for some sort of provision for decrypting proxies. >=20 > The recent revelations about Gogo inflight, Superfish/Komodia, Comodo and o= thers interfering with the underlying security and trust model of root certi= ficates makes this topical because it provides excellent demonstrations of h= ow this can be done wrong such that it fatally compromises the security the u= ser relies upon, and thus provides an opportunity to highlight the issues on= e must consider when weighing this option: > Liability =E2=80=93 I realize that IETF does not trade in legal advice, so= this would have to be caveated pretty heavily, but I think it's a worthwhil= e part of the discussion since it's a direct result of a specific set of tec= hnical actions and should be weighed when considering whether the ends justi= fy the means. > Duty to take action =E2=80=93 encrypted traffic (or unencrypted traffic th= at is not subject to DPI) comes with a hidden benefit for the SPs who carry i= t- plausible deniability. If a service provider or enterprise is decrypting t= raffic with intent to inspect it, whether with or without its users' knowled= ge, it can be argued that it is responsible for the traffic's content such t= hat it is required to take action on content or activities that are banned b= y policy or law, including enforcing copyright, preventing exploitation of c= hildren, threats of violence, reporting potential violations to the proper a= uthorities, etc. An SP must be ready to take responsibility for traffic that= flows across its network if it chooses to inspect it. > Duty to protect sensitive information =E2=80=93 decrypting middle boxes re= present attractive targets since a compromise leads to the potential to acce= ss a lot of information that would otherwise be protected by encryption. If a= compromise occurs, and it exposes information protected by privacy laws (me= dical, financial, etc), the SP or enterprise actively making efforts to disa= ble (albeit temporarily) security measures may be held responsible for the d= amages caused by that information exposure. And the risk isn't limited to tr= aditional bad actors =E2=80=93 this makes a good target for state agencies a= ttempting to preserve their pervasive monitoring abilities, thus defeating t= he purpose of opportunistic/increased encryption in the first place. This pr= oblem gets worse if the data is stored unencrypted for any length of time, a= s it is sensitive to secondary system compromises or government compulsion. T= here is also the concern about downgrade attacks, where the intermediate dev= ice uses weaker ciphers or key lengths when it proxies the connection to the= actual destination, thus making the traffic more vulnerable. > Transparency =E2=80=93 this interception and decryption MUST be done with t= he full knowledge of the users. What this means in execution is something th= at has been an ongoing debate (i.e. Will normal folks understand a click-thr= ough warning well enough to do the "right" thing to protect their informatio= n by opting out for sensitive stuff (assuming they're allowed to opt out)? I= s it ok to tell employees when they sign their contract but never warn them w= hen you're doing it for sensitive info? etc) but it's definitely worth makin= g that need for transparency crystal-clear, even if we don't necessarily def= ine what is an acceptable level of transparency. > Feel free to forward this to whatever email list it may be discussed on. I= t wasn't clear from the draft name where this was headed.=20 > Thanks, > =20 > Wes George > =20 > Anything below this line has been added by my company=E2=80=99s mail serve= r, I have no control over it. > ----------- >=20 > This E-mail and any of its attachments may contain Time Warner Cable propr= ietary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the us= e of the individual or entity to which it is addressed. If you are not the i= ntended recipient of this E-mail, you are hereby notified that any dissemina= tion, distribution, copying, or action taken in relation to the contents of a= nd attachments to this E-mail is strictly prohibited and may be unlawful. If= you have received this E-mail in error, please notify the sender immediatel= y and permanently delete the original and any copy of this E-mail and any pr= intout. --Apple-Mail-35E98D6F-7B56-419C-A783-56200E8983EB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Forwarding as requested.  Wes has= some good comments, Al or I will respond soon.

Tha= nks,
Kathleen

Sent from my iPhone

Begin forwa= rded message:

Resent-From: <wesley.george@twcable.com= >
From: "George, Wes" <wesley.george@twcable.com>
Date: March 11, 2015= at 4:39:58 PM EDT
Resent-To: <draft-mm-wg-effect-encrypt@ietf.org>
To:= "draft-mm-= wg-effect-encrypt@tools.ietf.org" <draft-mm-wg-effect-encrypt@tools.ietf.org>=
Subject: ubiquitous encryption draft feedback

Hi - 

I think that the section discussing middle boxes decrypting (MiTM) traf= fic to monitor it (4.2) needs a few bolsters- 
I'm not sure whether IETF will find the support to actively condemn thi= s behavior (i.e. NOT RECOMMENDED), but a discussion of the considerations ar= ound what happens if it's done (or more accurately, done carelessly) would b= e appropriate for such a document. This is somewhat difficult because it gets into areas that IETF has typical= ly shied away from because it has an intersection between policy, law, and u= se of technology. However, I still think it's appropriate since IMO first bl= ood was already drawn by wading into the pervasive monitoring debate, which has a similar overlap. 

Section 4 of the draft makes brief mention of the fact that this might b= e done outside of the enterprise (e.g. In an SP network) but I would break t= he link between DLP monitoring and SPs, and instead briefly discuss this in t= he section on other reasons SPs monitor traffic (in section 2) such as for performance/capacity managem= ent or performance optimizations based on the underlying transport media e.g= . Improving performance on high-latency and capacity constrained Satellite o= r mobile connections. The ETSI OWA has covered that set of problems in reasonable detail both in their gro= up and in httpbis when advocating for some sort of provision for decrypting p= roxies.

The recent revelations about Gogo inflight, Superfish/Komodia, Comodo a= nd others interfering with the underlying security and trust model of root c= ertificates makes this topical because it provides excellent demonstrations o= f how this can be done wrong such that it fatally compromises the security the user relies upon, and thu= s provides an opportunity to highlight the issues one must consider when wei= ghing this option:
  • Liability =E2=80=93 I realize that IETF does not trade in legal advice, s= o this would have to be caveated pretty heavily, but I think it's a worthwhi= le part of the discussion since it's a direct result of a specific set of te= chnical actions and should be weighed when considering whether the ends justify the means.
    • Duty to take action =E2=80=93 encrypted traffic (or unencrypted traffic t= hat is not subject to DPI) comes with a hidden benefit for the SPs who carry= it- plausible deniability. If a service provider or enterprise is decryptin= g traffic with intent to inspect it, whether with or without its users' knowledge, it can be argued that it is r= esponsible for the traffic's content such that it is required to take action= on content or activities that are banned by policy or law, including enforc= ing copyright, preventing exploitation of children, threats of violence, reporting potential violations to the pro= per authorities, etc. An SP must be ready to take responsibility for traffic= that flows across its network if it chooses to inspect it.
    • Duty to p= rotect sensitive information =E2=80=93 decrypting middle boxes represent att= ractive targets since a compromise leads to the potential to access a lot of= information that would otherwise be protected by encryption. If a compromis= e occurs, and it exposes information protected by privacy laws (medical, financial, etc), the SP or e= nterprise actively making efforts to disable (albeit temporarily) security m= easures may be held responsible for the damages caused by that information e= xposure. And the risk isn't limited to traditional bad actors =E2=80=93 this makes a good target for st= ate agencies attempting to preserve their pervasive monitoring abilities, th= us defeating the purpose of opportunistic/increased encryption in the first p= lace. This problem gets worse if the data is stored unencrypted for any length of time, as it is sensitive to se= condary system compromises or government compulsion. There is also the conce= rn about downgrade attacks, where the intermediate device uses weaker cipher= s or key lengths when it proxies the connection to the actual destination, thus making the traffic more vuln= erable.
  • Transparency =E2=80=93 this interception and decryption MUST be don= e with the full knowledge of the users. What this means in execution is some= thing that has been an ongoing debate (i.e. Will normal folks understand a c= lick-through warning well enough to do the "right" thing to protect their information by opting out for sensitive stuf= f (assuming they're allowed to opt out)? Is it ok to tell employees when the= y sign their contract but never warn them when you're doing it for sensitive= info? etc) but it's definitely worth making that need for transparency crystal-clear, even if we don't nec= essarily define what is an acceptable level of transparency.
Feel free to forward this to whatever email list it may be discussed on= . It wasn't clear from the draft name where this was headed. 

= Thanks,

=  

= Wes George

=  

= Anything below this line has been= added by my company=E2=80=99s mail server, I have no control over it.<= /o:p>

= -----------


This E-mail and any of its at= tachments may contain Time Warner Cable proprietary information, which is pr= ivileged, confidential, or subject to copyright belonging to Time Warner Cab= le. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you ar= e not the intended recipient of this E-mail, you are hereby notified that an= y dissemination, distribution, copying, or action taken in relation to the c= ontents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receive= d this E-mail in error, please notify the sender immediately and permanently= delete the original and any copy of this E-mail and any printout.
= --Apple-Mail-35E98D6F-7B56-419C-A783-56200E8983EB-- From nobody Thu Mar 12 08:04:06 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10CE1A7022 for ; Tue, 10 Mar 2015 13:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYu2SGI-awzY for ; Tue, 10 Mar 2015 13:04:55 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 547251A0687 for ; Tue, 10 Mar 2015 13:04:55 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 577376D7B5; Tue, 10 Mar 2015 16:04:53 -0400 (EDT) Message-ID: <54FF4E62.7040208@iang.org> Date: Tue, 10 Mar 2015 20:04:50 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Stephen Farrell References: <54F9C81D.3000106@cs.tcd.ie> In-Reply-To: <54F9C81D.3000106@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 08:04:04 -0700 Subject: Re: [saag] is one or two ports "more secure" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 20:04:56 -0000 On 6/03/2015 15:30 pm, Stephen Farrell wrote: > > Thanks folks, I think you've re-enforced my perception > that this is not something on which we have consensus. > It clearly is something where folks feel strongly, and > want to convince others, but that is not the same. If > someone wants to write a draft on the topic, then I'm > sure we can make space for discussion of that at a > future saag session (not Dallas, that's kinda full > already) and we could take it from there. Two ports correlates with lack of consensus. Try mandating one port, and see if consensus follows ;) iang From nobody Fri Mar 13 07:46:33 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3A31A89B5 for ; Fri, 13 Mar 2015 07:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNJGdgHdZVBT for ; Fri, 13 Mar 2015 07:46:30 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB1B1A89B3 for ; Fri, 13 Mar 2015 07:46:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 99E6EE2049 for ; Fri, 13 Mar 2015 10:46:29 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 07744-10 for ; Fri, 13 Mar 2015 10:46:28 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 26570E2048 for ; Fri, 13 Mar 2015 10:46:28 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2DEkR2t022944; Fri, 13 Mar 2015 10:46:27 -0400 From: Derek Atkins To: saag@ietf.org Date: Fri, 13 Mar 2015 10:46:27 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: [saag] Possible rechartering of OpenPGP Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 14:46:31 -0000 Hi, Over the past couple days there's been some discussion on the possibility of rechartering the OpenPGP working group. Some of the discussions have been about updating RFCs 4880, 3156, and 6637. Other discussions have been about new features and/or algorithms. If you're interested in this topic I suggest you subscribe to the OpenPGP mailing list We are planning a Bar BOF in Dallas to discuss possible rechartering. The exact date, time, and location will be sent to the openpgp mailing list. Assuming this BOF happens before Thursday I'll give a report in SAAG. Happy Encrypting! -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Sat Mar 14 08:01:37 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356D81A8965; Fri, 13 Mar 2015 10:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5xQ1Jp5BPXN; Fri, 13 Mar 2015 10:11:39 -0700 (PDT) Received: from emvm-gh1-uea08.nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 135771A8A9A; Fri, 13 Mar 2015 10:11:33 -0700 (PDT) X-TM-IMSS-Message-ID: <8a06fd0800122d48@nsa.gov> Received: from MSHT-GH1-UEA01.corp.nsa.gov (msht-gh1-uea01.corp.nsa.gov [10.215.227.18]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 8a06fd0800122d48 ; Fri, 13 Mar 2015 13:11:26 -0400 Received: from MSMR-GH1-UEA08.corp.nsa.gov (10.215.225.3) by MSHT-GH1-UEA01.corp.nsa.gov (10.215.227.18) with Microsoft SMTP Server (TLS) id 14.2.347.0; Fri, 13 Mar 2015 13:11:31 -0400 Received: from MSMR-GH1-UEA04.corp.nsa.gov ([10.215.228.141]) by MSMR-GH1-UEA08.corp.nsa.gov ([10.215.225.3]) with mapi id 14.02.0347.000; Fri, 13 Mar 2015 13:11:30 -0400 From: "Boyle, Vincent M" To: "'saag@ietf.org'" Thread-Topic: looking to hold a TLS VPN side meeting at IETF 92 Thread-Index: AdBdsL81XCyfXC5pQPeZlyI69acR3g== Date: Fri, 13 Mar 2015 17:11:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.225.46] Content-Type: multipart/alternative; boundary="_000_E18BF42C3D667642ABC0EF4B6064EB67D0918938MSMRGH1UEA04cor_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 14 Mar 2015 08:01:36 -0700 Cc: "'ipsec@ietf.org'" , "'tls@ietf.org'" Subject: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 17:11:43 -0000 --_000_E18BF42C3D667642ABC0EF4B6064EB67D0918938MSMRGH1UEA04cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I'm planning to hold a side meeting at IETF 92 to gauge int= erest in creating a standard for TLS VPNs. One motivating use case for my o= rganization is the need to protect data between an app on a mobile device = and the enterprise network that it connects to. For many of our customers,= a TLS-based solution is preferable to IPSec (perhaps because their vendors= support the former). For some sensitive military applications, there is a = requirement to provide two layers of encryption, so using TLS for the secon= d layer makes sense. Having each app invoke TLS is problematic because it i= ntroduces validation costs for each app before it is deployed (to ensure th= at it correctly implements TLS or makes the appropriate OS calls). We would= prefer the option of validating a TLS VPN product and having it available = for use by all apps on the device. To create the necessary validation requi= rements and test activities, we need to have a standard that we can point t= o. The development of an open standard would provide a consistent and fair= method of measuring security (using Protection Profiles) which scales to e= nable the validation and testing of TLS VPNs. Beyond this specific (but fairly pressing) use case, we bel= ieve that there are many organizations that would benefit from the availabi= lity of a standards-based, validated mechanism to protect communications be= tween their mobile devices and the enterprise network. Please discuss on the saag mail list. I will schedule a me= eting time at a local drinking establishment for either Monday or Wednesday= at 7:30 PM (local Dallas time). I'd appreciate feedback on the meeting tim= es (if you expect to attend) as well as any comment on the usefulness or fe= asibility of this effort. Thanks, Mike Boyle Standards Lead Information Assurance Directorate, NSA --_000_E18BF42C3D667642ABC0EF4B6064EB67D0918938MSMRGH1UEA04cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

        &nbs= p;       I’m planning to hold a side me= eting at IETF 92 to gauge interest in creating a standard for TLS VPNs. One= motivating use case for my organization is the need to  protect data = between an app on a mobile device and the enterprise network that it connects to.  For many of our customers, a TLS-based = solution is preferable to IPSec (perhaps because their vendors support the = former). For some sensitive military applications, there is a requirement t= o provide two layers of encryption, so using TLS for the second layer makes sense. Having each app invoke TLS is = problematic because it introduces validation costs for each app before it i= s deployed (to ensure that it correctly implements TLS or makes the appropr= iate OS calls). We would prefer the option of validating a TLS VPN product and having it available for use= by all apps on the device. To create the necessary validation requirements= and test activities, we need to have a standard that we can point to. &nbs= p;The development of an open standard would provide a consistent and fair method of measuring security (using Pr= otection Profiles) which scales to enable the validation and testing of TLS= VPNs.

 

        &nbs= p;       Beyond this specific (but fairly pre= ssing) use case, we believe that there are many organizations that would be= nefit from the availability of a standards-based, validated mechanism to pr= otect communications between their mobile devices and the enterprise network.

 

        &nbs= p;       Please discuss on the  saag mai= l list. I will schedule a meeting time at a local drinking establishment fo= r either Monday or Wednesday at 7:30 PM (local Dallas time). I’d appr= eciate feedback on the meeting times (if you expect to attend) as well as any comment on the usefulness or feasibility = of this effort.

 

Thanks,

Mike Boyle

Standards Lead

Information Assurance Directorate, NSA

--_000_E18BF42C3D667642ABC0EF4B6064EB67D0918938MSMRGH1UEA04cor_-- From nobody Sat Mar 14 10:20:53 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778C11A0099 for ; Sat, 14 Mar 2015 10:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isWmrnmAF7uj for ; Sat, 14 Mar 2015 10:20:51 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8DA1A008B for ; Sat, 14 Mar 2015 10:20:50 -0700 (PDT) Received: by wibdy8 with SMTP id dy8so9221599wib.0 for ; Sat, 14 Mar 2015 10:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=DMIY0DaVnDF6YDK1Tz8izZfx9GUPQRckQ6/6AwCrIPs=; b=znJrrUEMpo4QpTo+k3U1vg8vWHk4KptMCFKhqplhTiG3RxtN86qzBj0cu0YTDrLCM8 JD0OKd4FlD52acxGkbg6m7XawKq0dWMBA8MAx1Xwa46YZXFfIZ/RUDoJ8wJ0+mqaP8qr D9l5IG0sB1dq/jNyQ47QAWp2OWZjDDVxa8VdQ8GmEIrCDcr9C/ESR1gS6fSi/vqi75X3 7WJj2mT1BE8yFceWYFm/NCvytJAzot5XcDolF64/doOexTlH7S1rcFS2LO5nDxLuww1u AM3Oj0DY8uaN85VyFktwbkN3VhFa4TU1okKz9FSgGv2jVL4pcNuWgK/z/yMwuPXBELZW 23kA== X-Received: by 10.180.95.97 with SMTP id dj1mr106666057wib.43.1426353649699; Sat, 14 Mar 2015 10:20:49 -0700 (PDT) Received: from nomad (ip-94-112-138-148.net.upcbroadband.cz. [94.112.138.148]) by mx.google.com with ESMTPSA id lg18sm7723355wic.23.2015.03.14.10.20.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Mar 2015 10:20:48 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <1426353642.28541.3.camel@gnutls.org> From: Nikos Mavrogiannopoulos To: "Boyle, Vincent M" Date: Sat, 14 Mar 2015 18:20:42 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: "'saag@ietf.org'" Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 17:20:52 -0000 On Fri, 2015-03-13 at 17:11 +0000, Boyle, Vincent M wrote: > Hi all, > > I’m planning to hold a side meeting at IETF 92 to > gauge interest in creating a standard for TLS VPNs. One motivating use > case for my organization is the need to protect data between an app > on a mobile device and the enterprise network that it connects to. > For many of our customers, a TLS-based solution is preferable to IPSec > (perhaps because their vendors support the former). I'm certainly interested though I will not be at the meeting. I already work on documenting -and implementing- such a protocol: https://github.com/openconnect/protocol so a standardized variant is certainly a good thing. regards, Nikos From nobody Sat Mar 14 10:23:38 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242421A0099 for ; Sat, 14 Mar 2015 10:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL_mC9ohoe7a for ; Sat, 14 Mar 2015 10:23:35 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D1C1A00B0 for ; Sat, 14 Mar 2015 10:23:35 -0700 (PDT) Received: by ykfs63 with SMTP id s63so4666243ykf.2 for ; Sat, 14 Mar 2015 10:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0tysMT2BtEZ7zVT1i6H/hepgivfQO2vHvGqSZod9siU=; b=Xgn2l57eDiBHUPLJinMXBKISOF6JIHL33OX9esz/NrNial7VD3FI5N2WFVky8KfED9 PBytpi958/HJQMCDgK3AWCYu+qteb/ym7QtH+MF4SWWUHHZYU2+kic3iRfOQjkuo8zm9 zfHAaIo05h2B4Yx9Y5wpUTv2pmB09a/zqziOtfmG+gw0Q9s5ny33LzB6PDS0lArUHQMn wWityFjUF5Z0V9SUsrJ8OLWWO3Z8qNlrGYjLytgrvG9Ehx7dCZdZUObA1CuRci3r5AfM fjeqssRvwvwn+u3s7o53IcyuDtpduu/aTwr/HfZtmxuAAX6rqsJqbxdQ3RIHWruMSleP EHvQ== MIME-Version: 1.0 X-Received: by 10.236.209.129 with SMTP id s1mr51740234yho.49.1426353815010; Sat, 14 Mar 2015 10:23:35 -0700 (PDT) Received: by 10.170.58.201 with HTTP; Sat, 14 Mar 2015 10:23:34 -0700 (PDT) In-Reply-To: <1426353642.28541.3.camel@gnutls.org> References: <1426353642.28541.3.camel@gnutls.org> Date: Sat, 14 Mar 2015 10:23:34 -0700 Message-ID: From: Watson Ladd To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Boyle, Vincent M" , "saag@ietf.org" Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 17:23:37 -0000 On Sat, Mar 14, 2015 at 10:20 AM, Nikos Mavrogiannopoulos wrote: > On Fri, 2015-03-13 at 17:11 +0000, Boyle, Vincent M wrote: >> Hi all, >> >> I=E2=80=99m planning to hold a side meeting at IETF 92 t= o >> gauge interest in creating a standard for TLS VPNs. One motivating use >> case for my organization is the need to protect data between an app >> on a mobile device and the enterprise network that it connects to. >> For many of our customers, a TLS-based solution is preferable to IPSec >> (perhaps because their vendors support the former). > > I'm certainly interested though I will not be at the meeting. I already > work on documenting -and implementing- such a protocol: > https://github.com/openconnect/protocol so a standardized variant is > certainly a good thing. Isn't this exactly what OpenVPN does? It seems to me that we should not reinvent the wheel, but instead focus on documenting existing work and learning from experience. > > regards, > Nikos > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sat Mar 14 10:31:31 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2D51A00E1 for ; Sat, 14 Mar 2015 10:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AV5vz2PdW2V2 for ; Sat, 14 Mar 2015 10:31:27 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (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 688B41A0033 for ; Sat, 14 Mar 2015 10:31:27 -0700 (PDT) Received: by wegp1 with SMTP id p1so11649474weg.1 for ; Sat, 14 Mar 2015 10:31:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=eeig4CA+eHOxTZDkReCxPYWDY7193hJScIfO4wM2cm8=; b=as4PdEepVVU+kAyfXCpK6NE6UntHT1fnYamw0FAZX66ZuiH4TS3eO4g+QMAJrLLEtk WXvlxaAVOEfGowKHtRqAoISoV0flbB3lq9lvr8oCUWRXvlYnI2eg6XBkkkdCHWxHl7kW OYrgOCGQ8brK4KsUYyjO62AFktak59Q6Eaq5fy5qgCp4LyduY2fM8O5rIQV/KlwQF+MS ZiW/Oe+0VzI4rPeBjpSxUN91pW1GRyiPmGSlnUR4M42qXw5D+kZQXQqoz7YgqwujxGZf HNwm+KgAEzoIYTNCBLMAH8AVTeZLcrcUl84+enCtB4n+SOOqo0Xfnj5AG1q//4wlQ5DS hleA== X-Gm-Message-State: ALoCoQmoasuh2iMA/xg8k9ZHFwNde5R+qAaa8ZJ9pbJ3/qmEOOXmscI+ji/iW77trKIUabKtQl5i X-Received: by 10.194.19.10 with SMTP id a10mr109525604wje.153.1426354286167; Sat, 14 Mar 2015 10:31:26 -0700 (PDT) Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id dz6sm7813227wib.0.2015.03.14.10.31.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Mar 2015 10:31:25 -0700 (PDT) Message-ID: <55047069.5000402@azet.org> Date: Sat, 14 Mar 2015 18:31:21 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Watson Ladd References: <1426353642.28541.3.camel@gnutls.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE23B080E8C3698E3689DD621" Archived-At: Cc: "Boyle, Vincent M" , "saag@ietf.org" Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 17:31:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE23B080E8C3698E3689DD621 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Watson Ladd wrote: > On Sat, Mar 14, 2015 at 10:20 AM, Nikos Mavrogiannopoulos > wrote: >=20 > Isn't this exactly what OpenVPN does? It seems to me that we should > not reinvent the wheel, but instead focus on documenting existing work > and learning from experience. >=20 No. OpenVPN uses a duplexed connection (data, metadata), they authenticate with TLS but from thereon they drop to AES-CBC encrypt-then-mac. Aaron --------------enigE23B080E8C3698E3689DD621 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVBHBqAAoJEOTbZJL9ubXV5VUP/34YXBXgefgCfgIj/HJ9yrQA 059IEgFiN8krInLuKtlzYA9GyACPz8hYTzikVSXWivs5b5duLeG7vH8RZxhoNqBj x8jLNn+aU0Wptu1ZldQgnxrG5Ghu8RtMrOEotLd91qpDnCCStfby+OwYLpn3PkLm kApVzttb7uOE2sf6NyUPzHdH9k1DWjMrBrafKWI9GRYmVt2W6yjCqpZHzI7QmAgC +ThTjVDjVBop8MFHB+M0XKOXzXBO52X48UPf18ZTQbhJbV8DU9x4JFLsTwgiCLsz G4zRy6xVVEcjDEKGcE7tkrh0oMKK5FlcDWaR8k2id/ZxAiYidH6jL316jgyGQH1j d/Dp3EjodxMkAk6X26AbLH+ja5pNiopzg9KEoRHgFZJcxPEl5il1pSGaVOwz7nob NyEuiNEcayJgivyoO3o2YiRWCFsc5JCMNV77hYzO5qSeLvJYo6lt2svBVk6BJxrz GxPJR0RxME+Va4g3TU2qP8FoZmC1tboi10fm7RY/8JWZp6lYKaQnKdePO2Lm4i+P JvNBHp+I9jtDiEiJCtSRGHi7Fno5tA9UYK4aDPX7e2rCSWUpQdOUFLeWINJ91wYY oMGbG0k4Y1sMF7v5SVTJn5UIrRW5SJX/dxrTzs+A+rP1gPHA4G82lXem5z2qmw5q mFoHAisUkwSwbbzRO4wt =6Gcu -----END PGP SIGNATURE----- --------------enigE23B080E8C3698E3689DD621-- From nobody Sat Mar 14 10:41:07 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2E81A00C5 for ; Sat, 14 Mar 2015 10:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPwZpBkYOy_O for ; Sat, 14 Mar 2015 10:41:04 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F4121A00FD for ; Sat, 14 Mar 2015 10:41:02 -0700 (PDT) Received: by wifj2 with SMTP id j2so10924891wif.1 for ; Sat, 14 Mar 2015 10:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=vaXzbtlAWMjUuItFQBg8SRp34b2dPytLD3TZRfo2UJU=; b=GRVU5X4blnkoi8Z0oi/+k04xPyY9L5vFKUPYxNlfTTu7QrGLoA+OZ+InDDVypJPxF+ l7Yjk4qDQ/OcMDHsfTFanPpKvdgnUYGnbNlHGVbsHttam7SzKewiPKG5oJT4p79cvKmh zNcBAwhVx1imWDTxawzwrg0/1KfVHrvB9kHjjez6m7Pf6ujQCQbgaIUWVMctAEjlg8al d2aMoSn6tMDqs1wFtPIwsPkbnMIRrrt2ReTpLHRL+qvqKTrlrsYxfn5D18KjknwO4ZRw LRKpUGVP5uPd9FiZemDSrwnmQlCvlEMUXFGTpKYjsuHYoPoPpxCx2hpukMsdzMed4MvM BeDA== X-Received: by 10.180.108.81 with SMTP id hi17mr49917211wib.91.1426354861339; Sat, 14 Mar 2015 10:41:01 -0700 (PDT) Received: from nomad (ip-94-112-138-148.net.upcbroadband.cz. [94.112.138.148]) by mx.google.com with ESMTPSA id l9sm7804571wij.16.2015.03.14.10.41.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Mar 2015 10:41:00 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <1426354854.28541.5.camel@gnutls.org> From: Nikos Mavrogiannopoulos To: Watson Ladd Date: Sat, 14 Mar 2015 18:40:54 +0100 In-Reply-To: References: <1426353642.28541.3.camel@gnutls.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 17:41:05 -0000 On Sat, 2015-03-14 at 10:23 -0700, Watson Ladd wrote: > On Sat, Mar 14, 2015 at 10:20 AM, Nikos Mavrogiannopoulos > wrote: > > On Fri, 2015-03-13 at 17:11 +0000, Boyle, Vincent M wrote: > >> Hi all, > >> > >> I’m planning to hold a side meeting at IETF 92 to > >> gauge interest in creating a standard for TLS VPNs. One motivating use > >> case for my organization is the need to protect data between an app > >> on a mobile device and the enterprise network that it connects to. > >> For many of our customers, a TLS-based solution is preferable to IPSec > >> (perhaps because their vendors support the former). > > > > I'm certainly interested though I will not be at the meeting. I already > > work on documenting -and implementing- such a protocol: > > https://github.com/openconnect/protocol so a standardized variant is > > certainly a good thing. > > Isn't this exactly what OpenVPN does? It seems to me that we should > not reinvent the wheel, but instead focus on documenting existing work > and learning from experience. No it is not. We should check before we talk also. From nobody Sat Mar 14 11:21:40 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44271A00EF; Sat, 14 Mar 2015 11:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tY16nLt8tbbQ; Sat, 14 Mar 2015 11:21:38 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8971A00C8; Sat, 14 Mar 2015 11:21:38 -0700 (PDT) Received: by wixw10 with SMTP id w10so11399445wix.0; Sat, 14 Mar 2015 11:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=HCkgWH9OcYpZ+v8LcK8G6NZ5+Ccwc7sz1b6y6K+rqN4=; b=KcGVOmA90gwS+xsK53RbuD/AhMLbwk4/Ny+P5XNVgrqj8IJjdMVNnWaW5R4qziQLEg aYAiYL3yEvUsdIGUND1M5srU07gqiXVzFEb1IQPiBbDT5qsSIITqfPQCBnkVdkXf5ZgH HgTQ0UQSQHt71nXuzHq5loUrm4P/y2lNAXIZqupF4pUVQrtu7JzPbbyPCipNSx87OLUV Zid0sSgVCFCrgY4Em3j6VU4FbhsyAE4phB74uIVaj8+t/Wt241cdoe072yUH9oiodPUA s5Iz2LsGq1KMhwg5iKzTYR1bz18mdGQlLwFEVajW2wKeozRFingjYW55IebWlLmB+RzY A4vQ== X-Received: by 10.180.98.67 with SMTP id eg3mr40191276wib.11.1426357297004; Sat, 14 Mar 2015 11:21:37 -0700 (PDT) Received: from [192.168.1.13] ([46.120.13.132]) by mx.google.com with ESMTPSA id ka1sm7996177wjc.2.2015.03.14.11.21.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Mar 2015 11:21:36 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F704F348-AB4A-4A80-B0EB-8D23AC87B890" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Sat, 14 Mar 2015 20:21:34 +0200 Message-Id: References: To: "Boyle, Vincent M" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ipsec@ietf.org" , Security Area Advisory Group , "tls@ietf.org" Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 18:21:39 -0000 --Apple-Mail=_F704F348-AB4A-4A80-B0EB-8D23AC87B890 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Mike > Please discuss on the saag mail list. I will schedule = a meeting time at a local drinking establishment for either Monday or = Wednesday at 7:30 PM (local Dallas time). I=E2=80=99d appreciate = feedback on the meeting times (if you expect to attend) as well as any = comment on the usefulness or feasibility of this effort. On Wednesday there is going to be a I2NSF side meeting that is likely to = attract many of the same people. I would go with Monday. Yoav= --Apple-Mail=_F704F348-AB4A-4A80-B0EB-8D23AC87B890 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Mike

      =           Please discuss on the  saag mail = list. I will schedule a meeting time at a local drinking establishment = for either Monday or Wednesday at 7:30 PM (local Dallas time). I=E2=80=99d= appreciate feedback on the meeting times (if you expect to attend) as = well as any comment on the usefulness or feasibility of this = effort.

On Wednesday there is going to be a = I2NSF side meeting that is likely to attract many of the same people. I = would go with Monday.

Yoav
= --Apple-Mail=_F704F348-AB4A-4A80-B0EB-8D23AC87B890-- From nobody Sat Mar 14 11:26:40 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F8C1A00EF for ; Sat, 14 Mar 2015 11:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmVcZD31W5En for ; Sat, 14 Mar 2015 11:26:36 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id DB98A1A002C for ; Sat, 14 Mar 2015 11:26:36 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4895548879; Sat, 14 Mar 2015 18:26:36 +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 3BED548878; Sat, 14 Mar 2015 18:26:36 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas5.msg.corp.akamai.com [172.27.25.34]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 37DB69803E; Sat, 14 Mar 2015 18:26:36 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sat, 14 Mar 2015 13:26:35 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.0913.011; Sat, 14 Mar 2015 13:26:35 -0500 From: "Salz, Rich" To: Watson Ladd , Nikos Mavrogiannopoulos Thread-Topic: [saag] looking to hold a TLS VPN side meeting at IETF 92 Thread-Index: AdBdsL81XCyfXC5pQPeZlyI69acR3gA9FxsAAAAZoQAACEpGgA== Date: Sat, 14 Mar 2015 18:26:34 +0000 Message-ID: References: <1426353642.28541.3.camel@gnutls.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.56.88] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Boyle, Vincent M" , "saag@ietf.org" Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 18:26:38 -0000 DQo+IElzbid0IHRoaXMgZXhhY3RseSB3aGF0IE9wZW5WUE4gZG9lcz8gSXQgc2VlbXMgdG8gbWUg dGhhdCB3ZSBzaG91bGQgbm90DQo+IHJlaW52ZW50IHRoZSB3aGVlbCwgYnV0IGluc3RlYWQgZm9j dXMgb24gZG9jdW1lbnRpbmcgZXhpc3Rpbmcgd29yayBhbmQNCj4gbGVhcm5pbmcgZnJvbSBleHBl cmllbmNlLg0KDQpEb24ndCBqdW1wIHRvIGNvbmNsdXNpb25zOyBpdCBjb3VsZCBiZSB0aGF0J3Mg ImFsbCIgdGhhdCdzIGRvbmUuDQo= From nobody Sat Mar 14 11:36:10 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FD41A00FE for ; Sat, 14 Mar 2015 11:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yaFqzzyyqLs for ; Sat, 14 Mar 2015 11:36:07 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::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 D7B9E1A00EF for ; Sat, 14 Mar 2015 11:36:06 -0700 (PDT) Received: by wejb47 with SMTP id b47so12248980wej.0 for ; Sat, 14 Mar 2015 11:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9oleYl6DqPTwjtEwumaKUoC+DjCs8deWI6aq1yXbyk0=; b=aWuOCW3i7SCQsvk7oKB19ZeBAh2RBCxqS0Rxtp5Smss8qp7BF2qb73KS1wcjG3JXs9 14yzxdewpRJPoYhnz/xIsQIBdZLG7JShiAgfllJ/BKH6kS6OnBHP7Onvc3Qf521bCnGI edUV7vV+efS+Cm8kSGl+1gBUlSeWxKlaeOSCT73hLIjAYvkS1ztDYxLFK8mly6baGE+V GYLBgxw+soaCR2Z4f6q+47rPzTZ8zOJqPIsGj43AJT5m7Rgr06Ar+KqfS4OaIuAvKm/h 19C/3i8F7qQ/3VOcsSmyG3MmGRoCq0l0qdv9f1Dze1cYAd5Q1tY56FEDDx/r/DdkavZa lnDg== X-Received: by 10.180.107.71 with SMTP id ha7mr151663576wib.23.1426358165565; Sat, 14 Mar 2015 11:36:05 -0700 (PDT) Received: from [192.168.1.13] ([46.120.13.132]) by mx.google.com with ESMTPSA id w8sm8040361wja.4.2015.03.14.11.36.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Mar 2015 11:36:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Sat, 14 Mar 2015 20:36:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1FD06F74-3766-49FE-9BA9-16D75737F2B9@gmail.com> References: <1426353642.28541.3.camel@gnutls.org> To: Watson Ladd X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "Boyle, Vincent M" , Security Area Advisory Group Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 18:36:08 -0000 > On Mar 14, 2015, at 7:23 PM, Watson Ladd = wrote: >=20 > On Sat, Mar 14, 2015 at 10:20 AM, Nikos Mavrogiannopoulos > wrote: >> On Fri, 2015-03-13 at 17:11 +0000, Boyle, Vincent M wrote: >>> Hi all, >>>=20 >>> I=E2=80=99m planning to hold a side meeting at IETF = 92 to >>> gauge interest in creating a standard for TLS VPNs. One motivating = use >>> case for my organization is the need to protect data between an app >>> on a mobile device and the enterprise network that it connects to. >>> For many of our customers, a TLS-based solution is preferable to = IPSec >>> (perhaps because their vendors support the former). >>=20 >> I'm certainly interested though I will not be at the meeting. I = already >> work on documenting -and implementing- such a protocol: >> https://github.com/openconnect/protocol so a standardized variant is >> certainly a good thing. >=20 > Isn't this exactly what OpenVPN does? It seems to me that we should > not reinvent the wheel, but instead focus on documenting existing work > and learning from experience. No, but SSL VPNs are for the most part proprietary protocols, so each = vendor has their own. The sort-of exception is Microsoft=E2=80=99s SSTP = comes pre-packaged with Windows, so vendors could rely on it rather than = allowing you to download the client from a portal. The thing is that standardizing a protocol is only good where = interoperability is required, so that one vendor=E2=80=99s client works = with another vendor=E2=80=99s server. This is important in many = applications, but hasn=E2=80=99t been in remote access VPNs, for which = SSL is one technology.=20 Yoav From nobody Sat Mar 14 11:38:14 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C5D1A00CA for ; Sat, 14 Mar 2015 11:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6Kd0cafqMzg for ; Sat, 14 Mar 2015 11:38:12 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1271A0039 for ; Sat, 14 Mar 2015 11:38:12 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l4CM46s1yz449; Sat, 14 Mar 2015 19:38:08 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=RLdeQRM6; dkim-adsp=pass X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id N0x4_1iRoExn; Sat, 14 Mar 2015 19:38:07 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 14 Mar 2015 19:38:07 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 515A6803E0; Sat, 14 Mar 2015 14:38:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426358285; bh=SxVqpdggDZ4T+6wRIE07G3iKNAPFyHApB7mxQmfhISw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=RLdeQRM6NnLEbaRpA5ZTjL9QKLvWVkIiA+apK4RnZy2Q3wFi/XDA/8acHS6lg27jh cgyzVcLXDtpEk0t04QsgZ2uk76q+/ajd603IxB+9gNqUVael7Us3+vogYf9H5KRI18 T2wzaRanWRZj6ICxNEzZw8zU7rb23YldzvN1aq64= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2EIc4iH012077; Sat, 14 Mar 2015 14:38:05 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sat, 14 Mar 2015 14:38:04 -0400 (EDT) From: Paul Wouters To: "Boyle, Vincent M" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] [TLS] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 18:38:13 -0000 On Sat, 14 Mar 2015, Yoav Nir wrote: > Hi, Mike >                 Please discuss on the  saag mail list. I will schedule a meeting time at a local > drinking establishment for either Monday or Wednesday at 7:30 PM (local Dallas time). I’d > appreciate feedback on the meeting times (if you expect to attend) as well as any comment on the > usefulness or feasibility of this effort. > > > On Wednesday there is going to be a I2NSF side meeting that is likely to attract many of the same people. I > would go with Monday. Monday there will be an openpgp side meeting that is likely to attract many of the same people. Paul From nobody Sat Mar 14 12:47:56 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67A71A0204; Sat, 14 Mar 2015 12:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFumaO-AK18y; Sat, 14 Mar 2015 12:47:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1FE1A0194; Sat, 14 Mar 2015 12:47:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EF90120012; Sat, 14 Mar 2015 15:57:05 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7D49263784; Sat, 14 Mar 2015 15:47:49 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 67D48636B6; Sat, 14 Mar 2015 15:47:49 -0400 (EDT) From: Michael Richardson To: "Boyle\, Vincent M" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: "'ipsec@ietf.org'" , "'saag@ietf.org'" , "'tls@ietf.org'" Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 19:47:53 -0000 --=-=-= Content-Type: text/plain I sure hope that you will give us a definition of a TLS VPN. It's really important that we know what is in scope and what is not. My take is that solutions that run TCP and/or HTTPS proxy over TLS, are not TLS VPNs, because they don't pass the "N"etwork part of VPN. They are useful mechanisms, and I'm all for standardizing them, but the word VPN should not be applied. OpenVPN is a TLS keyed VPN. It can and does run over a single TCP port, but that has congestion issues (tcp over tcp), so running the data part it over UDP is preferrale, but not always possible. (Meanwhile,there are IPsec vendors that run ESP over TCP in non-standard fashions...) I'd like to see some convergence at the dataplane side. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVQSQZYCLcPvd0N1lAQJyIAf/c7X5sxRvcVQgaY2Lll11d8IxEFqh0/q3 U/dBnT6EJHW4h6g1rRlqVFmFyUPXSwqZZiPvSfG1s1bE2ew4Q7k9Fspj1sbUGBL5 U294sZpxCeCrSBUhnqH/nopap5hReAU54VgEjlEebmn8PGHuNn7y537+tIq09yQM os+uIf/O1OAgTwcX8WzYMg4BQuUb7hQqA21JzENeBSxsYgim4aPKAQXCu3krlguz ZTXSH+7Bkne/z/6PhHkdqg7BpDhPgxqZwT/rmrmmAAJu0a5Ou5iQdaa+HWgPZibe 6QIMS/9Ah0TBFjrT3MJ/EoR1cLoU/GTZvA3xM6rcDsY/7Bvkigieig== =7djO -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Mar 15 18:46:30 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7D11A1EF6 for ; Sun, 15 Mar 2015 18:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9da1cTr-Jbba for ; Sun, 15 Mar 2015 18:46:25 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9831A1EF4 for ; Sun, 15 Mar 2015 18:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1426470385; x=1458006385; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Axs5qsApvJZ1e0FnqU6w/d+Xx8u5UwIYN/QI4SKcA9M=; b=QKaMe3OM/YmvIg/Id0Xqo/bQvs0a4hoOdH29nMj6KkUwQOdy2W8ut0VG ZfkfXq83eR2XXYCxm9L60CdmGDDSvQa9DX1fSi7zefetttIgJeyk3bHWK NjriJ4ccoiQQof8sWx8oj1J2Aga89ty54xJHC06HstS5STTDRtDqVCsci Q=; X-IronPort-AV: E=Sophos;i="5.11,407,1422874800"; d="scan'208";a="314020773" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 16 Mar 2015 14:46:23 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Mon, 16 Mar 2015 14:46:22 +1300 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] looking to hold a TLS VPN side meeting at IETF 92 Thread-Index: AdBfiwGx3E0240cQQheNCmw3PCyb0g== Date: Mon, 16 Mar 2015 01:46:22 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFB25C2@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 01:46:29 -0000 Yoav Nir writes:=0A= =0A= >The thing is that standardizing a protocol is only good where=0A= >interoperability is required, so that one vendor=92s client works with ano= ther=0A= >vendor=92s server. This is important in many applications, but hasn=92t be= en in=0A= >remote access VPNs, for which SSL is one technology.=0A= =0A= What would be achieved by creating yet another new standard (insert obligat= ory=0A= XKCD reference) in this area though? If you want (allegedly) interoperable= =0A= VPN technology you've got IPsec. If you want something that doesn't suck= =0A= quite as badly, you've got either OpenVPN or (admittedly) vendor-specific S= SL=0A= VPNs, although hopefully at least built around DTLS. What fraction of=0A= whatever's left will be served by yet another VPN standard, and will anyone= =0A= care enough to make it worthwhile?=0A= =0A= (Just trying to see what actual problem is being solved here).=0A= =0A= Peter.=0A= From nobody Sun Mar 15 21:20:00 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F346C1A0019 for ; Sun, 15 Mar 2015 21:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oazBDjDuHzR8 for ; Sun, 15 Mar 2015 21:19:57 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59F551A001D for ; Sun, 15 Mar 2015 21:19:57 -0700 (PDT) Received: by wegp1 with SMTP id p1so29448598weg.1 for ; Sun, 15 Mar 2015 21:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ALB8ByzvZFTKHo4SFJiShg2EiUSPPaluuS5QqVXIotg=; b=BI7csNAUBmiSL66WPaXKtVpnKhwUXnXGqZtrjEbAoA67a8FU6KGyl/1dy2Z7kWitTH BHZxPW+V1HuWCMQK24jdpLp+tm35psF1EmfAD8s6+zyaMY9m56AIBQ7GpVPQ4bg12jef oEfUb6eH7vDKkJg2MtUD9IydKB7RsEuhMvp6xtY+7hWEqGfW7voelWILhq5O0OZkJwZc BSimagO3lB8N1ZSzV6oAnDPKGcoA4ZQR9UIjEr9As8iBJdMAozqefFbBJbQxLQB+vn4y Am17G59MaAVI39TGD6VdcBmFCc4k7tjMnf7A388K9vqxH+NMRbLkqFJN69+d1nsn4fKy US0A== X-Received: by 10.180.83.102 with SMTP id p6mr136420396wiy.78.1426479596183; Sun, 15 Mar 2015 21:19:56 -0700 (PDT) Received: from [192.168.1.13] ([46.120.13.132]) by mx.google.com with ESMTPSA id n6sm13535076wjy.8.2015.03.15.21.19.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Mar 2015 21:19:55 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB25C2@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 16 Mar 2015 06:19:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB25C2@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 04:19:59 -0000 > On Mar 16, 2015, at 3:46 AM, Peter Gutmann = wrote: >=20 > Yoav Nir writes: >=20 >> The thing is that standardizing a protocol is only good where >> interoperability is required, so that one vendor=92s client works = with another >> vendor=92s server. This is important in many applications, but hasn=92t= been in >> remote access VPNs, for which SSL is one technology. >=20 > What would be achieved by creating yet another new standard (insert = obligatory > XKCD reference) in this area though? If you want (allegedly) = interoperable > VPN technology you've got IPsec. If you want something that doesn't = suck > quite as badly, you've got either OpenVPN or (admittedly) = vendor-specific SSL > VPNs, although hopefully at least built around DTLS. What fraction of > whatever's left will be served by yet another VPN standard, and will = anyone > care enough to make it worthwhile? >=20 > (Just trying to see what actual problem is being solved here). There=92s usually little benefit in getting CompanyA=92s client working = with CompanyB=92s server when both are VPN vendors. One potential = benefit is what we have with L2TP: that OS vendors can bundle the = client, so no installation is necessary. Another potential benefit is = that a standard allows open source projects and 3rd party vendors to = implement a client for the less popular client platforms that the VPN = vendors can=92t be bothered with. While there have been TLS VPNs built around DTLS, they offer little = benefit over IPsec VPNs. The great feature of TLS VPNs is that they work = over TCP port 443, and thus fool stupid firewalls into allowing this = traffic to pass. The firewall policy of =93allow TCP ports 80 and 443; = allow DNS; block everything else=94 is all too common in hotels, = restaurants and airports. Yoav From nobody Mon Mar 16 01:44:52 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83731A1B19 for ; Mon, 16 Mar 2015 01:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzhhA18PrUZY for ; Mon, 16 Mar 2015 01:44:49 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7211D1A1B18 for ; Mon, 16 Mar 2015 01:44:49 -0700 (PDT) Received: by wifj2 with SMTP id j2so36754526wif.1 for ; Mon, 16 Mar 2015 01:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=z15CVurvhao9MS50iFRcxv2nwtyb5qUDUYR1GDKIB8U=; b=vKXBxaWHpMWgfsD0yyMQ3Q5AqK83Wgn0Rwrclkbm5lkHpnMNwilyQLy2QZ1YvrH8TV 6f6ndN2law0de2zxb8xKRAhY7PO7agtIq3zmQM1kAhG0UDq26eogEOyDvHLGVYZjmv5S QUgRXMKessLcyFiQ/JQlEBxbjR4hzI8VhGkJQrK7WQSedVwQ1g/7L3qk9tTI6Ol0KL/l UnIezVfREJompVbScr6fsPdae/XtJDm9kyXwomDUTjigg7LHyC8gPMI5VYLEkpyp8/J9 SfdCWGzxQAAWeMCnbn0OxSlqsycAP4bomKC2eYO8lBw6ckc34UZswE271Ah90AbptPQV V6hQ== X-Received: by 10.194.200.166 with SMTP id jt6mr75370575wjc.66.1426495488207; Mon, 16 Mar 2015 01:44:48 -0700 (PDT) Received: from [192.168.12.120] (bzq-218-112-74.red.bezeqint.net. [81.218.112.74]) by mx.google.com with ESMTPSA id v8sm9870540wib.0.2015.03.16.01.44.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2015 01:44:47 -0700 (PDT) Message-ID: <550697FE.1020208@gmail.com> Date: Mon, 16 Mar 2015 10:44:46 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Peter Gutmann , "saag@ietf.org" References: <9A043F3CF02CD34C8E74AC1594475C73AAFB25C2@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB25C2@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 08:44:51 -0000 I fully agree with Yoav re: TLS VPNs. Having said that, standards have another benefit in addition to interoperability. A security protocol standard ensures the customer (which is typically an enterprise) that the protocol is at least minimally secure. Thanks, Yaron From nobody Mon Mar 16 03:22:57 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268D51A1B9A for ; Mon, 16 Mar 2015 03:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llt5pzFljF_M for ; Mon, 16 Mar 2015 03:22:55 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::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 CF60B1A0086 for ; Mon, 16 Mar 2015 03:22:54 -0700 (PDT) Received: by lbbzq9 with SMTP id zq9so28047269lbb.0 for ; Mon, 16 Mar 2015 03:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=fP5XbCcCYQCB/H6ii6gP+t6SfkEG1GFe9kYRR9AU6FA=; b=YmFoNWP0/5KrtGkZmp5gX76R522ya5NufZCwAInOvmbBKW0Rzh6oLPJIAfGKMGyX8c ZCnRqo6uRZOCurfnwcfgKv0awcSenArT+0CPzygYQQK9wAfv65v1KSUIgAd/w6InXdm4 48iZEXSMvvj1Zi+A8SrO79dq3DDR5zXvj623QNWVORigWHP5I5laPC9yl5S49nhVuXNd NDnNtZ4BSB/CyJoYeTBxPPizV8ko7uDk4drsGSiPWQmlroD810MjMy2C8LE0fpZvdVAS wgKOeqZxXf0wY/sD/VhkJnvcLuFQ4HCKi+3R5uY7pBrr9F24I7hC+7da365luYux9B2X Hhsg== MIME-Version: 1.0 X-Received: by 10.112.91.165 with SMTP id cf5mr30667483lbb.121.1426501373254; Mon, 16 Mar 2015 03:22:53 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.112.140.104 with HTTP; Mon, 16 Mar 2015 03:22:53 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB25C2@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 16 Mar 2015 11:22:53 +0100 X-Google-Sender-Auth: 3KOFYfO9GrTwinN41TGaA9TC9lI Message-ID: From: Nikos Mavrogiannopoulos To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 10:22:56 -0000 On Mon, Mar 16, 2015 at 5:19 AM, Yoav Nir wrote: >> What would be achieved by creating yet another new standard (insert obli= gatory >> XKCD reference) in this area though? If you want (allegedly) interopera= ble >> VPN technology you've got IPsec. If you want something that doesn't suc= k >> quite as badly, you've got either OpenVPN or (admittedly) vendor-specifi= c SSL >> VPNs, although hopefully at least built around DTLS. What fraction of >> whatever's left will be served by yet another VPN standard, and will any= one >> care enough to make it worthwhile? > There's usually little benefit in getting CompanyA's client working with = CompanyB's server when both are VPN vendors. One potential benefit is what = we have with L2TP: that OS vendors can bundle the client, so no installatio= n is necessary. Another potential benefit is that a standard allows open so= urce projects and 3rd party vendors to implement a client for the less popu= lar client platforms that the VPN vendors can't be bothered with. > While there have been TLS VPNs built around DTLS, they offer little benef= it over IPsec VPNs. The great feature of TLS VPNs is that they work over TC= P port 443, and thus fool stupid firewalls into allowing this traffic to pa= ss. The firewall policy of "allow TCP ports 80 and 443; allow DNS; block ev= erything else" is all too common in hotels, restaurants and airports. I question the "offer little benefit over IPSec". I've seen this argument more than a decade ago, and still the majority of VPNs in use are user-space VPNs based on SSL. The last sentence may actually capture the benefit... it simply works :) regards, Nikos From nobody Mon Mar 16 04:24:39 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AE81A00CD for ; Mon, 16 Mar 2015 04:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7jPRCQzg5qs for ; Mon, 16 Mar 2015 04:24:36 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB911A0110 for ; Mon, 16 Mar 2015 04:24:36 -0700 (PDT) Received: by wibdy8 with SMTP id dy8so34759694wib.0 for ; Mon, 16 Mar 2015 04:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bc8hE7GUM1R1URr/WuCbE0bSfKmevMzVnKOIoPPDOwM=; b=u5bptD3v5vVuecPMAtWoja7WrMq/7pbN+momLjTiGF973JofhehNQzJSAgvbxAWPFf nOfGqZa3oybxsg7x4DflRnVWNjv9X/rZ6txFx+DFCZ2gE2PmfU7aNR+CQ5gtWZHJdz4e 8PgkXM0H4fPLTF4prCK88XFIxgKL7Hr0vtoEkONxiY9B53HRYvSNW3xhvSv49fgbV52J xEh7cj8M+tn/MsbQJYNOp5DX/NzbNpLCf/+Gbw6dMNZ+BM+jcRf1VnFrdYwxuNQ5HXsX psvrEKBqPDGme1ffyHigeFyKwDSR2qGGbZPEkD0r8wCudGtHrjh7L5A7GJTYXgmWYXla TawQ== X-Received: by 10.194.110.38 with SMTP id hx6mr119484126wjb.128.1426505074972; Mon, 16 Mar 2015 04:24:34 -0700 (PDT) Received: from [192.168.1.13] ([46.120.13.132]) by mx.google.com with ESMTPSA id u18sm14937878wib.1.2015.03.16.04.24.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Mar 2015 04:24:34 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Mon, 16 Mar 2015 13:24:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB25C2@uxcn10-5.UoA.auckland.ac.nz> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 11:24:38 -0000 > On Mar 16, 2015, at 12:22 PM, Nikos Mavrogiannopoulos = wrote: >=20 > On Mon, Mar 16, 2015 at 5:19 AM, Yoav Nir wrote: >>> What would be achieved by creating yet another new standard (insert = obligatory >>> XKCD reference) in this area though? If you want (allegedly) = interoperable >>> VPN technology you've got IPsec. If you want something that doesn't = suck >>> quite as badly, you've got either OpenVPN or (admittedly) = vendor-specific SSL >>> VPNs, although hopefully at least built around DTLS. What fraction = of >>> whatever's left will be served by yet another VPN standard, and will = anyone >>> care enough to make it worthwhile? >> There's usually little benefit in getting CompanyA's client working = with CompanyB's server when both are VPN vendors. One potential benefit = is what we have with L2TP: that OS vendors can bundle the client, so no = installation is necessary. Another potential benefit is that a standard = allows open source projects and 3rd party vendors to implement a client = for the less popular client platforms that the VPN vendors can't be = bothered with. >> While there have been TLS VPNs built around DTLS, they offer little = benefit over IPsec VPNs. The great feature of TLS VPNs is that they work = over TCP port 443, and thus fool stupid firewalls into allowing this = traffic to pass. The firewall policy of "allow TCP ports 80 and 443; = allow DNS; block everything else" is all too common in hotels, = restaurants and airports. >=20 > I question the "offer little benefit over IPSec". I've seen this > argument more than a decade ago, and still the majority of VPNs in use > are user-space VPNs based on SSL. The last sentence may actually > capture the benefit... it simply works :) I don=92t have the numbers about the prevalence of IPsec VPNs (including = L2TP) vs SSL VPNs. But please note that those =93user-space VPNs based = on SSL=94 are based on TLS over TCP, not DTLS. DTLS is a UDP connection = over a weird port (443 is a weird port for UDP) that is at least as = likely as UDP port 4500 to be blocked by middleboxes) Yoav From nobody Mon Mar 16 05:19:30 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FB11A8702 for ; Mon, 16 Mar 2015 05:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4gQRuxAUPGn for ; Mon, 16 Mar 2015 05:19:27 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::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 992EB1A86FA for ; Mon, 16 Mar 2015 05:19:26 -0700 (PDT) Received: by ladw1 with SMTP id w1so38032885lad.0 for ; Mon, 16 Mar 2015 05:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=vhKnSeiA+gGdI4gGUneo2vCo92oYsjD/CrAeQqAksS8=; b=JnrCY5VNYBlAUR99szgKUK5Cr0Ksieo+jYU3Q8JQ6ibjnLjXLkM447Hq9v3BRJ8RLn Lj9WSg3HPwWn+/9NuswkG3ndFiq/iqGNLY+mxeRDDbrglrGI+kehp6+T8GRIffCDW8bR gY0z6z69jJhooQZD6tOFgDVw+AxfOBbWJViBDN3tT+ssT/yTLDCCHuzXndvPA9wlDjKM SCGxJ3rsSeB/WnShwFkNycnnfklu3URHfH0KtICi0sov+DIjXw3AxDPi94kYHeg5pmNl AcE9VXdDX122q1KwPxeHyllHs7XbNZnYzRcMOGLNl4F5PbOvfXFBIcXOwgHLrMAhGFPE S0Bw== MIME-Version: 1.0 X-Received: by 10.152.120.202 with SMTP id le10mr40747271lab.115.1426508365045; Mon, 16 Mar 2015 05:19:25 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.112.140.104 with HTTP; Mon, 16 Mar 2015 05:19:24 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB25C2@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 16 Mar 2015 13:19:24 +0100 X-Google-Sender-Auth: e_i51OofkFbShzo53LBjmifu8G4 Message-ID: From: Nikos Mavrogiannopoulos To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 12:19:28 -0000 On Mon, Mar 16, 2015 at 12:24 PM, Yoav Nir wrote: >> I question the "offer little benefit over IPSec". I've seen this >> argument more than a decade ago, and still the majority of VPNs in use >> are user-space VPNs based on SSL. The last sentence may actually >> capture the benefit... it simply works :) > I don't have the numbers about the prevalence of IPsec VPNs (including L2= TP) vs SSL VPNs. But please note that those "user-space VPNs based on SSL" = are based on TLS over TCP, not DTLS. DTLS is a UDP connection over a weird = port (443 is a weird port for UDP) that is at least as likely as UDP port 4= 500 to be blocked by middleboxes) In openconnect we use a protocol which is very close to the cisco anyconnect. That is based on TLS and DTLS. The openconnect client also supports the Juniper SSL VPN, which is based on TLS and ESP packets over UDP. Both seem to work pretty well over middle boxes. The advantage they have is that they don't require the UDP session, if it doesn't work they simply use the TCP channel. regards, Nikos From nobody Mon Mar 16 06:05:43 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67B61A8734 for ; Mon, 16 Mar 2015 06:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JfAxmtCyGe3 for ; Mon, 16 Mar 2015 06:05:38 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF32C1A8732 for ; Mon, 16 Mar 2015 06:05:37 -0700 (PDT) Received: by lbcds1 with SMTP id ds1so30181364lbc.3 for ; Mon, 16 Mar 2015 06:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wcDQiJgU1g0ky+MfRTHp07HBrujltPSdYY0rJ85sdSs=; b=Su5YgkSRVI+l887RUs3Ud4nIRQ4I/zeVDjMGOck/kEqqMJMTLZy7FQyDzXiXSXKzjC z1Hlj75nrsEM+FwPAho7XbKYxbgdEmpPXG7VC3Bj3qAMjRtfa3qN2YAHZpjhO5J3t1/E WaDHTYzqwOntQR0+8CjqPRrbmMOjSzUIyM5Y0yxK//555gPAUI/QH++LixfR7qU8Tw97 nXDPH+8nsvwr8Gb7krtx8NVGQObq5hy3EoOTbeW9T6lhot7o1Vy2HHo6EDkmauhx6y9R gr8+QAQyI9Vzlri8kykNdeIN69cpiazKGtD5eT3VcLjUH7bvBVr+33ypDkn71Mc9G8+9 MUdA== MIME-Version: 1.0 X-Received: by 10.112.161.66 with SMTP id xq2mr55287601lbb.103.1426511136210; Mon, 16 Mar 2015 06:05:36 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Mon, 16 Mar 2015 06:05:36 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Mar 2015 09:05:36 -0400 X-Google-Sender-Auth: 9pjO4RfHdyUht197KANqZs3fpLY Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: multipart/alternative; boundary=001a11c3447e8ac5800511678149 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Possible rechartering of OpenPGP Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 13:05:41 -0000 --001a11c3447e8ac5800511678149 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 13, 2015 at 10:46 AM, Derek Atkins wrote: > Hi, > > Over the past couple days there's been some discussion on the > possibility of rechartering the OpenPGP working group. Some of the > discussions have been about updating RFCs 4880, 3156, and 6637. Other > discussions have been about new features and/or algorithms. > > If you're interested in this topic I suggest you subscribe to the > OpenPGP mailing list > > We are planning a Bar BOF in Dallas to discuss possible rechartering. > The exact date, time, and location will be sent to the openpgp mailing > list. Assuming this BOF happens before Thursday I'll give a report in > SAAG. > > Happy Encrypting! > > -derek > To what end? Right now we have two email standards and a stalemate. PGP has won the mindshare battle and S/MIME has won the deployment battle. Neither side has delivered a product that the typical Internet user is willing to use and neither side is willing to give an inch to the other. And the prospects for end-to-end secure email are currently getting worse with webmail replacing end-to-end mail. Rather than reform to work on "OpenPGP", I think it would be better to develop a successor standard to S/MIME and OpenPGP that allows a single message format to be used with either trust model, or with new trust models. Quite a few things have changed since 1992 and many of the design constraints in S/MIME and OpenPGP no longer apply: * Public Key crypto is now cheap * Can rely on network connectivity to solve some problems * Internet users are not experts and don't want to be * Mail is merely one form of stored document * Crypto libraries typically bundle ASN.1 handling code for PKIX All of the tricks that I use to make S/MIME encryption totally transparent to the end user can be applied to PGP as well. --001a11c3447e8ac5800511678149 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 13, 2015 at 10:46 AM, Derek Atkins <derek@ihtfp.com><= /span> wrote:
Hi,

Over the past couple days there's been some discussion on the
possibility of rechartering the OpenPGP working group.=C2=A0 Some of the discussions have been about updating RFCs 4880, 3156, and 6637.=C2=A0 Other=
discussions have been about new features and/or algorithms.

If you're interested in this topic I suggest you subscribe to the
OpenPGP mailing list <openpgp@ietf.o= rg>

We are planning a Bar BOF in Dallas to discuss possible rechartering.
The exact date, time, and location will be sent to the openpgp mailing
list.=C2=A0 Assuming this BOF happens before Thursday I'll give a repor= t in
SAAG.

Happy Encrypting!

-derek

To what end?
=

Right now we have two email standards and a stalemate. = PGP has won the mindshare battle and S/MIME has won the deployment battle. = Neither side has delivered a product that the typical Internet user is will= ing to use and neither side is willing to give an inch to the other.
<= div>
And the prospects for end-to-end secure email are curren= tly getting worse with webmail replacing end-to-end mail.


Rather than reform to work on "OpenPGP", I= think it would be better to develop a successor standard to S/MIME and Ope= nPGP that allows a single message format to be used with either trust model= , or with new trust models.

Quite a few things hav= e changed since 1992 and many of the design constraints in S/MIME and OpenP= GP no longer apply:

* Public Key crypto is now che= ap
* Can rely on network connectivity to solve some problems
* Internet users are not experts and don't want to be
*= Mail is merely one form of stored document
* Crypto libraries ty= pically bundle ASN.1 handling code for PKIX


All of the tricks that I use to make S/MIME encryption totally tra= nsparent to the end user can be applied to PGP as well.
--001a11c3447e8ac5800511678149-- From nobody Mon Mar 16 07:06:14 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4181A8778 for ; Mon, 16 Mar 2015 07:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7RiRnLMcUmw for ; Mon, 16 Mar 2015 07:06:06 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E281A8774 for ; Mon, 16 Mar 2015 07:05:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 7ED4DE2036; Mon, 16 Mar 2015 10:05:36 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 28376-10; Mon, 16 Mar 2015 10:05:34 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 530D0E203F; Mon, 16 Mar 2015 10:05:34 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2GE5XfV026044; Mon, 16 Mar 2015 10:05:33 -0400 From: Derek Atkins To: Phillip Hallam-Baker References: Date: Mon, 16 Mar 2015 10:05:31 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Mon, 16 Mar 2015 09:05:36 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Possible rechartering of OpenPGP Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 14:06:12 -0000 Phillip Hallam-Baker writes: > On Fri, Mar 13, 2015 at 10:46 AM, Derek Atkins wrote: > > Hi, >=20=20=20=20 > Over the past couple days there's been some discussion on the > possibility of rechartering the OpenPGP working group.=C2=A0 Some of = the > discussions have been about updating RFCs 4880, 3156, and 6637.=C2=A0= Other > discussions have been about new features and/or algorithms. >=20=20=20=20 > If you're interested in this topic I suggest you subscribe to the > OpenPGP mailing list >=20=20=20=20 > We are planning a Bar BOF in Dallas to discuss possible rechartering. > The exact date, time, and location will be sent to the openpgp mailing > list.=C2=A0 Assuming this BOF happens before Thursday I'll give a rep= ort in > SAAG. >=20=20=20=20 > Happy Encrypting! >=20=20=20=20 > -derek > > To what end? To clean up a bunch of issues that implementation have hit. To update some of the key format issues that have been lying around. > Right now we have two email standards and a stalemate. PGP has won the > mindshare battle and S/MIME has won the deployment battle. Neither side h= as > delivered a product that the typical Internet user is willing to use and > neither side is willing to give an inch to the other. I wouldn't say S/MIME has won a deployment battle; I would say it won the "Implemented in MUA" battle. There is PGP/MIME, too. So why not use your might and get behind that? What makes S/MIME so much "better" than PGP/MIME that the major MUA manufacturers aren't willing to implement it? > And the prospects for end-to-end secure email are currently getting worse= with > webmail replacing end-to-end mail. > > Rather than reform to work on "OpenPGP", I think it would be better to de= velop > a successor standard to S/MIME and OpenPGP that allows a single message f= ormat > to be used with either trust model, or with new trust models. That's a good idea, but separate from this one. > Quite a few things have changed since 1992 and many of the design constra= ints > in S/MIME and OpenPGP no longer apply: > > * Public Key crypto is now cheap > * Can rely on network connectivity to solve some problems > * Internet users are not experts and don't want to be Yes, this is something that we all have to accept. :) > * Mail is merely one form of stored document While I agree with you on this, I don't think everyone does. > * Crypto libraries typically bundle ASN.1 handling code for PKIX I don't see this last item as a feature. PKIX is not the right solution for Internet Email. If it were then S/MIME would be in widespread use already. The fact that it's not, even though pretty much every email client supports it, implies that S/MIME+PKIX is absolutely the *WRONG* solution, so let's look for something else. > All of the tricks that I use to make S/MIME encryption totally transparen= t to > the end user can be applied to PGP as well. Who cares about S/MIME? As you point out, pretty much every email client has supported it for a very long time, so why isn't it in use? Let's solve that problem. Updating OpenPGP is still necessary, and might even be a partial solution to the problem! -derek --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Mar 16 09:05:24 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F531A8886 for ; Mon, 16 Mar 2015 09:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZ2RFd_sfrtx for ; Mon, 16 Mar 2015 09:05:21 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71351A887D for ; Mon, 16 Mar 2015 09:05:20 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id t2GG4fiH028360; Mon, 16 Mar 2015 09:05:18 -0700 Received: from sc-owa04.marvell.com ([199.233.58.150]) by mx0b-0016f401.pphosted.com with ESMTP id 1t4hxheyy4-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Mar 2015 09:05:17 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA04.marvell.com ([::1]) with mapi; Mon, 16 Mar 2015 09:05:16 -0700 From: Paul Lambert To: Phillip Hallam-Baker , Derek Atkins Date: Mon, 16 Mar 2015 09:05:15 -0700 Thread-Topic: [saag] Possible rechartering of OpenPGP Working Group Thread-Index: AdBgAv45DeXIaQwkTFqGYXxMqR4pNw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D12C4D1760CE8paulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-16_03:2015-03-13,2015-03-16,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503160165 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Possible rechartering of OpenPGP Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 16:05:22 -0000 --_000_D12C4D1760CE8paulmarvellcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Rather than reform to work on "OpenPGP", I think it would be better to deve= lop a successor standard to S/MIME and OpenPGP that allows a single message= format to be used with either trust model, or with new trust models. +1 Quite a few things have changed since 1992 and many of the design constrain= ts in S/MIME and OpenPGP no longer apply: * Public Key crypto is now cheap * Can rely on network connectivity to solve some problems * Internet users are not experts and don't want to be * Mail is merely one form of stored document * Crypto libraries typically bundle ASN.1 handling code for PKIX -1 on the PKIX =85 All of the tricks that I use to make S/MIME encryption totally transparent = to the end user can be applied to PGP as well. --_000_D12C4D1760CE8paulmarvellcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


Rather= than reform to work on "OpenPGP", I think it would be better to = develop a successor standard to S/MIME and OpenPGP that allows a single mes= sage format to be used with either trust model, or with new trust models.

+1 <= /div>

=

Quite a few things have chan= ged since 1992 and many of the design constraints in S/MIME and OpenPGP no = longer apply:

* Public Key crypto is now cheap
* Can rely on network connectivity to solve some problems
= * Internet users are not experts and don't want to be
* Mail is m= erely one form of stored document
* Crypto libraries typically bu= ndle ASN.1 handling code for PKIX

-1 on the PKIX =85 

<= div>

All of the tricks that I use to make S/MI= ME encryption totally transparent to the end user can be applied to PGP as = well.


--_000_D12C4D1760CE8paulmarvellcom_-- From nobody Mon Mar 16 09:17:45 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB241A8888 for ; Mon, 16 Mar 2015 09:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDqgthheqsd8 for ; Mon, 16 Mar 2015 09:17:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F151A1B2A for ; Mon, 16 Mar 2015 09:17:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5356BBE5D; Mon, 16 Mar 2015 16:17:39 +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 kCKraZe30G63; Mon, 16 Mar 2015 16:17:39 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2FE38BE56; Mon, 16 Mar 2015 16:17:39 +0000 (GMT) Message-ID: <55070222.90800@cs.tcd.ie> Date: Mon, 16 Mar 2015 16:17:38 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Paul Lambert , Phillip Hallam-Baker , Derek Atkins References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Possible rechartering of OpenPGP Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 16:17:43 -0000 On 16/03/15 16:05, Paul Lambert and/or PHB wrote: > > Rather than reform to work on "OpenPGP", I think it would be better > to develop a successor standard to S/MIME and OpenPGP that allows a > single message format to be used with either trust model, or with new > trust models. It's probably obvious, but if one wanted the above, then organising a bunch of similarly-minded folks would be the thing to do. Asking a different bunch of folks to not do something non-crazy that they seem to want to do isn't really so likely to be a winning strategy. Cheers, S. PS: Of course we don't yet know if those interested in some new work on openpgp will get their act together either, but there are some good folks who seem to be trying. From nobody Mon Mar 16 10:53:43 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3101A8983 for ; Mon, 16 Mar 2015 10:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmAJXvjhpJI2 for ; Mon, 16 Mar 2015 10:53:38 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4141A8982 for ; Mon, 16 Mar 2015 10:53:37 -0700 (PDT) Received: by obbgg8 with SMTP id gg8so41753079obb.1 for ; Mon, 16 Mar 2015 10:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4HlmRqEaysJxXGPy+at0i/P5DJAa9KoqooM28hNZQYw=; b=GZwvfsb7178d8JAkoKPSJh8KsvBt0DFCMNhqmWWZp1OuYGDuMSWjImL2uaLIFf+Fv9 YJYMWMkDqqEkOB9qSc5Sd/lXnsrfLLMjhSpJN3QDTynLyk482S6MmFwKOGP9OQKBAUTZ x9tH8FoYVDH8fU+ln+PesloYPv2/FKiyYghv03VLRQqF6UqcSU5qInA4jDTr7xizQ4iS cpwADETg+FNAmW7/puz+xFtdSlOjh6OaZqmOzETwmvtPLFgiIzTXgeeSkGgLrcu4ePdR +z37AuroMV+9FbHMfhqCachGMIFxH6mFdjg3blV9xSfrK9npAILXnFrNJA/7Hfem88bp 3Mkw== X-Received: by 10.182.181.72 with SMTP id du8mr12784011obc.71.1426528417375; Mon, 16 Mar 2015 10:53:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.155.134 with HTTP; Mon, 16 Mar 2015 10:53:17 -0700 (PDT) In-Reply-To: <55070222.90800@cs.tcd.ie> References: <55070222.90800@cs.tcd.ie> From: Donald Eastlake Date: Mon, 16 Mar 2015 13:53:17 -0400 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [saag] Possible rechartering of OpenPGP Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 17:53:38 -0000 On Mon, Mar 16, 2015 at 12:17 PM, Stephen Farrell wrote: > > On 16/03/15 16:05, Paul Lambert and/or PHB wrote: >> >> Rather than reform to work on "OpenPGP", I think it would be better >> to develop a successor standard to S/MIME and OpenPGP that allows a >> single message format to be used with either trust model, or with new >> trust models. > > It's probably obvious, but if one wanted the above, then organising > a bunch of similarly-minded folks would be the thing to do. Asking > a different bunch of folks to not do something non-crazy that they > seem to want to do isn't really so likely to be a winning strategy. +1 Donald > Cheers, > S. > > PS: Of course we don't yet know if those interested in some new work > on openpgp will get their act together either, but there are some good > folks who seem to be trying. From nobody Mon Mar 16 11:16:43 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB9F1A89B1 for ; Mon, 16 Mar 2015 11:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q603B7ZZEKJy for ; Mon, 16 Mar 2015 11:16:40 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016021A89AF for ; Mon, 16 Mar 2015 11:16:40 -0700 (PDT) Received: by lbcds1 with SMTP id ds1so36899561lbc.3 for ; Mon, 16 Mar 2015 11:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=d5CDKgBeFJ3qf3fFv3FJGB4Ch8oQv0khPheJ9GffAOI=; b=DLGACKAupWjVe0x+lVY7rVunWcZ6r+xUU2bGVHWopg8NAF9AKFEe10r+qoW28jU0A5 mnfX2oLMtbzxnvWSmj1RVzN3JrGxJ5QpC4SQpI2JbuBuLmUjPGcA5niSYbvPMiQsQt5w +ZHQlorW1sjAYVpPgmCn3X6S5shQJpXy+g4cHIhmRG4OyEZb5PGCqgkRCs5JXXzWsMGc Xph0U4w28/OebRvBJ9FXExeUxBkAm/KPFcQrLo3Qfw2jiGnnYDJa7JLQDJENXCvndyIx vFna9lIuCqhMSS8Ph06BqmCiZ1jMkJPw1wNYH9VLM1AUfTqPCUuO9O3qvSQfGHTw07B0 GTAA== MIME-Version: 1.0 X-Received: by 10.112.78.37 with SMTP id y5mr55234496lbw.91.1426529798395; Mon, 16 Mar 2015 11:16:38 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Mon, 16 Mar 2015 11:16:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Mar 2015 14:16:38 -0400 X-Google-Sender-Auth: 0LA4DHTmhsyFv4THv2MXW7gKZnA Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: multipart/alternative; boundary=001a11c3bb70e51f7a05116bd984 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Possible rechartering of OpenPGP Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 18:16:43 -0000 --001a11c3bb70e51f7a05116bd984 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 16, 2015 at 10:05 AM, Derek Atkins wrote: > Phillip Hallam-Baker writes: > > > On Fri, Mar 13, 2015 at 10:46 AM, Derek Atkins wrote: > > > > Hi, > > > > Over the past couple days there's been some discussion on the > > possibility of rechartering the OpenPGP working group. Some of the > > discussions have been about updating RFCs 4880, 3156, and 6637. > Other > > discussions have been about new features and/or algorithms. > > > > If you're interested in this topic I suggest you subscribe to the > > OpenPGP mailing list > > > > We are planning a Bar BOF in Dallas to discuss possible rechartering. > > The exact date, time, and location will be sent to the openpgp > mailing > > list. Assuming this BOF happens before Thursday I'll give a report > in > > SAAG. > > > > Happy Encrypting! > > > > -derek > > > > To what end? > > To clean up a bunch of issues that implementation have hit. > To update some of the key format issues that have been lying around. > > > Right now we have two email standards and a stalemate. PGP has won the > > mindshare battle and S/MIME has won the deployment battle. Neither side > has > > delivered a product that the typical Internet user is willing to use and > > neither side is willing to give an inch to the other. > > I wouldn't say S/MIME has won a deployment battle; I would say it won > the "Implemented in MUA" battle. There is PGP/MIME, too. So why not > use your might and get behind that? > I did not say get behind S/MIME. This idea that we have to choose is the real problem. What I think we need to do is to move to an email message standard that: * Can be used in OpenPGP clients * Can be used in S/MIME clients * Is supported in Web browsers as an encrypted format I don't think it is at all necessary that SecureMail TNG need be 'either' S/MIME or OpenPGP. But they should both be able to leverage the existing infrastructures (PGP key servers, PKIX certs, deployed MUA) as legacy wherever they exist. As a practical consequence of the fact that the OpenPGP brand has won, any successor spec is not going to be called S/MIME. > What makes S/MIME so much "better" than PGP/MIME that the major MUA > manufacturers aren't willing to implement it? Well that is an important question that I would like to get them to answer. But one reason is that as far as the vendors are concerned 'security' is an enterprise feature and they are selling gear that lets Alice in Accounts send mail to Bob in Legal, not Alice sending Bob intimate photographs. The vendors have invested in managing keys with PKIX and they want to be able to leverage that investment. I think that should certainly be one option for using secure mail. Because when I am sending an email to Carol at the bank, I really do care that it is going to the bank security infrastructure, not Carol's personal one. Another issue with OpenPGP is that it actually has two different trust models, the one we all use and the one we all talk about. The one we use is key fingerprints. The one that gets talked about is key signing. > > * Mail is merely one form of stored document > > While I agree with you on this, I don't think everyone does. Considering document level encryption as an email message you are sending to yourself solves a lot of problems and enables use of a lot of existing infrastructure. > > > * Crypto libraries typically bundle ASN.1 handling code for PKIX > > I don't see this last item as a feature. PKIX is not the right solution > for Internet Email. If it were then S/MIME would be in widespread use > already. The fact that it's not, even though pretty much every email > client supports it, implies that S/MIME+PKIX is absolutely the *WRONG* > solution, so let's look for something else. The same argument can be made against PGP and with greater force. The number of registered PGP keys and active S/MIME certs are very similar. The number of folk required to use S/MIME for government work is non negligible. Thinking of it as an either/or thing is not helpful. What we should be doing is to look for ways we can reach common ground. I find it rather odd that we have a 'TLS everywhere' lobby and a 'no PKIX in email' lobby and there is a huge overlap. We can solve a lot of interop issues and jettison a lot of code by working out ways to share code between the systems. DANE has managed to do that, we should at least try the same approach in email. > All of the tricks that I use to make S/MIME encryption totally > transparent to > > the end user can be applied to PGP as well. > > Who cares about S/MIME? As you point out, pretty much every email > client has supported it for a very long time, so why isn't it in use? > Let's solve that problem. > The reason it is not more widely used is that the usability still sucks. Having tried to use OpenPGP and failed the one time I tried to use it since, I don't think that is the answer either. Any system that INSISTS that I choose some passphrase to store the private key rather than let me make my own choice is going to fail when I only use it once every 6 months. Then I discovered that there is no way to unregister the key having lost the passphrase. If I can't use it then heaven help the typical user. > Updating OpenPGP is still necessary, and might even be a partial > solution to the problem! Nobody is arguing against that. But how we go about things makes a big difference. --001a11c3bb70e51f7a05116bd984 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 16, 2015 at 10:05 AM, Derek Atkins <derek@ihtfp.com><= /span> wrote:
Phillip Hallam-Baker <= ;phill@hallambaker.com> wri= tes:

> On Fri, Mar 13, 2015 at 10:46 AM, Derek Atkins <derek@ihtfp.com> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi,
>
>=C2=A0 =C2=A0 =C2=A0Over the past couple days there's been some dis= cussion on the
>=C2=A0 =C2=A0 =C2=A0possibility of rechartering the OpenPGP working gro= up.=C2=A0 Some of the
>=C2=A0 =C2=A0 =C2=A0discussions have been about updating RFCs 4880, 315= 6, and 6637.=C2=A0 Other
>=C2=A0 =C2=A0 =C2=A0discussions have been about new features and/or alg= orithms.
>
>=C2=A0 =C2=A0 =C2=A0If you're interested in this topic I suggest yo= u subscribe to the
>=C2=A0 =C2=A0 =C2=A0OpenPGP mailing list <openpgp@ietf.org>
>
>=C2=A0 =C2=A0 =C2=A0We are planning a Bar BOF in Dallas to discuss poss= ible rechartering.
>=C2=A0 =C2=A0 =C2=A0The exact date, time, and location will be sent to = the openpgp mailing
>=C2=A0 =C2=A0 =C2=A0list.=C2=A0 Assuming this BOF happens before Thursd= ay I'll give a report in
>=C2=A0 =C2=A0 =C2=A0SAAG.
>
>=C2=A0 =C2=A0 =C2=A0Happy Encrypting!
>
>=C2=A0 =C2=A0 =C2=A0-derek
>
> To what end?

To clean up a bunch of issues that implementation have hit.
To update some of the key format issues that have been lying around.

> Right now we have two email standards and a stalemate. PGP has won the=
> mindshare battle and S/MIME has won the deployment battle. Neither sid= e has
> delivered a product that the typical Internet user is willing to use a= nd
> neither side is willing to give an inch to the other.

I wouldn't say S/MIME has won a deployment battle; I would say i= t won
the "Implemented in MUA" battle.=C2=A0 There is PGP/MIME, too.=C2= =A0 So why not
use your might and get behind that? =C2=A0

<= div>I did not say get behind S/MIME. This idea that we have to choose is th= e real problem.

What I think we need to do is to m= ove to an email message standard that:

* Can be us= ed in OpenPGP clients
* Can be used in S/MIME clients
*= Is supported in Web browsers as an encrypted format

I don't think it is at all necessary that SecureMail TNG need be = 9;either' S/MIME or OpenPGP. But they should both be able to leverage t= he existing infrastructures (PGP key servers, PKIX certs, deployed MUA) as = legacy wherever they exist.

As a practical consequ= ence of the fact that the OpenPGP brand has won, any successor spec is not = going to be called S/MIME.

=C2=A0
What makes S/MIME so much "better" than PGP/MIME that the m= ajor MUA manufacturers aren't willing to=C2=A0implement it?

Well that is an important question that I would like t= o get them to answer.

But one reason is that as fa= r as the vendors are concerned 'security' is an enterprise feature = and they are selling gear that lets Alice in Accounts send mail to Bob in L= egal, not Alice sending Bob intimate photographs.

= The vendors have invested in managing keys with PKIX and they want to be ab= le to leverage that investment. I think that should certainly be one option= for using secure mail. Because when I am sending an email to Carol at the = bank, I really do care that it is going to the bank security infrastructure= , not Carol's personal one.


Ano= ther issue with OpenPGP is that it actually has two different trust models,= the one we all use and the one we all talk about.=C2=A0

The one we use is key fingerprints. The one that gets talked about i= s key signing.=C2=A0

=C2=A0
= > * Mail is merely one form of stored document

While I agree with you on this, I don't think everyone does.

Considering document level encryption as an em= ail message you are sending to yourself solves a lot of problems and enable= s use of a lot of existing infrastructure.

=C2=A0<= /div>

> * Crypto libraries typically bundle ASN.1 handling code for PKIX

I don't see this last item as a feature.=C2=A0 PKIX is not the r= ight solution
for Internet Email.=C2=A0 If it were then S/MIME would be in widespread use=
already.=C2=A0 The fact that it's not, even though pretty much every em= ail
client supports it, implies that S/MIME+PKIX is absolutely the *WRONG*
solution, so let's look for something else.

=
The same argument can be made against PGP and with greater force. The = number of registered PGP keys and active S/MIME certs are very similar. The= number of folk required to use S/MIME for government work is non negligibl= e.

Thinking of it as an either/or thing is not hel= pful. What we should be doing is to look for ways we can reach common groun= d.

I find it rather odd that we have a 'TLS ev= erywhere' lobby and a 'no PKIX in email' lobby and there is a h= uge overlap.=C2=A0

We can solve a lot of interop i= ssues and jettison a lot of code by working out ways to share code between = the systems. DANE has managed to do that, we should at least try the same a= pproach in email.


> All of the tricks that I use to make S/MIME encryption tot= ally transparent to
> the end user can be applied to PGP as well.

Who cares about S/MIME?=C2=A0 As you point out, pretty much every em= ail
client has supported it for a very long time, so why isn't it in use? Let's solve that problem.

The reaso= n it is not more widely used is that the usability still sucks.
<= br>
Having tried to use OpenPGP and failed the one time I tried t= o use it since, I don't think that is the answer either. Any system tha= t INSISTS that I choose some passphrase to store the private key rather tha= n let me make my own choice is going to fail when I only use it once every = 6 months.

Then I discovered that there is no way t= o unregister the key having lost the passphrase.

<= br>
If I can't use it then heaven help the typical user.

=C2=A0
Updating OpenPGP is still necessary, and might even be a partial
solution to the problem!

Nobody is arguing = against that. But how we go about things makes a big difference.=C2=A0
--001a11c3bb70e51f7a05116bd984-- From nobody Mon Mar 16 11:50:10 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948CA1A8A92 for ; Mon, 16 Mar 2015 11:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEFMzX4R8Gwb for ; Mon, 16 Mar 2015 11:50:07 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::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 5285D1A8A87 for ; Mon, 16 Mar 2015 11:50:07 -0700 (PDT) Received: by lbcds1 with SMTP id ds1so37522265lbc.3 for ; Mon, 16 Mar 2015 11:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=m/VbmmJFiosMFQyh0ride/QPKXltKetD8xjhsOaHmFg=; b=pum7nhejSqUK3gmwJ6t8DQ+YVx+TYf5cndEPexOjxwJo2GtONQg4I/qWIk0G46owQj HAH4nQ1edp7CovLHZif6fuWaVR/1q9pPa1ze7BXquz8WmhllMJMyCwrSKNBE0bRJbBj7 zzaDDZ6CnR6hBtRPUuzmgbYdmXxVKkYmLuHkpCrf0l5HKuGzD+0V9CBtJgvI1AnIfCui xGmMFWsneXvciMUWa4NW2maqj8DcA4JgWrE1ayU+pgfV2H7ejyrQWFWSQWQravmvvFTt 5N8pj5p6bWCQ21q7vVQd8OAWC0EEBEpf+B6Q5mllT2Zsn2VZBuvKCaNcQEH6yxdw3+uh QP8A== MIME-Version: 1.0 X-Received: by 10.152.206.7 with SMTP id lk7mr57549289lac.55.1426531805684; Mon, 16 Mar 2015 11:50:05 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Mon, 16 Mar 2015 11:50:05 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Mar 2015 14:50:05 -0400 X-Google-Sender-Auth: xowQXaP4dbJzjEqWxo0cYXMdaEk Message-ID: From: Phillip Hallam-Baker To: Paul Lambert Content-Type: multipart/alternative; boundary=001a1134986889ea5805116c51dc Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Possible rechartering of OpenPGP Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 18:50:09 -0000 --001a1134986889ea5805116c51dc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 16, 2015 at 12:05 PM, Paul Lambert wrote: > > > Rather than reform to work on "OpenPGP", I think it would be better to > develop a successor standard to S/MIME and OpenPGP that allows a single > message format to be used with either trust model, or with new trust mode= ls. > > > +1 > > > Quite a few things have changed since 1992 and many of the design > constraints in S/MIME and OpenPGP no longer apply: > > * Public Key crypto is now cheap > * Can rely on network connectivity to solve some problems > * Internet users are not experts and don't want to be > * Mail is merely one form of stored document > * Crypto libraries typically bundle ASN.1 handling code for PKIX > > > -1 on the PKIX =E2=80=A6 > I didn't say people had to use it. Only that it exists. One way to start a harmonization program would be to define one mechanism for taking a fingerprint of a public key that can be recognized by OpenPGP based infrastructure and other infrastructure. The OpenPGP fingerprint desperately needs an update. It is best if the IETF has one fingerprint algorithm that can be used in any application. Including TLS and IPSEC. For a while folk have been running a .onion domain with the idea that the dns domain name is .onion. Which is a fine solution for TOR but still undersells the concept. For example, consider the following where is a root of trust under which the DNSSEC and PKIX key signing keys are signed. We can use this sort of approach to define universal constants in a key centric PKI. example.com. Fingerprints of keys are very useful and powerful. The current OpenPGP fingerprint needs updating. If we move to a mechanism that makes use of the existing PKIX keyInfo structure we have a mechanism that will automatically add support for all new public key algorithms, suites, etc as they are defined. So as far as the specification goes it would be: Base32 ( + Truncate ( SHA-2-512 ( ), n)) Now before folk start complaining about 'ASN.1 encoding'. This is already used to define crypto formats at the lower layers (PKCS#1 for example). The reason it doesn't get in the way is that it is easily faked for fixed length keys by simply splicing in constant strings. We can do that for public key algorithms as well. OIDs are a particularly obnoxious encoding to implement. But I don't do that in any of my runtime code, I convert every OID to a sequence of bytes. --001a1134986889ea5805116c51dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 16, 2015 at 12:05 PM, Paul Lambert <paul@marvell.com>= wrote:


Rather than r= eform to work on "OpenPGP", I think it would be better to develop= a successor standard to S/MIME and OpenPGP that allows a single message fo= rmat to be used with either trust model, or with new trust models.

+1=C2=A0


Quite a few things have c= hanged since 1992 and many of the design constraints in S/MIME and OpenPGP = no longer apply:

* Public Key crypto is now cheap<= /div>
* Can rely on network connectivity to solve some problems
* Internet users are not experts and don't want to be
* Ma= il is merely one form of stored document
* Crypto libraries typic= ally bundle ASN.1 handling code for PKIX

-1 on the PKIX =E2=80=A6=C2=A0

I didn't say people had to use it. = Only that it exists.

One way to start a harmonizat= ion program would be to define one mechanism for taking a fingerprint of a = public key that can be recognized by OpenPGP based infrastructure and other= infrastructure.

The OpenPGP fingerprint desperate= ly needs an update. It is best if the IETF has one fingerprint algorithm th= at can be used in any application. Including TLS and IPSEC.

<= /div>
For a while folk have been running a .onion domain with the idea = that the dns domain name is <fingerprint>.onion. Which is a fine solu= tion for TOR but still undersells the concept.

For= example, consider the following where <fingerprint> is a root of tru= st under which the DNSSEC and PKIX key signing keys are signed. We can use = this sort of approach to define universal constants in a key centric PKI.= =C2=A0

example.com.<fingerprint>

Fingerpr= ints of keys are very useful and powerful.


The current OpenPGP fingerprint needs updating. If we move to a mec= hanism that makes use of the existing PKIX keyInfo structure we have a mech= anism that will automatically add support for all new public key algorithms= , suites, etc as they are defined.

So as far as th= e specification goes it would be:

Base32 ( <ver= sion> + Truncate ( SHA-2-512 ( <keyinfo> ), n))


Now before folk start complaining about 'ASN.1 en= coding'. This is already used to define crypto formats at the lower lay= ers (PKCS#1 for example). The reason it doesn't get in the way is that = it is easily faked for fixed length keys by simply splicing in constant str= ings.

We can do that for public key algorithms as = well. OIDs are a particularly obnoxious encoding to implement. But I don= 9;t do that in any of my runtime code, I convert every OID to a sequence of= bytes.
--001a1134986889ea5805116c51dc-- From nobody Mon Mar 16 13:30:20 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F931A90D5 for ; Mon, 16 Mar 2015 13:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIcUCbpvUlOa for ; Mon, 16 Mar 2015 13:30:10 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::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 5D52F1A90D4 for ; Mon, 16 Mar 2015 13:30:10 -0700 (PDT) Received: by lbbzq9 with SMTP id zq9so39324864lbb.0 for ; Mon, 16 Mar 2015 13:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/ho4VL6XS4N+lCuy5rGLV+0eg/QCBc+iH27V2xTOi+4=; b=aLnc+vGrzZQRdcOf6GTReWB9RXlAATikNFbDatFFUUV7ttKqqADaBPBsxitqe9qfp4 u4n5AjDn7VbBXi7O/FM/qkB2wI5A/Pm2G98GcbZXFep1bicb3yCVuCfmuwY2m7r6VrRS sY5hQvfKYPspoVLreC3PRym2E/D1Rj5tyVkpLiFDgmKNFHL0UW/6WyEF7sovtr+EBlmv zmymzXCgHzgQ+XWPSBpxt9iIHl2wWDCukU7ihDTI5OE5lI/wrtis+mlw+ErrqKijV0lH Jt+IVCHAyz/afuJvPpVNO0qKunFaM9yAdyzuor5oXqu9VpKWyAaEEkehDEw0udDPvr6t vr7w== MIME-Version: 1.0 X-Received: by 10.112.134.106 with SMTP id pj10mr58280852lbb.58.1426537808916; Mon, 16 Mar 2015 13:30:08 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Mon, 16 Mar 2015 13:30:08 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB25C2@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB25C2@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 16 Mar 2015 16:30:08 -0400 X-Google-Sender-Auth: rYoSkug-7147dOYoZB6fQMb_17c Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: multipart/alternative; boundary=047d7b3a8ac85bf86805116db784 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 20:30:12 -0000 --047d7b3a8ac85bf86805116db784 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Mar 15, 2015 at 9:46 PM, Peter Gutmann wrote: > Yoav Nir writes: > > >The thing is that standardizing a protocol is only good where > >interoperability is required, so that one vendor=E2=80=99s client works = with > another > >vendor=E2=80=99s server. This is important in many applications, but has= n=E2=80=99t been > in > >remote access VPNs, for which SSL is one technology. > > What would be achieved by creating yet another new standard (insert > obligatory > XKCD reference) in this area though? If you want (allegedly) interoperab= le > VPN technology you've got IPsec. IPSec and SSL VPNs are very different things. SSL VPNs work through NAT by design. IPSEC was originally designed to make NAT work as badly as possible leading to a host of vendor hacks to make it workable. Every platform I use has IPSEC built in. No company I have ever worked for has ever used the built in clients. Instead they always want me to download some piece of crud that does not work reliably and has a UI designed by an imbecile. > If you want something that doesn't suck > quite as badly, you've got either OpenVPN or (admittedly) vendor-specific > SSL > VPNs, although hopefully at least built around DTLS. What fraction of > whatever's left will be served by yet another VPN standard, and will anyo= ne > care enough to make it worthwhile? > Where was it said that there would be another standard rather than a description of the SSL VPNs that exist? I didn't see it. OpenVPN is as far as I know currently a product rather than a specification. Making it a standard and pushing the client part into the vendor supported part of the stack would be a huge win. --047d7b3a8ac85bf86805116db784 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 15, 2015 at 9:46 PM, Peter Gutmann <pgut001@cs.auc= kland.ac.nz> wrote:
Yoav Nir <ynir.ietf@gma= il.com> writes:

>The thing is that standardizing a protocol is only good where
>interoperability is required, so that one vendor=E2=80=99s client works= with another
>vendor=E2=80=99s server. This is important in many applications, but ha= sn=E2=80=99t been in
>remote access VPNs, for which SSL is one technology.

What would be achieved by creating yet another new standard (insert = obligatory
XKCD reference) in this area though?=C2=A0 If you want (allegedly) interope= rable
VPN technology you've got IPsec.=C2=A0

IPSec and SSL VPNs are very different things. SSL VPNs work through NAT by= design. IPSEC was originally designed to make NAT work as badly as possibl= e leading to a host of vendor hacks to make it workable.

Every platform I use has IPSEC built in. No company I have ever work= ed for has ever used the built in clients. Instead they always want me to d= ownload some piece of crud that does not work reliably and has a UI designe= d by an imbecile.

=C2=A0
If you want something that doesn't suck
quite as badly, you've got either OpenVPN or (admittedly) vendor-specif= ic SSL
VPNs, although hopefully at least built around DTLS.=C2=A0 What fraction of=
whatever's left will be served by yet another VPN standard, and will an= yone
care enough to make it worthwhile?

Wher= e was it said that there would be another standard rather than a descriptio= n of the SSL VPNs that exist? I didn't see it.

OpenVPN is as far as I know currently a product rather than a specificatio= n. Making it a standard and pushing the client part into the vendor support= ed part of the stack would be a huge win.


--047d7b3a8ac85bf86805116db784-- From nobody Mon Mar 16 14:32:15 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EFE1A9169 for ; Mon, 16 Mar 2015 14:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCBTaX99B2pl for ; Mon, 16 Mar 2015 14:32:13 -0700 (PDT) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3341A9153 for ; Mon, 16 Mar 2015 14:32:08 -0700 (PDT) Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1YXccJ-0007E6-L9 for saag@ietf.org; Mon, 16 Mar 2015 15:32:07 -0600 Received: from [72.250.219.84] (helo=sylvester.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1YXccD-0004Xf-RE for saag@ietf.org; Mon, 16 Mar 2015 15:32:07 -0600 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id t2GLVqrf023178 for ; Mon, 16 Mar 2015 15:31:52 -0600 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id t2GLVpbf023176; Mon, 16 Mar 2015 15:31:51 -0600 Date: Mon, 16 Mar 2015 15:31:51 -0600 Message-Id: <201503162131.t2GLVpbf023176@sylvester.rhmr.com> From: "Hilarie Orman" To: saag@ietf.org X-XM-AID: U2FsdGVkX19iOPv3pp0eBDjotMx2Q2ti X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ****;saag@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 5323 ms - load_scoreonly_sql: 0.08 (0.0%), signal_user_changed: 4.9 (0.1%), b_tie_ro: 2.9 (0.1%), parse: 0.87 (0.0%), extract_message_metadata: 15 (0.3%), get_uri_detail_list: 0.87 (0.0%), tests_pri_-1000: 4.7 (0.1%), tests_pri_-950: 1.47 (0.0%), tests_pri_-900: 1.16 (0.0%), tests_pri_-400: 15 (0.3%), check_bayes: 14 (0.3%), b_tokenize: 3.8 (0.1%), b_tok_get_all: 3.8 (0.1%), b_comp_prob: 1.61 (0.0%), b_tok_touch_all: 2.4 (0.0%), b_finish: 0.68 (0.0%), tests_pri_0: 87 (1.6%), tests_pri_500: 5189 (97.5%), poll_dns_idle: 5176 (97.2%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: Subject: Re: [saag] Possible rechartering of OpenPGP Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 21:32:14 -0000 > From: Stephen Farrell > On 16/03/15 16:05, Paul Lambert and/or PHB wrote: > > > > Rather than reform to work on "OpenPGP", I think it would be better > > to develop a successor standard to S/MIME and OpenPGP that allows a > > single message format to be used with either trust model, or with new > > trust models. . + 1 > It's probably obvious, but if one wanted the above, then organising > a bunch of similarly-minded folks would be the thing to do. Ignoring the fact that it would take quite a long time for them to agree on what the goal was, it seems like a good idea. Quixotic, but worthwhile. Hilarie From nobody Mon Mar 16 17:38:56 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2777A1ACD91 for ; Mon, 16 Mar 2015 17:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rn5O46e8nLP7 for ; Mon, 16 Mar 2015 17:38:48 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::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 890761ACDA9 for ; Mon, 16 Mar 2015 17:38:43 -0700 (PDT) Received: by lamx15 with SMTP id x15so54387855lam.3 for ; Mon, 16 Mar 2015 17:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=otvtKDaeFA/LVpw1QTdIroOipvoHV/HA69mhjMS3z/0=; b=t2k2GSUlO9ZeS8tN6rEzczIbS3WEHI0yE8w0QTL5nN3aN7ZMg1qgyajKJ1EdomCEKu l676iK4cEn6jMAczb48KHUvo/hg1V1xzU42FU+1MFIUix2cXXshV5zDA63Wc9FAwDJ7R k1RWItwL+GBab0ExZVic64+ldKBgDMdTrbYyU1KOslvXY9GWQtUKKUmhq1VXK6Jzf+CD v22UcwF/G9GPlglEPchOyIK+0FuhoQfRMT3BITVTYvX16G5DD4SxHV9SvHGv4VvIgr9f VJExpj1L74dbg3i9M5g5/Ud4RqqbeNn90TVAr1y2FUx48/74jdDGrxvy6svytbGTo/fl 4/aw== MIME-Version: 1.0 X-Received: by 10.112.151.226 with SMTP id ut2mr38942358lbb.55.1426552721847; Mon, 16 Mar 2015 17:38:41 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Mon, 16 Mar 2015 17:38:41 -0700 (PDT) In-Reply-To: <201503162131.t2GLVpbf023176@sylvester.rhmr.com> References: <201503162131.t2GLVpbf023176@sylvester.rhmr.com> Date: Mon, 16 Mar 2015 20:38:41 -0400 X-Google-Sender-Auth: I13i5Xul1808E7mily8ryFdGCv0 Message-ID: From: Phillip Hallam-Baker To: Hilarie Orman Content-Type: multipart/alternative; boundary=047d7bf0c0363d3a46051171304e Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Possible rechartering of OpenPGP Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 00:38:49 -0000 --047d7bf0c0363d3a46051171304e Content-Type: text/plain; charset=UTF-8 On Mon, Mar 16, 2015 at 5:31 PM, Hilarie Orman wrote: > > From: Stephen Farrell > > > On 16/03/15 16:05, Paul Lambert and/or PHB wrote: > > > > > > Rather than reform to work on "OpenPGP", I think it would be better > > > to develop a successor standard to S/MIME and OpenPGP that allows a > > > single message format to be used with either trust model, or with new > > > trust models. > > . + 1 > > > It's probably obvious, but if one wanted the above, then organising > > a bunch of similarly-minded folks would be the thing to do. > > Ignoring the fact that it would take quite a long time for them to > agree on what the goal was, it seems like a good idea. Quixotic, > but worthwhile. Well my goal is simply to get as many people using secure mail as we can. Understanding that 'secure' now means a combination of STARTTLS _and_ end-to-end security. We don't need to all agree on the same goal. Looking at the proposals on the list, I think people are looking to change several parts of the OpenPGP infrastructure. And I think that looking at the mechanisms they are going to need to achieve seamless interop between PGPvCurrent and PGPvNext, I can provide a mechanism which allows interop with the S/MIME formats as well. --047d7bf0c0363d3a46051171304e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 16, 2015 at 5:31 PM, Hilarie Orman <hilarie@purples= treak.com> wrote:
>=C2= =A0 From: Stephen Farrell <= stephen.farrell@cs.tcd.ie>

>=C2=A0 On 16/03/15 16:05, Paul Lambert and/or PHB wrote:
>=C2=A0 >
>=C2=A0 > Rather than reform to work on "OpenPGP", I think = it would be better
>=C2=A0 > to develop a successor standard to S/MIME and OpenPGP that = allows a
>=C2=A0 > single message format to be used with either trust model, o= r with new
>=C2=A0 > trust models.

. + 1

>=C2=A0 It's probably obvious, but if one wanted the above, then org= anising
>=C2=A0 a bunch of similarly-minded folks would be the thing to do.

Ignoring the fact that it would take quite a long time for them to agree on what the goal was, it seems like a good idea.=C2=A0 Quixotic,
but worthwhile.

Well my goal is simply to g= et as many people using secure mail as we can. Understanding that 'secu= re' now means a combination of STARTTLS _and_ end-to-end security.

We don't need to all agree on the same goal.
=


Looking at the proposals on the list, I = think people are looking to change several parts of the OpenPGP infrastruct= ure. And I think that looking at the mechanisms they are going to need to a= chieve seamless interop between PGPvCurrent and PGPvNext, I can provide a m= echanism which allows interop with the S/MIME formats as well.




<= /div>
--047d7bf0c0363d3a46051171304e-- From nobody Tue Mar 17 05:12:20 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC301A037D for ; Tue, 17 Mar 2015 05:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gKrtZWHeTNq for ; Tue, 17 Mar 2015 05:10:21 -0700 (PDT) Received: from emvm-gh1-uea08.nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 45F4B1A037B for ; Tue, 17 Mar 2015 05:10:21 -0700 (PDT) X-TM-IMSS-Message-ID: <0de329c600017269@nsa.gov> Received: from MSHT-GH1-UEA02.corp.nsa.gov (msht-gh1-uea02.corp.nsa.gov [10.215.227.181]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 0de329c600017269 ; Tue, 17 Mar 2015 08:10:21 -0400 Received: from MSMR-GH1-UEA04.corp.nsa.gov ([10.215.228.141]) by MSHT-GH1-UEA02.corp.nsa.gov ([10.215.227.181]) with mapi id 14.02.0347.000; Tue, 17 Mar 2015 08:10:20 -0400 From: "Boyle, Vincent M" To: "'saag@ietf.org'" Thread-Topic: [saag] looking to hold a TLS VPN side meeting at IETF 92 Thread-Index: AdBdsL81XCyfXC5pQPeZlyI69acR3gA6/qoAAIMgOTA= Date: Tue, 17 Mar 2015 12:10:18 +0000 Message-ID: References: <1426353642.28541.3.camel@gnutls.org> In-Reply-To: <1426353642.28541.3.camel@gnutls.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.227.232] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 12:10:24 -0000 SSBhcHByZWNpYXRlIGFsbCB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdC4gVG8gY2xhcmlmeSBh IGNvdXBsZSBwb2ludHMsIHdlIGRvbid0IGhhdmUgYSBmaXhlZCBpZGVhIHdoYXQgYSBUTFMgVlBO IHN0YW5kYXJkcyBzaG91bGQgbG9vayBsaWtlLiBSYXRoZXIsIHdlIGhhdmUgcmVxdWlyZW1lbnRz LCBzdWNoIGFzIHRoZSBhYmlsaXR5IHRvIHN1cHBvcnQgbW9iaWxlIGRldmljZXMgY29ubmVjdGlu ZyBiYWNrIHRvIGFuIGVudGVycHJpc2UgbmV0d29yay4gV2UgYWxzbyB3YW50IHRvIGNvbWUgdXAg d2l0aCBhIHNvbHV0aW9uIHRoYXQgd291bGQgd29yayB3aXRoIGFub3RoZXIgbGF5ZXIgb2YgZW5j cnlwdGlvbiAobGlrZWx5IElQU2VjKSwgd2l0aG91dCBnZXR0aW5nIGludG8gZmlnaHRzIGluIHRo ZSBrZXJuZWwuIEknbSBwYXJ0aWN1bGFybHkgaW50ZXJlc3RlZCB0byBoZWFyIHBlb3BsZSdzIHRo b3VnaHRzIG9uIHRoYXQsIGFzIGl0IGhhcyBiZWVuIGEgcHJvYmxlbSBmb3IgdXMgaW4gdGhlIHBh c3QgKGluIHNpdHVhdGlvbnMgd2hlcmUgd2UgZG9uJ3QgZW1wbG95IHZpcnR1YWxpemF0aW9uKS4g QXMgb3RoZXJzIGFscmVhZHkgc2FpZCwgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIGNsaWVudHMg YW5kIHNlcnZlcnMgb2YgZGlmZmVyZW50IHZlbmRvcnMgaXMgaGlnaGx5IGRlc2lyYWJsZSBhcyB3 ZWxsLiBJIGFscmVhZHkgbWVudGlvbmVkIHRoYXQgd2UgbmVlZCBhIHN0YW5kYXJkIHRvIGJ1aWxk IG91ciBzZWN1cml0eSB0ZXN0aW5nIGFyb3VuZC4gSSBndWVzcyB0aGF0J3MgbW9yZSBhIHJlcXVp cmVtZW50IGZvciAqYW55KiBzdGFuZGFyZCwgbm90IGEgcGFydGljdWxhciB0ZWNobmljYWwgcmVx dWlyZW1lbnQuDQoNCkFsc28sIEkgd2FudCB0byBzZWNvbmQgUEhCJ3Mgb2JzZXJ2YXRpb24gdGhh dCB3ZSdyZSBub3QgbG9va2luZyBmb3IgbmV3IHRlY2hub2xvZ3kuIFdlIHJlYWxseSB3YW50IHRv IGxldmVyYWdlIHdoYXQncyBhbHJlYWR5IGF2YWlsYWJsZSBhbmQgZ2V0IGNvbnNlbnN1cyBvbiBh IHN0YW5kYXJkIHRoYXQgaGFzIGdvb2Qgc2VjdXJpdHkgcHJvcGVydGllcyBhbmQgd2lsbCBwcm9t b3RlIGludGVyb3BlcmFiaWxpdHkuIA0KDQpTbywgYWZ0ZXIgaGVhcmluZyBhYm91dCBzb21lIGNv bmZsaWN0cyB3aXRoIG90aGVyIHNpZGUgbWVldGluZ3MgSSdtIGxlYW5pbmcgdG93YXJkIHRoZSBX ZWRuZXNkYXkgYXQgNzozMCB0aW1lc2xvdC4gSSdsbCByZXNlYXJjaCBhIHZlbnVlIGFuZCBzZW5k IG91dCBhbiBhbm5vdW5jZW1lbnQgdG9tb3Jyb3cuDQoNCk1pa2UNCg0KDQo= From nobody Tue Mar 17 05:24:54 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F421A038B for ; Tue, 17 Mar 2015 05:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BumpJ9KAR5lf for ; Tue, 17 Mar 2015 05:24:50 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::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 DF3E21A039A for ; Tue, 17 Mar 2015 05:24:49 -0700 (PDT) Received: by lbbzq9 with SMTP id zq9so5640663lbb.0 for ; Tue, 17 Mar 2015 05:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=IcXtVsR4zagcthlzYS/zEzt0hvixU2GOWYPJJZ8fD9Q=; b=vF6xLaVAn3gLX7Y9N/0Etz3a4mmMtyHIyGpr1dQ5QPm6O6V8EP0IJI2uXbQr2+cHBH MEeRli4zyWZtw8vjNZN6s28AovlkY3bbMHkvIbOn1bqfJTr+AO+HZZJfgZeIGZn2qY9K g2TLGpBBSKOnDBINi6ZKOtbyL8ckQeYEH2Bzxt6CnT7nycIAF2uGBh1dEH8OTfubPnNQ YmuQXBNFMDonsI2TDEkQOBF2S4YqPj72VUSb1pvSqID2MToxD2Nu459rNcZFhsZCI/6R M3OMHR84trl36/hP1qqvDL5FEaWVNTA34SbBNSRqvEtMHawhy3gAcmNGcq8l7hrUl6x/ VaTg== MIME-Version: 1.0 X-Received: by 10.152.206.70 with SMTP id lm6mr60721211lac.35.1426595088340; Tue, 17 Mar 2015 05:24:48 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.112.140.104 with HTTP; Tue, 17 Mar 2015 05:24:48 -0700 (PDT) In-Reply-To: References: <1426353642.28541.3.camel@gnutls.org> Date: Tue, 17 Mar 2015 13:24:48 +0100 X-Google-Sender-Auth: 1F8B--CIs8fpGgSeLJc8fUCOeyg Message-ID: From: Nikos Mavrogiannopoulos To: "Boyle, Vincent M" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 12:24:52 -0000 On Tue, Mar 17, 2015 at 1:10 PM, Boyle, Vincent M wrote: > I appreciate all the discussion on the list. To clarify a couple points, = we don't have a fixed idea what a TLS VPN standards should look like. Rathe= r, we have requirements, such as the ability to support mobile devices conn= ecting back to an enterprise network. We also want to come up with a soluti= on that would work with another layer of encryption (likely IPSec), without= getting into fights in the kernel. I'm particularly interested to hear peo= ple's thoughts on that, as it has been a problem for us in the past (in sit= uations where we don't employ virtualization). As others already said, inte= roperability between clients and servers of different vendors is highly des= irable as well. I already mentioned that we need a standard to build our se= curity testing around. I guess that's more a requirement for *any* standard= , not a particular technical requirement. > Also, I want to second PHB's observation that we're not looking for new t= echnology. We really want to leverage what's already available and get cons= ensus on a standard that has good security properties and will promote inte= roperability. That is good on itself, but note that because of the ad-hoc designs of SSL VPNs very few (to none) of them have good security properties. Attempting to even document one of them is a non-trivial task due to legacy cruft these systems carry. It's no surprise that none of these systems have a single page of protocol description. While documenting such a historic system would be a good first step, I hope it would lead eventually to the design of a decent VPN protocol based on SSL/TLS. With certain SSL VPNs that can be done in a backwards compatible way, others cannot be extended at all. regards, Nikos From nobody Tue Mar 17 06:37:09 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1E71A0BE8 for ; Tue, 17 Mar 2015 06:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJTXxfZoipnz for ; Tue, 17 Mar 2015 06:37:06 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::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 C32461A0687 for ; Tue, 17 Mar 2015 06:37:05 -0700 (PDT) Received: by ladw1 with SMTP id w1so8743939lad.0 for ; Tue, 17 Mar 2015 06:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oTCaHlko6rZjXyDOoBXizty+gpVYHiKWdM2HbAeCWuc=; b=fgkUbT7hCTImTuUY0lbiE33i1C9TjP4qBIkPenuKVAnBPVnTntY2rPEZiWtxOGQFRJ YhT06Y3C4Ys9MAERPT4948ecLa5Pm3xupOJK5wwH59pXsyCgEuiH1FlsdHaVKqRR7ZEr KkUAZ/IzkWDsQNrz/7yRj/dse9skkbQWjBGcaEKGqj/W3+k3MX9FuvIm6EEPypNk9zAR 5sKTa6wVOUfvGWqsgB/Q5NihuYKkpkCnFlWjmvNo6troXSE0qtv14fGxDiKjvjAfjrj8 gyFzlaZf1F16UruBySCo4XVMZOsGrUNlwpMVPL/io2ssluG3QuASWXtd4hQ/re7Di5Zv +EmA== MIME-Version: 1.0 X-Received: by 10.153.6.35 with SMTP id cr3mr32797327lad.79.1426599424152; Tue, 17 Mar 2015 06:37:04 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Tue, 17 Mar 2015 06:37:04 -0700 (PDT) In-Reply-To: References: <1426353642.28541.3.camel@gnutls.org> Date: Tue, 17 Mar 2015 09:37:04 -0400 X-Google-Sender-Auth: u8smsRGRPlqBc9efp8d2iJGOSJA Message-ID: From: Phillip Hallam-Baker To: "Boyle, Vincent M" Content-Type: multipart/alternative; boundary=001a11349e2ce9dc7b05117c0f45 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 13:37:08 -0000 --001a11349e2ce9dc7b05117c0f45 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 17, 2015 at 8:10 AM, Boyle, Vincent M wrote: > I appreciate all the discussion on the list. To clarify a couple points, > we don't have a fixed idea what a TLS VPN standards should look like. > Rather, we have requirements, such as the ability to support mobile devices > connecting back to an enterprise network. We also want to come up with a > solution that would work with another layer of encryption (likely IPSec), > without getting into fights in the kernel. I'm particularly interested to > hear people's thoughts on that, as it has been a problem for us in the past > (in situations where we don't employ virtualization). As others already > said, interoperability between clients and servers of different vendors is > highly desirable as well. I already mentioned that we need a standard to > build our security testing around. I guess that's more a requirement for > *any* standard, not a particular technical requirement. > > Also, I want to second PHB's observation that we're not looking for new > technology. We really want to leverage what's already available and get > consensus on a standard that has good security properties and will promote > interoperability. > > So, after hearing about some conflicts with other side meetings I'm > leaning toward the Wednesday at 7:30 timeslot. I'll research a venue and > send out an announcement tomorrow. > I think it would also be very worthwhile considering the intersection of DPRIV and TLSVPN. My proposal for DPRIV (and several others) replaces the traditional method of configuring the recursive by IP address alone with a TLS based protocol to establish a long term session between the client and the service. This includes one or more hosts delivering the service and the corresponding cryptographic parameters. That session binding component could be shared between a DNS Privacy protocol and a TLS VPN protocol. The practical impact of this would be single point configuration for the end user. End users do not want to have to configure their devices to do DNS and then configure them for email and then configure them for the VPN and then configure the dozen other protocols that they need to use. Consider the case that Alice takes a job with the State Department and wants to have access to all the State Dept material on the phone while still being able to use the same phone to plan her daughter's wedding. As far as Alice is concerned, this should be a one time configuration, she types in the domain name she is given "it.state.gov" and the passcode "1234" and the device asks "do you want to use this service for services in *.state.gov". She says 'yes' and as far as she is concerned the job is done. Under the covers the principal changes are that the device will now direct all DNS requests for *.state.gov to their service over DPRIV protocol. This is the place where I would also put the hook for a TLSVPN and the reason I would want the two configurations to be tied together. Because when we are using split horizon DNS we want to map the 10.x.x.x and 192.168.x.x space into the address space of the target network rather than the local network. Having had my wife trying to make use of a printer on our home network in 192.168.1.x space from a machine logged into a VPN in 192.168.1.x space, this is certainly a concern. So in my view, one reason to consider a standards effort in IETF would be that if DPRIV does the job the right way, it will make it much easier to provide a seamless end user experience. The current problem with VPNs in my experience is that they are as reliable as a high school science experiment. If DPRIV is going to get widely adopted then it is going to have to find a group of early adopters. VPNs remain a source of real and lasting pain for end users. All the ones on the market today are very high administration. The only way that is going to get fixed is if the platforms start to support VPN in ways that meet enterprise needs in practice. --001a11349e2ce9dc7b05117c0f45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 17, 2015 at 8:10 AM, Boyle, Vincent M <= ;vmboyle@nsa.gov&g= t; wrote:
I appreciate all the discussion on the= list. To clarify a couple points, we don't have a fixed idea what a TL= S VPN standards should look like. Rather, we have requirements, such as the= ability to support mobile devices connecting back to an enterprise network= . We also want to come up with a solution that would work with another laye= r of encryption (likely IPSec), without getting into fights in the kernel. = I'm particularly interested to hear people's thoughts on that, as i= t has been a problem for us in the past (in situations where we don't e= mploy virtualization). As others already said, interoperability between cli= ents and servers of different vendors is highly desirable as well. I alread= y mentioned that we need a standard to build our security testing around. I= guess that's more a requirement for *any* standard, not a particular t= echnical requirement.

Also, I want to second PHB's observation that we're not looking for= new technology. We really want to leverage what's already available an= d get consensus on a standard that has good security properties and will pr= omote interoperability.

So, after hearing about some conflicts with other side meetings I'm lea= ning toward the Wednesday at 7:30 timeslot. I'll research a venue and s= end out an announcement tomorrow.

I thi= nk it would also be very worthwhile considering the intersection of DPRIV a= nd TLSVPN.

My proposal for DPRIV (and several othe= rs) replaces the traditional method of configuring the recursive by IP addr= ess alone with a TLS based protocol to establish a long term session betwee= n the client and the service. This includes one or more hosts delivering th= e service and the corresponding cryptographic parameters.

That session binding component could be shared between a DNS Privac= y protocol and a TLS VPN protocol.


= The practical impact of this would be single point configuration for the en= d user. End users do not want to have to configure their devices to do DNS = and then configure them for email and then configure them for the VPN and t= hen configure the dozen other protocols that they need to use.
Consider the case that Alice takes a job with the State Depart= ment and wants to have access to all the State Dept material on the phone w= hile still being able to use the same phone to plan her daughter's wedd= ing.

As far as Alice is concerned, this should be = a one time configuration, she types in the domain name she is given "<= a href=3D"http://it.state.gov">it.state.gov" and the passcode &quo= t;1234" and the device asks "do you want to use this service for = services in *.state.gov". She says &#= 39;yes' and as far as she is concerned the job is done.

<= /div>

Under the covers the principal changes are that th= e device will now direct all DNS requests for *.state.gov to their service over DPRIV protocol.

<= div>This is the place where I would also put the hook for a TLSVPN and the = reason I would want the two configurations to be tied together. Because whe= n we are using split horizon DNS we want to map the 10.x.x.x and 192.168.x.= x space into the address space of the target network rather than the local = network.

Having had my wife trying to make use of = a printer on our home network in 192.168.1.x space from a machine logged in= to a VPN in 192.168.1.x space, this is certainly a concern.

<= /div>

So in my view, one reason to consider a standards = effort in IETF would be that if DPRIV does the job the right way, it will m= ake it much easier to provide a seamless end user experience. The current p= roblem with VPNs in my experience is that they are as reliable as a high sc= hool science experiment.=C2=A0

If DPRIV is going t= o get widely adopted then it is going to have to find a group of early adop= ters. VPNs remain a source of real and lasting pain for end users. All the = ones on the market today are very high administration. The only way that is= going to get fixed is if the platforms start to support VPN in ways that m= eet enterprise needs in practice.
--001a11349e2ce9dc7b05117c0f45-- From nobody Tue Mar 17 15:14:07 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8361A892B for ; Tue, 17 Mar 2015 15:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGmI_n-Dt9Yo for ; Tue, 17 Mar 2015 15:14:05 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (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 E4E011A1B89 for ; Tue, 17 Mar 2015 15:14:04 -0700 (PDT) Received: by weop45 with SMTP id p45so18324349weo.0 for ; Tue, 17 Mar 2015 15:14:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=MT45NrYd/pzTXBrxr0ZRIdr4jt1RKcQcT7kRlZKgf0A=; b=VRFis1dy8sEA5HtXckrYZDw8IZ2/O2iKgE6mwxhH4g2J22aoa5ZoWwrUACN29AERgr P8WVpbQbVoflKS6L5kLxCn/njQ+5CwD2iiaYoklqF0Pdn47aB7LOlMj8XL8mLrvPtbwg 4q2ffzqGCMu80OgZok0hQtHRw0Yj96RorsRCD32y3DLvJPxsj/ZeWG76/7xLpdBPKGUv 7nRP4HX9661CgSuJNYs0D/xRi7vgaEV8bjvK8019fwMsLEAjR/cb7uZLtYUJfz4LJ28M +Cq8ucqxNTJeLGSYAT+fba6rNPO1RHDX71FGsarLqhmd4K/1+jF+TVieOyzWqQg1Q0Sd YybQ== X-Gm-Message-State: ALoCoQmSOZpyBzzCdCLpkDLEiozgid8N9ZSGxHg/U/AAbiwzwwaZ5BS2m0bLfJ4Vnwb6i+lpPMFs X-Received: by 10.180.81.7 with SMTP id v7mr1443520wix.27.1426630443730; Tue, 17 Mar 2015 15:14:03 -0700 (PDT) Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id u18sm470714wib.1.2015.03.17.15.14.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 15:14:02 -0700 (PDT) Message-ID: <5508A726.5090406@azet.org> Date: Tue, 17 Mar 2015 23:13:58 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <9A043F3CF02CD34C8E74AC1594475C73AAFB25C2@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig204ADF0BC38D41F293E68EC0" Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 22:14:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig204ADF0BC38D41F293E68EC0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Nikos Mavrogiannopoulos wrote: > argument more than a decade ago, and still the majority of VPNs in use > are user-space VPNs based on SSL. The last sentence may actually > capture the benefit... it simply works :) >=20 +1. IPSec might (!) work well if you use one vendor throughout your network, pretty much the same thing as some have argued with vendor SSL/TLS VPN solutions. Because IPSec is such an overly complicated protocol there's not much security in the clients that are available throughout enduser operating system. Apple, for example, uses racoon (a NetBSD client) for IPSec. It only supports IKEv1 in Aggressive Mode. That's a pretty big userbase that is forced to use an insecure protocol. Besides a couple of commercial and seldomly used FOSS software implementations nobody really implements all authentication subprotocols. I rarely see companies that configure IPSec for their users (if they do, most hate it and constantly have problems with that decision), most do use AnyConnect or OpenVPN. That is, of course, for roadwarrior and site-access setups. IPSec works pretty well for site-to-site setups; then -- again -- if you use different vendors, or even different product-cycles of a given vendor, you might run into interoperability problems. I don't know of a single network engineer that enjoys deploying IPSec. I don't really see a need for a new standard as I also think that everything that is needed for a TLS VPN is already specified. Maybe a BCP document on how to properly use and implement TLS VPNs would make more sense? Aaron --------------enig204ADF0BC38D41F293E68EC0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVCKcnAAoJEOTbZJL9ubXV9ugP/RGBTZG6FacSYH+W/6Td9+nk 0hNDKYqk22Ei9NdfVWPWea9xujIIvhothGAE4ut0n9xIt9YI05A1AWOfhlmkxCZY vFxBHdhgBQ4lI4/3Kdg95EFPMJJ97NKTIITu+6t+wzrcXTiVi2MrXY4pUvclSD/E AnWN0nW0kfO8++hrWj0i8Tts/YkHb9TN/pVcUcKRCwaooGawNphvjv99BD6ZVDtB Y8rQfB9xps84LANDPV/HcnjNa+6puUs8YPWio5F5rJf/x1MY5n5cYNLFRr6rTmhu 80HE9cBiBJO0hCZd5/qRN/x+A0fn6zT0XuMkxzJlZRf+fpVN+rNJEOXgcHxxeE7e qUN+Ipc3JazgE+A9jkukLov+bqCCRbc/8uXOPrRyZmYooD8BRKreYejb6iAskLU3 4d9MjuJqd18QeQk12y8NmvCh7X0jnoMtBZRtAjo8XDseQ+H/f8DMXWOrHVqIr3/G 6P5lLPeKNzPj9WbxvV1SsQKdal6ubpe8PinpZFhlc4B6i7E/zqx/Uyr3QED5Vwo9 38y3V8OAr80GG89HRRGf9Grgcz7nToGH814s23yzVqHExvwl6weNpWDZ5jmET8SY Ji6z0sTpDhO88pfIZNbtPFvibLjT5Ail4L4m+7wMtpadcx0YcRv1/vH0H+4Isexh FeFbten+YhZQCRBvhGlf =ejiu -----END PGP SIGNATURE----- --------------enig204ADF0BC38D41F293E68EC0-- From nobody Tue Mar 17 20:40:22 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2015E1A8A57 for ; Tue, 17 Mar 2015 20:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXTyiEtxHUbH for ; Tue, 17 Mar 2015 20:40:20 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891E71A8A50 for ; Tue, 17 Mar 2015 20:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1426650019; x=1458186019; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=NL8qa9DzgVlYsrW5ewK7j5jDT78z72kxLfV8fSQsMu0=; b=Yb4sKXl9JcOSt6unHico+ZMwscvjLbVlOWoR3IIWstNOqjq7ehmpOTOm IeRFv1CL5qKm6GZhmh5fExoF4GLTZYzNShczACr+afFSjaoWRboe0fMH8 rH4+HCU8egoIGJUxhMaUQgmVgC0bDXJhzIio2t5E6kn6dPivftWvQN96G E=; X-IronPort-AV: E=Sophos;i="5.11,420,1422874800"; d="scan'208";a="314650393" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 18 Mar 2015 16:40:18 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Wed, 18 Mar 2015 16:40:18 +1300 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] looking to hold a TLS VPN side meeting at IETF 92 Thread-Index: AdBhLUAQmFB8XwvaR4mPYCV6pbMXPQ== Date: Wed, 18 Mar 2015 03:40:17 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B16@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 03:40:21 -0000 Aaron Zauner writes:=0A= =0A= >IPSec might (!) work well if you use one vendor throughout your network,= =0A= >pretty much the same thing as some have argued with vendor SSL/TLS VPN=0A= >solutions. =0A= =0A= That's the impression I got from folks who have to deploy IPsec solutions,= =0A= there seem to be two approaches:=0A= =0A= 1. Use all gear from the same vendor, configured identically.=0A= =0A= 2. If you can't manage that, budget lots of time to get things working, and= =0A= bring along something like OpenSWAN and a lot of debugging tools (to quo= te=0A= their docs, "Configuration is normally the easy portion of setting up an= =0A= ipsec tunnel, it's normally the debugging that takes up the majority of= =0A= time. Particularly if dealing with heterogeneous peers"). Get things up= =0A= and running, typically in some lowest-common-denominator mode, and never= =0A= touch it again in case it breaks.=0A= =0A= >Because IPSec is such an overly complicated protocol there's not much=0A= >security in the clients that are available throughout enduser operating=0A= >system. Apple, for example, uses racoon (a NetBSD client) for IPSec. It on= ly=0A= >supports IKEv1 in Aggressive Mode. =0A= =0A= That's pretty much a given when you have to use approach #2, unfortunately.= =0A= =0A= >IPSec works pretty well for site-to-site setups; then -- again -- if you u= se=0A= >different vendors, or even different product-cycles of a given vendor, you= =0A= >might run into interoperability problems. I don't know of a single network= =0A= >engineer that enjoys deploying IPSec.=0A= =0A= Yup. It's great if you're being paid by the hour, but then again so is=0A= digging ditches.=0A= =0A= >I don't really see a need for a new standard as I also think that everythi= ng=0A= >that is needed for a TLS VPN is already specified. Maybe a BCP document on= how=0A= >to properly use and implement TLS VPNs would make more sense?=0A= =0A= Or just "Use OpenVPN". It's not the perfect solution, but most of the time= it=0A= just works. Want to use an Android phone to check email on your corporate= =0A= server? Use OpenVPN. iPhone to monitor your home alarm? OpenVPN. Two PC= s=0A= to talk to each other privately? OpenVPN.=0A= =0A= Peter.= From nobody Wed Mar 18 12:00:08 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE821A9063 for ; Wed, 18 Mar 2015 12:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eI-JrL82ben for ; Wed, 18 Mar 2015 12:00:05 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (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 A770A1A900A for ; Wed, 18 Mar 2015 12:00:04 -0700 (PDT) Received: by wegp1 with SMTP id p1so39789197weg.1 for ; Wed, 18 Mar 2015 12:00:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=ima1I8MOmiTZKQJgdKKaZNhfLmdCftjLMtNP/IUihqA=; b=cBfb0kd+XmHuvGj3XglkYN7iQPM1NNj1BwvRvTPEdRs92obc4UTuOX8DnFo6lXm6vc lFtpzDX3UxBDGrrxKepeZTK8Tb9vsuANjjYueLQVg1ofxLefRkTLxWQgiAKwqAIHS0nl 9IZm808WBQN9YdXnz8SsPxJJ/OtdptLttrgBx9VYfN6RqQFZ00Ur36674/S6mK0k8BO1 EkMxnX+uVhOrQjGRx2rRLz8dP5LaghzQB+g3tViqJvQrGs5A85A75TSU5zyOVSx6wEnf 09rVZ02cbbMelKivszYg/E8htTHX1BYVK3NO1SaEsNKArsLsPyrxOBdPurtxydWMdetL 5t9Q== X-Gm-Message-State: ALoCoQmOkGzRuoUJHbonntIlY8SLiElIIep+euUWMb+O4sKbPRLPNuHgj9M+J2xXbt6uzL0So7Ap X-Received: by 10.195.13.168 with SMTP id ez8mr142766858wjd.30.1426705203330; Wed, 18 Mar 2015 12:00:03 -0700 (PDT) Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id pa4sm25663463wjb.11.2015.03.18.12.00.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 12:00:02 -0700 (PDT) Message-ID: <5509CB2D.7060100@azet.org> Date: Wed, 18 Mar 2015 19:59:57 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B16@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B16@uxcn10-5.UoA.auckland.ac.nz> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig4FB2B16B13F8FD1F8196F950" Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 19:00:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4FB2B16B13F8FD1F8196F950 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Peter, Peter Gutmann wrote: > That's pretty much a given when you have to use approach #2, unfortunat= ely. >=20 Yes, but that's not only the implementers fault, it's certainly an issue with the protocol if almost every implementation happens to be non-interoperable unless you configure every single setting in the same way and pray that it works (it probably won't anyway). >=20 > Yup. It's great if you're being paid by the hour, but then again so is= > digging ditches. Nah it's not. I guess I only commented on this thread because I currently have a customer engagement with opensource IPsec stacks. And to support a lot of client operating systems. I've pretty much told them by now that I'm not comfortable recommending anything that uses IPSec currently. Mostly because you'll end up with a common denominator of IKEv1 in Aggressive Mode. Even then using PSK is more of an issue than PKIX - but how are you going to manage enduser devices where you do not have any deployment influence? Customers will get pissed if they need to look up how to install a certificate to use a tunnel from their mobile phone. > Or just "Use OpenVPN". It's not the perfect solution, but most of the = time it > just works. Want to use an Android phone to check email on your corpor= ate > server? Use OpenVPN. iPhone to monitor your home alarm? OpenVPN. Tw= o PCs > to talk to each other privately? OpenVPN. That does require installing additional apps on many plattforms. StrongSWAN seems to have similar apps for mobile devices. A good security protocol should not need an AppStore, I guess :) OpenVPN is also not a TLS-only "VPN". An OpenVPN developer told me that recent releases do duplexing (mentioned earlier): TLS is used for a control channel while the data channel is AES-CBC encrypt-then-mac. Aaron --------------enig4FB2B16B13F8FD1F8196F950 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVCcsuAAoJEOTbZJL9ubXVkFoQAK8TBj2yYpXbZbk9mcOxhLSh NpUNadSd8KmeWFm8r/efJwoO7RN9n6aHiDNaji+19e31Nmzhxbi2hAG+PFyPfRuU 8wQaNwk5NKeTOnoS/vgyYRU7nqOFxwqkaE/dRgam4HO1zoxul4GYLP6fDfcY3mXD 5+mZdUWLEQeG7oMa9m6FEGuYlRDosRrXFPzStCUXp5q8/4b/+hTKM4RqKVC+EhUs nQJ7uBedEGJU5EQi3G3Nz+cxT1wIU2nbRpBIMrayaPxbLn+drl7CGjRGpusRH/Zm IYcP8Y9uxzFKVpowrBpBl2O1bOWGvCSFwqc8lpchW9b5l3E8VCT08EeVYzltyBH7 VXlwOk2kRTpHNLtxIBmlSZVLHZR/qHtSBICbaRliySYcyNnT6MwU/6AdWGU6Sfvn SR7pHG1FiolfK5+nKcQGX7zrL0zHBLS/bvUTQOQfOB7jjR9TRr1DpY8eRrHNmuzA nhylat92ariQZOBTnpOmJGWx2yj75SmLTvWC+5kwWGJHXztTP8LLpSHYzolizNHv hgSujDKQca3HjDRR07FkMkz7JusmTZeUC4pDRe/0/fapLK8s2wsExpGaSQky1Anb gQTq+vd3TxVIWen/RAOk2G+tS0FXCxJ3iFUytUy7vpQhsSaJLsoPXDc2lAb2pDxm QAEhknO0vhagWkA9irA+ =5HXa -----END PGP SIGNATURE----- --------------enig4FB2B16B13F8FD1F8196F950-- From nobody Wed Mar 18 13:02:58 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DED1A8884 for ; Wed, 18 Mar 2015 13:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC8tpAH9H1iw for ; Wed, 18 Mar 2015 13:02:54 -0700 (PDT) Received: from emvm-gh1-uea08.nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6401A004A for ; Wed, 18 Mar 2015 13:02:54 -0700 (PDT) X-TM-IMSS-Message-ID: <14ba1c53000315ce@nsa.gov> Received: from MSHT-GH1-UEA02.corp.nsa.gov (msht-gh1-uea02.corp.nsa.gov [10.215.227.181]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 14ba1c53000315ce ; Wed, 18 Mar 2015 16:02:51 -0400 Received: from MSMR-GH1-UEA04.corp.nsa.gov ([10.215.228.141]) by MSHT-GH1-UEA02.corp.nsa.gov ([10.215.227.181]) with mapi id 14.02.0347.000; Wed, 18 Mar 2015 16:02:51 -0400 From: "Boyle, Vincent M" To: "'saag@ietf.org'" Thread-Topic: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 Thread-Index: AdBhtoMSmzKwcb83TCGnnAIJlnjatg== Date: Wed, 18 Mar 2015 20:02:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.225.46] Content-Type: multipart/alternative; boundary="_000_E18BF42C3D667642ABC0EF4B6064EB67D091AC81MSMRGH1UEA04cor_" MIME-Version: 1.0 Archived-At: Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 20:02:56 -0000 --_000_E18BF42C3D667642ABC0EF4B6064EB67D091AC81MSMRGH1UEA04cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a quick update: a colleague of mine and I did some investigating and w= e think the City Tavern would be a good venue for the side meeting. I'm per= forming a bit of due diligence to make sure they can accommodate us, but I = believe that's where we will meet (unless a Dallas local wants to warn us o= ff). So, 7:30 PM local time at the City Tavern (1402 Main Street, which loo= ks to be a 10 minute walk from the Fairmont). I'll attempt to reserve some = space under my name. Hope to see you there, Mike --_000_E18BF42C3D667642ABC0EF4B6064EB67D091AC81MSMRGH1UEA04cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a quick update: a colleague of mine and I did s= ome investigating and we think the City Tavern would be a good venue for th= e side meeting. I’m performing a bit of due diligence to make sure th= ey can accommodate us, but I believe that’s where we will meet (unless a Dallas local wants to warn us off). So, 7:30 = PM local time at the City Tavern (1402 Main Street, which looks to be a 10 = minute walk from the Fairmont). I’ll attempt to reserve some space un= der my name.

 

Hope to see you there,

Mike

--_000_E18BF42C3D667642ABC0EF4B6064EB67D091AC81MSMRGH1UEA04cor_-- From nobody Wed Mar 18 23:17:27 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665841A893F for ; Wed, 18 Mar 2015 23:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNA6CPj9mONE for ; Wed, 18 Mar 2015 23:17:20 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5661A893B for ; Wed, 18 Mar 2015 23:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1426745840; x=1458281840; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=+itnZxbbhkXRsdX70WTw0M/sf8MP9yaA6dOIVBB+EZs=; b=RGnQzNV3mzE5Prq83tt63Oy/k1Ug5Cyk4Z2p4NLLd0TVKzTR8Fpimape 54uJ3O3yWP1fSygoYHe+ooA/zcKQy494LJzT62TXaLZVBd1+0bR+qZxiN NSUxxGNpZmh4tdqgGB67BWzseh3FQ5ndTFOolP00PdMQQBFF2gddrBSZn 4=; X-IronPort-AV: E=Sophos;i="5.11,428,1422874800"; d="scan'208";a="315041933" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 19 Mar 2015 19:17:18 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Thu, 19 Mar 2015 19:17:10 +1300 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] looking to hold a TLS VPN side meeting at IETF 92 Thread-Index: AdBiDFUViBmieqsEQeKPYIfhgk/KZA== Date: Thu, 19 Mar 2015 06:17:10 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFB7049@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 06:17:25 -0000 Aaron Zauner writes:=0A= =0A= >[...]=0A= =0A= I think we're both in violent agreement there, the protocol sucks, the spec= =0A= sucks (despite heroic efforts by the post-v1 cleanup crew), implementations= =0A= suck, and having to deploy it in the field is the sum of the suckage of all= of=0A= its parts :-).=0A= =0A= >OpenVPN is also not a TLS-only "VPN". An OpenVPN developer told me that=0A= >recent releases do duplexing (mentioned earlier): TLS is used for a contro= l=0A= >channel while the data channel is AES-CBC encrypt-then-mac.=0A= =0A= Yeah, it's kind of a swiss-army-chainsaw of getting packets from A to B. T= his=0A= again points to a problem in trying to do a spec, if you come up with some= =0A= clean, minimal design then it won't do a lot of what OpenVPN (or a lot of= =0A= commercial TLS VPNs) do, so it probably won't see much uptake. OTOH if you= =0A= try and make it a swiss-army-chainsaw spec... well, IKEv1 tried that.=0A= =0A= In any case though, I'm not really fussed, if people feel like doing a spec= =0A= for this, feel free..=0A= =0A= Peter.= From nobody Thu Mar 19 03:55:27 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33CD1A88CE for ; Thu, 19 Mar 2015 03:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uo9XLRcjWcD2 for ; Thu, 19 Mar 2015 03:55:23 -0700 (PDT) Received: from emvm-gh1-uea08.nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id A73F31A883A for ; Thu, 19 Mar 2015 03:55:23 -0700 (PDT) X-TM-IMSS-Message-ID: <17eb304100036cce@nsa.gov> Received: from MSHT-GH1-UEA02.corp.nsa.gov (msht-gh1-uea02.corp.nsa.gov [10.215.227.181]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 17eb304100036cce ; Thu, 19 Mar 2015 06:55:20 -0400 Received: from MSMR-GH1-UEA02.corp.nsa.gov (10.215.227.180) by MSHT-GH1-UEA02.corp.nsa.gov (10.215.227.181) with Microsoft SMTP Server (TLS) id 14.2.347.0; Thu, 19 Mar 2015 06:55:21 -0400 Received: from MSMR-GH1-UEA04.corp.nsa.gov ([10.215.228.141]) by MSMR-GH1-UEA02.corp.nsa.gov ([10.215.227.180]) with mapi id 14.02.0347.000; Thu, 19 Mar 2015 06:55:21 -0400 From: "Boyle, Vincent M" To: "'saag@ietf.org'" Thread-Topic: RE: [saag] looking to hold a TLS VPN side meeting at IETF 92 Thread-Index: AdBiMzFA5a/uYbE0RRW+3+D5B49e9Q== Date: Thu, 19 Mar 2015 10:55:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.225.46] Content-Type: multipart/alternative; boundary="_000_E18BF42C3D667642ABC0EF4B6064EB67D091AD3CMSMRGH1UEA04cor_" MIME-Version: 1.0 Archived-At: Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 10:55:26 -0000 --_000_E18BF42C3D667642ABC0EF4B6064EB67D091AD3CMSMRGH1UEA04cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I left out an important detail; the date! The side meeting will be at 7:30 = at City Tavern on *Wednesday*, the 25th. Thanks to Joe Salowey for pointing that out to me. Mike On Wed, Mar 18, 2015 at 1:02 PM, Boyle, Vincent M > wrote: Just a quick update: a colleague of mine and I did some investigating and w= e think the City Tavern would be a good venue for the side meeting. I'm per= forming a bit of due diligence to make sure they can accommodate us, but I = believe that's where we will meet (unless a Dallas local wants to warn us o= ff). So, 7:30 PM local time at the City Tavern (1402 Main Street, which loo= ks to be a 10 minute walk from the Fairmont). I'll attempt to reserve some = space under my name. Hope to see you there, Mike --_000_E18BF42C3D667642ABC0EF4B6064EB67D091AD3CMSMRGH1UEA04cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I left out an important detail; the date! The side m= eeting will be at 7:30 at City Tavern on *Wednesday*, the 25th<= /sup>.

Thanks to Joe Salowey for pointing that out to me.

 

Mike

 

On Wed, Mar 18, 2015 at 1:02 PM, Boyle, Vincent M &l= t;vmboyle@nsa.gov&= gt; wrote:

Just a quick update: a colleague of mine and I did some investigat= ing and we think the City Tavern would be a good venue for the side meeting= . I’m performing a bit of due diligence to make sure they can accommodate us, but I believe that’s where we = will meet (unless a Dallas local wants to warn us off). So, 7:30 PM local t= ime at the City Tavern (1402 Main Street, which looks to be a 10 minute wal= k from the Fairmont). I’ll attempt to reserve some space under my name.

 

Hope to see you there,

Mike

 

--_000_E18BF42C3D667642ABC0EF4B6064EB67D091AD3CMSMRGH1UEA04cor_-- From nobody Thu Mar 19 04:22:02 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C9C1A899E for ; Thu, 19 Mar 2015 04:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIjjTXK87DlP for ; Thu, 19 Mar 2015 04:21:53 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 1F1A81A8990 for ; Thu, 19 Mar 2015 04:21:52 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t2JBLYnF029753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Mar 2015 13:21:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2JBLVWt001909; Thu, 19 Mar 2015 13:21:31 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21770.45371.223543.54229@fireball.kivinen.iki.fi> Date: Thu, 19 Mar 2015 13:21:31 +0200 From: Tero Kivinen To: Aaron Zauner In-Reply-To: <5509CB2D.7060100@azet.org> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B16@uxcn10-5.UoA.auckland.ac.nz> <5509CB2D.7060100@azet.org> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 7 min Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 11:21:54 -0000 Aaron Zauner writes: > Peter Gutmann wrote: > > That's pretty much a given when you have to use approach #2, unfortunately. > > > > Yes, but that's not only the implementers fault, it's certainly an issue > with the protocol if almost every implementation happens to be > non-interoperable unless you configure every single setting in the same > way and pray that it works (it probably won't anyway). Actually it is implementors fault, as they use obsoleted IKEv1 protocol. IKEv2 obsoleted IKEv1 in 2005, but now ten years later, people are still using old version. IKEv2 fixed lots of issues in IKEv1, especially in the configuration end, for example making things like lifetimes local matter, so user does not need to configure or care about them, and they will not cause interoperability issues. Also things like you must use aggressive mode with road warriors with pre-shared keys went away, and the IP-address assignment and EAP in the base standard there is no need for non-interable versions of xauth and cfg-mode. The problem is that with all its problems the IKEv1 still works "well" enough, that even if implementors implement IKEv2 they do not turn it on by default, i.e. they usually first try IKEv1. This means those implementations do not benefit from features provided by IKEv2. > Nah it's not. I guess I only commented on this thread because I > currently have a customer engagement with opensource IPsec stacks. And > to support a lot of client operating systems. I've pretty much told them > by now that I'm not comfortable recommending anything that uses IPSec > currently. Mostly because you'll end up with a common denominator of > IKEv1 in Aggressive Mode. Even then using PSK is more of an issue than > PKIX - but how are you going to manage enduser devices where you do not > have any deployment influence? Customers will get pissed if they need to > look up how to install a certificate to use a tunnel from their mobile > phone. How about proposing using non-obsoleted protocol, instead of proposing protocol that was obsoleted more than ten years ago? If the implementation you plan to use only supports IKEv1, then you know it has not been updated in last ten years, thus most likely it is not secure anymore. -- kivinen@iki.fi From nobody Thu Mar 19 16:53:20 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566801A014D for ; Thu, 19 Mar 2015 16:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a0-0qbtl84u for ; Thu, 19 Mar 2015 16:53:15 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913451A0111 for ; Thu, 19 Mar 2015 16:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1426809194; x=1458345194; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=+AqFvsx5faBtuJ67kYyGawrLalC9PG9onfvRh/L+Uj0=; b=KLXaslI+szX2JB+okG7rV/nKkDQualpHeYV2iOYAVd2ZCucXg1dpIiYq kiXmEBQ9BP1eCfJ2UFEdXL8UpPHOGyPRrDj6H0xgBFSBN8YzylUCK72WY 6FsuFql9XjjE5dKg/dRQrb0J+alWDR0S1ObHLEiCKQLVqsgVMb2FJ7dFy E=; X-IronPort-AV: E=Sophos;i="5.11,433,1422874800"; d="scan'208";a="315241424" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 20 Mar 2015 12:53:12 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Fri, 20 Mar 2015 12:53:05 +1300 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [Cfrg] Elliptic Curves - byte order (ends on March 25th) Thread-Index: AdBin9efvg0R4+hMTaOVqR1PnMH5Xg== Date: Thu, 19 Mar 2015 23:53:05 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFB7E5B@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] [Cfrg] Elliptic Curves - byte order (ends on March 25th) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 23:53:19 -0000 Phillip Hallam-Baker writes:=0A= >On Thu, Mar 19, 2015 at 5:20 PM, Salz, Rich wrote:=0A= >>> I protest that, as a British person, dictionaries are not required for = such=0A= >>> quotidian vocabulary. There's a reason why we grow up listening to Radi= o 4.=0A= >>=0A= >> Quotidian? Now you're just showing off, which is very un-British.=0A= >=0A= >No, you are just one of the few Americans who can recognize how Brits show= off.=0A= =0A= By hanging on in quiet desperation?=0A= =0A= Peter.= From nobody Mon Mar 23 08:05:17 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC911A8F51 for ; Mon, 23 Mar 2015 08:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exZ1QwZXYI1N for ; Mon, 23 Mar 2015 08:05:09 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E531A8F4B for ; Mon, 23 Mar 2015 08:05:08 -0700 (PDT) Received: from [IPv6:2001:67c:370:176:3429:53ff:fe09:c1e2] (unknown [IPv6:2001:67c:370:176:3429:53ff:fe09:c1e2]) by mail.nic.cz (Postfix) with ESMTPSA id 309541400C3 for ; Mon, 23 Mar 2015 16:05:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1427123107; bh=k2TSTBKjA3KzJOwS4MxdS967ZvMuvOwUCQPKUaItJ9w=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=jIrI6rCx3KkkyxYi8lbm3N/iVky8z9oO/FzEv8a15f6/7A+p2g18WxAoUv4HzuhtE DaIJCWIqahIsPIPCUUH/Amt8Xx0R6M+1yKV872zLoJal2Apus8xmZ+OJu4qP4XTKqX wIhODoSLMkBKzU4hLaPDjTGWw+Or70MGQW+BLjq0= Message-ID: <55102BA1.3090109@nic.cz> Date: Mon, 23 Mar 2015 16:05:05 +0100 From: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <2070793.lmylhNrOvK@pc-cznic4> In-Reply-To: <2070793.lmylhNrOvK@pc-cznic4> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [saag] review request, draft-jvcelak-nsec5-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 15:05:10 -0000 Hello list, I just submitted the draft into the data tracker: http://datatracker.ietf.org/doc/draft-vcelak-nsec5/ Regards, Jan From nobody Mon Mar 23 14:00:39 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AFC1B2A4D; Mon, 23 Mar 2015 14:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxrdBErO-Txu; Mon, 23 Mar 2015 14:00:37 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31051A1A98; Mon, 23 Mar 2015 14:00:37 -0700 (PDT) Received: from [31.133.180.160] (dhcp-b4a0.meeting.ietf.org [31.133.180.160]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t2NL0XVo003942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Mar 2015 14:00:37 -0700 Message-ID: <55107EEB.8070300@dcrocker.net> Date: Mon, 23 Mar 2015 16:00:27 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Apps Discuss , "saag@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 23 Mar 2015 14:00:37 -0700 (PDT) Archived-At: Subject: [saag] BarBOF for PRIME/DMAIL, after Apps and SAAG presentations X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:00:39 -0000 There was a presentation at this morning's Apps Area session on PRIME, an privacy-intensive email architecture by Ladar Levison. http://darkmail.info/ The presentation covered basic architecture. At the Thursday afternoon SAAG session, Ladar will discuss more detailed security considerations for the work. We've secured a room for follow-on Bar-BOF-y discussions after the SAAG session: Thursday evening, 7:30pm Room: Royal d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Mar 23 15:28:21 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD621A1BCA; Mon, 23 Mar 2015 15:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJY6Q9V40PUJ; Mon, 23 Mar 2015 15:28:15 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698421A1BEF; Mon, 23 Mar 2015 15:28:15 -0700 (PDT) Received: from [31.133.180.160] (dhcp-b4a0.meeting.ietf.org [31.133.180.160]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t2NMSApd005424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Mar 2015 15:28:14 -0700 Message-ID: <55109374.2010408@dcrocker.net> Date: Mon, 23 Mar 2015 17:28:04 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: R.E.Sonneveld@sonnection.nl, dcrocker@bbiw.net, Apps Discuss , "saag@ietf.org" References: <55107EEB.8070300@dcrocker.net> <55108498.1050006@sonnection.nl> In-Reply-To: <55108498.1050006@sonnection.nl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 23 Mar 2015 15:28:14 -0700 (PDT) Archived-At: Subject: Re: [saag] [apps-discuss] BarBOF for PRIME/DMAIL, after Apps and SAAG presentations X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 22:28:17 -0000 On 3/23/2015 4:24 PM, Rolf E. Sonneveld wrote: >Does Ladar intend to submit DMAIL/DIME via the ISE > or is there any chance a DIME WG will be chartered? We discussed this, some time back, but not recently. Given his near-term workload, I would not want to predict how or whether RFC publication of the docs will proceed. IMO, the Independent stream would be a reasonable choice. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Mar 23 19:29:06 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256391B2B97 for ; Mon, 23 Mar 2015 19:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQ5UZtKReFLw for ; Mon, 23 Mar 2015 19:29:03 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (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 1471E1B2B95 for ; Mon, 23 Mar 2015 19:29:02 -0700 (PDT) Received: by wixw10 with SMTP id w10so81384468wix.0 for ; Mon, 23 Mar 2015 19:29:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=hfhUrmYeX4Kh7mDvyNA2L7DjgRXoz8I02+dbz6GsVfg=; b=BSNyh8QqVYuNmTBedtqCuchDPVshP6LouSjLxjXBNmmpPxNhdwFey9gLKeyq3wLvN6 NS+DhAre0RUIC9fyI7ARrczkc7EWjFn8LnAR9RiVuCjDGcMeTzioBFIrCD+nrrtxEJmH ZKeXNAO7XCy04OSila0uymWRwf9UEKuCYKtl3ne7qlkpDUknCTCohpKEahwC+CnhIWqn /rbghHxdVkS0mgwtij51E/C4DcXKjDX66B5YLOSIopzEdkbAz9JDuaDkPmY+zpPcTQ6U E5lbXiRcMIi+ac4zbYZKn9aSLqASXquI2zJOwzcqabu2br+EIdKDCHi2Iz3BBaUS/Z/7 LKKg== X-Gm-Message-State: ALoCoQk9mBflaWnl3WJ1Nb6YNpOMeR5W5pwbsR1COos1CZTe2L20XseD7eU91kQEq2J+MSOAgczs X-Received: by 10.194.60.104 with SMTP id g8mr3619084wjr.96.1427164141537; Mon, 23 Mar 2015 19:29:01 -0700 (PDT) Received: from typhoon.azet.org (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id k6sm13778749wia.6.2015.03.23.19.28.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 19:29:00 -0700 (PDT) Date: Tue, 24 Mar 2015 03:28:58 +0100 From: Aaron Zauner To: Tero Kivinen Message-ID: <20150324022857.GA15592@typhoon.azet.org> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B16@uxcn10-5.UoA.auckland.ac.nz> <5509CB2D.7060100@azet.org> <21770.45371.223543.54229@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: <21770.45371.223543.54229@fireball.kivinen.iki.fi> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 02:29:05 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Tero, * Tero Kivinen [19/03/2015 12:21:36] wrote: > Actually it is implementors fault, as they use obsoleted IKEv1 > protocol. IKEv2 obsoleted IKEv1 in 2005, but now ten years later, > people are still using old version. IKEv2 fixed lots of issues in > IKEv1, especially in the configuration end, for example making things > like lifetimes local matter, so user does not need to configure or > care about them, and they will not cause interoperability issues. Also > things like you must use aggressive mode with road warriors with > pre-shared keys went away, and the IP-address assignment and EAP in > the base standard there is no need for non-interable versions of xauth > and cfg-mode. >=20 > The problem is that with all its problems the IKEv1 still works "well" > enough, that even if implementors implement IKEv2 they do not turn it > on by default, i.e. they usually first try IKEv1. This means those > implementations do not benefit from features provided by IKEv2. I don't disagree, see previous mails and below. That being said, it's still unclear to me why something like IKEv1 has been proposed and standardized at all, but that was long before my time. Protocol upgrades are a big issue throughout working groups and implementations. > How about proposing using non-obsoleted protocol, instead of proposing > protocol that was obsoleted more than ten years ago? If the > implementation you plan to use only supports IKEv1, then you know it > has not been updated in last ten years, thus most likely it is not > secure anymore. This certainly wasn't my proposal. The issue I see is that a lot of operating systems (not appliances) will default to IKEv1 or only support IKEv1 (in the case of Apple). Thus the common denominator is still IKEv1. I'd be happy to help design products that support IKEv2. As is (i.e. without shipping a seperate application to endusers) there's no real way to do that -- at least that I'm aware of. (We're going off-topic here, I'd suggest off-list CCs) Aaron --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVEMvpAAoJEOTbZJL9ubXV7I0QAL26fA/Ez4bfj/Kn4KExA6Jm 67dsm2V2HTdj9ohE0WDxQ6nTX7zHnjnlq8vPfkOu5tmgNpzERW6pAtTuiDr2IyuJ hIyqkdntWFrrkr3Yclwe58z6+wPbkDqNSL3NHwR3GJcRDlKAiz6Zy7ge1E6is/hn gHYPjO8UV7X6jaFbzFYu6+ItgrYeX4o+eQIlwodSGfV3TwGqdTMm2zWEUOMANQJH KFgQdOnqh+423OiESWtOljVsG3/wqh+4mG350ZZqBaCzDU/QlPtQJdTvD2PL+0px 5fKe4cNQwBUfaiKjBSWdhEW/lOPQmG8RZstmQujjCrBB1luC9PVnftEydgdtUY0F zXq+cavHmoNTp0bRV6tTnqMyWauZJPFLRvQLEQqNKed7I51Z00+kG+qeCZxzxmr/ R8Dasgxh60ehUw+b+yk72o8LpvfisBoo0dew6ZaidfrYr2Unwmc1l4blDCsObdsV f5TOmCc2kvD2wIvBUBXwzKFJkx4170RjIrtGECe0Ot9EIv0R0YkcbtaVwm//EwGO 7Zln3/NaiuWEq6f3hCLLdUoTlMyxlhEKR6IWVGpD1tFwAzTuWXK+nwuCaEjfJsOr 5Tj45FBKjctGU/VitHNPB5GrMfohZZ1VMaSCY3VRHA09UpH+hzB8SP1lzj+MSF1n tEDW2OkIlv04dDBjQj+s =9USM -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From nobody Tue Mar 24 07:39:40 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD941A876D for ; Tue, 24 Mar 2015 07:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JihiOqUXQR-k for ; Tue, 24 Mar 2015 07:39:27 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::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 1BDFC1A87CB for ; Tue, 24 Mar 2015 07:38:41 -0700 (PDT) Received: by lagg8 with SMTP id g8so161188125lag.1 for ; Tue, 24 Mar 2015 07:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bDD0ZXDzBH2aCqzGzQ3N08Y+sRKgjFYUxRvLeSUMF5Q=; b=GWKKtwmBREx7y3Ph3Ti5Df+kguDYB2C47EBEvqUP3MCGu7qojXbExRRCp3x6uG5c67 g/rdu1+7HUSiPY24uSXtGTkzk6zrFsl7XgVttGsOZsYK52HUxEmkcPhS87PaqbhaKIhF 0oaZZoL+ef9ubr8XiRziyEkOf+b/Daw3nA4rxIK5bmLbCdvgyXgYwjinZ9l3khQc9hP1 h4yphqEf5Cu5OeL3YHwXoNm35zMV/hEY3TvPufn8Etu1jiXyADa3OoeCRPbGoogl2+Wt 3FLLFcD0z9yqA4AMiKreIoid1bml4ZZERLYas6HIcrgtreaZoHj+4uEZLO673frZCRmt M++w== MIME-Version: 1.0 X-Received: by 10.152.25.132 with SMTP id c4mr4106391lag.4.1427207919611; Tue, 24 Mar 2015 07:38:39 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Tue, 24 Mar 2015 07:38:39 -0700 (PDT) In-Reply-To: <4B3D2CEE-BEB9-4BD3-A305-E1D79F8C5FD3@gmail.com> References: <4B3D2CEE-BEB9-4BD3-A305-E1D79F8C5FD3@gmail.com> Date: Tue, 24 Mar 2015 10:38:39 -0400 Message-ID: From: Kathleen Moriarty To: "saag@ietf.org" , wesley.george@twcable.com Content-Type: multipart/alternative; boundary=089e0160b9b011b5fa051209bd89 Archived-At: Cc: "MORTON, ALFRED C \(AL\)" Subject: Re: [saag] ubiquitous encryption draft feedback X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 14:39:33 -0000 --089e0160b9b011b5fa051209bd89 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Wes, Thanks again for your feedback, it's very helpful. Responses in line. On Wed, Mar 11, 2015 at 7:03 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Forwarding as requested. Wes has some good comments, Al or I will respon= d > soon. > > Thanks, > Kathleen > > Sent from my iPhone > > Begin forwarded message: > > *Resent-From:* > *From:* "George, Wes" > *Date:* March 11, 2015 at 4:39:58 PM EDT > *Resent-To:* > *To:* "draft-mm-wg-effect-encrypt@tools.ietf.org" < > draft-mm-wg-effect-encrypt@tools.ietf.org> > *Subject:* *ubiquitous encryption draft feedback* > > Hi - > > I think that the section discussing middle boxes decrypting (MiTM) > traffic to monitor it (4.2) needs a few bolsters- > I'm not sure whether IETF will find the support to actively condemn this > behavior (i.e. NOT RECOMMENDED), but a discussion of the considerations > around what happens if it's done (or more accurately, done carelessly) > would be appropriate for such a document. This is somewhat difficult > because it gets into areas that IETF has typically shied away from becaus= e > it has an intersection between policy, law, and use of technology. Howeve= r, > I still think it's appropriate since IMO first blood was already drawn by > wading into the pervasive monitoring debate, which has a similar overlap. > > We are making an effort to keep this document neutral to encourage participation and document what is happening, what is the objective, what data is used, and that it might break with encryption. Monitoring or whatever activity is happening may be possible in other ways or it may no longer be possible, which I think is clear int he draft. I think the existing text makes the same point, but keeps this draft away from a policy document and as more of a helpful document that could be used to figure out next steps as we better understand the effects of the changes underway. > Section 4 of the draft makes brief mention of the fact that this might > be done outside of the enterprise (e.g. In an SP network) but I would bre= ak > the link between DLP monitoring and SPs, and instead briefly discuss this > in the section on other reasons SPs monitor traffic (in section 2) such a= s > for performance/capacity > > I'm confused. Section 4 is about the effects of monitoring in the enterprise with increased use of encryption. Do you mean there is some types of monitoring missing in the sections on encryption and monitoring in the SP environment? We could remove the couple of sentences that say the enterprise might outsource this activity and leave that to the application content service provider section. I don't think we should be adding text in this section on the reasons SP monitor traffic. If we missed some reasons in section 2, text or pointers to documented information is appreciated. management or performance optimizations based on the underlying transport > media e.g. Improving performance on high-latency and capacity constrained > Satellite or mobile connections. The ETSI OWA has covered that set of > problems in reasonable detail both in their group and in httpbis when > advocating for some sort of provision for decrypting proxies. > > The recent revelations about Gogo inflight, Superfish/Komodia, Comodo > and others interfering with the underlying security and trust model of ro= ot > certificates makes this topical because it provides excellent > demonstrations of how this can be done wrong such that it fatally > compromises the security the user relies upon, and thus provides an > opportunity to highlight the issues one must consider when weighing this > option: > > - Liability =E2=80=93 I realize that IETF does not trade in legal advi= ce, so > this would have to be caveated pretty heavily, but I think it's a > worthwhile part of the discussion since it's a direct result of a spec= ific > set of technical actions and should be weighed when considering whethe= r the > ends justify the means. > > Hmm, we are trying hard to stay neutral and just document monitoring practices. This sounds like another document. It would be tough in the IETF as we stay to technical details as much as possible. The UTA WG published an RFC on all the attacks against TLS and DTLS as well as a BCP on configuring TLS and DTLS. > > - > - Duty to take action =E2=80=93 encrypted traffic (or unencrypted t= raffic > that is not subject to DPI) comes with a hidden benefit for the SPs= who > carry it- plausible deniability. If a service provider or enterpris= e is > decrypting traffic with intent to inspect it, whether with or witho= ut its > users' knowledge, it can be argued that it is responsible for the t= raffic's > content such that it is required to take action on content or activ= ities > that are banned by policy or law, including enforcing copyright, pr= eventing > exploitation of children, threats of violence, reporting potential > violations to the proper authorities, etc. An SP must be ready to t= ake > responsibility for traffic that flows across its network if it choo= ses to > inspect it. > > I think this is more appropriate for privacy statements, or the PM RFC, but not this one. > > - > - Duty to protect sensitive information =E2=80=93 decrypting middle= boxes > represent attractive targets since a compromise leads to the potent= ial to > access a lot of information that would otherwise be protected by > encryption. If a compromise occurs, and it exposes information prot= ected by > privacy laws (medical, financial, etc), the SP or enterprise active= ly > making efforts to disable (albeit temporarily) security measures ma= y be > held responsible for the damages caused by that information exposur= e. And > the risk isn't limited to traditional bad actors =E2=80=93 this mak= es a good target > for state agencies attempting to preserve their pervasive monitorin= g > abilities, thus defeating the purpose of opportunistic/increased en= cryption > in the first place. This problem gets worse if the data is stored > unencrypted for any length of time, as it is sensitive to secondary= system > compromises or government compulsion. There is also the concern abo= ut > downgrade attacks, where the intermediate device uses weaker cipher= s or key > lengths when it proxies the connection to the actual destination, t= hus > making the traffic more vulnerable. > - Transparency =E2=80=93 this interception and decryption MUST be done= with > the full knowledge of the users. > > We are not arguing for interception and decryption at all in this draft. Since we are just documenting monitoring practices, I think this belongs in other drafts as well or scope would be way to big (it's big enough already). > > - What this means in execution is something that has been an ongoing > debate (i.e. Will normal folks understand a click-through warning well > enough to do the "right" thing to protect their information by opting = out > for sensitive stuff (assuming they're allowed to opt out)? Is it ok to= tell > employees when they sign their contract but never warn them when you'r= e > doing it for sensitive info? etc) but it's definitely worth making tha= t > need for transparency crystal-clear, even if we don't necessarily defi= ne > what is an acceptable level of transparency. > > This is getting into company policy, which is outside the scope of the IETF work. > Feel free to forward this to whatever email list it may be discussed on. > It wasn't clear from the draft name where this was headed. > > Thanks for your review and detailed response. If you have monitoring areas we missed in the SP space, contributions are much appreciated. If you think the tone of the draft was not made clear enough, please let us know what text you think led to that problem and we'll fix it. Thanks, Kathleen > Thanks, > > > > Wes George > > > > Anything below this line has been added by my company=E2=80=99s mail serv= er, I > have no control over it. > > ----------- > > ------------------------------ > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified th= at > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy o= f > this E-mail and any printout. > > --=20 Best regards, Kathleen --089e0160b9b011b5fa051209bd89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Wes,

Thanks again for your feedback,= it's very helpful.=C2=A0 Responses in line.

On Wed, Mar 11, 2015 at 7:03 PM, Kathlee= n Moriarty <kathleen.moriarty.ietf@gmail.com>= wrote:
Forwarding= as requested.=C2=A0 Wes has some good comments, Al or I will respond soon.=

Thanks,
Kathleen

Sent from my iP= hone

Begin forwarded message:

Resent-From: <wesley.george@twcable.com>
From: "George, Wes" <wesley.george@twcable.com>
Date: March 1= 1, 2015 at 4:39:58 PM EDT
Resent-To: <draft-mm-wg-effect-encrypt= @ietf.org>
To: "draft-mm-wg-effect-encrypt@tools.= ietf.org" <draft-mm-wg-effect-encrypt@tools.ietf.org>= ;
Subject: ubiquitous encryption draft feedback

Hi -=C2=A0

I think that the section discussing middle boxes decrypting (MiTM) tra= ffic to monitor it (4.2) needs a few bolsters-=C2=A0
I'm not sure whether IETF will find the support to actively condem= n this behavior (i.e. NOT RECOMMENDED), but a discussion of the considerati= ons around what happens if it's done (or more accurately, done careless= ly) would be appropriate for such a document. This is somewhat difficult because it gets into areas that IETF has typica= lly shied away from because it has an intersection between policy, law, and= use of technology. However, I still think it's appropriate since IMO f= irst blood was already drawn by wading into the pervasive monitoring debate, which has a similar overlap.=C2=A0
We are making an effort to k= eep this document neutral to encourage participation and document what is h= appening, what is the objective, what data is used, and that it might break= with encryption.=C2=A0 Monitoring or whatever activity is happening may be= possible in other ways or it may no longer be possible, which I think is c= lear int he draft.=C2=A0 I think the existing text makes the same point, bu= t keeps this draft away from a policy document and as more of a helpful doc= ument that could be used to figure out next steps as we better understand t= he effects of the changes underway.


Section 4 of the draft makes brief mention of the fact that this might= be done outside of the enterprise (e.g. In an SP network) but I would brea= k the link between DLP monitoring and SPs, and instead briefly discuss this= in the section on other reasons SPs monitor traffic (in section 2) such as for performance/capacity
=
I'm confused.=C2=A0 Section = 4 is about the effects of monitoring in the enterprise with increased use o= f encryption. Do you mean there is some types of monitoring missing in the = sections on encryption and monitoring in the SP environment?=C2=A0 We could= remove the couple of sentences that say the enterprise might outsource thi= s activity and leave that to the application content service provider secti= on. I don't think we should be adding text in this section on the reaso= ns SP monitor traffic.=C2=A0 If we missed some reasons in section 2, text o= r pointers to documented information is appreciated.

management or performance optimizations based on the underlying tra= nsport media e.g. Improving performance on high-latency and capacity constr= ained Satellite or mobile connections. The ETSI OWA has covered that set of problems in reasonable detail both in their gr= oup and in httpbis when advocating for some sort of provision for decryptin= g proxies.

The recent revelations about Gogo inflight, Superfish/Komodia, Comodo = and others interfering with the underlying security and trust model of root= certificates makes this topical because it provides excellent demonstratio= ns of how this can be done wrong such that it fatally compromises the security the user relies upon, and th= us provides an opportunity to highlight the issues one must consider when w= eighing this option:
  • Liability =E2=80=93 I realize that IETF does not trade in legal advice,= so this would have to be caveated pretty heavily, but I think it's a w= orthwhile part of the discussion since it's a direct result of a specif= ic set of technical actions and should be weighed when considering whether the ends justify the means.
Hmm, we are trying hard to stay neutral and = just document monitoring practices.=C2=A0 This sounds like another document= .=C2=A0 It would be tough in the IETF as we stay to technical details as mu= ch as possible.=C2=A0 The UTA WG published an RFC on all the attacks agains= t TLS and DTLS as well as a BCP on configuring TLS and DTLS.=C2=A0
    • Duty to take action =E2=80=93 encrypted traffic (or unencrypted traffic= that is not subject to DPI) comes with a hidden benefit for the SPs who ca= rry it- plausible deniability. If a service provider or enterprise is decry= pting traffic with intent to inspect it, whether with or without its users' knowledge, it can be argued that it= is responsible for the traffic's content such that it is required to t= ake action on content or activities that are banned by policy or law, inclu= ding enforcing copyright, preventing exploitation of children, threats of violence, reporting potential violations to the pr= oper authorities, etc. An SP must be ready to take responsibility for traff= ic that flows across its network if it chooses to inspect it.
I think this is more appro= priate for privacy statements, or the PM RFC, but not this one.=C2=A0
=
=
    • Duty to protect sensitive information =E2=80=93 decryp= ting middle boxes represent attractive targets since a compromise leads to = the potential to access a lot of information that would otherwise be protec= ted by encryption. If a compromise occurs, and it exposes information protected by privacy laws (medical, financial, etc), the SP or= enterprise actively making efforts to disable (albeit temporarily) securit= y measures may be held responsible for the damages caused by that informati= on exposure. And the risk isn't limited to traditional bad actors =E2=80=93 this makes a good target for s= tate agencies attempting to preserve their pervasive monitoring abilities, = thus defeating the purpose of opportunistic/increased encryption in the fir= st place. This problem gets worse if the data is stored unencrypted for any length of time, as it is sensitive to s= econdary system compromises or government compulsion. There is also the con= cern about downgrade attacks, where the intermediate device uses weaker cip= hers or key lengths when it proxies the connection to the actual destination, thus making the traffic more vul= nerable.
  • Transparency =E2=80=93 this interception and decryption MUST be do= ne with the full knowledge of the users.
We are not arguing for interception and decryption at al= l in this draft.=C2=A0 Since we are just documenting monitoring practices, = I think this belongs in other drafts as well or scope would be way to big (= it's big enough already).=C2=A0
  • What this means in ex= ecution is something that has been an ongoing debate (i.e. Will normal folk= s understand a click-through warning well enough to do the "right" thing to protect their information by opting out for sen= sitive stuff (assuming they're allowed to opt out)? Is it ok to tell em= ployees when they sign their contract but never warn them when you're d= oing it for sensitive info? etc) but it's definitely worth making that need for transparency crystal-clear, even if we don'= t necessarily define what is an acceptable level of transparency.
=
This is getting into company pol= icy, which is outside the scope of the IETF work.=C2=A0
Feel free to forward this to whatever email list it may be discussed o= n. It wasn't clear from the draft name where this was headed.=C2=A0

Thanks for your= review and detailed response.=C2=A0 If you have monitoring areas we missed= in the SP space, contributions are much appreciated.=C2=A0 If you think th= e tone of the draft was not made clear enough, please let us know what text= you think led to that problem and we'll fix it.

Thanks,
Kathleen=C2=A0

Tha= nks,

= =C2=A0

Wes= George

= =C2=A0

Anything below this line has been added= by my company=E2=80=99s mail server, I have no control over it.<= /u>

-----------


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.



=
--

Best = regards,
Kathleen
--089e0160b9b011b5fa051209bd89-- From nobody Tue Mar 24 08:55:41 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C541A1B40; Mon, 23 Mar 2015 14:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mgt_c5zWIUA; Mon, 23 Mar 2015 14:24:45 -0700 (PDT) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE8D1A1AFF; Mon, 23 Mar 2015 14:24:45 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3l9pd767H9z5Mgfn; Mon, 23 Mar 2015 22:24:43 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3l9pd74jqrz5Mgff; Mon, 23 Mar 2015 22:24:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 3C36F12341C; Mon, 23 Mar 2015 22:24:43 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id De8V4fGQ8MFE; Mon, 23 Mar 2015 22:24:41 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 196601232B9; Mon, 23 Mar 2015 22:24:41 +0100 (CET) Message-ID: <55108498.1050006@sonnection.nl> Date: Mon, 23 Mar 2015 22:24:40 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dcrocker@bbiw.net, Apps Discuss , "saag@ietf.org" References: <55107EEB.8070300@dcrocker.net> In-Reply-To: <55107EEB.8070300@dcrocker.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1427145883; bh=vpDVEcZ0NG42Sh3YWHbFCCti756yCWu49cerNJdR5pA=; h=Message-ID:Date:From:To:Subject:From; b=L6CYTuihbi8OZoH0m/1Z3lLOFwQbSZGA4tmRBBD5yx2Ym+oWpshIwyVoS9hyAJPM5 qhrhbYQno4X9hLByQQS4RdSzwZO1K211PfsQs60rLxhgvISmCqoW4ORCvhTLLDtlOV Y13i6cZUwd/sa/Y/Zc4DGHF5BKaf9ETYDcMTMP/8= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3l9pd767H9z5Mgfn Archived-At: X-Mailman-Approved-At: Tue, 24 Mar 2015 08:55:40 -0700 Subject: Re: [saag] [apps-discuss] BarBOF for PRIME/DMAIL, after Apps and SAAG presentations X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:24:47 -0000 Hi, Dave, On 03/23/2015 10:00 PM, Dave Crocker wrote: > There was a presentation at this morning's Apps Area session on PRIME, > an privacy-intensive email architecture by Ladar Levison. > > http://darkmail.info/ > > The presentation covered basic architecture. > > At the Thursday afternoon SAAG session, Ladar will discuss more detailed > security considerations for the work. > > We've secured a room for follow-on Bar-BOF-y discussions after the SAAG > session: > > Thursday evening, 7:30pm > > Room: Royal thanks for the info. Does Ladar intend to submit DMAIL/DIME via the ISE or is there any chance a DIME WG will be chartered? /rolf P.S. Has anyone a link to the recording of this PRIME session, this morning? I tried to find it at http://ietf92.conf.meetecho.com/index.php/Recorded_Sessions but it is not (yet?) available. From nobody Tue Mar 24 10:15:18 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3F21A916B for ; Tue, 24 Mar 2015 10:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6hklNUmWZhU for ; Tue, 24 Mar 2015 10:15:15 -0700 (PDT) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) (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 EE61C1A9026 for ; Tue, 24 Mar 2015 10:15:14 -0700 (PDT) Received: by oiag65 with SMTP id g65so173560683oia.2 for ; Tue, 24 Mar 2015 10:15:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=C71dsi2gEyzEzF5Mbp2F80n0MIUnMQ8t/AYutPkYf4k=; b=l53gukkn1xqNjnA592csyzmE6zqO8Nc47/hftFN8a/2IQqg74f5T8HN6r1xbCxHMEc phUva5fzk2vcFa121FLHtEkWrCMm9XaLXVelmGErpJiN2PI7TGOlyeHmYNwTx5B/8EXr FKwXfZxYL5tSkb1sSxMmrFntxNibsZUEk4RVq0SPMa1FpaHXF9Qa2USWFGIfghc04v69 bsqXan8nYiBmGDSpHPP7wFxUyCK0EH5Q9oWgHy17IfynO56AgdhUpxznXgjCSay4oqrf zjDB2xSSf70EbjRQnBDMqgFkTzqLDMgPndzaucDxhCfQ5P/DJLooov15K8bj/R+G8T4c gzjw== X-Gm-Message-State: ALoCoQkzsCdpPq+nq1puG9J4CPxWCMDaqlqM8rhjQGX4+gAb76aT1K/4YB9GLQvBnpbqgq/FQ4Tf X-Received: by 10.60.98.207 with SMTP id ek15mr4127745oeb.34.1427217314479; Tue, 24 Mar 2015 10:15:14 -0700 (PDT) Received: from [172.16.86.24] ([199.227.110.154]) by mx.google.com with ESMTPSA id dy9sm2508462obb.6.2015.03.24.10.15.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2015 10:15:13 -0700 (PDT) Message-ID: <55119B9F.9080008@mnt.se> Date: Tue, 24 Mar 2015 18:15:11 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] tokbind report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 17:15:16 -0000 The token binding wg met for the first time today in Dallas. The wg is hoping to make very rapid progress and is aiming to be done by the end of the year. From nobody Tue Mar 24 11:49:45 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F621A8AA2 for ; Tue, 24 Mar 2015 11:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZRg6DkA-sYm for ; Tue, 24 Mar 2015 11:49:41 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3F61A8A9C for ; Tue, 24 Mar 2015 11:49:39 -0700 (PDT) Received: by wixw10 with SMTP id w10so6327536wix.0 for ; Tue, 24 Mar 2015 11:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IbjNB5DI1eSZoZIheDmcmYwYMpiqwhYCWCWVu/B6vTE=; b=h44ZUclY6W9vxUmpGivAth9MrAbeM/03ifXOT1zX/3144NmKKcWg/pULVgFGNT8AQ0 C6MW8ChOO4bCDOee0wh9rYhZj68mLWOBS0diyaIlAfIa/ZpZPI9z3Eb2knQa7CM/fVbQ ZSEabZGbZysrrjJhPnQq2hdzowSjQENA/D54/aT9zruc3m1vnaj+c3oLFUSutqXkDkBd NWvadOeEZHM/JMmciDVa0AflOPdEVFNYbnHoakSEgxAEy65+31hjlXsRYiIWZMDoJZqG M0jbwWIUhQFoMlIGjH0wlFhLjiwXv0ekshWo+kVI4KkyGpn6GF5YyM8VRcoIIygq9DlM mzww== MIME-Version: 1.0 X-Received: by 10.194.110.38 with SMTP id hx6mr10454823wjb.128.1427222978276; Tue, 24 Mar 2015 11:49:38 -0700 (PDT) Received: by 10.194.5.97 with HTTP; Tue, 24 Mar 2015 11:49:38 -0700 (PDT) Date: Tue, 24 Mar 2015 14:49:38 -0400 Message-ID: From: Daniel Migault To: saag@ietf.org Content-Type: multipart/alternative; boundary=089e010d89f2a2b9cc05120d3ee8 Archived-At: Subject: [saag] Dots BOF and using data models for threat X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 18:49:43 -0000 --089e010d89f2a2b9cc05120d3ee8 Content-Type: text/plain; charset=UTF-8 Hi, Looking at the coming BOF on DDoS, I would be interested to have opinions on whether using an information model to describe the threats would be useful to derive the appropriated events to track/measure. Appropriated alarms could be reported in order to take the appropriated mitigating actions. I believe questions could be: - 1) Your opinion on feasibility and level of complexity? - 2) Your opinion on advantages in term of management, deployment...? - 3) Your opinion on how it could ease addressing future threats? Feel free to make any additional comments! -- Daniel Migault Ericsson --089e010d89f2a2b9cc05120d3ee8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Looking at the coming BOF on DDoS, I woul= d be interested to have opinions on whether using an information model to d= escribe the threats would be useful to derive the appropriated events to tr= ack/measure. Appropriated alarms could be reported in order to take the app= ropriated mitigating actions.=C2=A0 =C2=A0

I believe question= s could be:
=C2=A0=C2=A0=C2=A0 - 1) Your opinion on feasibility and= level of complexity?
=C2=A0=C2=A0=C2=A0 - 2) Your opinion on= advantages in term of management, deployment...?=C2=A0 =C2=A0
=C2=A0=C2=A0=C2=A0 - 3) Your opinion on how it could = ease addressing future threats?

Feel free to make any add= itional comments!
=C2=A0
--
Daniel Migault
Ericsson
--089e010d89f2a2b9cc05120d3ee8-- From nobody Tue Mar 24 11:52:17 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65BF1A8A80 for ; Tue, 24 Mar 2015 11:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Gkjo9fpUQgR for ; Tue, 24 Mar 2015 11:52:12 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::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 72C171A8AA5 for ; Tue, 24 Mar 2015 11:51:52 -0700 (PDT) Received: by labto5 with SMTP id to5so1699701lab.0 for ; Tue, 24 Mar 2015 11:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tAMwtzi/2w/Zyhw/T3BnucBDaQPuHVT12n7mjOhKE70=; b=gtlBY63dPHnAyDtZ+E5GInmQSdEwfi2rMO3rsHcFX5lKJcQuI+SGymLWsxIkcqGtda Gc+svknqqLkHI8dzxLyM/BODvFCQwzhgUPhWboEZGBlmVDUgTQREhj1M30KETQJ6eV3R E1L33OrZu24lagAt8HJAn9WohNEEAJpR1NDtypLXQHnw69cWzA7kpPMepLU3irgtfmvo bquj95U6Wdvez8YNrPkEV6OXQBcz/ksGY0Wp0WktSZ0u2h+/hdEYt0yYQ8gLIZdP8OGq fOloRNYR8Qyoa07MLRGyJqavJ1uyMSudA9A0cnnWeH7TFb/4Fa5wk0AGwo+NVF/HMF0p aw5w== MIME-Version: 1.0 X-Received: by 10.152.25.132 with SMTP id c4mr5042138lag.4.1427223110864; Tue, 24 Mar 2015 11:51:50 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Tue, 24 Mar 2015 11:51:50 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 Mar 2015 14:51:50 -0400 Message-ID: From: Kathleen Moriarty To: Daniel Migault Content-Type: multipart/alternative; boundary=089e0160b9b089d4ea05120d462c Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Dots BOF and using data models for threat X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 18:52:14 -0000 --089e0160b9b089d4ea05120d462c Content-Type: text/plain; charset=UTF-8 Thanks for your comment. There is a list for DOTS, so let's continue the conversation on that list. If you are interested and have not joined the list, please do so. The BoF is in the next meeting slot. Could you resend your message to dots@ietf.org? Thanks! On Tue, Mar 24, 2015 at 2:49 PM, Daniel Migault wrote: > Hi, > > Looking at the coming BOF on DDoS, I would be interested to have opinions > on whether using an information model to describe the threats would be > useful to derive the appropriated events to track/measure. Appropriated > alarms could be reported in order to take the appropriated mitigating > actions. > > I believe questions could be: > - 1) Your opinion on feasibility and level of complexity? > - 2) Your opinion on advantages in term of management, deployment...? > > - 3) Your opinion on how it could ease addressing future threats? > > Feel free to make any additional comments! > > -- > Daniel Migault > Ericsson > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > -- Best regards, Kathleen --089e0160b9b089d4ea05120d462c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your comment.=C2=A0 There is a list for DOTS, s= o let's continue the conversation on that list. If you are interested a= nd have not joined the list, please do so.=C2=A0 The BoF is in the next mee= ting slot.

Could you resend your message to dots@ietf.org?

Thanks!

On Tue, = Mar 24, 2015 at 2:49 PM, Daniel Migault <mglt.ietf@gmail.com> wrote:
Hi,
=
Looking at the coming BOF on DDoS, I would be interested to have opinio= ns on whether using an information model to describe the threats would be u= seful to derive the appropriated events to track/measure. Appropriated alar= ms could be reported in order to take the appropriated mitigating actions.= =C2=A0 =C2=A0

I believe questions could be:
=C2=A0=C2= =A0=C2=A0 - 1) Your opinion on feasibility and level of complexity?
=C2=A0=C2=A0=C2=A0 - 2) Your opinion on advantages in term of manage= ment, deployment...?=C2=A0 =C2=A0
=C2=A0= =C2=A0=C2=A0 - 3) Your opinion on how it could ease addressing future threa= ts?

Feel free to make any additional comments!
=C2=A0
--
Daniel Migault
Ericsson

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




--

Best regards,
Ka= thleen
--089e0160b9b089d4ea05120d462c-- From nobody Tue Mar 24 12:00:38 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45151A8AA4 for ; Tue, 24 Mar 2015 12:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vacm0CjrVFmp for ; Tue, 24 Mar 2015 12:00:34 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428BD1A8A72 for ; Tue, 24 Mar 2015 12:00:33 -0700 (PDT) Received: by wibg7 with SMTP id g7so82937880wib.1 for ; Tue, 24 Mar 2015 12:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FA9/u43xOlT3JVYFpb36YUTanlHHqTnDpMLbIexLwK8=; b=Oa8TfCIDdTrSCJ6A9J95gMqo4uou2beEyi/kD258QuTrDUNmQDomAxx/nfIDUjwENW 6dWs+vv8vgvSd51MaVv8hEyQhm6VnSjzv6fT68i1hxR53YtWDAZEP4Hvk7MM0PwG30CX gYP4IHtz3zLHA/bFoEK7TjBtwenrl20dS1T9mDPHHBoTbuG68BVyPw8DocHZq3lQStOH G2MFDxH2CXxJC1jNaPqzIEjhcttX3QqGnK8zwbnNovQGrZCp5WsJH8469ggJai0D/jQ8 MJHrMlPPlAhT54XGeovv8mQL5gHnTF+iSEHiWhlpiBdk1aKy70atBWIe6K5PteWclK75 3fJQ== MIME-Version: 1.0 X-Received: by 10.194.110.38 with SMTP id hx6mr10532068wjb.128.1427223632073; Tue, 24 Mar 2015 12:00:32 -0700 (PDT) Received: by 10.194.5.97 with HTTP; Tue, 24 Mar 2015 12:00:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 Mar 2015 15:00:31 -0400 Message-ID: From: Daniel Migault To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=089e010d89f29add5a05120d651c Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Dots BOF and using data models for threat X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 19:00:36 -0000 --089e010d89f29add5a05120d651c Content-Type: text/plain; charset=UTF-8 For those interested here is the link to subscribe to the mailing list; https://www.ietf.org/mailman/listinfo/dots BR, Daniel On Tue, Mar 24, 2015 at 2:51 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Thanks for your comment. There is a list for DOTS, so let's continue the > conversation on that list. If you are interested and have not joined the > list, please do so. The BoF is in the next meeting slot. > > Could you resend your message to dots@ietf.org? > > Thanks! > > On Tue, Mar 24, 2015 at 2:49 PM, Daniel Migault > wrote: > >> Hi, >> >> Looking at the coming BOF on DDoS, I would be interested to have opinions >> on whether using an information model to describe the threats would be >> useful to derive the appropriated events to track/measure. Appropriated >> alarms could be reported in order to take the appropriated mitigating >> actions. >> >> I believe questions could be: >> - 1) Your opinion on feasibility and level of complexity? >> - 2) Your opinion on advantages in term of management, >> deployment...? >> - 3) Your opinion on how it could ease addressing future threats? >> >> Feel free to make any additional comments! >> >> -- >> Daniel Migault >> Ericsson >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> >> > > > -- > > Best regards, > Kathleen > -- Daniel Migault Ericsson --089e010d89f29add5a05120d651c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For those interested here is the link to subscri= be to the mailing list;

https://www.ietf.org/mailman/listinfo/dots=

BR,
Daniel

=
On Tue, Mar 24, 2015 at 2:51 PM, Kathleen Moriar= ty <kathleen.moriarty.ietf@gmail.com> wrote:<= br>
Thanks for your comment.= =C2=A0 There is a list for DOTS, so let's continue the conversation on = that list. If you are interested and have not joined the list, please do so= .=C2=A0 The BoF is in the next meeting slot.

Could you r= esend your message to do= ts@ietf.org?

Thanks!

On Tue, = Mar 24, 2015 at 2:49 PM, Daniel Migault <mglt.ietf@gmail.com> wrote:
Hi,

Looking at the coming BOF on DDoS, I= would be interested to have opinions on whether using an information model= to describe the threats would be useful to derive the appropriated events = to track/measure. Appropriated alarms could be reported in order to take th= e appropriated mitigating actions.=C2=A0 =C2=A0

I believe que= stions could be:
=C2=A0=C2=A0=C2=A0 - 1) Your opinion on feasibilit= y and level of complexity?
=C2=A0=C2=A0=C2=A0 - 2) Your opini= on on advantages in term of management, deployment...?=C2=A0 =C2=A0
=C2=A0=C2=A0=C2=A0 - 3) Your opinion on how it c= ould ease addressing future threats?

Feel free to make an= y additional comments!
=C2=A0
<= /span>
--
Daniel Migault
Ericsson

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


<= br clear=3D"all">

--

Best = regards,
Kathleen



--
Daniel Migault
Ericsson
--089e010d89f29add5a05120d651c-- From nobody Tue Mar 24 15:02:26 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A081A9007 for ; Tue, 24 Mar 2015 15:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtSYYfhSiDUo for ; Tue, 24 Mar 2015 15:02:19 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D22A1A8F3B for ; Tue, 24 Mar 2015 15:02:17 -0700 (PDT) Received: by wgbcc7 with SMTP id cc7so5920794wgb.0 for ; Tue, 24 Mar 2015 15:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=ChgkdXdCj0gY3MCWReAV79igELR03gjJXO2EBJAB5U0=; b=X6HQYH+n5jiH1ZGSihisUIxZ4sMk28gQBqp633YfZ0ZaQa4hj1+DmQunZBE3DqNBO9 h2XkaABYYrmCOAoqjqZlhm5EL7PSzYi4j2eeRI1wGZ+8T/Kk97DB/ksCc/rS4Wo9ZqE5 js6ni0Gr0t/nP01ZDbK8rOMAUSc76/yrgBB4z/4bkZvzQOVF0QMqJfW21dyg4L9ydW++ fp0z5GUXt8hX/JzMY5xLugDLVHwJOtQLjSSQxKAoRcyTtFEJp9Xlg7e1Kp99mxPD+JRn TxCUZtSYnVtgCOMK3H4j0sbDTbj5jOWBvXImMlYQuvBNOasPk/txXM+SODnw3+jK2gwT 27ig== X-Received: by 10.180.240.172 with SMTP id wb12mr9590863wic.55.1427234536332; Tue, 24 Mar 2015 15:02:16 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:b8e3:79c6:2d0b:cf61? ([2001:67c:370:136:b8e3:79c6:2d0b:cf61]) by mx.google.com with ESMTPSA id dm6sm1332513wib.22.2015.03.24.15.02.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Mar 2015 15:02:15 -0700 (PDT) From: "Adam W. Montville" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 24 Mar 2015 17:02:15 -0500 To: saag@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [saag] sacm report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 22:02:21 -0000 The sacm working group met yesterday, and will meet again on Friday. We = are working on furthering several drafts to WGLC, so that work can start = on prioritized data models, protocols and/or interfaces.= From nobody Tue Mar 24 15:50:54 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91E01A8F3B for ; Tue, 24 Mar 2015 15:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzO8ymDvm2hb for ; Tue, 24 Mar 2015 15:50:51 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55A621ACCDE for ; Tue, 24 Mar 2015 15:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1074; q=dns/txt; s=iport; t=1427237450; x=1428447050; h=from:to:subject:date:message-id:mime-version; bh=WZEzdD/lSTpk5iY0vOmrnJRL4Fpya2/aMo3GW+u+wEs=; b=UAWG9CDKOf8VdWZRjmPZ7xjQ87AOcbNVjkTh5X2CiApMDLYmdNbkaE+M 2UH4HnTEsnX+DljIGYEQixaBD5nZPECIPoNvpsCxZC3Bve4JkGB95mdWf cLXovbnHoAMW3TbI7kLNNrW6EnmEl6qpak4f8VGxMnGZJrNcTGsW7KaTD Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CxBwB/6RFV/4cNJK1cgkNDgTDEDol8TAEBAQEBAX2ECxCBCwELAQJyDxAIBIhCn0WpZQELAR+MRIgHBZBQiW+ULCKDboIzfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,460,1422921600"; d="scan'208,217";a="406380034" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP; 24 Mar 2015 22:50:49 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t2OMonf7027855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 24 Mar 2015 22:50:49 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.127]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Tue, 24 Mar 2015 17:50:49 -0500 From: "Nancy Cam-Winget (ncamwing)" To: "saag@ietf.org" Thread-Topic: anima report Thread-Index: AQHQZoT4SANXPXjXfkOKhK9vZm4b9A== Date: Tue, 24 Mar 2015 22:50:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.24.8.21] Content-Type: multipart/alternative; boundary="_000_D137385D11445Dncamwingciscocom_" MIME-Version: 1.0 Archived-At: Subject: [saag] anima report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 22:50:53 -0000 --_000_D137385D11445Dncamwingciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Anima Working Group met today and will meet again on Friday. The group= is working on several drafts to and reviewed two different bootstrapping p= roposals. --_000_D137385D11445Dncamwingciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <61F875405C53D14DB6DFE73A645DA8E2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
The Anima Working Group met today and will meet again on Friday.  = ;The group is working on several drafts to and reviewed two different boots= trapping proposals.


--_000_D137385D11445Dncamwingciscocom_-- From nobody Tue Mar 24 19:39:50 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870941A916C for ; Tue, 24 Mar 2015 19:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoJ94UMcay0y for ; Tue, 24 Mar 2015 19:39:45 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 538FD1A9142 for ; Tue, 24 Mar 2015 19:39:45 -0700 (PDT) Received: by qgfa8 with SMTP id a8so20933834qgf.0 for ; Tue, 24 Mar 2015 19:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=2PvZZ257Jh2rmLavSgthP0ZF9lnM2qpwEF4ZBHbrvcY=; b=j1nzZVJSUmrgLCsFxu3igXdiGztuuSdngnJ2kzqokIv4UtfflukkiN4Prlcn+Se2Gg BjXVRuQW4VThbk1HuSh+wwTnhCrMexwJ8Bbm9ZCGlbZJFavUzucvYY3NKqTYZhndpjro bXwHQdRfIeIHQMn0C/dDTX2Cj6ieDHVblG0vCuO0Jbi0VhmxTKxX5HNBv0BhRyCqm7CU D86c6u0IsoXST/3Ub+eEv5jaNszHZxKjDKin55dk6M4wirQeqNmSrCDtXJA/lqmSXqe+ jP51MwQz08cWqepAC09ADn48px+MYY9HrHb3uk3OpmTq7NI02vR/hTqonM5zMXJA65Ug pcOg== X-Received: by 10.140.238.139 with SMTP id j133mr10107772qhc.26.1427251184622; Tue, 24 Mar 2015 19:39:44 -0700 (PDT) Received: from Melindas-MacBook-Pro.local ([38.96.210.190]) by mx.google.com with ESMTPSA id k110sm788550qgf.27.2015.03.24.19.39.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2015 19:39:43 -0700 (PDT) Message-ID: <55121FEF.8060804@gmail.com> Date: Tue, 24 Mar 2015 21:39:43 -0500 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] trans report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 02:39:49 -0000 Trans met Monday afternoon. Our one deliverable, 6962-bis, is behind schedule but not terribly behind. It looks likely that we'll be adopting a threat analysis document as an additional deliverable. Work on gossip is proceeding but not yet fully baked. We're discussing the possibility of logging additional applications but, again, are waiting until the proposals are a bit more mature. Melinda From nobody Tue Mar 24 20:53:18 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF6D1AC449 for ; Tue, 24 Mar 2015 20:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrRhh-4sy3qm for ; Tue, 24 Mar 2015 20:53:15 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025EE1ACD7A for ; Tue, 24 Mar 2015 20:53:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 98BD6E2036 for ; Tue, 24 Mar 2015 23:53:13 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 27322-09 for ; Tue, 24 Mar 2015 23:53:11 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 47A74E2038; Tue, 24 Mar 2015 23:53:11 -0400 (EDT) Received: from 71.41.251.196 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Tue, 24 Mar 2015 23:53:11 -0400 Message-ID: Date: Tue, 24 Mar 2015 23:53:11 -0400 From: "Derek Atkins" To: saag@ietf.org User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: [saag] CFRG Presentation on Algebraic Eraser X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 03:53:16 -0000 Hi, On Wednesday in CFRG my colleague and I are presenting the Algebraic Eraser, a public key crypto system targeted at embedded, low-resource, IoT systems that performs 70-200x better than ECC in time and power consumption. If you're at all interested in seeing viable, performant public key crypto on extremely constrained devices I encourage you to attend CFRG at 1pm on Wednesday. The abstract of the talk: The Algebraic Eraser (AE), introduced by Anshel, Anshel, Goldfeld, and Lemieux in 2006, is a key agreement protocol for public-key cryptography which was designed to be suitable for implementation on low-cost platforms with constrained computational resources, such as RFID, NFC, and other platforms associated with the "Internet of Things." One novel feature of the protocol is that its complexityscales linearly with the desired security, unlike other asymmetric methods such as RSA and ECC. In this talk we give an overview of the protocol and present recent hardware timing data comparing the performance of AE with ECC. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Mar 24 21:31:56 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B631ACDA2 for ; Tue, 24 Mar 2015 21:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_1q2h83bC8c for ; Tue, 24 Mar 2015 21:31:54 -0700 (PDT) Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com [42.120.133.146]) by ietfa.amsl.com (Postfix) with ESMTP id E868A1ACD8A for ; Tue, 24 Mar 2015 21:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1427257908; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=E2uuJ2kDWHeQIdWHIPuIrtjq3cqFNnLgochAfJq86ho=; b=Cz0MQEeE0yCmXehnqOEB1vmH0BEUlgEWymaNPezWKvBoooh0BSYxLnafsY9DWSrnAxPA1DKuQQ47qAl6yOJ0Wk3XHWeJC2YDcIphN02uW765uOul27ExYHrOL8klPhTfAdYt15qUjuJFO8KEsLjW5YhIW4IOAR6CSJ8DJDy5LtE= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R961e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g08144; MF=kepeng.lkp@alibaba-inc.com; PH=DW; RN=1; RT=1; SR=0; Received: from WS-web (kepeng.lkp@alibaba-inc.com[38.96.210.190]) by r41g03024.xy2.aliyun.com at Wed, 25 Mar 2015 12:31:41 +0800 Date: Wed, 25 Mar 2015 12:31:41 +0800 From: "Kepeng Li" To: "saag" Message-ID: X-Mailer: Alimail-Mailagent revision 2687495 MIME-Version: 1.0 References: 7a940fc9-72a2-4503-a453-f8e2bae9cc51@alibaba-inc.com In-Reply-To: 7a940fc9-72a2-4503-a453-f8e2bae9cc51@alibaba-inc.com Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_4986_518ab940_55123a2d_800a" Archived-At: Subject: [saag] =?utf-8?q?ACE_Report?= X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Kepeng Li List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 04:31:55 -0000 ------=ALIBOUNDARY_4986_518ab940_55123a2d_800a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ACE WG Meeting=0AIETF 92 - Dallas=0ATuesday 24 March 2015, 13:00 - 15:00 CDT=0A= Chairs: Kepeng Li, Hannes Tschofenig=0A=0A* Use Cases (Sandeep S. Kumar)=0A - = No open issues. Next step is to initiate WGLC. Five people volunteered to revi= ew the draft.=0A=0A* Problem Description (Goeran Selander)- The term "Configur= ation Server" needs to be checked.=C2=A0=0A- There was consensus to use proble= m description and terminology as a starting point to work on.=0A=0A* Actors (C= arsten Bormann, 20 mins)=0A - There was preference to reuse OAuth terminologie= s (e.g. Resource Server, Authorization Server).- Action: Design team is reques= ted to merge Problem Description draft and Actors draft, and provide a combine= d draft.=0A=0A* Delegated CoAP Authentication and Authorization Framework (Car= sten Bormann)=0A - No time for the detailed discussion.=C2=A0It is recommended= to provide feedback in the mailing list.=0A=0A* Object Security (Goeran Selan= der)=0A - There was comment that part of the work should be done in CORE.- The= re was comment that it depends on COSE work.- No consensus to adopt it this ti= me. More time is needed.=0A* Use Oauth and UMA (Hannes Tschofenig)=0A - No tim= e for the detailed discussion. It is recommended to provide feedback in the ma= iling list.=0A=0A* Wrap-up- Chairs will request 2.5 hours for the next F2F mee= ting.=0AThanks,=0AKind RegardsKepeng ------=ALIBOUNDARY_4986_518ab940_55123a2d_800a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ACE WG Meeting
IETF 92 - Dallas
Tu= esday 24 March 2015, 13:00 - 15:00 CDT
Chairs: Kepeng Li, Hannes Tschofenig=

* Use Cases (Sandeep S. Kumar)
- No open issues. Next step is to i= nitiate WGLC. Five people volunteered to review the draft.

* Problem De= scription (Goeran Selander)
- The term "Configuration S= erver" needs to be checked. 
- There was consensus to use problem desc= ription and terminology as a starting point to work on.

* Actors (Carst= en Bormann, 20 mins)
- There was preference to reuse OAuth terminologies (= e.g. Resource Server, Authorization Server).
- Action: = Design team is requested to merge Problem Description draft and Actors draft, = and provide a combined draft.

* Delegated CoAP Authentication and Autho= rization Framework (Carsten Bormann)
- No time for the detailed discussion= . It is recommended to provide feedback in the mailing list.

* Obj= ect Security (Goeran Selander)
- There was comment that part of the work s= hould be done in CORE.
- There was comment that it depe= nds on COSE work.
- No consensus to adopt it this time.= More time is needed.

* Use Oauth and UMA (Hannes T= schofenig)
- No time for the detailed discussion. It is recommended to pro= vide feedback in the mailing list.

* Wrap-up
- Chairs will request 2.5 hours for the next F2F= meeting.

Thanks,
<= br>
Kind Regards
Kepeng
------=ALIBOUNDARY_4986_518ab940_55123a2d_800a-- From nobody Wed Mar 25 06:23:27 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A081ACED0 for ; Wed, 25 Mar 2015 06:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMzhp80KpiOv for ; Wed, 25 Mar 2015 06:23:25 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::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 1A2981ACEFA for ; Wed, 25 Mar 2015 06:22:35 -0700 (PDT) Received: by qgh3 with SMTP id 3so30055291qgh.2 for ; Wed, 25 Mar 2015 06:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GesnWbVVF7clLFk+VLRMxNLdarWK0OW9MebHSYyDSoA=; b=bmvqVh5gNAvhPcBaYJf6fdpGpdjVKfjc8yg0fsQa3J5SxC4fwIys0hbfZsy5ZKjqss rwzQmNXH2WQ50V7aTJTqp77h1LIKuXj9KOpXoxff31DLocn3enMEngVPTGMHq2Lkakbv lEZxVJBp8j8BuIOl/2QKL08EO6PAG5JzgOf4m7bpkryvc/gbQzoV8XyhZzfUI0vKHqmr ZHNRPGAj7iQKy06lqG9isI5VWLi27wycGx37kTwaNhmflO5osYRtHn3G4i35P6+t2Nrb 8PDp26bnc5ZG27jZuz3ojfnGc5VK3fIQdjBS8uKjXOT9kABP51TW7/ugGzhOfT/3J4ty iLHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GesnWbVVF7clLFk+VLRMxNLdarWK0OW9MebHSYyDSoA=; b=hsU7gkolp048csHuAn/9FD321bG0dJzZ2N6VP4kms0cG3154bdAcwGmeEemJAQEFTK 3hIRUWv1QLAYylulEsno9okwPM8CU8429Fam40pwJAz5c1OTWnQUFRDf082j8lrrc046 oEMrpYbkHPno4rgCgErFWw8RKiuHQHJ4aFTKMXTO2CDhMvo3gvuKVO19LSrCeJS/0yeb 3vafda47xEgfWyZ8vlxH2G1dqhpvMFDEsgA4tJ3LTuCaiWUkRRs5V6A7JhfgpTVv0GsA t8CICcjpKj4HkqEbuobgRJRov/RctIoZ1sp3pFJSZ/4JGzorT6PggzW4M83Pi9z56go5 K2UQ== X-Gm-Message-State: ALoCoQmLWCQgrrOWvYa8qRN0nyP/Q04jD1AYqm8pL3SS7fp2Cyx5BrecfDnEIPNTONZ7FlTBhQ90 MIME-Version: 1.0 X-Received: by 10.55.52.83 with SMTP id b80mr19368330qka.36.1427289753063; Wed, 25 Mar 2015 06:22:33 -0700 (PDT) Received: by 10.229.184.66 with HTTP; Wed, 25 Mar 2015 06:22:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Mar 2015 13:22:33 +0000 Message-ID: From: Ben Laurie To: Derek Atkins Content-Type: multipart/alternative; boundary=001a11490774b9320505121cca27 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] CFRG Presentation on Algebraic Eraser X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 13:23:26 -0000 --001a11490774b9320505121cca27 Content-Type: text/plain; charset=UTF-8 On 25 March 2015 at 03:53, Derek Atkins wrote: > Hi, > > On Wednesday in CFRG my colleague and I are presenting the Algebraic > Eraser, a public key crypto system targeted at embedded, low-resource, IoT > systems that performs 70-200x better than ECC in time and power > consumption. If you're at all interested in seeing viable, performant > public key crypto on extremely constrained devices I encourage you to > attend CFRG at 1pm on Wednesday. > > The abstract of the talk: > > The Algebraic Eraser (AE), introduced by Anshel, Anshel, Goldfeld, and > Lemieux in 2006, is a key agreement protocol for public-key cryptography > which was designed to be suitable for implementation on low-cost platforms > with constrained computational resources, such as RFID, NFC, and other > platforms associated with the "Internet of Things." One novel feature of > the protocol is that its complexityscales linearly with the desired > security, unlike other asymmetric methods such as RSA and ECC. In this > talk we give an overview of the protocol and present recent hardware > timing data comparing the performance of AE with ECC. > Has there been any analysis of AE? --001a11490774b9320505121cca27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 25 March 2015 at 03:53, Derek Atkins <derek@ihtfp.com> wrote:
Hi,

On Wednesday in CFRG my colleague and I are presenting the Algebraic
Eraser, a public key crypto system targeted at embedded, low-resource, IoT<= br> systems that performs 70-200x better than ECC in time and power
consumption.=C2=A0 If you're at all interested in seeing viable, perfor= mant
public key crypto on extremely constrained devices I encourage you to
attend CFRG at 1pm on Wednesday.

The abstract of the talk:

The Algebraic Eraser (AE), introduced by Anshel, Anshel, Goldfeld, and
Lemieux in 2006, is a key agreement protocol for public-key cryptography which was designed to be suitable for implementation on low-cost platforms<= br> with constrained computational resources, such as RFID, NFC, and other
platforms associated with the "Internet of Things."=C2=A0 One nov= el feature of
the protocol is that its complexityscales linearly with the desired
security, unlike other asymmetric methods such as RSA and ECC.=C2=A0 In thi= s
talk we give an overview of the protocol and present recent hardware
timing data comparing the performance of AE with ECC.
=
Has there been any analysis of AE?

--001a11490774b9320505121cca27-- From nobody Wed Mar 25 06:44:38 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6569B1A0158 for ; Wed, 25 Mar 2015 06:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fftcpAB6cKAM for ; Wed, 25 Mar 2015 06:44:35 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82431A0130 for ; Wed, 25 Mar 2015 06:44:33 -0700 (PDT) Received: by wibg7 with SMTP id g7so110334604wib.1 for ; Wed, 25 Mar 2015 06:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=L4d45wejB4gIbnjTmHR7d0t0PiImtZYNoUBp6oOarcg=; b=QxrgkJyyS+cFw70AhqOFem3VKxiWXj+b6FAgjurKZoFDBGvsm+RY9Ghh1zJ37FjPcX 3da4HkRiH/SL9i71mkQ4yqpUV098COsVl7OM/c34YU8NOOrJJQ52iUFntFNvLM0DsCOZ B84z/k4mtCERaJ0zgrNUTLqnpBEPxCL8/4X5+kJ15PiKFNleWt1bfbqVY5n72j2jygyh NC04YIV/FY//MQY2+96E8e/aJMLZnLRKlIZ6WNIM6rh1KzO9kke3GbJJm93SfdJLqSSk CvKi2AyAmu5UFZCWOFxOYfbub1ldDYDBAJEkOE5lL8XfHxTzsblZGHfXcdKzVA2BL4rX JVeg== X-Received: by 10.180.89.34 with SMTP id bl2mr38607104wib.23.1427291071847; Wed, 25 Mar 2015 06:44:31 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:65f0:c547:af67:e57b? ([2001:67c:370:176:65f0:c547:af67:e57b]) by mx.google.com with ESMTPSA id g2sm7454789wib.1.2015.03.25.06.44.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Mar 2015 06:44:30 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=utf-8 From: Yoav Nir X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 25 Mar 2015 08:44:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9A0E432F-0126-4200-A707-3B7B108B9751@gmail.com> References: To: Derek Atkins X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] CFRG Presentation on Algebraic Eraser X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 13:44:37 -0000 Hi, Derek If it indeed "performs 70-200x better than ECC in time and power = consumption=E2=80=9D, why is it appropriate only for IoT systems? Why = is it inappropriate for quad-core 3 GHz 16 GB desktop systems connecting = to 32-core 3GHz 128GB servers? Yoav > On Mar 24, 2015, at 10:53 PM, Derek Atkins wrote: >=20 > Hi, >=20 > On Wednesday in CFRG my colleague and I are presenting the Algebraic > Eraser, a public key crypto system targeted at embedded, low-resource, = IoT > systems that performs 70-200x better than ECC in time and power > consumption. If you're at all interested in seeing viable, performant > public key crypto on extremely constrained devices I encourage you to > attend CFRG at 1pm on Wednesday. >=20 > The abstract of the talk: >=20 > The Algebraic Eraser (AE), introduced by Anshel, Anshel, Goldfeld, and > Lemieux in 2006, is a key agreement protocol for public-key = cryptography > which was designed to be suitable for implementation on low-cost = platforms > with constrained computational resources, such as RFID, NFC, and other > platforms associated with the "Internet of Things." One novel feature = of > the protocol is that its complexityscales linearly with the desired > security, unlike other asymmetric methods such as RSA and ECC. In = this > talk we give an overview of the protocol and present recent hardware > timing data comparing the performance of AE with ECC. >=20 > -derek >=20 > --=20 > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Wed Mar 25 07:18:08 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60651A6EED for ; Wed, 25 Mar 2015 07:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rK39xKcD91b for ; Wed, 25 Mar 2015 07:18:06 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::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 D32EA1A6EF0 for ; Wed, 25 Mar 2015 07:17:49 -0700 (PDT) Received: by ykek76 with SMTP id k76so13235065yke.0 for ; Wed, 25 Mar 2015 07:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1+icgzzIKsregDI40/gqtnRW65addzh11OpNzIilzFQ=; b=TGftN/0vd8ZoPhHsiEu3DyDWkXn87YxOWmFKKBKvc9MYO9tOoSou+5Z+a0xO/jtzk2 r9UCPI21mUVFdePS3oA+XRHte++ztJfnXgu0wLDxa4fNqrqFnM7xK8ul6MsSLwq+hFqz 8vTut+qFY8bLN1KPLfVsw4AG5N0UqGGsj5ow81QWv8ZI4v7zWsG1kp+i/P8MQKVdlD+w ZzwJPH4sBDS1f7QRDKwGmt4eqpWH6pBgODbZFFJv5uaDhPS/UwwzCbpUXRxYX02wuECg SkKY2xrg2eU1nletzwcn4V2RCPA6bv4RaSfm0ZE81VQJydVyQS90P+uQAyoU245MitnG qMXQ== MIME-Version: 1.0 X-Received: by 10.236.17.163 with SMTP id j23mr10547260yhj.138.1427293069202; Wed, 25 Mar 2015 07:17:49 -0700 (PDT) Received: by 10.170.58.201 with HTTP; Wed, 25 Mar 2015 07:17:49 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Mar 2015 07:17:49 -0700 Message-ID: From: Watson Ladd To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] CFRG Presentation on Algebraic Eraser X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 14:18:07 -0000 On Tue, Mar 24, 2015 at 8:53 PM, Derek Atkins wrote: > Hi, > > On Wednesday in CFRG my colleague and I are presenting the Algebraic > Eraser, a public key crypto system targeted at embedded, low-resource, IoT > systems that performs 70-200x better than ECC in time and power > consumption. If you're at all interested in seeing viable, performant > public key crypto on extremely constrained devices I encourage you to > attend CFRG at 1pm on Wednesday. > > The abstract of the talk: > > The Algebraic Eraser (AE), introduced by Anshel, Anshel, Goldfeld, and > Lemieux in 2006, is a key agreement protocol for public-key cryptography > which was designed to be suitable for implementation on low-cost platforms > with constrained computational resources, such as RFID, NFC, and other > platforms associated with the "Internet of Things." One novel feature of > the protocol is that its complexityscales linearly with the desired > security, unlike other asymmetric methods such as RSA and ECC. In this > talk we give an overview of the protocol and present recent hardware > timing data comparing the performance of AE with ECC. This protocol appears to be based on conjugation in the braid group, with some variations. I've seen http://arxiv.org/pdf/0801.4786v1.pdf attacking this proposal. Are there other analyses we should be looking at? Sincerely, Watson Ladd > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Mar 25 07:37:31 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D9E1A1B6A for ; Wed, 25 Mar 2015 07:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2o1oMutetUV for ; Wed, 25 Mar 2015 07:37:27 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1F01A1BA3 for ; Wed, 25 Mar 2015 07:37:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 43156E2036; Wed, 25 Mar 2015 10:37:08 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 31385-07; Wed, 25 Mar 2015 10:37:06 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 4D398E2038; Wed, 25 Mar 2015 10:37:06 -0400 (EDT) Received: from 31.133.176.247 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 25 Mar 2015 10:37:06 -0400 Message-ID: <278d67722706f326a5676f18c862dcf8.squirrel@mail2.ihtfp.org> In-Reply-To: References: Date: Wed, 25 Mar 2015 10:37:06 -0400 From: "Derek Atkins" To: "Watson Ladd" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] CFRG Presentation on Algebraic Eraser X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 14:37:29 -0000 Hi, On Wed, March 25, 2015 10:17 am, Watson Ladd wrote: > On Tue, Mar 24, 2015 at 8:53 PM, Derek Atkins wrote: >> Hi, >> >> On Wednesday in CFRG my colleague and I are presenting the Algebraic >> Eraser, a public key crypto system targeted at embedded, low-resource, >> IoT >> systems that performs 70-200x better than ECC in time and power >> consumption. If you're at all interested in seeing viable, performant >> public key crypto on extremely constrained devices I encourage you to >> attend CFRG at 1pm on Wednesday. >> >> The abstract of the talk: >> >> The Algebraic Eraser (AE), introduced by Anshel, Anshel, Goldfeld, and >> Lemieux in 2006, is a key agreement protocol for public-key cryptography >> which was designed to be suitable for implementation on low-cost >> platforms >> with constrained computational resources, such as RFID, NFC, and other >> platforms associated with the "Internet of Things." One novel feature >> of >> the protocol is that its complexityscales linearly with the desired >> security, unlike other asymmetric methods such as RSA and ECC. In this >> talk we give an overview of the protocol and present recent hardware >> timing data comparing the performance of AE with ECC. > > This protocol appears to be based on conjugation in the braid group, > with some variations. I've seen http://arxiv.org/pdf/0801.4786v1.pdf > attacking this proposal. Are there other analyses we should be looking > at? Sure. You can look at http://arxiv.org/pdf/1202.0598v1.pdf and http://arxiv.org/pdf/1105.1141v1.pdf which talk to the two proposed attacks and show how they don't actually work. Thanks, > Sincerely, > Watson Ladd -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Mar 25 07:43:25 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486E51B29C3 for ; Wed, 25 Mar 2015 07:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR7d5h-UBkRD for ; Wed, 25 Mar 2015 07:43:23 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 460D41B29CC for ; Wed, 25 Mar 2015 07:42:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B0C2BE2036; Wed, 25 Mar 2015 10:42:02 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 31500-03; Wed, 25 Mar 2015 10:41:59 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id CE885E2038; Wed, 25 Mar 2015 10:41:59 -0400 (EDT) Received: from 31.133.176.247 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 25 Mar 2015 10:41:59 -0400 Message-ID: <568ac22332dc60e9a5597ed3f6564248.squirrel@mail2.ihtfp.org> In-Reply-To: References: Date: Wed, 25 Mar 2015 10:41:59 -0400 From: "Derek Atkins" To: "Ben Laurie" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] CFRG Presentation on Algebraic Eraser X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 14:43:24 -0000 Hi Ben, On Wed, March 25, 2015 9:22 am, Ben Laurie wrote: > On 25 March 2015 at 03:53, Derek Atkins wrote: > >> Hi, >> >> On Wednesday in CFRG my colleague and I are presenting the Algebraic >> Eraser, a public key crypto system targeted at embedded, low-resource, >> IoT >> systems that performs 70-200x better than ECC in time and power >> consumption. If you're at all interested in seeing viable, performant >> public key crypto on extremely constrained devices I encourage you to >> attend CFRG at 1pm on Wednesday. >> >> The abstract of the talk: >> >> The Algebraic Eraser (AE), introduced by Anshel, Anshel, Goldfeld, and >> Lemieux in 2006, is a key agreement protocol for public-key cryptography >> which was designed to be suitable for implementation on low-cost >> platforms >> with constrained computational resources, such as RFID, NFC, and other >> platforms associated with the "Internet of Things." One novel feature >> of >> the protocol is that its complexityscales linearly with the desired >> security, unlike other asymmetric methods such as RSA and ECC. In this >> talk we give an overview of the protocol and present recent hardware >> timing data comparing the performance of AE with ECC. >> > > Has there been any analysis of AE? Yes, there has. Over the last decade since AE was first proposed there have been only two classes of attacks ever found, both of which have been refuted (see my previous reply to Watson Ladd). In short, there was a class of weak keys if you randomly generate your private keys (but RSA has the same issue, you cannot chose a "random N", you need it to be the product of two large primes). The other attack basically boils down to having keys that are too short are easy to break. Details are in my other reply. Thanks for your interest, -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Mar 25 07:50:22 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC29B1A1AF0 for ; Wed, 25 Mar 2015 07:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9q5ryGPYWw7 for ; Wed, 25 Mar 2015 07:50:19 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6641A3B9F for ; Wed, 25 Mar 2015 07:50:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 6CE35E2036; Wed, 25 Mar 2015 10:50:16 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 31500-05; Wed, 25 Mar 2015 10:50:14 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 785DFE2038; Wed, 25 Mar 2015 10:50:14 -0400 (EDT) Received: from 31.133.176.247 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 25 Mar 2015 10:50:14 -0400 Message-ID: In-Reply-To: <9A0E432F-0126-4200-A707-3B7B108B9751@gmail.com> References: <9A0E432F-0126-4200-A707-3B7B108B9751@gmail.com> Date: Wed, 25 Mar 2015 10:50:14 -0400 From: "Derek Atkins" To: "Yoav Nir" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] CFRG Presentation on Algebraic Eraser X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 14:50:20 -0000 Hi Yoav, On Wed, March 25, 2015 9:44 am, Yoav Nir wrote: > Hi, Derek > > If it indeed "performs 70-200x better than ECC in time and power > consumption”, why is it appropriate only for IoT systems? Why is it > inappropriate for quad-core 3 GHz 16 GB desktop systems connecting to > 32-core 3GHz 128GB servers? Thank you for your interest. I'll point out that I never said it was "inappropriate for quad-core 3GHz 16 GB desktop systems connecting to 32-core 3GHz 128GB servers". Indeed, I never said anything about the appropriateness or inappropriateness of AE for a particular use case. I just said that we're focused on IoT because that's a place that is currently not being served by existing Public Key Cryptography methods due to the extremely constrained environments and computational complexity of existing PK methods. Thanks, > Yoav -derek >> On Mar 24, 2015, at 10:53 PM, Derek Atkins wrote: >> >> Hi, >> >> On Wednesday in CFRG my colleague and I are presenting the Algebraic >> Eraser, a public key crypto system targeted at embedded, low-resource, >> IoT >> systems that performs 70-200x better than ECC in time and power >> consumption. If you're at all interested in seeing viable, performant >> public key crypto on extremely constrained devices I encourage you to >> attend CFRG at 1pm on Wednesday. >> >> The abstract of the talk: >> >> The Algebraic Eraser (AE), introduced by Anshel, Anshel, Goldfeld, and >> Lemieux in 2006, is a key agreement protocol for public-key cryptography >> which was designed to be suitable for implementation on low-cost >> platforms >> with constrained computational resources, such as RFID, NFC, and other >> platforms associated with the "Internet of Things." One novel feature >> of >> the protocol is that its complexityscales linearly with the desired >> security, unlike other asymmetric methods such as RSA and ECC. In this >> talk we give an overview of the protocol and present recent hardware >> timing data comparing the performance of AE with ECC. >> >> -derek >> >> -- >> Derek Atkins 617-623-3745 >> derek@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Mar 25 07:51:05 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF601A870A for ; Wed, 25 Mar 2015 07:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPgLWufPVrZw for ; Wed, 25 Mar 2015 07:51:02 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::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 E58D51A86FA for ; Wed, 25 Mar 2015 07:51:01 -0700 (PDT) Received: by wgs2 with SMTP id 2so30596557wgs.1 for ; Wed, 25 Mar 2015 07:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=QzYBBCB0lX7j2FTlzXsvcaa39XdSSPNXzFlSjoGAqLo=; b=LwizThTgwj3617GLCiQYwc10rjDiXGbMANS9YhI5krtyAy9h8jsQClApb1mIFvBPnO gbJd+68rBQ2ntLeiNPM/NTpMv69jm9dbLWXpnfcTzJYLDeXJP8jrZy1uWht9o7QyK5Xi 2KP27coXnXOCV7/o0cwMBOzwOU31ImMlR7Z9lDe7n2bSK84E9T4zd4MT4leWToWCvRTD YO+k8LYEze2EFO3Hwe/Mfevwr2OtjtgROFhAeemr5gRelfgapcTqlco0slXw2z0ee+f2 s1SFA9oSqkkF0dFR/zpNAfBakYE0v6O9xrXq7SDK04CUD9WpEbriLsath+ekrPspMp69 nlFw== X-Received: by 10.194.185.9 with SMTP id ey9mr18828337wjc.135.1427295060694; Wed, 25 Mar 2015 07:51:00 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:a156:5753:476f:6dc5? ([2001:67c:370:160:a156:5753:476f:6dc5]) by mx.google.com with ESMTPSA id eo1sm4629626wib.16.2015.03.25.07.50.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 07:51:00 -0700 (PDT) Message-ID: <5512CB52.3030809@gmail.com> Date: Wed, 25 Mar 2015 09:50:58 -0500 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "saag@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] IPsecME report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 14:51:03 -0000 The WG has not met yet, in fact we have that most attractive last session on Friday. We recently sent "Null authentication" (useful for opportunistic IPsec) to Kathleen. The focus of the meeting will be on our single WG document, DDoS protection. We will also discuss crypto algorithms, to diversify the choice of algorithms and to better support constrained environments. Thanks, Paul and Yaron From nobody Wed Mar 25 08:12:46 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BED1AD359 for ; Wed, 25 Mar 2015 08:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMa4UoIzvaKg for ; Wed, 25 Mar 2015 08:12:44 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23CA41A876A for ; Wed, 25 Mar 2015 08:12:44 -0700 (PDT) Received: by lbbsy1 with SMTP id sy1so19921109lbb.1 for ; Wed, 25 Mar 2015 08:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=tlmiVF/Q/swa6mMwa7nWJV9eFxM9HM0D6CIbptZq67k=; b=XcrH/x7/izFruFhAg0JjZoCqq7kojd5LQ1wdbRGSX4k5GF9gLimruZfey1JyJCY/Ov lazob2YA4wDLSCg6tZ9jWbzfVNUp+v0zA7QvRHjaXbHwoR67e5Acc+U+vXyGOpHTInQz wGPh5iZZolbgTX1uMfmQT5NsU2Vydrhff8UhARGBUoPxz7VQZIGT8sMWv7A5D3IIiGU6 Y1tvcRfkoQPrB/m16AuCtZYZUD05uM68mCX3d9R9yIId7I2qTrM56gteyy4QeBHYlJj1 qdSsUq0/wUTeuoVDR4P1r/baIyXNZPYaoW1EAvsV9qAAfjIOS4b3Sob89UuI7g8I0IOT WBpQ== MIME-Version: 1.0 X-Received: by 10.112.25.38 with SMTP id z6mr9014589lbf.106.1427296362687; Wed, 25 Mar 2015 08:12:42 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.112.140.104 with HTTP; Wed, 25 Mar 2015 08:12:42 -0700 (PDT) Date: Wed, 25 Mar 2015 16:12:42 +0100 X-Google-Sender-Auth: W3CWH93zinT0F1BZnHXLutvKrO4 Message-ID: From: Nikos Mavrogiannopoulos To: IETF SAAG Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Subject: [saag] RFC5280 + DNS name constraints X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:12:45 -0000 Hello, The text for DNS name constraints in RFC5280 [0] is the following: "DNS name restrictions are expressed as host.example.com. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name satisfies the name constraint. For example, www.host.example.com would satisfy the constraint but host1.example.com would not." My interpretation of it is that name constraints are domain names of the form of "name.example.com", "example.com", "com", etc. However, I got a report that are several certificates with constraints expressed in the following format ".example.com", ".com", and that gnutls is the only implementation which doesn't honor these constraints. Allegedly openssl and NSS are two implementations which accept this type of constraints. Reading the text above, it is not apparent to me why ".example.com" would be acceptable at all as a DNS name constraint. Is my interpretation of the text above correct? Do you know if that definition of name constraints has been superseded by another document which includes the '.'? regards, Nikos [0]. http://tools.ietf.org/html/rfc5280#section-4.2.1.10 From nobody Wed Mar 25 08:15:25 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0501B2A15 for ; Wed, 25 Mar 2015 08:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6V_9xrH1Jiq8 for ; Wed, 25 Mar 2015 08:15:14 -0700 (PDT) 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 D9C981B2A14 for ; Wed, 25 Mar 2015 08:15:11 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DAD9E282FC0; Wed, 25 Mar 2015 15:15:10 +0000 (UTC) Date: Wed, 25 Mar 2015 15:15:10 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150325151510.GG21586@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] CFRG Presentation on Algebraic Eraser X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:15:19 -0000 On Tue, Mar 24, 2015 at 11:53:11PM -0400, Derek Atkins wrote: > The abstract of the talk: > > The Algebraic Eraser (AE), introduced by Anshel, Anshel, Goldfeld, and > Lemieux in 2006, is a key agreement protocol for public-key cryptography > which was designed to be suitable for implementation on low-cost platforms > with constrained computational resources, such as RFID, NFC, and other > platforms associated with the "Internet of Things." One novel feature of > the protocol is that its complexityscales linearly with the desired > security, unlike other asymmetric methods such as RSA and ECC. In this > talk we give an overview of the protocol and present recent hardware > timing data comparing the performance of AE with ECC. The description of CBKAP on page 11 in the paper: http://www.securerf.com/wp-content/uploads/2014/03/SecureRF-Technical-White-Paper-06-with-Appendix-A-B.pdf appears to rely on a TTP (think KDC?) that creates the commuting generator sets, and is able to impersonate all the users of the protocol (with the chosen parameters). Is this why the system is for IoT, rather than broad use on the public Internet. -- Viktor. From nobody Wed Mar 25 08:26:15 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CD21A8761 for ; Wed, 25 Mar 2015 08:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYeXdCmhmOFX for ; Wed, 25 Mar 2015 08:26:12 -0700 (PDT) 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 8336D1A87C9 for ; Wed, 25 Mar 2015 08:26:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3535A282FC0; Wed, 25 Mar 2015 15:26:11 +0000 (UTC) Date: Wed, 25 Mar 2015 15:26:11 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150325152610.GH21586@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] RFC5280 + DNS name constraints X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:26:14 -0000 On Wed, Mar 25, 2015 at 04:12:42PM +0100, Nikos Mavrogiannopoulos wrote: > However, I got a report that are several certificates with constraints > expressed in the following format ".example.com", ".com", and that > gnutls is the only implementation which doesn't honor these > constraints. Allegedly openssl and NSS are two implementations which > accept this type of constraints. Reading the text above, it is not > apparent to me why ".example.com" would be acceptable at all as a DNS > name constraint. IIRC the "." form is an interoperability concession for some CAs that have issued certicates with name constraints of that form. IIRC the "." prefix is by analogy with name constraints for URIs, but is not defined for DNS names in any standard. This was added to OpenSSL somewhat recently. http://rt.openssl.org/Ticket/Display.html?id=3562 -- Viktor. From nobody Wed Mar 25 08:52:37 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0691A8896 for ; Wed, 25 Mar 2015 08:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpDrBKHN74YP for ; Wed, 25 Mar 2015 08:52:28 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::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 A379B1A8830 for ; Wed, 25 Mar 2015 08:52:27 -0700 (PDT) Received: by wgra20 with SMTP id a20so32480881wgr.3 for ; Wed, 25 Mar 2015 08:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=4zHLu0h+3pcVxxh52VdbDdoMK983vSJ1twJPTFRI4CE=; b=urgdUO3Mfpwk8obY2NmH9Z/m4mh/IYUrm89kWI/7rTtxr1y8KK5qZBXmEptSjtDq79 bqOTCijq44nrB4q/JvH/RPlStIpLD8nrcvKHaqZgs1yeSbN7Xao5+G/GnPgics3rEn8X k8REhNx7VYY6mVqXAVX0uN6WmTPauHXsYOkkc1g4KzGen2yLKeibSPtRsCSbfraXJZWD 5ehrdAKAVDY3cSfmGh0BDbpgf/QBcr8dDmUJI99y5icA7mMBZ1hnoXPIQvOBT4VUoyBK Kt2bsExCYxenu+8CfmnPtDntZKnZsKBYzl5veo7d5RSrp0pej6QB+t6pBZFe9foK7BEW hNww== X-Received: by 10.194.60.104 with SMTP id g8mr19042361wjr.96.1427298746372; Wed, 25 Mar 2015 08:52:26 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:c01a:caa3:86b7:6e37? ([2001:67c:370:160:c01a:caa3:86b7:6e37]) by mx.google.com with ESMTPSA id cj9sm4261076wjc.42.2015.03.25.08.52.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 08:52:25 -0700 (PDT) Message-ID: <5512D9B3.5030405@gmail.com> Date: Wed, 25 Mar 2015 11:52:19 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Derek Atkins , Yoav Nir References: <9A0E432F-0126-4200-A707-3B7B108B9751@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000905030204080408040206" Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] CFRG Presentation on Algebraic Eraser X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:52:36 -0000 This is a multi-part message in MIME format. --------------000905030204080408040206 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Derek: The email below contains some pointers to public-key crypto in standards and products, including those in the IoT space (whatever that term in its currently diluted form means). So, there is some evidence that widely accepted public key crypto fits in at least part of that application domain. Are there any "Algebraic Eraser challenges", with price money $10k or up, similar to the Certicom ECC challenges around 2000? That might help in enticing research interest. I am looking forward to your presentation. Best regards, Rene == [excerpt of your email of Wed March 25, 2015, 10.50am EDT] "I just said that we're focused on IoT because that's a place that is currently not being served by existing Public Key Cryptography methods due to the extremely constrained environments and computational complexity of existing PK methods." -------- Forwarded Message -------- Subject: some pointers to public-key crypto in standards and products Date: Wed, 11 Mar 2015 09:45:29 -0400 From: Rene Struik To: 6tisch@ietf.org <6tisch@ietf.org>, tisch-security <6tisch-security@ietf.org> Dear Pascal: As requested, please find below some pointers to cryptographic support for public key operations in industry specifications and products. Some standards and specifications that include public key support: ZigBee IP, ISA SP100, ICAO ePassport, EMVCo chipcards, Connected vehicles (IEEE 1609.2, etc.), IEEE 802.11/Wifi Alliance, PIV access control card (FIPS 201, etc.), CoRE/Coap Some chipsets: http://www.atmel.com/Images/Atmel-8923S-CryptoAuth-ATECC508A-Datasheet-Summary.pdf http://www.ti.com/lit/ds/symlink/cc2538.pdf Reference to any external standard or any external product does not indicate endorsement hereof or vouching for security claims. There are thousands of academic papers on implementation of symmetric and public key crypto on small devices, including hundreds on more exotic - to mainstream audience - techniques on squeezing crypto on smaller and smaller devices (so-called light-weight cryptography). For those interested in a US DARPA initiative to create a complete anti-cloning solution (including crypto, antenna, packaging) for a penny, see http://www.darpa.mil/NewsEvents/Releases/2014/02/24.aspx. Some of these aspects were discussed on the 6TiSCH security calls, most recently on the Feb 24, 2015 call: http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00489.html I hope this helps. It should at least provide some evidence that cryptographic components are fast reaching commodity status. Final note: of course, there is still plenty of room to use crypto unwisely/imprudently. That is why people like me do not have to be idle. Best regards, Rene -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 On 3/25/2015 10:50 AM, Derek Atkins wrote: > Hi Yoav, > > On Wed, March 25, 2015 9:44 am, Yoav Nir wrote: >> Hi, Derek >> >> If it indeed "performs 70-200x better than ECC in time and power >> consumption”, why is it appropriate only for IoT systems? Why is it >> inappropriate for quad-core 3 GHz 16 GB desktop systems connecting to >> 32-core 3GHz 128GB servers? > Thank you for your interest. I'll point out that I never said it was > "inappropriate for quad-core 3GHz 16 GB desktop systems connecting to > 32-core 3GHz 128GB servers". Indeed, I never said anything about the > appropriateness or inappropriateness of AE for a particular use case. I > just said that we're focused on IoT because that's a place that is > currently not being served by existing Public Key Cryptography methods due > to the extremely constrained environments and computational complexity of > existing PK methods. > > Thanks, > >> Yoav > -derek > >>> On Mar 24, 2015, at 10:53 PM, Derek Atkins wrote: >>> >>> Hi, >>> >>> On Wednesday in CFRG my colleague and I are presenting the Algebraic >>> Eraser, a public key crypto system targeted at embedded, low-resource, >>> IoT >>> systems that performs 70-200x better than ECC in time and power >>> consumption. If you're at all interested in seeing viable, performant >>> public key crypto on extremely constrained devices I encourage you to >>> attend CFRG at 1pm on Wednesday. >>> >>> The abstract of the talk: >>> >>> The Algebraic Eraser (AE), introduced by Anshel, Anshel, Goldfeld, and >>> Lemieux in 2006, is a key agreement protocol for public-key cryptography >>> which was designed to be suitable for implementation on low-cost >>> platforms >>> with constrained computational resources, such as RFID, NFC, and other >>> platforms associated with the "Internet of Things." One novel feature >>> of >>> the protocol is that its complexityscales linearly with the desired >>> security, unlike other asymmetric methods such as RSA and ECC. In this >>> talk we give an overview of the protocol and present recent hardware >>> timing data comparing the performance of AE with ECC. >>> >>> -derek >>> >>> -- >>> Derek Atkins 617-623-3745 >>> derek@ihtfp.com www.ihtfp.com >>> Computer and Internet Security Consultant >>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >> > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------000905030204080408040206 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 
Dear Derek:

The email below contains some pointers to public-key crypto in standards and products, including those in the IoT space (whatever that term in its currently diluted form means). So, there is some evidence that widely accepted public key crypto fits in at least part of that application domain.

Are there any "Algebraic Eraser challenges", with price money $10k or up, similar to the Certicom ECC challenges around 2000? That might help in enticing research interest.

I am looking forward to your presentation.

Best regards, Rene

==
[excerpt of your email of Wed March 25, 2015, 10.50am EDT]
"I just said that we're focused on IoT because that's a place that is currently not being served by existing Public Key Cryptography methods due
to the extremely constrained environments and computational complexity of existing PK methods."


-------- Forwarded Message --------
Subject: some pointers to public-key crypto in standards and products
Date: Wed, 11 Mar 2015 09:45:29 -0400
From: Rene Struik <rstruik.ext@gmail.com>
To: 6tisch@ietf.org <6tisch@ietf.org>, tisch-security <6tisch-security@ietf.org> 


Dear Pascal:

As requested, please find below some pointers to cryptographic support 
for public key operations in industry specifications and products.

Some standards and specifications that include public key support:
ZigBee IP, ISA SP100, ICAO ePassport, EMVCo chipcards, Connected 
vehicles (IEEE 1609.2, etc.), IEEE 802.11/Wifi Alliance, PIV access 
control card (FIPS 201, etc.), CoRE/Coap

Some chipsets:
http://www.atmel.com/Images/Atmel-8923S-CryptoAuth-ATECC508A-Datasheet-Summary.pdf
http://www.ti.com/lit/ds/symlink/cc2538.pdf

Reference to any external standard or any external product does not 
indicate endorsement hereof or vouching for security claims.

There are thousands of academic papers on implementation of symmetric 
and public key crypto on small devices, including hundreds on more 
exotic - to mainstream audience - techniques on squeezing crypto on 
smaller and smaller devices (so-called light-weight cryptography). For 
those interested in a US DARPA initiative to create a complete 
anti-cloning solution (including crypto, antenna, packaging) for a 
penny, see http://www.darpa.mil/NewsEvents/Releases/2014/02/24.aspx.

Some of these aspects were discussed on the 6TiSCH security calls, most 
recently on the Feb 24, 2015 call:
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00489.html

I hope this helps. It should at least provide some evidence that 
cryptographic components are fast reaching commodity status.

Final note: of course, there is still plenty of room to use crypto 
unwisely/imprudently. That is why people like me do not have to be idle.

Best regards, Rene

-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
On 3/25/2015 10:50 AM, Derek Atkins wrote:
Hi Yoav,

On Wed, March 25, 2015 9:44 am, Yoav Nir wrote:

Hi, Derek

If it indeed "performs 70-200x better than ECC in time and power
consumption”, why is it appropriate only for IoT systems?  Why is it
inappropriate for quad-core 3 GHz 16 GB desktop systems connecting to
32-core 3GHz 128GB servers?

Thank you for your interest.  I'll point out that I never said it was
"inappropriate for quad-core 3GHz 16 GB desktop systems connecting to
32-core 3GHz 128GB servers".  Indeed, I never said anything about the
appropriateness or inappropriateness of AE for a particular use case.  I
just said that we're focused on IoT because that's a place that is
currently not being served by existing Public Key Cryptography methods due
to the extremely constrained environments and computational complexity of
existing PK methods.

Thanks,


Yoav

-derek


On Mar 24, 2015, at 10:53 PM, Derek Atkins <derek@ihtfp.com> wrote:

Hi,

On Wednesday in CFRG my colleague and I are presenting the Algebraic
Eraser, a public key crypto system targeted at embedded, low-resource,
IoT
systems that performs 70-200x better than ECC in time and power
consumption.  If you're at all interested in seeing viable, performant
public key crypto on extremely constrained devices I encourage you to
attend CFRG at 1pm on Wednesday.

The abstract of the talk:

The Algebraic Eraser (AE), introduced by Anshel, Anshel, Goldfeld, and
Lemieux in 2006, is a key agreement protocol for public-key cryptography
which was designed to be suitable for implementation on low-cost
platforms
with constrained computational resources, such as RFID, NFC, and other
platforms associated with the "Internet of Things."  One novel feature
of
the protocol is that its complexityscales linearly with the desired
security, unlike other asymmetric methods such as RSA and ECC.  In this
talk we give an overview of the protocol and present recent hardware
timing data comparing the performance of AE with ECC.

-derek

--
      Derek Atkins                 617-623-3745
      derek@ihtfp.com             www.ihtfp.com
      Computer and Internet Security Consultant

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







-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------000905030204080408040206-- From nobody Wed Mar 25 12:45:08 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F263E1B2B33 for ; Wed, 25 Mar 2015 12:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufU9SwNI-qkU for ; Wed, 25 Mar 2015 12:45:06 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4950A1B2B18 for ; Wed, 25 Mar 2015 12:45:06 -0700 (PDT) Received: by wibg7 with SMTP id g7so122535897wib.1 for ; Wed, 25 Mar 2015 12:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=ZjP1sBb6Dc0vQOeNffA9nfMqDUStO+a6IKgmDLqOTYM=; b=wtK8GXjcdPb/uQzPQ4eopEFaqJ5WwQDPQk+uh+q5mcj58rWjFJCp2/dQhU0fCr9S34 YJwF3ae4S8x58QcZFbI7gkFrCMWO3IRTA5IUnq92bhB1m4v35KDCUDElIUFjJ0tEtWPJ 4gLZfgXDcE4ksL10TzajvGROs7sGJMI2zQmd19r9H7cPl/YaHbap27lbOh4svkZp0bal Ia6jSN+ocMbO2R+8EsLPtsCWPeOqq3DBRwTFjGiySEO9mnvQKApbblS3QZgCCnO09aOy PfZAjJNew5DSyCTbTAXt++YtZuWRlkmiFb1PFIYeVHbRUzTZ6M7NYNYlUkqnqUs0/neX JiLA== X-Received: by 10.180.240.172 with SMTP id wb12mr18615932wic.55.1427312705089; Wed, 25 Mar 2015 12:45:05 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:f82b:cbab:60dc:467b? ([2001:67c:370:176:f82b:cbab:60dc:467b]) by mx.google.com with ESMTPSA id r14sm5688151wiv.13.2015.03.25.12.45.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Mar 2015 12:45:04 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_1502FE8D-7709-4468-A44A-57F74AB3798D" Message-Id: <12D88F27-1AE8-47EB-A386-11AA1E02955D@gmail.com> Date: Wed, 25 Mar 2015 14:45:02 -0500 To: Security Area Advisory Group Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [saag] HTTP-Auth Summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 19:45:08 -0000 --Apple-Mail=_1502FE8D-7709-4468-A44A-57F74AB3798D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 HTTP-Auth (with or without a hyphen) will meet on Thursday after the = SAAG meeting. Since the last IETF, three of our documents have moved on: HOBA has been published as RFC 7486 Basic is in the RFC Editor=E2=80=99s queue Digest is in IETF LC The meeting this week will focus on the three documents that make up the = MutualAuth authentication method. Matt & Yoav --Apple-Mail=_1502FE8D-7709-4468-A44A-57F74AB3798D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 HTTP-Auth (with or without a hyphen) will meet on Thursday = after the SAAG meeting.

Since the last IETF, three of our documents have moved = on:
  • HOBA = has been published as RFC 7486
  • Basic is in the RFC = Editor=E2=80=99s queue
  • Digest is in IETF = LC

The= meeting this week will focus on the three documents that make up the = MutualAuth authentication method.

Matt & Yoav

= --Apple-Mail=_1502FE8D-7709-4468-A44A-57F74AB3798D-- From nobody Wed Mar 25 13:51:49 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818401A8ABE for ; Wed, 25 Mar 2015 13:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaFI_aasWO2w for ; Wed, 25 Mar 2015 13:51:46 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 D68CC1A905D for ; Wed, 25 Mar 2015 13:51:39 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t2PKpYsU006896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 25 Mar 2015 22:51:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2PKpYxn027666; Wed, 25 Mar 2015 22:51:34 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21779.8150.157717.160955@fireball.kivinen.iki.fi> Date: Wed, 25 Mar 2015 22:51:34 +0200 From: Tero Kivinen To: Security Area Advisory Group X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 22 min Archived-At: Subject: [saag] Tcpinc summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 20:51:48 -0000 Tcpinc WG is transport area working group, but there is lots of security people interested in the group. We will meet right after the saag (Thursday 15:20-17:20 in Parisian) and our main goal for this meeting is to try to select which draft to adopt as basis for the protocol specification. The candidate drafts are: https://datatracker.ietf.org/doc/draft-bittau-tcpinc-tcpcrypt/ https://datatracker.ietf.org/doc/draft-rescorla-tcpinc-tls-option/ We will have presentation for both of the drafts and then short presentation about framing protocols in general. Hopefully after the discussion we can go forward and adopt one of the drafts as basis for protocol specification (we already have ongoing discussion thread in the mailing list about this). -- kivinen@iki.fi From nobody Wed Mar 25 15:55:34 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F349D1A1B2E for ; Wed, 25 Mar 2015 15:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywBtZcS_V-Ko for ; Wed, 25 Mar 2015 15:55:27 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD641A1B25 for ; Wed, 25 Mar 2015 15:55:27 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5E23228521 for ; Wed, 25 Mar 2015 22:55:26 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 3AC2028518 for ; Wed, 25 Mar 2015 22:55:26 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 3506A2026 for ; Wed, 25 Mar 2015 22:55:26 +0000 (GMT) Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 25 Mar 2015 18:54:18 -0400 Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com ([172.27.123.102]) by usma1ex-dag1mb2.msg.corp.akamai.com ([172.27.123.102]) with mapi id 15.00.0913.011; Wed, 25 Mar 2015 18:54:18 -0400 From: "Salz, Rich" To: "saag@ietf.org" Thread-Topic: ACME BoF summary Thread-Index: AdBnTmJfrsAZLj3vQvaOb/qLMwMgDw== Date: Wed, 25 Mar 2015 22:54:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.112.203] Content-Type: multipart/alternative; boundary="_000_feca67910654453f84f0db1c38822c49usma1exdag1mb2msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [saag] ACME BoF summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 22:55:32 -0000 --_000_feca67910654453f84f0db1c38822c49usma1exdag1mb2msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We had a packed, enthusiastic crowd. Draft minutes were posted to the acme = list. There was very strong consensus to get a WG together; details to be w= orked out on-list before IETF 93. -- Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz --_000_feca67910654453f84f0db1c38822c49usma1exdag1mb2msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We had a packed, enthusiastic crowd. Draft minutes w= ere posted to the acme list. There was very strong consensus to get a WG to= gether; details to be worked out on-list before IETF 93.

 

 

-- 

Senior Architect, Akamai Technologies

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

 

--_000_feca67910654453f84f0db1c38822c49usma1exdag1mb2msgcorpak_-- From nobody Wed Mar 25 16:34:34 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED461A899C for ; Wed, 25 Mar 2015 16:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwZm8LuZn7YA for ; Wed, 25 Mar 2015 16:34:30 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1791A8898 for ; Wed, 25 Mar 2015 16:34:30 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-d5-55134605d981 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id D3.9C.03355.50643155; Wed, 25 Mar 2015 19:34:29 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t2PNYSbN028214 for ; Wed, 25 Mar 2015 19:34:29 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2PNYQsM018007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 25 Mar 2015 19:34:28 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2PNYQ8X006233; Wed, 25 Mar 2015 19:34:26 -0400 (EDT) Date: Wed, 25 Mar 2015 19:34:26 -0400 (EDT) From: Benjamin Kaduk To: saag@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsUixG6nosvqJhxqsO6NqMWU/k4mB0aPJUt+ MgUwRnHZpKTmZJalFunbJXBltD84zFSwibVi5tKz7A2Ma1m6GDk4JARMJD73V3QxcgKZYhIX 7q1n62Lk4hASWMwk0X/tJJRzlFGi7c1KZgjnGpPE09nTWSCcBkaJXR3XWUH6WQS0Jd5M7GUB sdkEVCRmvtnIBmKLCAhKPOibBBYXFhCXuHGrmR3E5hVwlNj1/hVYr6iAjsTq/VNYIOKCEidn PgGzmQW0JJZP38YygZFvFpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3SN9XIzS/RS U0o3MYLCiVOSbwfj14NKhxgFOBiVeHh/SAiFCrEmlhVX5h5ilORgUhLlnaglHCrEl5SfUpmR WJwRX1Sak1p8iFGCg1lJhJdVDyjHm5JYWZValA+TkuZgURLn3fSDL0RIID2xJDU7NbUgtQgm K8PBoSTBu88FqFGwKDU9tSItM6cEIc3EwQkynAdo+A2QGt7igsTc4sx0iPwpRl2OO1P+L2IS YsnLz0uVEufdAVIkAFKUUZoHNweWBl4xigO9JcxbC1LFA0whcJNeAS1hAlpyLp8PZElJIkJK qoGRO8/3blpnwoFd552FV0k29h2f3l7oUvvdv+/zhpwzL6ZsD4/VVXh06doWBe0nce4pJ2/8 eeeRcvB/VEXW203fL2R6shR6Rh54oua3mo39lJDVAs5FCgsnKenqn98yhV/SdUd4vDzv1v25 SXf8H93+wr01vud6w/ZWzWuhNbxzj1+//e5tg/xdJZbijERDLeai4kQA+P1v5d4CAAA= Archived-At: Subject: [saag] kitten summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 23:34:33 -0000 [steps out of time machine] Kitten met Friday afternoon, in the last session of the week. draft-ietf-kitten-cammac was in the RFC Editor's queue but got pulled; draft-ietf-kitten-gss-loop managed to stay in the queue (so far). We have three drafts almost ready to be sent to the IESG, another three waiting for WGLC, and entirely too many other WG documents needing revision and review. We heard talks about several proposed extensions to Kerberos and the GSS-API, including adding AEAD modes, and a talk about deprecating triple-DES and RC4 for Kerberos, of which some were met with enthusiasm and others with apathy. -Ben [steps back into time machine ... *poof* From nobody Wed Mar 25 16:37:06 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D876C1AD33B for ; Wed, 25 Mar 2015 16:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGvOqFlnCnhv for ; Wed, 25 Mar 2015 16:37:01 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71AE01A8898 for ; Wed, 25 Mar 2015 16:37:00 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-9e-5513469a87ff Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6C.42.19337.A9643155; Thu, 26 Mar 2015 00:36:58 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.210.2; Thu, 26 Mar 2015 00:36:57 +0100 Message-ID: <55134697.2010706@ericsson.com> Date: Wed, 25 Mar 2015 18:36:55 -0500 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: References: <55134454.9050302@ericsson.com> In-Reply-To: <55134454.9050302@ericsson.com> X-Forwarded-Message-Id: <55134454.9050302@ericsson.com> Content-Type: multipart/mixed; boundary="------------000401070603050005090007" X-Brightmail-Tracker: H4sIAAAAAAAAA1VSbUhTYRTmvbub19Xo9c7qZFGw0kpLzQSNPiUqf4VRkkTWpl5ytJbtrvVB yFqBJYRllm6ZlA2X5ZobVmsmuWWZaB9oJX0gJZkJfZgVqSW1e18T+/ec8zznPA/veRkJOyCN YLR6I2fQa3QqmZy2ZowcWmhbq0yP//k2Ormk6Di1CqXa7UNUGtoiX5bD6bQmzhC3Qi3P7bUX h+RZ8/ZXPeuizOiRthCFMoAT4duDa1KCp8CTLpesEMkZFjch+PzOggSCxQ4ER34YBazAMdDX 7pAImMaRUGl+FiJgGU6GF4OHZQKejDfCUEE9RfRh0GJ9Rws4HCuhtscp9pV4C5RXDYzuj4Ei /5GghmFC8QIosOlJniQo7nWKEglOA/utrjG52XJMehJh2zgH2ziZLbhJgueDyxdH2rPg5qdy CcF74belG/3flwdxEYKzX36KBOBJUNDaJhIsdiNwOi6JBItLKCjt0hPiNIJK61FKKGj8XQKl D31SMh4FPe2Nop/wSMcu22kyUYeg6b2TJqJ5UFb9RMwq+DkDs0k7HArN7aMSBbSWNMuEWcAn EHQ0vA4hi54iqPedoEgmBwU13QxZlAhtHhnR3EfQes9FkSJ4wjNDf0Jsozf0v6kZi3en47AY +98NbeIN0+H88BnRIDyo8Z17Q5MYn0PBe/e5lBQtUhgpO0VfQIlX0GSe47N27UhYHMsZtNk8 v1sfq+eMHhT8pP66X5Fe1PExJYAwg1QTFbVz2HRWqjHxB3YF0HSGVk1VrFgc2MTiHRojt5Pj 8jjDdsNeHccHEMWERphR7nVrVtyECum0QVfz1yn5rm1hV5PcK5ds6ONR1PC+23sy9memjzxe 49W99Okb5vHMck/n7w8mf9Qr9c3T634dvLh0wNvW447NLLtRb9m5ZH1+akvWjEC/uz1H01Gt nrmoWB25upONN6XMpfPlI3z/5uxPFQN/+g2rtiZ4GvuVy5tUNJ+rWRQtMfCav9xgmSCFAwAA Archived-At: Subject: [saag] Fwd: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 23:37:05 -0000 --------------000401070603050005090007 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Security people, We have just sent an initial proposal for a new WG charter to Dispatch WG. This is a proposal for a WG to work on end-to-end secured RTP conferencing with centralized media distribution devices. This work will require security expertise. Please review the proposed work and consider contributing. Any feedback on the charter is also appreciated. Cheers Magnus Westerlund (AVTCORE WG chair) --------------000401070603050005090007 Content-Type: message/rfc822; name="[dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC).eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="[dispatch] Proposal for a new WG: Privacy Enhanced RTP Confe"; filename*1="rencing (PERC).eml" X-Mozilla-Keys: Received: from sessmg12.ericsson.net (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.22) with Microsoft SMTP Server id 14.3.210.2; Thu, 26 Mar 2015 00:27:36 +0100 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by sessmg12.ericsson.net (Symantec Mail Security) with SMTP id A0.56.11600.76443155; Thu, 26 Mar 2015 00:27:36 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7C01B2AB5; Wed, 25 Mar 2015 16:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1427326053; bh=/1Af/noHOot/krfRFlPiWE9CB1tYYuPD0fN4jmVh35A=; h=Message-ID:Date:From:MIME-Version:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=gFeV8ys+7TItAGmN/TlN8sefJTjtwIkZItkDH+55XCpYvovDbZIK94eWsGChYIuTp 1Fs+V93x/ktNZ6kqNjvoN77VDfoBmBLgajEYLtF0MrTXxkl1rZUdwKG1Jnf+yY0yn3 7ztyvnDUYQRYAbdcp1cBuenS6jRFzGwbDnt0uHjY= X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F701B2A9F for ; Wed, 25 Mar 2015 16:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hor1YZlQd4vs for ; Wed, 25 Mar 2015 16:27:23 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 216261B29E7 for ; Wed, 25 Mar 2015 16:27:22 -0700 (PDT) X-AuditID: c1b4fb32-f792f6d000002d50-3c-55134466d24d Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CF.32.28835.85443155; Thu, 26 Mar 2015 00:27:20 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.210.2; Thu, 26 Mar 2015 00:27:19 +0100 Message-ID: <55134454.9050302@ericsson.com> Date: Wed, 25 Mar 2015 18:27:16 -0500 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 To: DISPATCH list X-Brightmail-Tracker: H4sIAAAAAAAAA1VTbWxTVRjeez/a26V3HvrBXipqVoXgQNjmfhyIkIGSuIQf/rBqSIxc4a6t dN3SW0gX/bExF3EydITCPhgOQ7IVJJOlQZ1Ktws2bgzYusxJUpYRJFGINjo2PnTivb1j6L/n nOd53uc5J+cIrK3O7BLkSFgOBaWA25TLcU8lVz3ne8nuKfrzgYOemUhz9HLvEaB7rsbNdKT1 HNB7o91m2tsVY+jl82mgTbGjPP1jfzNPG5KdPO3u+g3o6QtRoImfzgJN9UwydPJWAujVuTMs TfTPmujhhvW0ffgUS88P/c6WOV6+PzNuegW25r6wQw74d8uhNRu25fpujSfM1ZfWRa4115lr Yd/aRhAEJKU43GtqBIsGF+PIZI+GcwUbOchg5+ARs07YSBTwglqoExy5zeLhi3284ViON1L9 rI45sgz3dh/nDHcccOD6OcYQrcCW2AgYaY/hKfVpY9uBjbUpzsB5OPrLXUb3ImkCHPsubTYG /QjYv69+vlOMwcwPw2bDUoqpfw7MxyUBk1e+4Y1FF2D03oOsSiQrcWDq84WCibG6bHEToXjl bl322E7iwY77UcbQL8LB1p+zpRyavq99ijNKDfI419KcJYC8gadn2kHHds386d+x+UpP4lTT SdbAS3B47GJWQwjBo8e/zgZYyXo8Nt3KGfhd/P5OnP8EVrT9J7tNuyeWPIs9fWv0bZYU4MGP rpk7gT0BTkVWlEpvcclqOeTfrihVwdVBOdwL2iMbiP9V8hVMzG5UgQjgtopfPGPz2Hhpt1JT qcISgXE7xeZCu8eW93bVjhqfpPjeCu0KyIoKjwucO188tEp91Ua8UljeKcvVcughu1QQ3Cge elFzLgrJXjlS4Q+EH9GMYFEBBavbId7ZpGlEpVqqVPxegx+CAle+uFg3E53w7QoueB/+jBQ8 4bKLkJOTY7NquZX+8P/5m5CvncdujLf6g+GF6Te1YEYLvlSVpweHpUeUqxZeq5cyXMfazrTE /Fr0+oaP245t2Rx5p/WzclLu8O9VyyJzB4aC14NlO2fqC0YqRvfXbhvvqIj0OMctt2s+bF85 ltyyqTCezsze2F6uBnK87paGZR0ed1vGX5J4/oOJ9+Y8eVuTb559nxfXLXclKyyWLzc7i6e/ VUvZ6ejSPRszRW5O8UnFhWxIkf4FWT111RQEAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKJMWRmVeSWpSXmKPExsUyM+JvjW6Ei3CowZLtahZLJy1gdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrczt9kKnmtVTHp6gr2BcaVyFyMnh4SAicSlf5NYIGwxiQv3 1rOB2EICRxglJs8T7mLkArKXM0pM/fmfHSTBK6AtcfDBGmYQm0VAVWL/5UZWEJtNwELi5o9G sGZRgWCJn+27mSDqBSVOznwCtkAEqH7X7AdgtrCAh8SrDWsZuxg5OJgFNCXW79IHCTMLyEs0 b53NDHGDtkRDUwfrBEa+WUgmzULomIWkYwEj8ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2M wHA6uOW31Q7Gg88dDzEKcDAq8fBuUBEKFWJNLCuuzD3EKM3BoiTOa2d8KERIID2xJDU7NbUg tSi+qDQntfgQIxMHp1QDo+6NAMWUV/vZnuw1edNmeOrf3vO8B1p1fBqPOc/6k/L6c/HjM8v5 3JYvvHku6vtLhwesUYsKDeLL/zTvL77HLP9YrbDi57O/KRr+jz2PNH3+u6eZS23OZ/n81OzW hH2/N+2f6nVv68ojylOM3i5Z+TLwlOqGT49nFe0VebvQIO3OlR6bXu9bb0WVWIozEg21mIuK EwEnBvwCCAIAAA== Archived-At: Subject: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: dispatch-bounces@ietf.org Sender: dispatch Return-Path: dispatch-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: ESESSHC001.ericsson.se X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 RGlzcGF0Y2gsCgpBVlRDT1JFIFdHIGhhcyBkaXNjdXNzZWQgYSBjb3VwbGUgb2YgcHJvcG9zYWxz IHRoYXQgZGlzY3Vzc2VzIGVuZC10by1lbmQKc2VjdXJpdHkgaW4gY2VudHJhbGl6ZWQgUlRQIGJh c2VkIGNvbmZlcmVuY2VzLgoKRHJhZnRzIGZvciB0aGVzZSBQcm9wb3NhbHM6Cmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWpvbmVzLWF2dGNvcmUtcHJpdmF0ZS1tZWRpYS1y ZXF0cy8KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtam9uZXMtYXZ0Y29y ZS1wcml2YXRlLW1lZGlhLWZyYW1ld29yay8KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtY2hlbmctYXZ0Y29yZS1zcnRwLWNsb3VkLwoKSW4gdGhlc2UgZGlzY3Vzc2lvbnMg b25lIGhhcyByZWFjaGVkIHRoZSBjb25jbHVzaW9uIHRoYXQgdGhpcyB3b3JrCnJlcXVpcmVzIGl0 cyBvd24gdmVudWUgdG8gY29udGludWUgdGhlIHdvcmsuIFRoZXJlZm9yZSBhIG51bWJlciBvZgpp bnRlcmVzdGVkIGhhcyBwdXQgdG9nZXRoZXIgYSBpbml0aWFsIGRyYWZ0IGNoYXJ0ZXIgZm9yIGEg bmV3IFdHLgoKUGxlYXNlIHJldmlldyBhbmQgcHJvdmlkZSBmZWVkYmFjay4KCgpOYW1lOiBQcml2 YWN5IEVuaGFuY2VkIFJUUCBDb25mZXJlbmNpbmcgKFBFUkMpCkFyZWE6IEFSVApDaGFpcnM6IFRC RApNYWlsaW5nIExpc3Q6IDx1c2luZyBkaXNwYXRjaEBpZXRmLm9yZyBmb3Igbm93PgoKTW90aXZh dGlvbiBmb3IgbmV3IFdHCi0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKUlRQLWJhc2VkIHJlYWwtdGlt ZSBtdWx0aS1wYXJ0eSBpbnRlcmFjdGl2ZSBtZWRpYSBjb25mZXJlbmNpbmcgaXMgdG9kYXkKaW4g d2lkZXNwcmVhZCB1c2UuIE1hbnkgb2YgdGhlIGRlcGxveW1lbnRzIHVzZXMgb25lIG9yIG1vcmUg Y2VudHJhbGx5CmxvY2F0ZWQgbWVkaWEgZGlzdHJpYnV0aW9uIGRldmljZXMgdGhhdCBwZXJmb3Jt IHNlbGVjdGl2ZSBmb3J3YXJkaW5nIG9yCm1peGVzIG1lZGlhIHN0cmVhbXMgcmVjZWl2ZWQgZnJv bSB0aGUgcGFydGljaXBhdGluZyBlbmRwb2ludHMuIFRoZSBtZWRpYQp0cmFuc3BvcnQgcHJvdG9j b2wgY29tbW9ubHkgdXNlZCBpcyBSVFAgKFJGQzM1NTApLiBUaGVyZSBhcmUgdmFyaW91cwpzaWdu YWxpbmcgc3lzdGVtcyB1c2VkIHRvIGVzdGFibGlzaCB0aGVzZSBtdWx0aS1wYXJ0eSBjb25mZXJl bmNlcy4KClRoZXNlIGNvbmZlcmVuY2VzIHJlcXVpcmUgc2VjdXJpdHkgdG8gZW5zdXJlIHRoYXQg dGhlIFJUUCBtZWRpYSBhbmQKcmVsYXRlZCBtZXRhIGRhdGEgb2YgdGhlIGNvbmZlcmVuY2UgaXMg a2VwdCBwcml2YXRlIHRvIHRoZSBzZXQgb2YKaW52aXRlZCBwYXJ0aWNpcGFudHMgYW5kIG9ubHkg b3RoZXIgZGV2aWNlcyB0cnVzdGVkIGJ5IHRob3NlCnBhcnRpY2lwYW50cyB3aXRoIHRoZWlyIG1l ZGlhLiAgQXQgdGhlIHNhbWUgdGltZSwgbXVsdGktcGFydHkgbWVkaWEKY29uZmVyZW5jZXMgZG8g bmVlZCBzb3VyY2UgYXV0aGVudGljYXRpb24gYW5kIGludGVncml0eSBjaGVja3MgdG8KcHJvdGVj dCBhZ2FpbnN0IG1vZGlmaWNhdGlvbnMsIGluc2VydGlvbnMgb3IgcmVwbGF5IGF0dGFja3MuICBN ZWRpYQpkaXN0cmlidXRpb24gZGV2aWNlcyBzdXBwb3J0aW5nIHRoZXNlIGNvbmZlcmVuY2VzIG1h eSBhbHNvIHBlcmZvcm0gUlRQCmhlYWRlciBjaGFuZ2VzIGFuZCBvZnRlbiBjb25zdW1lIGFuZCBj cmVhdGUgUlRDUCBtZXNzYWdlcyBmb3IgZWZmaWNpZW50Cm1lZGlhIGhhbmRsaW5nLgoKVG8gZGF0 ZSwgZGVwbG95bWVudCBtb2RlbHMgZm9yIHRoZXNlIG11bHRpLXBhcnR5IG1lZGlhIGRpc3RyaWJ1 dGlvbgpkZXZpY2VzIGRvIG5vdCBlbmFibGUgdGhlbSB0byBwZXJmb3JtIHRoZWlyIGZ1bmN0aW9u cyB3aXRob3V0IGhhdmluZwprZXlzIHRvIGRlY3J5cHQgdGhlIHBhcnRpY2lwYW50c+KAmSBtZWRp YSwgcHJpbWFyaWx5IHVzaW5nIFNlY3VyZSBSVFAKKFJGQzM3MTEpIHRvIHByb3ZpZGUgc2Vzc2lv biBzZWN1cml0eS4KCkEgbmV3IGFyY2hpdGVjdHVyZSBtb2RlbCBhbmQgcmVsYXRlZCBzcGVjaWZp Y2F0aW9ucyBpcyBuZWVkZWQsIHdpdGggYQpmb2N1c2VkIGVmZm9ydCBmcm9tIHRoZSBSVFAgYW5k IFNlY3VyaXR5IGNvbW11bml0aWVzLgoKV0cgT2JqZWN0aXZlcwotLS0tLS0tLS0tLS0tCgpUaGlz IFdHIHdpbGwgd29yayBvbiBhIHNvbHV0aW9uIHRoYXQgZW5hYmxlcyBjZW50cmFsaXplZCBTUlRQ IGJhc2VkCmNvbmZlcmVuY2luZyB3aGVyZSB0aGUgY2VudHJhbCBkZXZpY2UgZGlzdHJpYnV0aW5n IHRoZSBtZWRpYSBpcyBub3QKcmVxdWlyZWQgdG8gYmUgdHJ1c3RlZCB3aXRoIHRoZSBrZXlzIHRv IGRlY3J5cHQgdGhlIHBhcnRpY2lwYW504oCZcyBtZWRpYS4KVGhlIG1lZGlhIG11c3QgYmUga2Vw dCBjb25maWRlbnRpYWwgYW5kIGF1dGhlbnRpY2F0ZWQgYmV0d2VlbiBhbgpvcmlnaW5hdGluZyBl bmRwb2ludCBhbmQgdGhlIGV4cGxpY2l0bHkgYWxsb3dlZCByZWNlaXZpbmcgZW5kcG9pbnRzIG9y Cm90aGVyIGRldmljZXMuICBGdXJ0aGVyIGl0IGlzIGRlc2lyZWQgdGhhdCBhIHNvbHV0aW9uIHN0 aWxsIHByb3ZpZGUKcmVwbGF5IHByb3RlY3Rpb24gc28gdGhhdCB0aGUgbWVkaWEgZGlzdHJpYnV0 aW9uIGRldmljZXMgY2Fu4oCZdCByZXBsYXkKcHJldmlvdXMgcGFydHMgb2YgdGhlIG1lZGlhLgoK VGhlIHNvbHV0aW9uIG11c3QgYWxzbyBwcm92aWRlIHNlY3VyaXR5IGZvciBlYWNoIGhvcCBiZXR3 ZWVuIGVuZHBvaW50cwphbmQgbXVsdGktcGFydHkgbWVkaWEgZGlzdHJpYnV0aW9uIGRldmljZXMg YW5kIGJldHdlZW4gbXVsdGktcGFydHkgbWVkaWEKZGlzdHJpYnV0aW9uIGRldmljZXMuIFRoZSBS VENQIG1lc3NhZ2VzIGFuZCBSVFAgaGVhZGVyIGV4dGVuc2lvbnMKcmVxdWlyZWQgZm9yIHRoZSBt ZWRpYSBkaXN0cmlidXRpb24gZGV2aWNlIHRvIHBlcmZvcm0gdGhlIHNlbGVjdGl2ZQptZWRpYSBm b3J3YXJkaW5nIG1heSByZXF1aXJlIGJvdGggc291cmNlIGF1dGhlbnRpY2F0aW9uIGFuZCBpbnRl Z3JpdHkgYXMKd2VsbCBhcyBjb25maWRlbnRpYWxpdHkuIFRoZSBzb2x1dGlvbiBtYXkgYWxzbyBj b25zaWRlciBwcm92aWRpbmcKZW5kLXRvLWVuZCBzZWN1cml0eSBmb3IgYSBzdWJzZXQgb2YgdGhl IFJUQ1AgbWVzc2FnZXMgb3IgaGVhZGVyIGV4dGVuc2lvbnMuCgpUaGUgc29sdXRpb24gc2hvdWxk IGJlIHVzYWJsZSBmcm9tIGJvdGggU0lQIGFuZCBXZWJSVEMgZW5kcG9pbnRzIHRoYXQKaW1wbGVt ZW50IHRoZSBleHRlbnNpb24gZGVmaW5lZCBieSB0aGlzIFdHLgoKVGhpcyBXRyB3aWxsIHBlcmZv cm0gdGhlIGZvbGxvd2luZyB3b3JrOgoKMS4gICAgRGVmaW5lIGEgZ2VuZXJhbCBhcmNoaXRlY3R1 cmUgYW5kIFJUUCB0b3BvbG9neShzKSB0aGF0IGVuYWJsZXMKICAgICAgZW5kLXRvLWVuZCBtZWRp YSBzZWN1cml0eSBmb3IgbXVsdGktcGFydHkgUlRQIGNvbmZlcmVuY2luZy4KCjIuICAgIERlZmlu ZSB0aGUgdHJ1c3QgbW9kZWwgYW5kIGRlc2NyaWJlIHRoZSByZXN1bHRpbmcgc2VjdXJpdHkKICAg ICAgcHJvcGVydGllcy4KCjMuICAgIFNwZWNpZnkgYW55IG5lY2Vzc2FyeSBleHRlbnNpb25zIHRv IFNSVFAuCgo0LiAgICBEZWZpbmUgYSBLZXkgTWFuYWdlbWVudCBGdW5jdGlvbiB0aGF0IGRpc3Ry aWJ1dGVzIHRoZSBrZXlzLiBUaGUKICAgICAgc3lzdGVtIG5lZWRzIHRvIGJlIGFibGUgdG8gYmlu ZCB0aGUgbWVkaWEgdG8gdGhlIHNlbmRlciBvZiB0aGUKICAgICAgbWVkaWHigJlzIGlkZW50aXR5 IGFuZC9vciB0aGUgaWRlbnRpdHkgb2YgdGhlIGNvbmZlcmVuY2UuCgpDb2xsYWJvcmF0aW9uCi0t LS0tLS0tLS0tLS0KCklmIHRoZXJlIGlzIGlkZW50aWZpY2F0aW9uIG9mIG1pc3NpbmcgcHJvdG9j b2xzIG9yIGZ1bmN0aW9uYWxpdGllcywgc3VjaAp3b3JrIGNhbiBiZSByZXF1ZXN0ZWQgdG8gYmUg ZG9uZSBpbiBhbm90aGVyIHdvcmtpbmcgZ3JvdXAgd2l0aCBhCnN1aXRhYmxlIGNoYXJ0ZXIgb3Ig YnkgcmVxdWVzdHMgZm9yIGNoYXJ0ZXJpbmcgaXQgaW4gdGhpcyBXRyBvciBhbm90aGVyCldHLiBQ b3RlbnRpYWwgd29yayB0aGF0IG1pZ2h0IHJlcXVpcmUgd29yayBpbiBvdGhlciBXR3MgYXJlIERU TFMKZXh0ZW5zaW9ucyAoVExTKSBhcyB3ZWxsIGFzIFJUUCBoZWFkZXIgZXh0ZW5zaW9ucyAoQVZU RVhUKS4gVGhpcwpyZXF1aXJlcyBzdHJvbmcgY29sbGFib3JhdGlvbiB3aXRoIHRoZSBzZWN1cml0 eSBhcmVhLiBXZSB3aWxsIG5vdGlmeQpTSVBSRUMsIFczQyBXZWJSVEMsIEFWVENvcmUsIGFuZCBv dGhlciByZWxhdGVkIGdyb3VwcyBhYm91dCB0aGlzIHdvcmsuCgpOb24tR29hbHMKLS0tLS0tLS0t CgpUaGUgV0cgaXMgbm90IGNoYXJ0ZXJlZCB0byBleHRlbmQgYW55IHNpZ25hbGluZyBzeXN0ZW0g dXNlZCB0byBlc3RhYmxpc2gKdGhlIFJUUCBiYXNlZCBjb25mZXJlbmNlcy4gSXQgd2lsbCBob3dl dmVyLCBuZWVkIHRvIGNvbnNpZGVyIGluIGl0cwphcmNoaXRlY3R1cmUgaG93IHRoZSBzb2x1dGlv biBtYXkgaW50ZWdyYXRlIHdpdGggdGhlc2Ugc3lzdGVtcy4KCldpbGwgbm90IGNvbnNpZGVyIG5v bi1yZWFsLXRpbWUgdXNhZ2VzLCBtdWx0aWNhc3QgYmFzZWQgbWVkaWEKZGlzdHJpYnV0aW9uLCBv ciBTZWN1cml0eSBkZXNjcmlwdGlvbnMtYmFzZWQga2V5aW5nLgoKR29hbHMgYW5kIE1pbGVzdG9u ZXMKLS0tLS0tLS0tLS0tLS0tLS0tLS0KClRCRCAgU3VibWl0IGFyY2hpdGVjdHVyZSBvciBmcmFt ZXdvcmsgc3BlY2lmaWNhdGlvbiB0byBJRVNHIChTdGFuZGFyZHMKVHJhY2spCgpUQkQgIFN1Ym1p dCBwcm90b2NvbCBzcGVjaWZpY2F0aW9uKHMpIHRvIElFU0cgKFN0YW5kYXJkcyBUcmFjaykKCgoK CkNoZWVycwoKTWFnbnVzIFdlc3Rlcmx1bmQKKEFWVENPUkUgV0cgY2hhaXIpCgoKLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQpTZXJ2aWNlcywgTWVkaWEgYW5kIE5ldHdvcmsgZmVhdHVyZXMsIEVyaWNzc29uIFJlc2Vh cmNoIEVBQi9UWE0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpFcmljc3NvbiBBQiAgICAgICAgICAgICAgICAgfCBQ aG9uZSAgKzQ2IDEwIDcxNDgyODcKRsOkcsO2Z2F0YW4gNiAgICAgICAgICAgICAgICAgfCBNb2Jp bGUgKzQ2IDczIDA5NDkwNzkKU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBt YWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGlzcGF0Y2ggbWFpbGluZyBsaXN0 CmRpc3BhdGNoQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZGlzcGF0Y2gK --------------000401070603050005090007-- From nobody Wed Mar 25 16:42:30 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5854D1A8898 for ; Wed, 25 Mar 2015 16:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4V5EzNXBfeVi for ; Wed, 25 Mar 2015 16:42:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD40F1A8A43 for ; Wed, 25 Mar 2015 16:42:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C4BA3BE9A; Wed, 25 Mar 2015 23:42:23 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvI71my8o8fV; Wed, 25 Mar 2015 23:42:22 +0000 (GMT) Received: from [31.133.180.113] (dhcp-b471.meeting.ietf.org [31.133.180.113]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 26524BE88; Wed, 25 Mar 2015 23:42:22 +0000 (GMT) Message-ID: <551347D9.3060606@cs.tcd.ie> Date: Wed, 25 Mar 2015 23:42:17 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Magnus Westerlund , saag@ietf.org References: <55134454.9050302@ericsson.com> <55134697.2010706@ericsson.com> In-Reply-To: <55134697.2010706@ericsson.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] Fwd: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 23:42:29 -0000 Thanks Magnus, For folks who're in Dallas, EKR will talk about this at the saag session for a few minutes too, Cheers, S. On 25/03/15 23:36, Magnus Westerlund wrote: > Security people, > > We have just sent an initial proposal for a new WG charter to Dispatch > WG. This is a proposal for a WG to work on end-to-end secured RTP > conferencing with centralized media distribution devices. This work will > require security expertise. > > Please review the proposed work and consider contributing. Any feedback > on the charter is also appreciated. > > Cheers > > Magnus Westerlund > (AVTCORE WG chair) > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Wed Mar 25 17:16:13 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783FC1A0211 for ; Wed, 25 Mar 2015 17:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jC0qH7alB8m for ; Wed, 25 Mar 2015 17:16:09 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487BA1A020A for ; Wed, 25 Mar 2015 17:16:09 -0700 (PDT) Received: by wibbg6 with SMTP id bg6so44976274wib.0 for ; Wed, 25 Mar 2015 17:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=NeF4dxY/iPHs1cCrmfreH+5ghxUZTdI/lE2KRPoxvdk=; b=Cd1dcownqzwZ7p7RZe8GrvZN/zmDIl737qpEMEGVK2Qs8dEC1ZFfmSu6F7hcbkYMCy y3UZjv+xusDYPvZXHlvoGblTs9A6zeWSfjTjy0xbOU36OAFxyi/+MUu3M9YhX9xyzuPe fz+jDkSdjhM1rEqUTtf6T4A7UE/KM7+v6S5H1f6hwBiDdQEi5NHQYGtezXIX8UFkgZz9 vO6io2tZwA0SENHEMLACFLyz+GtQrqEGFGzy+t97SKZ1mW36FRxOBVtG/tx0HSAzad11 Tf+mX1BbkB5PoIZsDzMAoeJzmO5/1bNJEzNeSyGPB8yG1AC2/V6VTEXjtWFoCtwae337 dC1w== X-Received: by 10.194.62.74 with SMTP id w10mr22336687wjr.95.1427328968032; Wed, 25 Mar 2015 17:16:08 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:fd9f:7d5c:2f08:7487? ([2001:67c:370:176:fd9f:7d5c:2f08:7487]) by mx.google.com with ESMTPSA id z13sm5866491wjr.44.2015.03.25.17.16.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Mar 2015 17:16:07 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_01704EF7-4B8F-49F7-BE19-C7AD158E9442" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Wed, 25 Mar 2015 19:16:05 -0500 Message-Id: <5EA01923-E4A1-446E-8268-B49FF22AA911@gmail.com> References: To: "Boyle, Vincent M" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 00:16:11 -0000 --Apple-Mail=_01704EF7-4B8F-49F7-BE19-C7AD158E9442 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Since the plenary is still ongoing, some of us may be somewhat late. Yoav > On Mar 19, 2015, at 5:55 AM, Boyle, Vincent M wrote: >=20 > I left out an important detail; the date! The side meeting will be at = 7:30 at City Tavern on *Wednesday*, the 25th. > Thanks to Joe Salowey for pointing that out to me. > =20 > Mike > =20 > On Wed, Mar 18, 2015 at 1:02 PM, Boyle, Vincent M > wrote: > Just a quick update: a colleague of mine and I did some investigating = and we think the City Tavern would be a good venue for the side meeting. = I=E2=80=99m performing a bit of due diligence to make sure they can = accommodate us, but I believe that=E2=80=99s where we will meet (unless = a Dallas local wants to warn us off). So, 7:30 PM local time at the City = Tavern (1402 Main Street, which looks to be a 10 minute walk from the = Fairmont). I=E2=80=99ll attempt to reserve some space under my name. > =20 > Hope to see you there, > Mike > =20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail=_01704EF7-4B8F-49F7-BE19-C7AD158E9442 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Since the plenary is still ongoing, some of us may be = somewhat late.

Yoav

On Mar 19, 2015, at 5:55 AM, = Boyle, Vincent M <vmboyle@nsa.gov> wrote:

I left out an = important detail; the date! The side meeting will be at 7:30 at City = Tavern on *Wednesday*, the 25th.

Thanks to Joe Salowey for pointing that out to = me.

 

Mike

 

On Wed, Mar 18, 2015 = at 1:02 PM, Boyle, Vincent M <vmboyle@nsa.gov> wrote:

Just a = quick update: a colleague of mine and I did some investigating and we = think the City Tavern would be a good venue for the side meeting. I=E2=80=99= m performing a bit of due diligence to make sure they can accommodate us, but I believe that=E2=80=99s = where we will meet (unless a Dallas local wants to warn us off). So, = 7:30 PM local time at the City Tavern (1402 Main Street, which looks to = be a 10 minute walk from the Fairmont). I=E2=80=99ll attempt to reserve some space under my name.

 

Hope to see = you there,

Mike

 

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

= --Apple-Mail=_01704EF7-4B8F-49F7-BE19-C7AD158E9442-- From nobody Thu Mar 26 04:52:00 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23CFC1B2C99 for ; Thu, 26 Mar 2015 04:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxXNKJsJEOAj for ; Thu, 26 Mar 2015 04:51:57 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5FB1B2C9A for ; Thu, 26 Mar 2015 04:51:57 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t2QBpuO2009820 for ; Thu, 26 Mar 2015 07:51:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1427370716; bh=qe30H1GDpqbSmbhZG2Rte4XwKTEYWY29ACRlDByu1GA=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=Uh1S+gJQ7K1SHRJH0/sAW49tmjAMEtKcpLKtcWxo8aU2oHnftTFJts88+onqRQ83s IQenZdcTJ2SXjd1gEcyILqQd+aaHQ+NhQhie6ikx8oFR7sifBiF71u/4CFf30JhSo6 b4P/hxSobRDdqVAa+5P7R38LYzZvV/4GnkDG5r9U= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t2QBptUi012896 for ; Thu, 26 Mar 2015 07:51:55 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0210.002; Thu, 26 Mar 2015 07:51:54 -0400 From: "Roman D. Danyliw" To: "saag@ietf.org" Thread-Topic: DOTS Summary Thread-Index: AdBnu0EHdCjeBu+iQmGGxZTER5UODg== Date: Thu, 26 Mar 2015 11:51:54 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCD93D5C9A@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [saag] DOTS Summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 11:51:59 -0000 The DDOS Open Threat Signaling (DOTS) BOF [1] met on Tuesday. This non-wor= king group forming BOF discussed how on-premises mitigation devices could c= ommunicate threat and telemetry data with a service provider for improved m= itigation. Two draft [2] [3] and a panel of vendors helped frame the discu= ssion. There was consensus that the on-premises mitigation devices should communic= ate capabilities, telemetry, and threat data to the service provider. The = service provider should push down policy and describe what mitigation it is= performing. There was also consensus that this is work that the IETF shou= ld perform. The next steps from the participants=92 comments leaned towards a new worki= ng group. Please continue the conversation and add your perspective on the= mailing list [4]. =20 [1] http://www.ietf.org/proceedings/92/slides/slides-92-dots-2.pptx [2] draft-teague-open-threat-signaling-00 [3] draft-fu-ipfix-network-security-00 [4] https://www.ietf.org/mailman/listinfo/dots= From nobody Thu Mar 26 07:18:19 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1427C1ACE81 for ; Thu, 26 Mar 2015 07:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIlnYA3yaQCd for ; Thu, 26 Mar 2015 07:18:16 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1331ACE7E for ; Thu, 26 Mar 2015 07:18:16 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id B482E28B0041 for ; Thu, 26 Mar 2015 10:18:15 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 916411F8035; Thu, 26 Mar 2015 10:18:15 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_F9C1BB5B-3DCD-4CB8-8628-CD10A627C150"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 26 Mar 2015 10:18:06 -0400 Message-Id: To: "saag@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Subject: [saag] report for SIDR X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 14:18:18 -0000 --Apple-Mail=_F9C1BB5B-3DCD-4CB8-8628-CD10A627C150 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 SIDR met Monday morning. Since the IETF91, two drafts have been through wg last call. = Publication was requested for one draft but AD comments need to be = addressed. One draft is in the RFC Editor queue -- since IETF91. The = holdup was consideration with IETF Trust of how to deal with templates. A new transport protocol for RPKI (instead of rsync) was adopted as a = new work item for the working group. Publication request imminent for another draft (before end of week) In the meeting: Two long dormant drafts were revived and presented (key roll, and use of = RPKI for signatures on IRR RPSL objects) Responses to the BGPSEC protocol wglc were covered, as well as errata on = existing RFC. The newly adopted transport protocol work was discussed =96 positive = comments from wg The results of a survey about deployment of RPKI and DNSSEC were = presented =96 some interesting statistics of deployment, why and why = not. --Sandy --Apple-Mail=_F9C1BB5B-3DCD-4CB8-8628-CD10A627C150 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVFBUkAAoJEHplpQeet0IZR2YQALzwqvGRcxF5qRQg79qqqP2K CBDFtI+lrEBwcMbhiNq6DOX+idB1BTlz4wLQeCD2lzdhEivLh1522rj/N+f6Edin R4u/f6P3C52nLMyZxeCzmrbr4BdpuLrsJaI9wlVyVlecauKEUkrP9YGsM6yYNlEL bpkOtrg+X6P1S3GeyRzpAaezUE9ys2WlSTLKvkeI9/PbKWsncalDOdhaySLOB8o9 aXi+Ehe1xErfSNBIfBd3k4+hc6zyOMJQD61u9siJ85dXTVmqeJa/RgwV/v0pSBqs wxotiSP7s0eCoOjHE63LYu599KMesJBQM+SJelBC2wndKQzFYQStRCDTr7JZ33ND +fhdOWCOvov+nTZl2nTQDjxJRl6MgiF+xbewnIyPOyFotSLfYyK0rqxOrHbjOGrl b2Ntl0lgeNMY6CotH60jCpe9HlhWRxt/Mt5b/1yO80a6YFvA3bLyJjlp2AX2e/Wj DuvKKV4tTKFSOuHEW0T0Wb1DtLYv/4iw2BJr/+g+fcUPEdDjNBd3vxhs8NuSYpKa G0XBjgMm9KowoxeQ6M54u1KPlRnmBTpoQ0z4x1u+zPE+rFMS3t5eu+us7QbbnfLJ s2FQE6DOrR0JLfJ6ByQNDbiaWq0vjQEkvBVC9QVEFHToHkkjRRmB9UvaKQI+fE59 U41ciKEfoL3CjGD5wFbH =rIrE -----END PGP SIGNATURE----- --Apple-Mail=_F9C1BB5B-3DCD-4CB8-8628-CD10A627C150-- From nobody Thu Mar 26 08:08:01 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DAC1A008F for ; Thu, 26 Mar 2015 08:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhZbuMKxmNiO for ; Thu, 26 Mar 2015 08:07:55 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0088.outbound.protection.outlook.com [65.55.169.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB07B1A1B64 for ; Thu, 26 Mar 2015 08:05:12 -0700 (PDT) Received: from DM2PR0601MB1117.namprd06.prod.outlook.com (25.160.218.13) by DM2PR0601MB1118.namprd06.prod.outlook.com (25.160.218.139) with Microsoft SMTP Server (TLS) id 15.1.125.19; Thu, 26 Mar 2015 15:05:11 +0000 Received: from DM2PR0601MB1118.namprd06.prod.outlook.com (25.160.218.139) by DM2PR0601MB1117.namprd06.prod.outlook.com (25.160.218.13) with Microsoft SMTP Server (TLS) id 15.1.125.19; Thu, 26 Mar 2015 15:05:10 +0000 Received: from DM2PR0601MB1118.namprd06.prod.outlook.com ([25.160.218.139]) by DM2PR0601MB1118.namprd06.prod.outlook.com ([25.160.218.139]) with mapi id 15.01.0125.002; Thu, 26 Mar 2015 15:05:10 +0000 From: Karen O'Donoghue To: "saag@ietf.org" Thread-Topic: JOSE wg summary Thread-Index: AQHQZ9ZA8dTqPdcoo0moSbvDi2knww== Date: Thu, 26 Mar 2015 15:05:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.181.39] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0601MB1117; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0601MB1118; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(62966003)(77156002)(86362001)(2501003)(450100001)(110136001)(87936001)(83716003)(102836002)(2656002)(82746002)(40100003)(2900100001)(99286002)(33656002)(50986999)(54356999)(36756003)(106116001)(122556002)(229853001)(2351001)(46102003)(107886001)(66066001)(92566002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0601MB1117; H:DM2PR0601MB1118.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR0601MB1117; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0601MB1117; x-forefront-prvs: 0527DFA348 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2015 15:05:09.9007 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0601MB1117 X-OriginatorOrg: isoc.org Archived-At: Subject: [saag] JOSE wg summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 15:08:00 -0000 The JOSE working group met on Tuesday, 24 March 2015. The four core specifi= cations (JWA, JWE, JWK, and JWS) along with the cookbook document are all a= pproved for publication and in the RFC Editor queue. The thumbprint draft h= as passed WGLC and is awaiting shepherd writeup. The plan is to close the w= orking group in the near future. Any additional proposals for changes/addit= ions are requested in the next month or so. The Tuesday meeting itself focu= sed on two drafts proposing CBOR Object Signing and Encryption work. There = appears to be demand for this work, and a mailing list is going to be estab= lished to discuss a proposed charter for a working group. = From nobody Thu Mar 26 09:20:31 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86701A7D82 for ; Thu, 26 Mar 2015 09:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RciMMfLeVEd for ; Thu, 26 Mar 2015 09:20:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AECE1A8799 for ; Thu, 26 Mar 2015 09:20:27 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 3F06818C33A; Thu, 26 Mar 2015 17:20:26 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 22D7F35C07A; Thu, 26 Mar 2015 17:20:26 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Thu, 26 Mar 2015 17:20:25 +0100 From: To: "saag@ietf.org" Thread-Topic: IETF92: DIME WG session report Thread-Index: AdBn4GPD2HYzt0+nQbK4xJIbGZH9EA== Date: Thu, 26 Mar 2015 16:20:24 +0000 Message-ID: <24201_1427386826_551431CA_24201_6621_1_6B7134B31289DC4FAF731D844122B36EEAF58D@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.26.135421 Archived-At: Cc: "dime-chairs@tools.ietf.org" Subject: [saag] IETF92: DIME WG session report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 16:20:29 -0000 We meet on Wednesday morning. About 20 people in the room with the most act= ive participants, for a full 150mn session. 2 WG documents are at a final stage:=20 * Diameter Congestion and Filter Attributes (draft-ietf-dime-congestion-flo= w-attributes-01) submitted at IESG * Diameter Overload Indication Conveyance (draft-ietf-dime-ovli-08) still w= aiting for proto-write but ready to be submitted About other WG documents, the security E2E Security Requirements document (= draft-ietf-dime-e2e-sec-req-02) has been revised and is ready for WGLC. A n= ew version of the Diameter Group Signaling document (draft-ietf-dime-group-= signaling-04) is expected next weeks before WGLC. And the Diameter Agent Ov= erload (draft-ietf-dime-agent-overload-01) and the Diameter Overload Rate C= ontrol (draft-ietf-dime-doic-rate-control-01) documents need more reviews t= o be moved forward. Two documents have adopted as WG documents: * Architectural Considerations for Diameter Load Information (draft-campbel= l-dime-load-considerations-01) investigating requirements and use cases for= load information exchange between Diameter nodes (e.g. for intelligent loa= d balancing). This adoption will be confirmed on the mailing list. * AVP for provisioning CPE supporting IPv4-Over-IPv6 Transitional Solutions= (draft-zhou-dime-4over6-provisioning-05) defining new set of AVP for dynam= ic configuration of subscriber-site-specific information related to IPv4/IP= v6 transition mechanisms. A new document has been presented as individual submission, Diameter Routin= g Message Priority (draft-donovan-dime-drmp-00). There is some interest in = this work but more work is needed before WG adoption. Dime Chairs ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Mar 26 09:22:35 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790E21A875D for ; Thu, 26 Mar 2015 09:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttxhvebolGmy for ; Thu, 26 Mar 2015 09:22:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9E91A8799 for ; Thu, 26 Mar 2015 09:22:19 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 22CBE18C2AC; Thu, 26 Mar 2015 17:22:18 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 973DC4C06D; Thu, 26 Mar 2015 17:22:17 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Thu, 26 Mar 2015 17:22:17 +0100 From: To: "saag@ietf.org" Thread-Topic: IETF92: RADEXT WG session report Thread-Index: AdBn4QVq53CV7wdARcOSFK/pcRhA2g== Date: Thu, 26 Mar 2015 16:22:16 +0000 Message-ID: <12478_1427386938_5514323A_12478_9875_1_6B7134B31289DC4FAF731D844122B36EEAF5A5@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.26.135421 Archived-At: Cc: "radext-chairs@tools.ietf.org" Subject: [saag] IETF92: RADEXT WG session report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 16:22:34 -0000 We meet on Monday afternoon. About 15 people in the room but unfortunately = key participants were not present in the room due to personal constraints. = As a consequence, the meeting was not so lively as usual and was shorter th= an expected (less than 1h). About WG documents: * Network Access Identifier (RFC 4282bis - draft-ietf-radext-nai-15) and R= ADIUS packets fragmentation (draft-ietf-radext-radius-fragmentation-12) hav= e successfully passed the IESG evalution and are ready for publication. * NAI-based Dynamic Peer Discover (draft-ietf-radext-dynamic-discovery-13) = has completed the IETF LC and is waiting for expert review before IANA allo= cation. Two WGLC will be launched right after the IETF week: * Larger Packets for RADIUS over TCP (draft-ietf-radext-bigger-packets-03) * IP Port Configuration and Reporting (draft-ietf-radext-ip-port-radius-ext= -03) 3 new WG documents have been adopted (to be confirmed on the mailing list): * Dynamic Authorization Proxying (draft-dekok-radext-coa-proxy-00) as candi= date Standards Track RFC. This document gives guidance on how to proxy CoA = messages defined in RFC5176. * Correct use of EAP-Response/Identity (draft-winter-radext-populating-eapi= dentity-01) as candidate BCP. It provides recommendations for implementers = of EAP peers regarding the type of EAP identities to use in EAP messages. * RADIUS Data Types (draft-dekok-radext-datatypes-05) as informational RFC.= This document clarifies the use of data type in RADIUS and defines an IANA= registry for the data types that was omitted when specifying RADIUS (RFC28= 65) We've discussed the errata on RFC 5176 and the WG agreed on the proposed st= atus (Verified). This was also confirmed on the mailing list. Finally, the WG charter has been discussed. A new charter is required as th= e current one is quite obsolete. A proposed text has been submitted on the = mailing list and needs to be commented. RADEXT chairs. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Mar 26 09:24:31 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C33D1A87EB for ; Thu, 26 Mar 2015 09:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2qX7h8rHvCi for ; Thu, 26 Mar 2015 09:24:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3DA21A87D9 for ; Thu, 26 Mar 2015 09:24:27 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 8439D374293; Thu, 26 Mar 2015 17:24:26 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 6180A158094; Thu, 26 Mar 2015 17:24:26 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Thu, 26 Mar 2015 17:24:26 +0100 From: To: "saag@ietf.org" Thread-Topic: Request for guidance regarding E2E security over Diameter Thread-Index: AdBn4UO6eeHIiYWPTtOuFgAIOEZrZA== Date: Thu, 26 Mar 2015 16:24:25 +0000 Message-ID: <26716_1427387066_551432BA_26716_9790_2_6B7134B31289DC4FAF731D844122B36EEAF5B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.26.135421 Archived-At: Cc: "dime-chairs@tools.ietf.org" Subject: [saag] Request for guidance regarding E2E security over Diameter X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 16:24:29 -0000 Hi, As currently specified, the Diameter Base protocol (RFC6733) only offers tr= ansport level protection between neighboring Diameter peers, using either T= LS/TCP, DTLS/SCTP, or IPsec as last resort. However, no mechanism has been = defined to ensure E2E security for data (in the conveyed (in the form of At= tribute-Value Pairs (AVPs)) in Diameter messages between two endpoints. Ear= ly 2000, at the beginning of the work on Diameter, CMS (Cryptographic Messa= ge Syntax) was identified as solution to provide AVP-level E2E security but= this work was not completed due to lack of deployment interest (at least a= t that time) and the foreseen complexity of the developed solution for Diam= eter. Due to the renewed interest for E2E security over Diameter, mainly for inte= r-domain signaling in the mobile network environment, the DIME WG has decid= ed to reactivate the work on E2E security for Diameter. The first step is a= lmost completed, with a document (draft-ietf-dime-e2e-sec-req-02) defining = the requirements for an AVP-level E2E security solution. The second step wi= ll be work on the specification of such mechanism. An early proposal was to= derive a solution from JOSE, encapsulating JOSE objects for integrity prot= ection and AVP encryption. It is however expected that other mechanisms cou= ld be proposed as candidate solutions. And we know already that there are e= xisting discussions on alternative to JOSE (e.g. COSE). Whatever the proposed solution(s),the DIME WG has not (and will not have) t= he expertise required to evaluate and select the more appropriate security = mechanism for E2E security over Diameter. We are therefore interested by an= y guidance and support from SAAG regarding the development of a solution fo= r E2E security over Diameter, based on the requirements collected in draft-= ietf-dime-e2e-sec-req-02. Regards, Lionel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Mar 26 09:34:37 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FCC1A88E1 for ; Thu, 26 Mar 2015 09:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADDz13bcrJi7 for ; Thu, 26 Mar 2015 09:34:33 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (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 62ACC1A8857 for ; Thu, 26 Mar 2015 09:34:33 -0700 (PDT) Received: by qgep97 with SMTP id p97so104956338qge.1 for ; Thu, 26 Mar 2015 09:34:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=sijoctvLCGgS6CZ2Gtvuwf6B3CLjBSvoDzsrja9v1QQ=; b=AY7IWm7OkV0gGdz9wMFwFqluULl0i3KcSGG7KPzbWdAZjysJwcVB4XG8ZZAPMK0JRN lUqjDIp3G3pzuPn+yC3nYrJmR007hhRZjXS2aIRg9WnxmGfzmr6ZcwrDR+Wl4lTTMBxQ K1Me29jzfyKdnTS/oFnGPgzP3ALJ4nWZwvsff/kI7soECJCZyc+4rqMIjS6OX/zXfWGp y32NVssqMw5jEnor15tItadziRj2G7RMRYPXPCcgHcoK/OKO08aj5bFFigPwjG3fEFwP lsgb1fi44i5ImohGr/m8siHxm1aNh756ZAqeYX20eGNGsKEvx5ZLerXjM4fXnmK+/BHn GKxQ== X-Gm-Message-State: ALoCoQna9DJJimS1OIaAD6EqFYDHa22zF+2K7mCX11Wu1EtkWwMcjGfh1lNRpwD8poggIda1FxEV MIME-Version: 1.0 X-Received: by 10.55.24.157 with SMTP id 29mr30842759qky.83.1427387667290; Thu, 26 Mar 2015 09:34:27 -0700 (PDT) Received: by 10.96.121.104 with HTTP; Thu, 26 Mar 2015 09:34:27 -0700 (PDT) X-Originating-IP: [2001:67c:370:176:80f4:9c35:2e3c:c628] Date: Thu, 26 Mar 2015 11:34:27 -0500 Message-ID: From: Joseph Salowey To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=001a113b9232ddd20e0512339656 Archived-At: Subject: [saag] IETF-92 TLS working group summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 16:34:34 -0000 --001a113b9232ddd20e0512339656 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable IETF-92 TLS - Thursday 9AM Agreement on accepting pull request 107 for handling TLS version. Discussion on 0-RTT handshake. The data sent by client under 0-RTT is vulnerable to replay and lacks PFS. There was consensus to add 0-RTT to TLS 1.3, however this needs to be confirmed on the list. The impact of 0-RTT on applications and other uses needs to be evaluated. There is continued investigation on the behavior of TLS with respect to replayable data. There was consensus to move to a DH based handshake based on an online signing version of Hugo Krawczyk=E2=80=99s OPTLS with some optimizations. = This needs to be confirmed on the list. There was consensus to move to an HKDF based key derivation function. This needs to be confirmed on the list. There was consensus for AEAD IV to use record sequence number and pad with 0=E2=80=99s as described in the interim. This needs to be confirmed on the= list. --001a113b9232ddd20e0512339656 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

IETF-92 TLS = - Thursday 9AM=C2=A0


Agreement on accepting pull r= equest 107 for handling TLS version.=C2=A0


Discussion on 0-RTT handshake= .=C2=A0 The data sent by client under 0-RTT is vulnerable to replay and lac= ks PFS.=C2=A0 There was consensus to add 0-RTT to TLS 1.3, however this nee= ds to be confirmed on the list. =C2=A0 The impact of 0-RTT on applications = and other uses needs to be evaluated.=C2=A0 There is continued investigatio= n on the behavior of TLS with respect to replayable data.


There was consensus to move t= o a DH based handshake based on an online signing version of Hugo Krawczyk= =E2=80=99s OPTLS with some optimizations.=C2=A0 This needs to be confirmed = on the list.


There was consensus to move t= o an HKDF based key derivation function.=C2=A0 This needs to be confirmed o= n the list.


There was consensus for AEAD = IV to use record sequence number and pad with 0=E2=80=99s as described in t= he interim.=C2=A0 This needs to be confirmed on the list.

--001a113b9232ddd20e0512339656-- From nobody Thu Mar 26 10:27:42 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98CC1A8754 for ; Thu, 26 Mar 2015 10:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDd9H6_FnWPI for ; Thu, 26 Mar 2015 10:27:40 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA7C1A6EF0 for ; Thu, 26 Mar 2015 10:27:39 -0700 (PDT) Received: from [192.168.10.151] ([31.133.152.120]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MAloF-1Yn3PG1EfD-00Bvo5 for ; Thu, 26 Mar 2015 18:27:38 +0100 Message-ID: <55144186.6040600@gmx.net> Date: Thu, 26 Mar 2015 18:27:34 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: saag OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mgErdc7b9UgCoHM08PBolt4A34d6WKWlM" X-Provags-ID: V03:K0:AwBQ5wcO0R70t+DAT8HnM/VCRKVy4e7ehEXfu+rm3EsqJDGEvwW oN/Pc4fkPDy3+QaNVatIgHmw+fd96f3Dh8UZ/YFytTLBd8vmAAS9fSIS7KgLB8xqarNNcH9 BV/h1KeelRUxl/MpFFfw+lM5fy349j/4O8xCf9zKF4PnxbLc5EfF/f4KiyClb3noZ13WWXA fDOQEdfRSY/epcWgBo7lw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [saag] OAuth Summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 17:27:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mgErdc7b9UgCoHM08PBolt4A34d6WKWlM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable We started the OAuth meeting with a discussion about the current status. The group is making good progress. * Four documents are currently in the RFC Editor Queue, namely the OAuth assertion framework, JWT Bearer Assertions, SAML Bearer Assertions and the JSON Web Token (JWT). * Two documents are currently in IETF processing, namely the Dynamic Client Registration and the Dynamic Client Registration Management protocols. * Three other documents are about to be sent to the IESG any day now, namely token introspection, the proof-of-possession architecture and the Proof Key for Code Exchange. The main part of the meeting was spent on the discussion of the proof-of-possession solution components, namely draft-ietf- oauth-signed-http-request, draft-ietf-oauth-pop-key- distribution, and draft-ietf-oauth-proof-of-possession. A design question regarding the support of proof-of-possession support for refresh tokens was raised during the meeting and further analysis is needed to resolve the issue. Two new documents have been presented to the audience, namely * JWT Destination Claim: draft-campbell-oauth-dst4jwt, and * Open Redirector: draft-bradley-oauth-open-redirector The security problems (based on actual attacks) described in the Open Redirector document raised the question about the best way to offer security guidance in the OAuth WG. A few participants from the working group met Wednesday evening to discuss next steps regarding the token exchange specification. --mgErdc7b9UgCoHM08PBolt4A34d6WKWlM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVFEGGAAoJEGhJURNOOiAteSsH/10DDmQkvoqqs5UPevWJsL1H liVxKLUrJvWWCvg1P9qKA0PiP0zb+2cjGqHyHbkArrHkTqSo8R+PC62u+wi1h47m NWVx2/wqBtgdQl+4wb6H5fNJIF7ls5C9+52kcX573wxDJJisxte84ylHkhLxGNfT YjPUDj3xHvoy1YaJl+Kf2RBVofUH2K9SUeObWfFxhI6grBZe0UT9Wpfe8bcWhKXR QPUz/A9b1sBZnXYZ/OFfZ7lbO4Z7/feDf61kncIlDpa54L9/8823q78aExbTbVPZ kvL/ZbtI2/50VimYAchPdGiM9/xCGbOcTH0bAamTgB3wOoAdQ/sC4W6OAoAA7B8= =qYAi -----END PGP SIGNATURE----- --mgErdc7b9UgCoHM08PBolt4A34d6WKWlM-- From nobody Thu Mar 26 11:03:56 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5180B1B29DD for ; Thu, 26 Mar 2015 11:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.967 X-Spam-Level: X-Spam-Status: No, score=-98.967 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEROzyY2rZvH for ; Thu, 26 Mar 2015 11:03:54 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id B0A751B29DB for ; Thu, 26 Mar 2015 11:03:41 -0700 (PDT) Received: (qmail 28070 invoked by uid 0); 26 Mar 2015 18:03:41 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy9.mail.unifiedlayer.com with SMTP; 26 Mar 2015 18:03:41 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id 8J3X1q00v2UhLwi01J3aCP; Thu, 26 Mar 2015 12:03:39 -0600 X-Authority-Analysis: v=2.1 cv=XvNpZz19 c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=XuYyiiJQKFMA:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=G3-J1MMgUXwA:10 a=emO1SXQWCLwA:10 a=7r5c9JmHAAAA:8 a=eRkPymCFHZVbseC4NfEA:9 a=izWC5V0wSuYzam1e:21 a=qXOoT5cgDQi8emBl:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=9NFZjCRF/EsWhlpZ3r0T2bqu9FfYo6TMXFikFvgR9us=; b=3VlLXc/+MIpNbsX4QNXJarjMQy3UeKkrxN8g2I5Rj+yf/8nsgdds8vMZepyUuzLg6kBYCouYdbt9AvQjqs3reAxyqq8yyTHzmMDGMWytQ6EROYLjij3uXOO5de8D4Cf6; Received: from [31.133.128.60] (port=46380) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YbC7x-0002RG-I0 for saag@ietf.org; Thu, 26 Mar 2015 12:03:33 -0600 Message-ID: <551449ED.5010804@KingsMountain.com> Date: Thu, 26 Mar 2015 11:03:25 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: IETF Security Area Advisory Group Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 31.133.128.60 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: [saag] fyi: FBI Director Warns How Encryption Will Lead To Tears X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 18:03:55 -0000 FBI Quietly Removes Recommendation To Encrypt Your Phone... As FBI Direct= or=20 Warns How Encryption Will Lead To Tears from the keeping-you-safe...-or-keeping-you-vulnerable dept: Back in October, we highlighted the contradiction of FBI Director James=20 Comey raging against encryption and demanding backdoors, while at the ver= y=20 same time the FBI's own website was suggesting mobile encryption as a way= to=20 stay safe. Sometime after that post went online, all of the information o= n=20 that page about staying safe magically disappeared, though thankfully I=20 screenshotted it at the time: =EF=BF=BC If you really want, you can still see that information over at the Intern= et=20 Archive or in a separate press release the FBI apparently didn't track do= wn=20 and memory hole yet. Still, it's no surprise that the FBI quietly deleted= =20 that original page recommending that you encrypt your phones "to protect = the=20 user's personal data," because the big boss man is going around spreading= a=20 bunch of scare stories about how we're all going to be dead or crying if = people actually encrypted their phones: Calling the use of encrypted phones and computers a =E2=80=9Chuge problem= =E2=80=9D and an=20 affront to the =E2=80=9Crule of law,=E2=80=9D Comey, painted an apocalypt= ic picture of the=20 world if the communications technology isn=E2=80=99t banned. =E2=80=9CWe=E2=80=99re drifting to a place where a whole lot of people ar= e going to look at=20 us with tears in their eyes,=E2=80=9D he told the House Appropriations Co= mmittee,=20 describing a hypothetical in which a kidnapped young girl=E2=80=99s phone= is=20 discovered but can=E2=80=99t be unlocked. So, until recently, the FBI was actively recommending you encrypt your da= ta=20 to protect your safety -- and yet, today it's "an affront to the rule of = law." Is this guy serious? More directly, this should raise serious questions about what Comey think= s=20 his role is at the FBI (or the FBI's role is for the country)? Is it to k= eep=20 Americans safe -- or is it to undermine their privacy and security just s= o=20 it can spy on everyone? Not surprisingly, Comey pulls out the trifecta of FUD in trying to explai= n=20 why it needs to spy on everyone: pedophiles, kidnappers and drug dealers:= =E2=80=9CTech execs say privacy should be the paramount virtue,=E2=80=9D = Comey continued,=20 =E2=80=9CWhen I hear that I close my eyes and say try to image what the w= orld looks=20 like where pedophiles can=E2=80=99t be seen, kidnapper can=E2=80=99t be s= een, drug dealers=20 can=E2=80=99t be seen.=E2=80=9D Except we know exactly what that looks like -- because that's the world=20 we've basically always lived with. And yet, law enforcement folks like th= e=20 FBI and various police departments were able to use basic detective work = to=20 track down criminals. If you want to understand just how ridiculous Comey's arguments are, simp= ly=20 replace his desire for unencrypted devices with video cameras in every=20 corner of your home that stream directly into the FBI. Same thing. Would = that make it easier for the FBI to solve some crimes? Undoubtedly. Would = it=20 be a massive violation of privacy and put many more people at risk? Absol= utely. It's as if Comey has absolutely no concept of a cost-benefit analysis. Al= l=20 "bad people" must be stopped, even if it means destroying all of our=20 freedoms, based on what he has to say. That's insane -- and raises seriou= s=20 questions about his competence to lead a government agency charged with=20 protecting the Constitution. end From nobody Thu Mar 26 11:18:40 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2D61A90BE for ; Thu, 26 Mar 2015 11:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Pp28jzGHCpQ for ; Thu, 26 Mar 2015 11:18:36 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0675.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::675]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19351A90B1 for ; Thu, 26 Mar 2015 11:18:35 -0700 (PDT) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) with Microsoft SMTP Server (TLS) id 15.1.118.21; Thu, 26 Mar 2015 18:18:19 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.01.0118.022; Thu, 26 Mar 2015 18:18:19 +0000 From: "Paterson, Kenny" To: "saag@ietf.org" Thread-Topic: report for CFRG from IETF 92 Thread-Index: AQHQZ/E8evnVeY+eq0eFO6NhWOdkwg== Date: Thu, 26 Mar 2015 18:18:19 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.153.109] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB384; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(2501003)(62966003)(77156002)(450100001)(77096005)(102836002)(106116001)(15975445007)(66066001)(36756003)(54356999)(107886001)(2900100001)(50986999)(83506001)(87936001)(86362001)(19580395003)(46102003)(2656002)(74482002)(110136001)(92566002)(2351001)(122556002)(40100003)(229853001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB384; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DBXPR03MB384; BCL:0; PCL:0; RULEID:; SRVR:DBXPR03MB384; x-forefront-prvs: 0527DFA348 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2015 18:18:19.3774 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB384 Archived-At: Subject: [saag] report for CFRG from IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 18:18:38 -0000 CFRG met on Wednesday afternoon. The meeting was well-attended. We had presentations and discussions on 4 distinct topics: - progress and next steps on the ECC work for TLS (https://tools.ietf.org/html/draft-irtf-cfrg-curves-01) - an update on scrypt (https://tools.ietf.org/html/draft-josefsson-scrypt-kdf-02) - hash based signatures (https://tools.ietf.org/html/draft-huelsing-cfrg-hash-sig-xmss-00) - an update on a PAKE requirements document and presentations on two specific PAKE protocols (https://datatracker.ietf.org/doc/draft-irtf-cfrg-augpake/, http://www.ietf.org/staging/draft-liu-sipcore-ec-srp-00.txt) -- Kenny, for the chairs. From nobody Thu Mar 26 11:28:45 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72B71AC3D7 for ; Thu, 26 Mar 2015 11:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKs2StpkOrS8 for ; Thu, 26 Mar 2015 11:28:41 -0700 (PDT) Received: from smtp72.iad3a.emailsrvr.com (smtp72.iad3a.emailsrvr.com [173.203.187.72]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E5C1ACC8B for ; Thu, 26 Mar 2015 11:28:12 -0700 (PDT) Received: from smtp26.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DC3D78054C; Thu, 26 Mar 2015 14:28:11 -0400 (EDT) Received: by smtp26.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 93AE680520; Thu, 26 Mar 2015 14:28:11 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from dhcp-b661.meeting.ietf.org (dhcp-b661.meeting.ietf.org [31.133.182.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Thu, 26 Mar 2015 18:28:11 GMT From: Olafur Gudmundsson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Mar 2015 14:28:11 -0400 Message-Id: <8DDBE6CE-7D3A-48AF-B773-21CAACE5687D@ogud.com> To: saag@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "" Subject: [saag] DANE summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 18:28:42 -0000 DANE had a one hour meeting.=20 doc-status:=20 - 2 WG documents advanced to IESG DANE-SMTP DANE-SRV - 1 document in WGLC OPENPGPKEY=20 - 2 documents pending a WGLC RSN.=20 We had discussion about a document that are proposing new things that = use dane for payment systems.=20 Most of the WG time was spent on a issue raised during the WGLC on = OPENPGPKEY document.=20 The discovery/search of actual email address of the receiver. This is an = old problem that affects all e-mail. We had a fruitful discussion with number of e-mail people providing = information and thoughts.=20 The sense of the room is that this is a big problem but not one that = DANE should be addressing.=20 The group will take under advisement how to focus the document to = express that the approach in the=20 document is Opportunistic, i.e. sender looks up the address it has and = does no other search. DANE has another document that is about OPENPGPKEY-USAGE document and = will have some description on=20 how to improve the probability of finding a OPENPGPKEY record.=20 The working group is updating its milestones, thus right now is a good = time submit new work for consideration.=20 Olafur for chairs From nobody Thu Mar 26 12:59:57 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB18A1B2B30 for ; Thu, 26 Mar 2015 12:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnoyE6j4A1Cb for ; Thu, 26 Mar 2015 12:59:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3174B1B2AC2 for ; Thu, 26 Mar 2015 12:59:51 -0700 (PDT) Received: from [192.168.10.152] ([31.133.152.120]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MOOJl-1YW0jx2BCH-005pIi for ; Thu, 26 Mar 2015 20:59:48 +0100 Message-ID: <55146532.2060209@gmx.net> Date: Thu, 26 Mar 2015 20:59:46 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: saag OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5V5akCa2IRSNu40elwillTpcaIxLb0gER" X-Provags-ID: V03:K0:8du6XyLLXdCdW3+iddcQ4PnNkErfOG+KASQd7yf17NUVhWYI2Zs bK1Mnj16RR44jd4rHbF8xGUFrWsQxUDdRfc8ajcNMKs26ebzx52nsbQ+5LNm8H0uBWjimm+ rlOICgwxVXeQnTL4yszO7db2ZBJBzVj//lYeLRa6d5fFoNalKx4z3NwbCNBtLIon/vYuCxg T902lHQiC1jEcK8/W0jpg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [saag] Notes from SAAG meeting today X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:59:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5V5akCa2IRSNu40elwillTpcaIxLb0gER Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable IETF-92 SAAG Meeting initial Agenda (120 mins) 1. WG/BoF/side meeting reports (10 mins) See mails sent to the SAAG mailing list. TLS VPN side meeting happened to understand what those are. Mailing list will be requested. Security discussion about IoT/6LO (Pavilion) scheduled for today (in the evening). Presentation about draft-mm-wg-effect-encrypt and soliciting input/feedback. 2. Invited/offered talks 2.1 Joe Bonneau/HSTS and HPKP in practice (30 mins) Chrome also supports HSTSP but it has not been turned on. Firefox supports it already since a few versions. How to pre-load into Chrome? Enter the data into https://hstspreload.appspot.com Firefox: Talk to Richard Barnes You have to have multiple pins (for redundant) for HPKP. Cryptocat managed to brick themselves end of last year by changing the certificate without updating the pre-loaded pins. Ekr: How many sides out of the 1 M domains from Alexa are using HTTPS? Joseph: Probably 30%. Don't remember. Out of these 30%, 1.1% use HSTS. Jeff: The details are in the paper. Yoav: Is there a tool to test HSTS? Joseph: Not that I know. Student wanted to write something but then didn't got to-do it. Jeff: SSL-Labs they test various SSL/TLS features and they also test HSTS. We could work with them to do more tests. =09 Richard: Active mixed content may be due to lack of support for HTTPS at content distribution networks. Joseph: Yes and scripts from ad networks. PHB: Concerned about two different registries. The info should be in the DNS. I proposed to have a harmonized format (in CAA record). Joseph: There has not been a momentum to align the different proposals. Joseph: I would suggest to per-default include sub domains. The secure attribute for cookies could be re-interpreted as well. Jeff: Thank you for doing this. Too often there are no such survey data. It is great to have that data. In terms of the pre-load list. The UI gets you into Chrome's list but those new requirements where added by the Firefox guys but that only gets you into additional browser lists. Adam: The list is also being populated into other browsers. Jeff: This is all ad-hoc. There might be a way to more formalize. In terms of sub-domains I have to go back and count the number of mails on that subject. The people in the room designing HSTS where browser vendors and relying parties we thought it would be dangerous to include subdomains when they are populated down the sub-domains. It is not clear which is the better way. Mark: Thanks for gathering this data. I appreciate the message on the last slide regarding developer testing. I am worried about the low adoption rate. We need to make them more comprehensible. DKG: Thanks for doing the work. I think we got the interaction with the different specifications wrong and we have to keep this in mind for future work. 2.3 Adam Langley/QUIC (15 mins) =09 Ekr: Thinking about harmonizing the cookie exchange between DTLS/TLS. Adam: We are meeting with the QUIC folks tonight. Paul: Have you given the same presentation in TSVWG. Adam: No. Paul: You may want to talk to the TSVWG about QUIC to make them less worried. ?: There was a presentation some time ago Wes: Thanks for pushing the boundaries. One question about the deployment: you talk about it being used today in Google/Chrome. Adam: Users would not notice. Wes: I am worried about that. You are lying to the users since they don't get HTTPS but rather something else. Adam: That would be a concern if the security concerns are less. Wes: It has not gotten the same level of review. I am not sure that's tru= e. Allison: TCPINC is the place where these types of things should be discussed. A question: Is there crypto-agility in your proposal? Adam: It is exactly the same as in TLS since we use the same certs. Mark: The semantics of the HTTPS URI schemes are not bound to TLS. Ekr: When we do TLS 1.3 we make experiments as well. 2.4 Jan V=C4=8Del=C3=A1k/Authenticated Denial of Existence in DNSSEC (NS= EC5) (10 mins) =09 Adam: When the zone is signed offline then you are creating NSEC5 records. Does the DNS server need to have these keys online? Jan: Yes. The keys are online. ?: I like the technology but I don't think it will be Message files are a much bigger issue. Your paper don't support ECC. Jan: We require deterministic signatures. If we use ECDSA then for one name and one key there may be more than one signature. Some years we were told that we need to support NSEC3. Given that everything in DNSSEC is moving forward very slowly I think we should just deploy DNSSEC instead of playing around with it. Joseph: We worked on this topic as well. There is an ECC way to do it. We went through the same problem and there is a way to do it but it is a bit messy. 2.5 Ladar Levinson/Darkmail (20 mins) =09 Jeff: I got a bit lost. I have a software I downloaded and I wanted to send you a message. I have not contacted you before. Ladar: You would type in the email address. The client would query the DNS for a record. Once it has the record it has the signing key for that domain. Then, you contact that organizational domain. Subsequently, you query the users signet and use the public key to encrypt the message with that key. Adam: Why did you choose two different curves? Ladar: I wanted different curves for signing and encryption. Ladar: Is the ChaCha TLS ciphersuite ever going to become a standard? Sean: We are starting a working group adoption of the ChaCha TLS ciphersuite. Adam: Signatures are designed to provide integrity and authenticity but not confidentiality. Ladar: The signatures are inside the encrypted part of the message. BarBOF happening this evening. Adam: You asked for tree signatures. Merkle tree signatures are totally fine. 2.6 Paul Wouters/Opportunistic IPsec update (1 minute) Paul pointed to the oe.libreswan.org. 2.7 Eric Rescorla/Secure Conferencing (5 mins) Adam: Does the key server know the key? Ekr: Yes. Adam: It does not need to be. DKG: Happy to talk to you afterwards. 3. Open-mic, ~30 Joe: Question about the QUIC talk. The information shown to the user needs to correct. Adam: It says QUIC. QUIC started with formal analysis of the crypto Wes: My concern was not that there are many failures with TLS. The HTTPS and the URI specification says that it is TLS. I am not saying it is bad todo experimented but I want to know whether I am experimented on. Adam: We cannot change the URI scheme. We also cannot change the icon either. Wes: I understand the need for experimentation. Adam: We are not going to deploy another URI scheme again. Paul: We could solve this using a pop-up, for example when downloading ?: Haven't there been a experiments with the lock icon? Adam: We are experimenting with you all the time, for example, when switching to ChaCha. Ekr: There are three things: URI scheme, a lock icon and then the crypto.= Jeff: This is a layer 9 problem. You agree to it when you download the browser. --5V5akCa2IRSNu40elwillTpcaIxLb0gER Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVFGUyAAoJEGhJURNOOiAt3cQH/iTbGWRBeo2rCBlFeWoMtZ1s rPOqwT4Q2BNy56FHjF9g8uw9v+VnS8rARNxee3+CuQK/R8CjR/VYTuyYuEtpJBI7 vtJQEn5oWWIseqkeKuFXM0baf9mVv0UMbivKvfi/N7Midc5N7qjF8vvgwwH3OrYD goWoOFLnkX8RMFdBNZzmMyHPXXb15Bjc1K/a5jphIwlG0VVJxQBZvhJxlniSRLd3 4Zu/Aj9YwnKLruYLKaMNalIkYPXvWc2nbD5f/wsj/ovXtupXEICWlorumd/YQtZz zYpfqJEJjyclxnrRYdPFTabizwykyOlOdCL/378oo0uSvQ9ei5Cqd3Q12LNCnbA= =wXR3 -----END PGP SIGNATURE----- --5V5akCa2IRSNu40elwillTpcaIxLb0gER-- From nobody Thu Mar 26 15:14:08 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970C91A00EC for ; Thu, 26 Mar 2015 15:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RM8fLPmwQNlQ for ; Thu, 26 Mar 2015 15:14:05 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (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 7C9C41A00F8 for ; Thu, 26 Mar 2015 15:14:00 -0700 (PDT) Received: by lbbxe10 with SMTP id xe10so91541lbb.2 for ; Thu, 26 Mar 2015 15:13:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=JpJwQ7EWRnVgX025yMmNsmy+DgDHBk7zyk8jlwjOPT4=; b=CZTJLZd7u+2ym8wj89/aYhfbQ7nB66D976rvHV2yKxttACkMpvPYjaQ0+JMva9pz1h Jt/ZgghFyssfamMBR6fHFqzy9moUcDAOPxiHsxRC/RASr1iMBIg+by+qo3Ksl2qlfYfJ bnO3IdWiYqrkrqok515H/Hn4mWXX7Dq9WUfEZHlVWAWPL+JtW6v3EMRJDq+H2NbKNOsX iktux+611Ex200lTXy70xaJHtl+nGMjJZk+GNTY29hiu8tX6Ynq/tDE4F+NhVbzxzJng H0wCKaZ92h2yXgFei0wLI15evyyh7Pn7B2YdSeJfU48VU7trEc5Ki7Sz39eHDTbQwoK9 vq/w== X-Gm-Message-State: ALoCoQliT02W+f7TPMEe8NStDtvreh7m/5yX/9SLH96ZWhhc+blVQ9UQ2iGJ8yOyEJS2nXEbZ1rF X-Received: by 10.112.17.36 with SMTP id l4mr10352893lbd.123.1427408039022; Thu, 26 Mar 2015 15:13:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.37.4 with HTTP; Thu, 26 Mar 2015 15:13:38 -0700 (PDT) In-Reply-To: <4B3D2CEE-BEB9-4BD3-A305-E1D79F8C5FD3@gmail.com> References: <4B3D2CEE-BEB9-4BD3-A305-E1D79F8C5FD3@gmail.com> From: Joseph Lorenzo Hall Date: Thu, 26 Mar 2015 17:13:38 -0500 Message-ID: To: Kathleen Moriarty Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: saag@ietf.org, Wes George Subject: Re: [saag] Fwd: ubiquitous encryption draft feedback X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 22:14:06 -0000 (this was Kathleen forwarding Wes' feedback quoted here) > Liability =E2=80=93 I realize that IETF does not trade in legal advice, s= o this > would have to be caveated pretty heavily, but I think it's a worthwhile p= art > of the discussion since it's a direct result of a specific set of technic= al > actions and should be weighed when considering whether the ends justify t= he > means. > > Duty to take action =E2=80=93 encrypted traffic (or unencrypted traffic t= hat is not > subject to DPI) comes with a hidden benefit for the SPs who carry it- > plausible deniability. If a service provider or enterprise is decrypting > traffic with intent to inspect it, whether with or without its users' > knowledge, it can be argued that it is responsible for the traffic's cont= ent > such that it is required to take action on content or activities that are > banned by policy or law, including enforcing copyright, preventing > exploitation of children, threats of violence, reporting potential > violations to the proper authorities, etc. An SP must be ready to take > responsibility for traffic that flows across its network if it chooses to > inspect it. Heya, as one of the resident policy wonks at IETF I should point out that the above certainly isn't the case in the US, where intermediaries generally have broad immunity from liability for hosting or transmitting third-party content.* As for the rest of the world, a recent and great UNESCO report by Rebecca MacKinnon et al. summarizes the landscape by describing three regimes: strict liability like in China and Thailand where even ignorance is no excuse, conditional liability where upon receiving notice the content has to be blocked or the intermediary risks a lawsuit, etc., and broad immunity such as the case in the US. I'll stop typing now as I doubt anyone on the SAAG list is as deep into this stuff as we are at CDT... here's the report, you can start reading a few pages around PDF p. 40: http://unesdoc.unesco.org/images/0023/002311/231162e.pdf All this is saying that I doubt a duty to monitor is a strong argument here since nothing much exists like that now (and even in the strict liability cases, which are few, you don't get much by monitoring over other things like denying access at the onset). best, Joe * (Content hosts are required to report instances of child sexual abuse imagery to the National Center for Missing and Exploited Children (NCMEC) when they become aware of them, and to retain some data about the image, but otherwise intermediaries typically don't have a legal obligation to take action even when they become aware of potentially unlawful content. The DMCA provides protection from potential secondary copyright liability -- if the content host takes down an allegedly infringing file upon notice from a rightsholder, it can't be sued as having contributed to that infringement. But technically an intermediary could ignore a DMCA demand and try its luck in the courts.) --=20 Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 joe@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 From nobody Thu Mar 26 15:58:40 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBD81A1B1F for ; Thu, 26 Mar 2015 15:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6r8MFBG39gP1 for ; Thu, 26 Mar 2015 15:58:34 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D87D1A1B27 for ; Thu, 26 Mar 2015 15:58:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5112ABEE7; Thu, 26 Mar 2015 22:58:29 +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 jVuf1I7W9jK4; Thu, 26 Mar 2015 22:58:27 +0000 (GMT) Received: from [31.133.180.113] (dhcp-b471.meeting.ietf.org [31.133.180.113]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C5AB0BE83; Thu, 26 Mar 2015 22:58:26 +0000 (GMT) Message-ID: <55148F0C.3070603@cs.tcd.ie> Date: Thu, 26 Mar 2015 22:58:20 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Hannes Tschofenig , saag References: <55146532.2060209@gmx.net> In-Reply-To: <55146532.2060209@gmx.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [saag] Notes from SAAG meeting today X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 22:58:38 -0000 Thanks Hannes. And also thanks to Mike Jones for notes and to PHB for watching the jabber room S. On 26/03/15 19:59, Hannes Tschofenig wrote: > IETF-92 SAAG Meeting initial Agenda (120 mins) > > 1. WG/BoF/side meeting reports (10 mins) > > See mails sent to the SAAG mailing list. > > TLS VPN side meeting happened to understand what those are. Mailing list > will be requested. > Security discussion about IoT/6LO (Pavilion) scheduled for today (in the > evening). > > Presentation about draft-mm-wg-effect-encrypt and soliciting > input/feedback. > > 2. Invited/offered talks > 2.1 Joe Bonneau/HSTS and HPKP in practice (30 mins) > > Chrome also supports HSTSP but it has not been turned on. Firefox > supports it already since a few versions. > > How to pre-load into Chrome? Enter the data into > https://hstspreload.appspot.com > Firefox: Talk to Richard Barnes > > You have to have multiple pins (for redundant) for HPKP. > > Cryptocat managed to brick themselves end of last year by changing the > certificate without updating the pre-loaded pins. > > Ekr: How many sides out of the 1 M domains from Alexa are using HTTPS? > Joseph: Probably 30%. Don't remember. Out of these 30%, 1.1% use HSTS. > Jeff: The details are in the paper. > > Yoav: Is there a tool to test HSTS? > Joseph: Not that I know. Student wanted to write something but then > didn't got to-do it. > > Jeff: SSL-Labs they test various SSL/TLS features and they also test > HSTS. We could work with them to do more tests. > > Richard: Active mixed content may be due to lack of support for HTTPS at > content distribution networks. > Joseph: Yes and scripts from ad networks. > > PHB: Concerned about two different registries. The info should be in the > DNS. I proposed to have a harmonized format (in CAA record). > Joseph: There has not been a momentum to align the different proposals. > > Joseph: I would suggest to per-default include sub domains. The secure > attribute for cookies could be re-interpreted as well. > Jeff: Thank you for doing this. Too often there are no such survey data. > It is great to have that data. > In terms of the pre-load list. The UI gets you into Chrome's list but > those new requirements where added by the Firefox guys but that only > gets you into additional browser lists. > > Adam: The list is also being populated into other browsers. > Jeff: This is all ad-hoc. There might be a way to more formalize. > In terms of sub-domains I have to go back and count the number of mails > on that subject. The people in the room designing HSTS where browser > vendors and relying parties we thought it would be dangerous to include > subdomains when they are populated down the sub-domains. It is not clear > which is the better way. > > Mark: Thanks for gathering this data. I appreciate the message on the > last slide regarding developer testing. > I am worried about the low adoption rate. We need to make them more > comprehensible. > > DKG: Thanks for doing the work. I think we got the interaction with the > different specifications wrong and we have to keep this in mind for > future work. > > > 2.3 Adam Langley/QUIC (15 mins) > > Ekr: Thinking about harmonizing the cookie exchange between DTLS/TLS. > Adam: We are meeting with the QUIC folks tonight. > > Paul: Have you given the same presentation in TSVWG. > Adam: No. > Paul: You may want to talk to the TSVWG about QUIC to make them less > worried. > > ?: There was a presentation some time ago > > Wes: Thanks for pushing the boundaries. One question about the > deployment: you talk about it being used today in Google/Chrome. > Adam: Users would not notice. > Wes: I am worried about that. You are lying to the users since they > don't get HTTPS but rather something else. > > Adam: That would be a concern if the security concerns are less. > Wes: It has not gotten the same level of review. I am not sure that's true. > > Allison: TCPINC is the place where these types of things should be > discussed. > A question: Is there crypto-agility in your proposal? > > Adam: It is exactly the same as in TLS since we use the same certs. > > Mark: The semantics of the HTTPS URI schemes are not bound to TLS. > Ekr: When we do TLS 1.3 we make experiments as well. > > > 2.4 Jan Včelák/Authenticated Denial of Existence in DNSSEC (NSEC5) (10 > mins) > > Adam: When the zone is signed offline then you are creating NSEC5 > records. Does the DNS server need to have these keys online? > Jan: Yes. The keys are online. > > ?: I like the technology but I don't think it will be > Message files are a much bigger issue. Your paper don't support ECC. > > Jan: We require deterministic signatures. If we use ECDSA then for one > name and one key there may be more than one signature. > > Some years we were told that we need to support NSEC3. Given that > everything in DNSSEC is moving forward very slowly I think we should > just deploy DNSSEC instead of playing around with it. > > Joseph: We worked on this topic as well. There is an ECC way to do it. > We went through the same problem and there is a way to do it but it is a > bit messy. > > 2.5 Ladar Levinson/Darkmail (20 mins) > > Jeff: I got a bit lost. I have a software I downloaded and I wanted to > send you a message. I have not contacted you before. > > Ladar: You would type in the email address. The client would query the > DNS for a record. Once it has the record it has the signing key for that > domain. > Then, you contact that organizational domain. Subsequently, you query > the users signet and use the public key to encrypt the message with that > key. > > Adam: Why did you choose two different curves? > Ladar: I wanted different curves for signing and encryption. > > Ladar: Is the ChaCha TLS ciphersuite ever going to become a standard? > Sean: We are starting a working group adoption of the ChaCha TLS > ciphersuite. > > Adam: Signatures are designed to provide integrity and authenticity but > not confidentiality. > Ladar: The signatures are inside the encrypted part of the message. > > BarBOF happening this evening. > > Adam: You asked for tree signatures. Merkle tree signatures are totally > fine. > > > > > 2.6 Paul Wouters/Opportunistic IPsec update (1 minute) > > Paul pointed to the oe.libreswan.org. > > > > 2.7 Eric Rescorla/Secure Conferencing (5 mins) > > Adam: Does the key server know the key? > Ekr: Yes. > Adam: It does not need to be. > DKG: Happy to talk to you afterwards. > > 3. Open-mic, ~30 > > Joe: Question about the QUIC talk. The information shown to the user > needs to correct. > Adam: It says QUIC. QUIC started with formal analysis of the crypto > > Wes: My concern was not that there are many failures with TLS. The HTTPS > and the URI specification says that it is TLS. > I am not saying it is bad todo experimented but I want to know whether I > am experimented on. > > Adam: We cannot change the URI scheme. We also cannot change the icon > either. > Wes: I understand the need for experimentation. > > Adam: We are not going to deploy another URI scheme again. > > Paul: We could solve this using a pop-up, for example when downloading > > ?: Haven't there been a experiments with the lock icon? > > Adam: We are experimenting with you all the time, for example, when > switching to ChaCha. > > Ekr: There are three things: URI scheme, a lock icon and then the crypto. > > Jeff: This is a layer 9 problem. You agree to it when you download the > browser. > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Fri Mar 27 08:02:00 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884D31A00E7; Tue, 24 Mar 2015 16:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcotKfrZKk_W; Tue, 24 Mar 2015 16:31:38 -0700 (PDT) Received: from out4133-98.mail.aliyun.com (out4133-98.mail.aliyun.com [42.120.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id A36E51A00CD; Tue, 24 Mar 2015 16:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1427239897; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=vkbe5g9xDElfFMUWucfQQSlkAqanckkx80DUEiRUxKY=; b=wBA9vthLoDpxLMhgUwRsgvMMIe9JJlMzRgii+QQhhcbzd0SOnxU9UEZ945o+UuxUEMeZf/4vbXmkclnQqW1nfcbWf5oMJjDc9BxungQsHXoTqykMuU95VQ/JnFXGzFu1RukPHGWjchKv3IBWaZUs3xreRkCpvkZ6lD/+OEWokEo= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R661e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g06010; MF=kepeng.lkp@alibaba-inc.com; PH=DW; RN=3; RT=3; SR=0; Received: from WS-web (kepeng.lkp@alibaba-inc.com[31.133.161.253]) by r41g03017.xy2.aliyun.com at Wed, 25 Mar 2015 07:31:33 +0800 Date: Wed, 25 Mar 2015 07:31:33 +0800 From: "Kepeng Li" To: "saag" , "Ace" Message-ID: <7a940fc9-72a2-4503-a453-f8e2bae9cc51@alibaba-inc.com> X-Mailer: Alimail-Mailagent revision 2687495 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_15072_4a2f1940_5511f3d5_2e58" Archived-At: X-Mailman-Approved-At: Fri, 27 Mar 2015 08:01:59 -0700 Subject: [saag] =?utf-8?q?ACE_Report?= X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Kepeng Li List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 23:31:39 -0000 ------=ALIBOUNDARY_15072_4a2f1940_5511f3d5_2e58 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ACE WG Meeting=0AIETF 92 - Dallas=0ATuesday 24 March 2015, 13:00 - 15:00 CDT=0A= Chairs: Kepeng Li, Hannes Tschofenig=0A=0A* Use Cases (Sandeep S. Kumar)=0A - = No open issues. Next step is to initiate WGLC. Five people volunteered to revi= ew the draft.=0A=0A* Problem Description (Goeran Selander)- The term "Configur= ation Server" needs to be checked.=C2=A0=0A- There was consensus to use proble= m description and terminology as a starting point to work on.=0A=0A* Actors (C= arsten Bormann, 20 mins)=0A - There was preference to reuse OAuth terminologie= s (e.g. Resource Server, Authorization Server).- Action: Design team is reques= ted to merge Problem Description draft and Actors draft, and provide a combine= d draft.=0A=0A* Delegated CoAP Authentication and Authorization Framework (Car= sten Bormann)=0A - No time for the detailed discussion.=C2=A0It is recommended= to provide feedback in the mailing list.=0A=0A* Object Security (Goeran Selan= der)=0A - There was comment that part of the work should be done in CORE.- The= re was comment that it depends on COSE work.- No consensus to adopt it this ti= me. More time is needed.=0A* Use Oauth and UMA (Hannes Tschofenig)=0A - No tim= e for the detailed discussion. It is recommended to provide feedback in the ma= iling list.=0A=0A* Wrap-up- Chairs will request 2.5 hours for the next F2F mee= ting.Thanks,Kind RegardsKepeng ------=ALIBOUNDARY_15072_4a2f1940_5511f3d5_2e58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ACE WG Meeting
IETF 92 - Da= llas
Tuesday 24 March 2015, 13:00 - 15:00 CDT
Chairs: Kepeng Li, Hannes = Tschofenig

* Use Cases (Sandeep S. Kumar)
- No open issues. Next st= ep is to initiate WGLC. Five people volunteered to review the draft.

* = Problem Description (Goeran Selander)
- The term "Configuration Se= rver" needs to be checked. 
- There was consensus to use problem descr= iption and terminology as a starting point to work on.

* Actors (Carste= n Bormann, 20 mins)
- There was preference to reuse OAuth terminologies (e= .g. Resource Server, Authorization Server).
- Action: Design team = is requested to merge Problem Description draft and Actors draft, and provide = a combined draft.

* Delegated CoAP Authentication and Authorization Fra= mework (Carsten Bormann)
- No time for the detailed discussion. It is= recommended to provide feedback in the mailing list.

* Object Security= (Goeran Selander)
- There was comment that part of the work should be don= e in CORE.
- There was comment that it depends on COSE work.
=
- No consensus to adopt it this time. More time is needed.
=
* Use Oauth and UMA (Hannes Tschofenig)
- No time for the detailed dis= cussion. It is recommended to provide feedback in the mailing list.
<= div class=3D"__aliyun_signature_wrap">
* Wrap-up
- Chairs will r= equest 2.5 hours for the next F2F meeting.

Thanks,

=
Kind Regards
Kepeng
------=ALIBOUNDARY_15072_4a2f1940_5511f3d5_2e58-- From nobody Fri Mar 27 10:17:27 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441E11B2A4C; Fri, 27 Mar 2015 10:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPQdkEoOj6Gk; Fri, 27 Mar 2015 10:17:23 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::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 E97151B2A38; Fri, 27 Mar 2015 10:17:16 -0700 (PDT) Received: by lbdc10 with SMTP id c10so14289284lbd.2; Fri, 27 Mar 2015 10:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bO5FHY6P5hCOl2S1A4AMHGIK4ULmqQBzH4UZOBVh+Lk=; b=MnPSWFW2YE3OQ5pakHmQffFLExwoIzCSl4xvXrQGatdtnXXBpiJsa/9TZN1mTd/hJ/ jbET/lxetkfDePYx1kdt0DnbASxTrBOI/JQi2yY+Knqmk0afWuNEPAvf005KOb6LF/YY vlyO5f8NMC04mlQq2om+IbpkBMumRRuPEYQ+4/LffTcBgPU+S/ybBukg4J6opZaQVGWY 4ce3P5/gSdPqVlXfni+Xqs7dKnThffKRDsKa3ltvx+JvpZMAVkm2V4JF03xwDQ3KRA+S B9pTVgziRBcfiwSlnKLPtAddldSHaiAbGAX2Zv9YJvBbRrEU7gMKYEQfShgl7iEPZx7/ lmtQ== MIME-Version: 1.0 X-Received: by 10.112.12.4 with SMTP id u4mr18561547lbb.4.1427476635528; Fri, 27 Mar 2015 10:17:15 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Fri, 27 Mar 2015 10:17:15 -0700 (PDT) Date: Fri, 27 Mar 2015 13:17:15 -0400 Message-ID: From: Kathleen Moriarty To: "saag@ietf.org" , emu@ietf.org Content-Type: multipart/alternative; boundary=001a11c3b394c935820512484d08 Archived-At: Subject: [saag] Feedback on Salted EAP draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 17:17:24 -0000 --001a11c3b394c935820512484d08 Content-Type: text/plain; charset=UTF-8 Hello, Dan Harkin's asked that I AD sponsor the following draft: https://www.iab.org/activities/workshops/caris/ I'm considering it, reviews and opinions are welcome. Thank you. -- Best regards, Kathleen --001a11c3b394c935820512484d08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Dan Harkin's asked that I AD= sponsor the following draft:


--001a11c3b394c935820512484d08-- From nobody Fri Mar 27 10:25:16 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375831B2A88; Fri, 27 Mar 2015 10:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8GaMZjw4azb; Fri, 27 Mar 2015 10:25:13 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0FC1B2A80; Fri, 27 Mar 2015 10:25:13 -0700 (PDT) Received: by lahp7 with SMTP id p7so56773992lah.2; Fri, 27 Mar 2015 10:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=pnXy5VdvPdtrdRrtH5FCznulB9UVRyjnXsk+62rcTZc=; b=uP3W1l++FpmQM4ho3B8YyQE8A/4zr+aoHsrGksvK49Bq/nI4eLg7NAWVqPaKwaLJJA YTYi6fDA/sQ1CejH19gQMUeNw7O+nTEHJkKH523MWKgoznSFdIrC5qvP5F57alLrYbOp DB+G4y2mWZJb586C/dKyYgRO1zb86V0NjJJCEcyhKSTUOfY5wxME+OaPDNl8S1LEzsTG /7WRy0z4mKzl3Ki0tUBP/6OvLk/ChtNH3gqqj4RmltghlEMJBuSzQDKv9UyLA5yLxFmV RzEYNJNNb8tbcb6qaMAxQFSp0bi/gSi4nKPEO5gBisa1zRSu+B5fhGzBtH4OtBHI+qKf CJxg== MIME-Version: 1.0 X-Received: by 10.112.12.4 with SMTP id u4mr18586355lbb.4.1427477112109; Fri, 27 Mar 2015 10:25:12 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Fri, 27 Mar 2015 10:25:12 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 Mar 2015 13:25:12 -0400 Message-ID: From: Kathleen Moriarty To: "saag@ietf.org" , emu@ietf.org Content-Type: multipart/alternative; boundary=001a11c3b394313ece0512486a06 Archived-At: Subject: Re: [saag] Feedback on Salted EAP draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 17:25:15 -0000 --001a11c3b394313ece0512486a06 Content-Type: text/plain; charset=UTF-8 I meant to send the link to Dan's draft: https://tools.ietf.org/html/draft-harkins-salted-eap-pwd-01 Long week... On Fri, Mar 27, 2015 at 1:17 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hello, > > Dan Harkin's asked that I AD sponsor the following draft: > https://www.iab.org/activities/workshops/caris/ > > I'm considering it, reviews and opinions are welcome. > > Thank you. > > -- > > Best regards, > Kathleen > -- Best regards, Kathleen --001a11c3b394313ece0512486a06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I meant to send the link to Dan's draft:

Long week...

On Fri, Mar 27, 2015 at 1:17 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Hello,

Dan Ha= rkin's asked that I AD sponsor the following draft:

I&= #39;m considering it, reviews and opinions are welcome.

Thank you.

--

Best regards,
Kathleen



--

Best regards,
Kath= leen
--001a11c3b394313ece0512486a06-- From nobody Fri Mar 27 10:34:17 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCA41A88DA; Fri, 27 Mar 2015 10:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHnOcAuvr3f1; Fri, 27 Mar 2015 10:34:14 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5721A88C6; Fri, 27 Mar 2015 10:34:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9DECB20684; Fri, 27 Mar 2015 13:32:26 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLup-bTwW398; Fri, 27 Mar 2015 13:32:26 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 27 Mar 2015 13:32:26 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 807B788A7D; Fri, 27 Mar 2015 13:34:12 -0400 (EDT) From: Sam Hartman To: Kathleen Moriarty References: Date: Fri, 27 Mar 2015 13:34:12 -0400 In-Reply-To: (Kathleen Moriarty's message of "Fri, 27 Mar 2015 13:25:12 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "saag@ietf.org" , emu@ietf.org Subject: Re: [saag] Feedback on Salted EAP draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 17:34:15 -0000 >>>>> "Kathleen" == Kathleen Moriarty writes: Kathleen> I meant to send the link to Dan's draft: Kathleen> https://tools.ietf.org/html/draft-harkins-salted-eap-pwd-01 Kathleen> Long week... I have briefly reviewed the goals behind this proposal and a sketch of the details but have not done a technical review of the proposal. The underlying goal is important and valuable. This issue is the same issue that was behind my response to your AD review of the oauth dynamic registration draft. The more we can do to make it possible to use deployed password databases with more modern security, the more we will be able to employ that modern security. However, take careful note of section 5 of the draft. Assuming that you can get positive technical reviews of the proposal, this draft seems to solve an important problem that would be valuable to solve in the EAP community. From nobody Fri Mar 27 10:41:46 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BBB1A88D6 for ; Fri, 27 Mar 2015 10:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJ8diEEGBYtN for ; Fri, 27 Mar 2015 10:41:38 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0624.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::624]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391421B2AC9 for ; Fri, 27 Mar 2015 10:41:38 -0700 (PDT) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) with Microsoft SMTP Server (TLS) id 15.1.118.21; Fri, 27 Mar 2015 17:38:04 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.01.0118.022; Fri, 27 Mar 2015 17:38:04 +0000 From: "Paterson, Kenny" To: "Paterson, Kenny" , "saag@ietf.org" Thread-Topic: report for CFRG from IETF 92 Thread-Index: AQHQZ/E8evnVeY+eq0eFO6NhWOdkwp0wRc2A Date: Fri, 27 Mar 2015 17:38:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.153.163] authentication-results: rhul.ac.uk; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB383; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(51704005)(479174004)(24454002)(2900100001)(450100001)(2950100001)(77156002)(107886001)(15975445007)(102836002)(62966003)(77096005)(106116001)(74482002)(36756003)(86362001)(2656002)(87936001)(83506001)(66066001)(19580405001)(19580395003)(122556002)(92566002)(46102003)(50986999)(2501003)(54356999)(40100003)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB383; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DBXPR03MB383; BCL:0; PCL:0; RULEID:; SRVR:DBXPR03MB383; x-forefront-prvs: 0528942FD8 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2015 17:38:04.0677 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB383 Archived-At: Subject: Re: [saag] report for CFRG from IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 17:41:43 -0000 Correction: I forgot to mention that we also had a presentation on the Algebraic Eraser crypto-system from Paul Gunnells (SecureRF Corporation). Apologies for the omission. Regards Kenny On 26/03/2015 13:18, "Paterson, Kenny" wrote: > >CFRG met on Wednesday afternoon. The meeting was well-attended. > >We had presentations and discussions on 4 distinct topics: > >- progress and next steps on the ECC work for TLS >(https://tools.ietf.org/html/draft-irtf-cfrg-curves-01) >- an update on scrypt >(https://tools.ietf.org/html/draft-josefsson-scrypt-kdf-02) >- hash based signatures >(https://tools.ietf.org/html/draft-huelsing-cfrg-hash-sig-xmss-00) >- an update on a PAKE requirements document and presentations on two >specific PAKE protocols >(https://datatracker.ietf.org/doc/draft-irtf-cfrg-augpake/, >http://www.ietf.org/staging/draft-liu-sipcore-ec-srp-00.txt) > >-- Kenny, for the chairs. > > From nobody Mon Mar 30 11:34:46 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589E41A9308 for ; Mon, 30 Mar 2015 11:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iH40Aicn3Cst for ; Mon, 30 Mar 2015 11:34:35 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922CF1A923C for ; Mon, 30 Mar 2015 11:34:35 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 32C978EFC4 for ; Mon, 30 Mar 2015 17:16:45 +0000 (UTC) Received: from bofh.nohats.ca (vpn-237-161.phx2.redhat.com [10.3.237.161]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2UHGiIY017034 for ; Mon, 30 Mar 2015 13:16:44 -0400 Message-ID: <551984FC.8020006@redhat.com> Date: Mon, 30 Mar 2015 13:16:44 -0400 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: saag@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C73AAFB25C2@uxcn10-5.UoA.auckland.ac.nz> <5508A726.5090406@azet.org> In-Reply-To: <5508A726.5090406@azet.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 18:34:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/17/2015 06:13 PM, Aaron Zauner wrote: > IPSec might (!) work well if you use one vendor throughout your network, That's a somewhat obsoleted viewpoint. While I think that is correct for IKEv1 and all the proprietary bold-on solutions, I do not see as many issues with IKEv2. Although for large scale solutions, there tends to be a strong vendor-lock but mostly in the management/gui aspects of having many devices (not endusers) > solutions. Because IPSec is such an overly complicated protocol there's not much security in the clients that are available throughout enduser operating > system. I'm not sure what you mean here. With the exception of group PreShared Keys and in particular Aggressive Mode IKEv1, yes that's broken and should not be used. But it _has_ been obsoleted for almost a decade now. Apple, for example, uses racoon (a NetBSD client) for > IPSec. It only supports IKEv1 in Aggressive Mode. That's a pretty big userbase that is forced to use an insecure protocol. It does support IKEv2 in the latest iOS, but the provisioning is so locked up that people haven't made it work yet It does suppor IKEv1 with certificates, which is _not_ insecure, even in Aggressive Mode. On the other side, there is Android which has locked up their IPsec stack even more. It cannot be at all provisioned, so VPN providers that want something that doesn't require the user to input a profile manually just choose to ship openvpn bundled in their app. This is not the fault of IPsec, but of Google. Users having a plethora of TLS/UDP based VPNs installed with less core integration into the OS is a suboptimal solution. > Besides a couple of commercial and seldomly used FOSS software implementations nobody really implements all authentication subprotocols. Where do you base your "seldom" on? Possibly you are thinking of Windows VPN clients, which is another story of a failed OS vendor. In this case, Microsoft waited 5+ years to allow anything but L2TP+IPsec based VPNs to be used by non-administrative users, so anything not using L2TP needed administrative rights which users often did not have (Or a third party client for XAUTH support) I rarely see companies that configure IPSec for their > users (if they do, most hate it and constantly have problems with that decision) I do not see that. IPsec/IKE configured VPNs do not cause additional problems. The days of ESPinUDP on port 4500 being blocked are long gone. > even different product-cycles of a given vendor, you might run into interoperability problems. I don't know of a single network engineer that enjoys > deploying IPSec. That's mostly because the Cisco command line is worse than juggling with swiss army knives with all blades extended. > I don't really see a need for a new standard as I also think that everything that is needed for a TLS VPN is already specified. Maybe a BCP document on how > to properly use and implement TLS VPNs would make more sense? TLS VPNs, at least those using TCP, are trivially DOS'ed. Most implementations, because they are userland, require lots of tun devices, custom routing or bridging, and back and forth of packet data between userland and kernel. It's a band-aid. People are quick to say IPsec/IKE is too complicated and hard. Yet the TLS protocol is more and more mimicking IKE, and IKE or IPsec hasn't seen anything close to the vast amount of crypto attacks as we've seen in TLS. On top of that, many TLS VPNs have their own huge problems related to things like environment variable passing, etc. As for those still think IPsec is too hard to configure, according to http://www.theguardian.com/technology/2015/jan/09/why-netflix-wont-block-vpn-users there are 30 million people using a VPN to access netflix. With the apple vs android split, that's about 15 million end users who are using IPsec just fine. All of this is unrelated to what is apparently the NSA's motivation of wanting two different VPN technologies at once for a "defence in depth" mode. While I can see why one would want to put TLS under IPsec, I think most of those issues are being addressed in TLS 1.3. If the NSA doesn't want to trust a single cipher, then I'd rather see a different chaining of ciphers :P Paul -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJVGYT7AAoJEISzragz8T5uKAAIAJTfj9mLjoIcDW7oY3aHsQaP Ge7n/NRtyKtJ0vFbi398quBvGt50aXIbUK0AVID2h783KMyX7DA/iBk7Uc5plR+K PCJXRCsN6UHE/WYbhtoenZEysD5yq2jikbI+SCW6ejKXJoTnfQM7KbuxLo5KJYwK uH5WnVVEE/KSxUe0zn13o/CtOuhiISGQBGE/fSIy9ED5Ud51AOJrZbjEVh15HZsT a1naMnu99048AR29pMcoxNL+LJB8gmXBT/UKvLymoNgJtqzvVvRSOzgtb9ftofG9 /5YtSd5IVvqlBf7oNxgZ63S4ciO0CyYDLYNNOZ/uV6r9zB8QM6oqcDi+00F9QsY= =e7AU -----END PGP SIGNATURE-----