From nobody Tue Jan 1 06:06:35 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB43B130DBE; Tue, 1 Jan 2019 06:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dE675WscXbGU; Tue, 1 Jan 2019 06:06:25 -0800 (PST) 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 4B08A12426A; Tue, 1 Jan 2019 06:06:25 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B4709394D3F; Tue, 1 Jan 2019 14:06:24 +0000 (UTC) Received: from ovpn-116-112.phx2.redhat.com (ovpn-116-112.phx2.redhat.com [10.3.116.112]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 175261042557; Tue, 1 Jan 2019 14:06:23 +0000 (UTC) Message-ID: From: Simo Sorce To: David Mandelberg , draft-ietf-curdle-gss-keyex-sha2.all@ietf.org, iesg@ietf.org, secdir@ietf.org Date: Tue, 01 Jan 2019 09:06:23 -0500 In-Reply-To: References: Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 01 Jan 2019 14:06:24 +0000 (UTC) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-curdle-gss-keyex-sha2-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2019 14:06:27 -0000 On Mon, 2018-12-31 at 14:57 -0500, David Mandelberg wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is Ready with nits. I have a few questions > below about the security of this document, but each area I have a > question about seems to be mostly copied from an established RFC rather > than new to this draft. > > Sections 4 and 5.2: Are you relying on MD5 for any security properties? No, it was used just to generate a unique name. > Can anything bad happen if an attacker finds a collision? No > Section 5.1: When calculating H, are the boundaries between each > concatenated thing clear? E.g., would V_C = "1.21" V_S = "0.1" and V_C = > "1.2" V_S = "10.1" result in the same value for H? All else equal I think it would > Section 5.1: I assume H or mic_token is used elsewhere to thwart an > active MITM? From what I see here, everything hashed into H other than K > is public, so an active MITM could generate different H values for > different K values for the two sides. the MIC around H is used to assure no tampering of messages happened. Anti-MITM properties are conferred by the GSSAPI exchange which is mutually authenticated. In order to perform a MITM an attacker need to get hold of both parties keys (a GSSAPI exchange does not use public/private or DH, it is a KDC mediated exchange using only symmetric keys). Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc From nobody Tue Jan 1 12:33:44 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE8D129A87 for ; Tue, 1 Jan 2019 12:33:37 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mandelberg.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osPJUBEEZIXu for ; Tue, 1 Jan 2019 12:33:36 -0800 (PST) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 DF356129C6A for ; Tue, 1 Jan 2019 12:33:34 -0800 (PST) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=aqzwMmRV c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=3JhidrIBZZsA:10 a=bmmO2AaSJ7QA:10 a=BTUBnpS-AAAA:8 a=KLlQBJra5XYmiPl-zaAA:9 a=QEXdDO2ut3YA:10 a=pblkFgjdBCuYZ9-HdJ6i:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZHNlb21uQHJjbi5jb20= Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=david@mandelberg.org; spf=softfail; sender-id=softfail Authentication-Results: smtp01.rcn.cmh.synacor.com header.DKIM-Signature=@mandelberg.org; dkim=pass Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=david@mandelberg.org; sender-id=softfail Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN) Received: from [209.6.43.168] ([209.6.43.168:58424] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 17/E2-32266-D9ECB2C5; Tue, 01 Jan 2019 15:33:33 -0500 Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 52D891C605C; Tue, 1 Jan 2019 15:33:32 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=201809; t=1546374812; bh=bL60RFE2fAI22NdlF2fnu9oZfKXxt9YYKbZpJZMqb8A=; h=Subject:To:References:From:Date:In-Reply-To:From; b=f/cwaiiUpOveEmzMBJk9tvjLiLU7weZvL3mF2G96/+FmwkCa6PEc/9k8sEOOKKYry 6rdzQbHemqwz6gXaNUEX9AwCd2+zs5MD+NBx2jpS0NgF8a42RgC0Dh2xulVdX044GZ wMHZg4XHUqOaEeooFmSZBTbXi+kYHc+8K3HUnBmIP0JiIbCJ44p+oVCGaSDCQeAbf3 6lm8VfgRGXsjUSiAo5PxRpAiis+iayLFzMVjvCD3jYn03MV5lQQ0w/olfzWPGBjd9w b6HnD1uWflt8Aj8OkpkJvDTTyHHl0adQGHJcbxUd5SIT+H4HiZtUFPy7XWSC7/YW7u 97DwtdguOmLjw== To: Simo Sorce , draft-ietf-curdle-gss-keyex-sha2.all@ietf.org, iesg@ietf.org, secdir@ietf.org References: From: David Mandelberg Message-ID: Date: Tue, 1 Jan 2019 15:33:31 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-curdle-gss-keyex-sha2-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2019 20:33:38 -0000 On 1/1/19 9:06 AM, Simo Sorce wrote: > On Mon, 2018-12-31 at 14:57 -0500, David Mandelberg wrote: >> Section 5.1: When calculating H, are the boundaries between each >> concatenated thing clear? E.g., would V_C = "1.21" V_S = "0.1" and V_C = >> "1.2" V_S = "10.1" result in the same value for H? > > All else equal I think it would Ok. I don't have any specific attacks in mind, but that seems like a potential weak point. This probably isn't the right document to change that in though. >> Section 5.1: I assume H or mic_token is used elsewhere to thwart an >> active MITM? From what I see here, everything hashed into H other than K >> is public, so an active MITM could generate different H values for >> different K values for the two sides. > > the MIC around H is used to assure no tampering of messages happened. > Anti-MITM properties are conferred by the GSSAPI exchange which is > mutually authenticated. > In order to perform a MITM an attacker need to get hold of both parties > keys (a GSSAPI exchange does not use public/private or DH, it is a KDC > mediated exchange using only symmetric keys). Sounds good, thanks for the explanation. -- https://david.mandelberg.org/ From nobody Tue Jan 1 14:13:38 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56C8130DC1; Tue, 1 Jan 2019 14:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gzu1nog52Om8; Tue, 1 Jan 2019 14:13:35 -0800 (PST) Received: from relay-exchange.andrew.cmu.edu (RELAY-EXCH-05.ANDREW.CMU.EDU [128.2.157.24]) (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 E30E2129BBF; Tue, 1 Jan 2019 14:13:34 -0800 (PST) Received: from dcns-msgp-01.andrew.ad.cmu.edu (DCNS-MSGP-01.ANDREW.AD.CMU.EDU [128.2.157.85]) by relay-exchange.andrew.cmu.edu (8.15.2/8.15.2) with ESMTPS id x01MDTo6023262 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 1 Jan 2019 17:13:29 -0500 Received: from dcns-msgp-03.andrew.ad.cmu.edu (128.2.157.87) by dcns-msgp-01.andrew.ad.cmu.edu (128.2.157.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1591.10; Tue, 1 Jan 2019 17:13:28 -0500 Received: from dcns-msgp-03.andrew.ad.cmu.edu ([128.2.157.87]) by dcns-msgp-03.andrew.ad.cmu.edu ([128.2.157.87]) with mapi id 15.01.1591.008; Tue, 1 Jan 2019 17:13:28 -0500 From: Jeffrey Hutzelman To: David Mandelberg , Simo Sorce , "draft-ietf-curdle-gss-keyex-sha2.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: [secdir] secdir review of draft-ietf-curdle-gss-keyex-sha2-07 Thread-Index: AQHUoUMUHwl08B2MXUm7QLQuuiqmK6Wax6aAgABsKYD//8YKXw== Date: Tue, 1 Jan 2019 22:13:28 +0000 Message-ID: <7167ade4a5f34131b0febdbf838ed1fe@cmu.edu> References: , <116626_1546374823_x01KXf1b120191_e99a19cd-6e21-f859-db68-23cdd20c1e25@mandelberg.org> In-Reply-To: <116626_1546374823_x01KXf1b120191_e99a19cd-6e21-f859-db68-23cdd20c1e25@mandelberg.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.2.42.4] Content-Type: multipart/alternative; boundary="_000_7167ade4a5f34131b0febdbf838ed1fecmuedu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 128.2.157.24 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-curdle-gss-keyex-sha2-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2019 22:13:37 -0000 --_000_7167ade4a5f34131b0febdbf838ed1fecmuedu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Actually, this is not an issue. The value H is the SSH exchange hash, which= is a common element across all key exchange methods. It is discussed in de= tail on the following page, which I think makes it clear that the hash is o= ver a concatenation of a number of items of type 'string', except for K, wh= ich is an mpint. These types and their representations are described in RFC= 4251 section 5. In particular, 'string' is a counted string, so no, the cas= es you describe do not result in the same value for H. -- Jeff ________________________________ From: secdir on behalf of David Mandelberg Sent: Tuesday, January 1, 2019 3:33 PM To: Simo Sorce; draft-ietf-curdle-gss-keyex-sha2.all@ietf.org; iesg@ietf.or= g; secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-curdle-gss-keyex-sha2-07 On 1/1/19 9:06 AM, Simo Sorce wrote: > On Mon, 2018-12-31 at 14:57 -0500, David Mandelberg wrote: >> Section 5.1: When calculating H, are the boundaries between each >> concatenated thing clear? E.g., would V_C =3D "1.21" V_S =3D "0.1" and V= _C =3D >> "1.2" V_S =3D "10.1" result in the same value for H? > > All else equal I think it would Ok. I don't have any specific attacks in mind, but that seems like a potential weak point. This probably isn't the right document to change that in though. --_000_7167ade4a5f34131b0febdbf838ed1fecmuedu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Actually, this is not an issue. The value H is the SSH exchange hash, wh= ich is a common element across all key exchange methods. It is discussed in= detail on the following page, which I think makes it clear that the hash i= s over a concatenation of a number of items of type 'string', except for K, which is an mpint. These types an= d their representations are described in RFC4251 section 5. In particular, = 'string' is a counted string, so no, the cases you describe do not result i= n the same value for H.


-- Jeff



From: secdir <secdir-b= ounces@ietf.org> on behalf of David Mandelberg <david=3D40mandelberg.= org@dmarc.ietf.org>
Sent: Tuesday, January 1, 2019 3:33 PM
To: Simo Sorce; draft-ietf-curdle-gss-keyex-sha2.all@ietf.org; iesg@= ietf.org; secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-curdle-gss-keyex-s= ha2-07
 
On 1/1/19 9:06 AM, Simo Sorce wrote:
> On Mon, 2018-12-31 at 14:57 -0500, David Mandelberg wrote:
>> Section 5.1: When calculating H, are the boundaries between each >> concatenated thing clear? E.g., would V_C =3D "1.21" V_S= =3D "0.1" and V_C =3D
>> "1.2" V_S =3D "10.1" result in the same value = for H?
>
> All else equal I think it would

Ok. I don't have any specific attacks in mind, but that seems like a
potential weak point. This probably isn't the right document to change
that in though.



--_000_7167ade4a5f34131b0febdbf838ed1fecmuedu_-- From nobody Wed Jan 2 08:02:23 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B0F130E34; Wed, 2 Jan 2019 08:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CddPk8fQAiyD; Wed, 2 Jan 2019 08:02:19 -0800 (PST) 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 5C7AD12950A; Wed, 2 Jan 2019 08:02:19 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ADB7A8764B; Wed, 2 Jan 2019 16:02:18 +0000 (UTC) Received: from ovpn-116-112.phx2.redhat.com (ovpn-116-112.phx2.redhat.com [10.3.116.112]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0073A19C65; Wed, 2 Jan 2019 16:02:17 +0000 (UTC) Message-ID: From: Simo Sorce To: Jeffrey Hutzelman , David Mandelberg , "draft-ietf-curdle-gss-keyex-sha2.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Date: Wed, 02 Jan 2019 11:02:16 -0500 In-Reply-To: <7167ade4a5f34131b0febdbf838ed1fe@cmu.edu> References: , <116626_1546374823_x01KXf1b120191_e99a19cd-6e21-f859-db68-23cdd20c1e25@mandelberg.org> <7167ade4a5f34131b0febdbf838ed1fe@cmu.edu> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 02 Jan 2019 16:02:18 +0000 (UTC) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-curdle-gss-keyex-sha2-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2019 16:02:21 -0000 Thank you Jeffrey, I forgot it was a counted string! Simo. On Tue, 2019-01-01 at 22:13 +0000, Jeffrey Hutzelman wrote: > Actually, this is not an issue. The value H is the SSH exchange hash, > which is a common element across all key exchange methods. It is > discussed in detail on the following page, which I think makes it > clear that the hash is over a concatenation of a number of items of > type 'string', except for K, which is an mpint. These types and their > representations are described in RFC4251 section 5. In particular, > 'string' is a counted string, so no, the cases you describe do not > result in the same value for H. > > > -- Jeff > > > ________________________________ > From: secdir on behalf of David Mandelberg > Sent: Tuesday, January 1, 2019 3:33 PM > To: Simo Sorce; draft-ietf-curdle-gss-keyex-sha2.all@ietf.org; iesg@ietf.org; secdir@ietf.org > Subject: Re: [secdir] secdir review of draft-ietf-curdle-gss-keyex-sha2-07 > > On 1/1/19 9:06 AM, Simo Sorce wrote: > > On Mon, 2018-12-31 at 14:57 -0500, David Mandelberg wrote: > > > Section 5.1: When calculating H, are the boundaries between each > > > concatenated thing clear? E.g., would V_C = "1.21" V_S = "0.1" and V_C = > > > "1.2" V_S = "10.1" result in the same value for H? > > > > All else equal I think it would > > Ok. I don't have any specific attacks in mind, but that seems like a > potential weak point. This probably isn't the right document to change > that in though. > > > -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc From nobody Wed Jan 2 14:00:46 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D06A126C01; Wed, 2 Jan 2019 14:00:36 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnXh8P7IUG1d; Wed, 2 Jan 2019 14:00:34 -0800 (PST) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660093.outbound.protection.outlook.com [40.107.66.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29D11274D0; Wed, 2 Jan 2019 14:00:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XOphyxmtHm+F5CKx3QvAveq8aE7Xs/qzJQjMoXhQ4Jo=; b=fwj7/s4JCIhuxl3qk7bCze2nNnadKuu8hppT6GQDyMW4OlB5iFie4MucfCudYkPAkQKyOuvCsEEogwUtUZbLddVpk3NG0svZTwtqIiBjHFbMdnJfZpnQXNEzttijbvvd+nUCe/jQxahSZgMDI5p0rGJJhBmi1u+ZKSFLfnLMzFw= Received: from YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM (52.132.44.159) by YTOPR0101MB1354.CANPRD01.PROD.OUTLOOK.COM (52.132.45.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1471.20; Wed, 2 Jan 2019 22:00:31 +0000 Received: from YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM ([fe80::2933:2dff:4d41:a673]) by YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM ([fe80::2933:2dff:4d41:a673%2]) with mapi id 15.20.1471.019; Wed, 2 Jan 2019 22:00:31 +0000 From: Suresh Krishnan To: Charlie Kaufman , "draft-ietf-6lo-deadline-time.all@ietf.org" CC: "secdir@ietf.org" , "iesg@ietf.org" Thread-Topic: Secdir review of draft-ietf-6lo-deadline-time-03 Thread-Index: AQHUmz3wn28DKZa1QE+QITpNT8nKbaWclqyA Date: Wed, 2 Jan 2019 22:00:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com; x-originating-ip: [45.19.110.76] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB1354; 6:hEDKSzx2AsAYquU3cFewl8J3RVLBeoQPedidzqUTO/rSRqt0dHhyl/nQVD0rrZ7mlcKvdT6VDQEHXB/APizkiW2Eb5ymoou874QHhjhHI7xKVhWTBmPGhGv161HERWe3b6k5PyVzoMN9cD280HxVfTDiP/MjAk1VDOcoY61VBnRHhwhGKRzY3xTPiV7XrvMRas6R7yFIXFlPEPjo8fcOYQBulmcNONoduXh1DQ5fgSBV/w7Qqm+h76v4zXONKLTFjJYF5fykdlAO5r3cpqZMuD1TtO67OqOW7ouLL1tWmTLlZvZ9mhvW6TDZP8Q/+nBMsb+F70tntryugeDTvPeX34X+vL5KFy4PG1WFBmYfMkF8ObP1QP7khwhUmr0SJuLJJP2xRrMG5IdAXnmfeECTb83ZWzqOfU9FA9n68pFaPtty/B9QUIm8qj4YJaXQ/e55FqzZI/LUyqeNo79+1Apjnw==; 5:Ku/V/AJys8RLjC95I+vzuuaBpRxPYuTc+5ZaE/XJgsxCiDe8NNaPYYpvpcJT7tuebP3VGlHT45gUBM6cmKfgfKSVaCVSWF6le2HItFkWu5aInPCwI5OySArOiz18uKY/H9tAss9u9kZPhrZ/2o5SLphZauIaV+cbzkD/Tg2fA/A=; 7:mz0YYsl1YknqenTfjlWKNanAqygqN1Pxop6qcOGLKTHwj9fKuh0PrtcSsNZ6xz/+Jra5XEAMYBZXTP8wOUItaoEWOAD0Sxe5SskhakSopMqOttIii5EcPrTsdyjGj3UoC6tyQETV0zmYQ161y9Adiw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5521cee1-b0aa-42b6-435d-08d670fdb6e9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB1354; x-ms-traffictypediagnostic: YTOPR0101MB1354: x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(3231475)(944501520)(52105112)(3002001)(93006095)(93001095)(10201501046)(6041310)(2016111802025)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6043046)(201708071742011)(7699051)(76991095); SRVR:YTOPR0101MB1354; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB1354; x-forefront-prvs: 0905A6B2C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(396003)(366004)(346002)(39840400004)(376002)(136003)(199004)(189003)(5660300001)(81166006)(81156014)(68736007)(25786009)(26005)(39060400002)(508600001)(8936002)(8676002)(76176011)(110136005)(102836004)(83716004)(54906003)(6506007)(53546011)(45080400002)(99286004)(186003)(2501003)(316002)(4326008)(2906002)(7736002)(71200400001)(71190400001)(33656002)(106356001)(6486002)(105586002)(6512007)(236005)(11346002)(6116002)(66066001)(476003)(72206003)(256004)(14454004)(82746002)(229853002)(36756003)(97736004)(80792005)(486006)(86362001)(6436002)(3846002)(2616005)(14444005)(6246003)(54896002)(446003)(53936002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:YTOPR0101MB1354; H:YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ti4C83z3zv1nUcrpeQ473+hESTv3LnQylqBgfsqTgP0e3iGscWSdkBRbYPrGJPYhviJwJa9nESaRQvSDfSUgvdrH134WtqpJIyQExaQN7v2JHBBwnSKKod86GoRrlYoOUKExiM9FXKH7N6s17qYZpkye5MF2pHRP4uDSGRXWAl+RHJCeVI8DLJ/24+Y2A7DMnGSa/Rukh+8jzSeNV0oeBM9MbHuhF57Q34QNmc66+K0YrYa8z0XJKWJ4Ucp1cU6ifzCQ83lG5Qch+7g8uUl6ZGvmN/j+J/Qf+wDMCyx4s+w/fiIh0C65S2r/W+CAQAhn spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_C810285DA26647CC86AFDA0807ABD059kaloomcom_" MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5521cee1-b0aa-42b6-435d-08d670fdb6e9 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2019 22:00:31.6187 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1354 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-6lo-deadline-time-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2019 22:00:37 -0000 --_000_C810285DA26647CC86AFDA0807ABD059kaloomcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks a lot for your review Charlie. Authors, can you please respond to th= is review with proposed resolutions. Regards Suresh On Dec 23, 2018, at 11:08 PM, Charlie Kaufman > wrote: I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document specifies a new optional extension in 6LoRHE headers to be us= ed to do fine grained time tracking of packets traversing a network. It sup= ports two functions: tracking the timing of transiting packets for the purp= ose of performance analysis and diagnostics, and delivery deadline enforcem= ent where the source instructs the network to drop a packet if it cannot be= delivered within a specified time bound. This avoids network congestion by= quickly discarding packets that are going to be useless by the time they a= re delivered. One of the challenges facing this design is maintaining tight clock synchro= nization between packet forwarding devices. The design assumes that sets of= such devices are held in tight synchronization through unspecified mechani= sms. These groupings are called "time zones". It also calls for the origina= tion time and delivery deadline fields be updated when a packet transitions= between "time zones" (which assumes that packet forwarding devices on sepa= rating two time zones be aware of the time difference between them so that = it can update those fields). The issues raised below may be covered in companion documents, but they are= what occurred to me while reviewing this one. Security issues: Section 6 specifies that when one of these packets is encapsulated and sent= through an IPv6 in IPv6 tunnel, and tunnel exit the time fields must be co= pied from the outer header to the inner header before the packet is forward= ed on. This would be true of any form of encapsulation, in particular inclu= ding IPsec tunnelling. Many time synchronization protocols - particularly those that target subsec= ond synchronization - assume they are running on a secure network (or that = attackers would not be motivated to mess up time synchronization). If the t= ime synchronization between the packet forwarding devices were to be broken= such that there was substantial drift between the devices, that could be u= sed as a denial of service attack if that could be used to cause most or al= l data packets to be discarded as expired. Non-security issues: The length of the time fields is specified in the OTL and DTL headers to ha= ve a length of between 1 and 8 octets. I could not tell from the spec wheth= er it was intended that the sender was supposed to pick a size big enough t= o represent the entire time field or whether it was OK to pick a smaller si= ze and place the low order bits of the time in the field. Placing the low o= rder bits there would normally work, though it makes size comparisons more = complex (particularly in cases where there are just barely enough bits to a= void wrapping before the packet expires). I was initially confused by the presence of two fields OT and DT when one s= hould be sufficient to enforce packet expiration. Reading between the lines= of the spec, I eventually concluded that only the DT field was intended to= be used for this purpose and the OT field was intended to be used to track= delivery performance and is not used in the calculation of packet lifetime= . Assuming I have that right, it would be good if it were more explicit in = the document. The bit bummer in me was offended by the fact that the TU and EXP fields ha= d two different ways of representing 1 second time granularity (TU=3D00/EXP= =3D110 and TU=3D01/EXP=3D000). Given that time granularity greater than 10 = seconds is never likely to be needed, the need for the TU=3D01 code point i= s questionable, but at the least perhaps the spec should say which is the p= referred encoding. I also could not tell whether the encoding was expected = to be constant within a Time Zone (in which case the fields would not be ne= cessary in every packet) or whether packet relay nodes were expected to can= onicalize the time representation whenever it parses a packet. But this is = only a matter of taste. --_000_C810285DA26647CC86AFDA0807ABD059kaloomcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Thanks a lot for your review Charlie. Authors, can you please respond to th= is review with proposed resolutions.

Regards
Suresh

On Dec 23, 2018, at 11:08 PM, Charlie Kaufman <charliekaufman@outlook.co= m> wrote:

I have revie= wed this document as part of the security directorate's ongoing effort to r= eview all IETF documents being processed by the IESG.  These comments = were written primarily for the benefit of the security area directors.  Document editors and WG chairs should t= reat these comments just like any other last call comments.

This documen= t specifies a new optional extension in 6LoRHE headers to be used to do fin= e grained time tracking of packets traversing a network. It supports two fu= nctions: tracking the timing of transiting packets for the purpose of performance analysis and diagnostics, and deliv= ery deadline enforcement where the source instructs the network to drop a p= acket if it cannot be delivered within a specified time bound. This avoids = network congestion by quickly discarding packets that are going to be useless by the time they are delivered.

One of the c= hallenges facing this design is maintaining tight clock synchronization bet= ween packet forwarding devices. The design assumes that sets of such device= s are held in tight synchronization through unspecified mechanisms. These groupings are called "time zone= s". It also calls for the origination time and delivery deadline field= s be updated when a packet transitions between "time zones" (whic= h assumes that packet forwarding devices on separating two time zones be aware of the time difference between them so that it can= update those fields).

The issues r= aised below may be covered in companion documents, but they are what occurr= ed to me while reviewing this one.

Security iss= ues:

Section 6 sp= ecifies that when one of these packets is encapsulated and sent through an = IPv6 in IPv6 tunnel, and tunnel exit the time fields must be copied from th= e outer header to the inner header before the packet is forwarded on. This would be true of any form of encapsulatio= n, in particular including IPsec tunnelling.

Many time sy= nchronization protocols - particularly those that target subsecond synchron= ization - assume they are running on a secure network (or that attackers wo= uld not be motivated to mess up time synchronization). If the time synchronization between the packet forwardin= g devices were to be broken such that there was substantial drift between t= he devices, that could be used as a denial of service attack if that could = be used to cause most or all data packets to be discarded as expired.

Non-security= issues:

The length o= f the time fields is specified in the OTL and DTL headers to have a length = of between 1 and 8 octets. I could not tell from the spec whether it was in= tended that the sender was supposed to pick a size big enough to represent the entire time field or whether it= was OK to pick a smaller size and place the low order bits of the time in = the field. Placing the low order bits there would normally work, though it = makes size comparisons more complex (particularly in cases where there are just barely enough bits to avoid wr= apping before the packet expires).
I was initia= lly confused by the presence of two fields OT and DT when one should be suf= ficient to enforce packet expiration. Reading between the lines of the spec= , I eventually concluded that only the DT field was intended to be used for this purpose and the OT field was int= ended to be used to track delivery performance and is not used in the calcu= lation of packet lifetime. Assuming I have that right, it would be good if = it were more explicit in the document.

The bit bumm= er in me was offended by the fact that the TU and EXP fields had two differ= ent ways of representing 1 second time granularity (TU=3D00/EXP=3D110 and T= U=3D01/EXP=3D000). Given that time granularity greater than 10 seconds is never likely to be needed, the need for the TU= =3D01 code point is questionable, but at the least perhaps the spec should = say which is the preferred encoding. I also could not tell whether the enco= ding was expected to be constant within a Time Zone (in which case the fields would not be necessary in every pack= et) or whether packet relay nodes were expected to canonicalize the time re= presentation whenever it parses a packet. But this is only a matter of tast= e.

--_000_C810285DA26647CC86AFDA0807ABD059kaloomcom_-- From nobody Thu Jan 3 03:29:56 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84A2124C04 for ; Thu, 3 Jan 2019 03:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.365 X-Spam-Level: X-Spam-Status: No, score=-4.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=O2UN+0WJ; dkim=pass (1024-bit key) header.d=ericsson.com header.b=m6JVfmM/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPJvFy6ekJXO for ; Thu, 3 Jan 2019 03:29:49 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 11FA912008F for ; Thu, 3 Jan 2019 03:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1546514986; x=1549106986; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=H4nFpLz+uad/Ke+qt0HvnKNChd9dgF3AFAW7V851ewQ=; b=O2UN+0WJ7AKJWrkNTiiP7D96P1v6VdnrF6iJH/kCkFly3Xz0OLbJT1wtfWkLZGfg NxM/0ysNekwx5s2kxoXo5pE2PZ8fzC/pBfZvjCs1zEXeli/JA08LR2UfYvpNSbuH PtDWtHct/VlzEi77TzcZVjbV7CQH5H+s9NKp+yDzh64=; X-AuditID: c1b4fb30-fabff7000000355c-ba-5c2df22a1e66 Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 97.E6.13660.A22FD2C5; Thu, 3 Jan 2019 12:29:46 +0100 (CET) Received: from ESESBMR503.ericsson.se (153.88.183.135) by ESESBMB504.ericsson.se (153.88.183.187) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 3 Jan 2019 12:29:46 +0100 Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESBMR503.ericsson.se (153.88.183.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 3 Jan 2019 12:29:45 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 3 Jan 2019 12:29:45 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H4nFpLz+uad/Ke+qt0HvnKNChd9dgF3AFAW7V851ewQ=; b=m6JVfmM/Gk4nKD+g0ep7KiQ5sgKDmN8b+8t6kkuufya9SQa0gIHsjQJhflobDSpASK/+bj3E+uXJRb60PuPJzG8krWXe306miLn/Q51O2imcCZuUb/j4xG2zImwpnBlfRTmYzvxNeGQ3wjk03wx9CDLXvToK35JQTXabCDwBZLY= Received: from DB7PR07MB5628.eurprd07.prod.outlook.com (20.178.47.151) by DB7PR07MB4585.eurprd07.prod.outlook.com (52.135.141.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.6; Thu, 3 Jan 2019 11:29:43 +0000 Received: from DB7PR07MB5628.eurprd07.prod.outlook.com ([fe80::2554:b72e:2ba3:26a3]) by DB7PR07MB5628.eurprd07.prod.outlook.com ([fe80::2554:b72e:2ba3:26a3%4]) with mapi id 15.20.1495.005; Thu, 3 Jan 2019 11:29:43 +0000 From: Christer Holmberg To: "Scott G. Kelly" , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-sipcore-sip-push.all@ietf.org" Thread-Topic: secdir review of draft-ietf-sipcore-sip-push-21 Thread-Index: AQHUoUFwpb8nIR8T3kKT3FjKoKE4faWdaLFK Date: Thu, 3 Jan 2019 11:29:42 +0000 Message-ID: References: <1546285539.44113084@apps.rackspace.com> In-Reply-To: <1546285539.44113084@apps.rackspace.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [87.93.24.165] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR07MB4585; 6:/a9Xz2/D7450UipazrasixYaZZxtaupqUkyGFdxaDH1YwxLITMZKTDR/ueJl3jBWlqqdKlGbrMSn3ujCsCojBikZ+GvyAcFtBoG0OuplcICsYS6depepimq55Vtqc+/anxGzpRNT84fboh+oSkBTWQ8CF4HmhNzcrM+qdne4Kf/Re+eBwMi2ff4GpdAg9Fl5YGSHlQ0yzfDvFYCM5++IiTiLcxG7oqJyS7ySIGbj1P9Geyv4QQKx9KCsDUAgbUN5/lc96xeoF3cujWjUsIwzlOasBHgbmKwFX5M4Q+wFCFNit8xCoqK5SMnfgR6qmemkq8ImBiKzcUk2v8J5x8VgVYMs5pGwj/AACYRdepBrGucK87XiCgCV1CzGo5ftifsLBkLrZ+CO3ky4tbKi54WjzEKLyJWhNYnaw8w2CJ659AN3cktlNfxzbESIJP8rkrBisnVYfCnuUPc8Ngk5E1gMvA==; 5:P08VhbeyoSNfxjj51M/YNwrUGlE1gxslP2LXTaznT4PUOCMvJvwSRmpF5tSZmDLX+unqSaZZB41wTrmQ1SEx90X8UnswItT5JcTMEGCNzAc5glnJif41/mVi9u2zz5s4Zprsvs0+iTu80SbddCFvH4pW4VBLgpGkZQCZZitA6vfAM7+utJd1mkdPWagix+U4OhK2seT2e9t/02OrRRn6gg==; 7:Dj4nMIdGu6EhUC5q/FoXT3MKxPFhvstYEHUDJQlYTNZXrRIIOHCa1YZuhykliRgq94Yiu82aTgN/gZej9tm6yhC3QZdyJPbadABc6x9zx7p72UjYTwxKFiplL1JNW5jbrbuntcCnhxg179sHMilbQA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7674955c-d787-451d-4ecf-08d6716ec1cb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:DB7PR07MB4585; x-ms-traffictypediagnostic: DB7PR07MB4585: x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(10201501046)(3002001)(3231475)(944501520)(52105112)(93006095)(93001095)(6041310)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB4585; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB4585; x-forefront-prvs: 0906E83A25 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(136003)(39860400002)(396003)(346002)(199004)(189003)(316002)(229853002)(53936002)(7696005)(3846002)(6116002)(55016002)(478600001)(68736007)(9686003)(33656002)(102836004)(71190400001)(71200400001)(76176011)(6606003)(74316002)(5660300001)(54896002)(345774005)(14444005)(256004)(2501003)(97736004)(7736002)(14454004)(106356001)(81166006)(6346003)(105586002)(81156014)(86362001)(476003)(99286004)(8676002)(2906002)(44832011)(486006)(2201001)(6246003)(8936002)(6506007)(110136005)(25786009)(11346002)(446003)(66066001)(19627405001)(26005)(186003)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB4585; H:DB7PR07MB5628.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uMatX84LYcuoB5JG0uwAJGbe6wJIUiBoN5hQoxtdIR72jZStTLSwG3nu+Mqd5gdicA6yz8hRZyRdslkDVblYWeddQ94LqwiTAn7fXxqj6Nfx92LYeT6hxSArZyQ6Ss8odnnvPzjkY6XWLXHJ9JWOxi65Lf0MieN1qXqIfHELLSh/JI3ti6RKNRpriX8BNJ+EolN8OQHqIenp+idLHqXDV2qDgM0Pbb4+cP8ORAI/qLZjTdR/aDpF4AtCL37ePIktojnAuLVgfrMGNsTK6Q4Ix/4hKihMitWHq7FLxJrDIaoKJhRyxFNMMD8VI9TOJE5H spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB7PR07MB56286B4A2702A5FF1915D1D6938D0DB7PR07MB5628eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7674955c-d787-451d-4ecf-08d6716ec1cb X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2019 11:29:42.9921 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4585 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SaUgUYRjHe2dm13Fz43W8nraEWuqDq+tV4SIaRgTSAdsXUVm0NccjdbUZ tbQQsSjUD62poYuwmkugZK33kYiZlUeUeXTYQaYYq1G6JZKK5DgWfvv9/8//eXn+8NIk0yxR 0MmGTJYz6FOVUhlVGdmepVbZ1Tr/kmKF5nvbINJUrJWQmqUWI9Is1ExRYVR4R8cQFW6x/CG0 RLQsJJ5NTc5mOb+j52RJhQ1eGf0nLv8s6SHz0bXgIuRIAz4M41UFkiIkoxncj+DGLysSxRKC fKuV+C/sd62kKGoJGCq0SQVBYSMJj758lAiPMbiEgJqx3WJqCsHQi88bKZqWYg0Ur3sLvise QTBQW7bpu+AQaBsIEnZdcShYi5akIgdCWaeJFJjCB+Dp4hgSWI510G60I2GV2Th8bpYSbEd8 BMwN9ZsnIOwOy0P3CYFJ7AGTM2ZC7InB0v2KFNkNbNPrEpH3wcRwq1RkTxg1F2/WB1zgAHUf upA4UMNCefnW8hmYHBwmxdBGl+KqOUocqKDpeu/WQgrYW6e3Qq9JeFAw5yBcDXgvfOqJEP1F CdwZN1JG5Gfadq3I6TDYXEeaNks7w2DlDCX6vvCuvEwqsjfcq5knRVZDxXoftd2vRg71yI1n +bi0xMBAX5ZLPs/z6QZfA5vZhDa+0uOWVf8OZPt2rA9hGimd5BOLah0j0WfzOWl9CGhS6Sp3 5310jDxen5PLcumxXFYqy/ehPTSl9JCvMc46BifqM9kUls1guX9TgnZU5COFlg485C4/Xn0w 76Jvc1CMHeJWRp/8YKaQdodBannusZyV4HlzMjZh/FLim5fzu/K7GlZrg9fuPrPVlpZqvX6f Mu8/OadOaJTaI51ur9yKino7e9qoujqWx/VyjRfeLz38yi+aOg3zodGuLnR5WGZM2E6yO9Qc cSVANjKc63NWSfFJ+gAVyfH6v0HFw0tGAwAA Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 11:29:51 -0000 --_000_DB7PR07MB56286B4A2702A5FF1915D1D6938D0DB7PR07MB5628eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Scott, Thank You for the review! Please see inline. >The summary of the review is ready with issues. > >The document describes how to enable a push notification service (PNS) to >wake a suspended SIP user agent. > >Due to the writing style, I found the document very difficult to understan= d. Maybe >the RFC editor can help with this, but it might be better if someone from = the working >group helped out with word-smithing. I have done quite a bit of word-smithing based on WGLC/AD reviews etc, but = if something is unclear I am of course very happy to fix that. >For security considerations, there are 3 entities involved in the communic= ations defined by this document: the >user agent (UA), the PNS server, and = the application server (in this case, a SIP proxy). The basic idea is that = the >UA registers with the PNS, obtaining a Push Resource ID (PRID). The UA= provides the PRID to the SIP proxy, and >then the SIP proxy presents the P= RID to the PNS along with a message for the UA, and the PNS uses the PRID t= o >route the message to the right UA. Correct. Note, though, that the "message" is only a push notification in order to wa= ke up the UA. The actual SIP message (that triggered the push notification)= will then be routed to the UA using normal SIP procedures. >The security considerations section mostly punts. With respect to UA-PNS i= nteractions, it says "The mechanisms >for authorizing and authenticating th= e users are PNS-specific, and are outside the scope of this document." It >= says nothing about how the UA authenticates the PNS. The UA-PNS interactions, including how the UA authenticates the PNS, are PN= S specific. >For application server (SIP proxy) to PNS interactions, it mentions the fa= ct that a PNS may requires some sort of >authz/authn for the SIP proxy, but= it gives no requirements/recommendations here. It later mentions a JWT >me= chanism for this purposes described in RFC8292, but again, no requirement, = no recommendation. The proxy-PNS interactions are also PNS specific, and not defined by this d= ocument. RFC8292 is an extension that can be used with the mechanism define= d in RFC8030, but it cannot be applied to any PNS on the fly. A PNS would h= ave to explicitly support it. >Also, it says > > Operators MUST ensure that the SIP signalling is properly secured, > e.g., using encryption, from malicious middlemen. TLS MUST be used, > unless the operators know that the signalling is secured using some > other mechanism. > >I don't think there is a clear requirement stated here. If an operator cho= oses a proprietary >scheme with weak crypto and claims that is "properly secured", have they m= et this requirement? I could say something like: "is secured using some other mechanism that pro= vides strong crypto properties". >Finally, I think RFC8030 has a good description of the security considerat= ions for this use case, and >should be referenced here. I can add a reference. However, while many of the security considerations i= n RFC8030 probably apply to any PNS, they are still written for a specific = PNS. Regards, Christesr --_000_DB7PR07MB56286B4A2702A5FF1915D1D6938D0DB7PR07MB5628eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Scott,


Thank You for the review! Please = see inline.


>The summary of the review is ready with issues= .
>
>The document describes how to enable a push notification service (PNS) = to 
>wake a suspended SIP user agent.
>
>Due to the writing style, I found the document very difficult to unders= tand. Maybe 
>the RFC editor can help with this, but it migh= t be better if someone from the working 
>group helped out with word-smithing.

I have done quite a bit of word-smithing based on = WGLC/AD reviews etc, but if something is unclear I am of course very happy = to fix that.

>For security considerations, there are 3 entities involved in the commu= nications defined by this document: the >user agent (UA), the PNS server= , and the application server (in this case, a SIP proxy). The basic idea is= that the >UA registers with the PNS, obtaining a Push Resource ID (PRID). The UA provides the PRID to the SIP p= roxy, and >then the SIP proxy presents the PRID to the PNS along with a = message for the UA, and the PNS uses the PRID to >route the message to t= he right UA.

Correct.

Note, though, that the "message" is only= a push notification in order to wake up the UA. The actual SIP message (th= at triggered the push notification) will then be routed to the UA using nor= mal SIP procedures.

>The security considerations section mostly pun= ts. With respect to UA-PNS interactions, it says "The mechanisms >f= or authorizing and authenticating the users are PNS-specific, and are outsi= de the scope of this document." It >says nothing about how the UA authenticates the PNS. 

The UA-PNS interactions, including how the UA auth= enticates the PNS, are PNS specific.

>For application server (SIP proxy) to PNS interactions, it mentions the= fact that a PNS may requires some sort of >authz/authn for the SIP prox= y, but it gives no requirements/recommendations here. It later mentions a J= WT >mechanism for this purposes described in RFC8292, but again, no requirement, no recommendation.

The proxy-PNS interactions are also PNS specific, = and not defined by this document. RFC8292 is an extension that can be used = with the mechanism defined in RFC8030, but it cannot be applied to any PNS = on the fly. A PNS would have to explicitly support it.

>Also, it says
>
  > Operators MUST ensure that the SIP signalling is properly secur= ed,
   > e.g., using encryption, from malicious middlemen.  T= LS MUST be used,
   > unless the operators know that the signalling is secured = using some
   > other mechanism.
>
>I don't think there is a clear requirement stated here. If an operator = chooses a proprietary 
>scheme with weak crypto and claims that is &qu= ot;properly secured", have they met this requirement? 

I could say something like: "is secured using= some other mechanism that provides strong crypto properties".

>Finally, I think RFC8030 has a good descriptio= n of the security considerations for this use case, and 
>should be referenced here.

I can add a reference. However, while many of the = security considerations in RFC8030 probably apply to any PNS, they are stil= l written for a specific PNS.

Regards,

Christesr

--_000_DB7PR07MB56286B4A2702A5FF1915D1D6938D0DB7PR07MB5628eurp_-- From nobody Thu Jan 3 04:04:07 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F8B12D4E8; Thu, 3 Jan 2019 04:03:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Cc: jmap@ietf.org, draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154651703823.29557.748556981627156046@ietfa.amsl.com> Date: Thu, 03 Jan 2019 04:03:58 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 12:03:58 -0000 Reviewer: Tero Kivinen Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is quite complicated JSON based meta application protocol, which allows all kind of operations to be done on the server. The security considerations lists most of the security concerns, including the fact that owner of the account can use push event notifications to cause denial of service attacks against 3rd party. Instead of just pointing it out, I think we should disallow that kind of DoS options, i.e., I think the push subscription needs to be extended to include initial verification step, i.e., when client registers a PushSubscription the server should immediately send one "event" notifying the creation of the push subscription and then when client sees that event it could verify that it can see it (this would also allow easy way to find out whether the given url actually works) and send verification token given in the first event back to server confirming that it can actually see the events. This would forbid client to set up denial service attacks against 3rd parties, and would also verify that the event channel is actually working, i.e. the url is accessible by the server and that the keys are correct etc. This document also has quite a lot of privacy concerns which are not addressed by it. For example email delivery and event notifications can leak lots of information even to passive attackers. I.e., if someone can see that wikileaks smtp server sends email to corporate smtp server, but the smtp traffic is encrypted so they do not know the recipient of the email, but then few seconds later see push event notification stream going to the Joe's laptop indicating something has happened in his mail box, they can find out the who the recipient was. Of course sharing mailboxes between multiple users (one of the examples given in 1.6.2), has lots of privacy issues. Perhaps some text explaining these issues would be needed in the security considerations section. Also I think it would be better example to say people share calendars, not mailboxes, as sharing calendars between different users is much more common than sharing mails. Group mailboxes do have their uses in cases of shared support mailbox, but it might be good idea to use that example instead of the current text in 1.6.2. I.e., user has their own primary mailbox, and then they also have access to shared support mailbox. From nobody Thu Jan 3 04:16:56 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC4E12D4EA for ; Thu, 3 Jan 2019 04:16:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <154651781469.29657.12090926037590934531.idtracker@ietfa.amsl.com> Date: Thu, 03 Jan 2019 04:16:54 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 12:16:55 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-01-10 Reviewer LC end Draft Phillip Hallam-Baker 2018-12-18 draft-ietf-rtgwg-spf-uloop-pb-statement-09 Phillip Hallam-Baker 2018-10-11 draft-ietf-softwire-yang-13 Steve Hanna 2018-12-18 draft-ietf-extra-sieve-fcc-08 Christian Huitema R2018-12-14 draft-ietf-v6ops-transition-ipv4aas-12 Last calls: Reviewer LC end Draft Daniel Gillmor 2018-03-19 draft-gutmann-scep-11 Leif Johansson 2018-12-24 draft-ietf-6lo-nfc-12 Chris Lonvick 2019-01-16 draft-ietf-dime-doic-rate-control-10 Aanchal Malhotra 2019-01-09 draft-ietf-curdle-rc4-die-die-die-14 Daniel Migault 2019-01-16 draft-ietf-dmm-ondemand-mobility-15 Matthew Miller 2019-01-14 draft-ietf-mile-xmpp-grid-09 Adam Montville 2019-01-10 draft-ietf-lamps-hash-of-root-key-cert-extn-02 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Stefan Santesson R2018-11-20 draft-wilde-service-link-rel-09 Samuel Weiler 2018-11-13 draft-ietf-dnsop-dns-capture-format-10 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-09 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Sean Turner 2018-11-25 draft-ietf-babel-dtls-02 Next in the reviewer rotation: Kathleen Moriarty Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper Tim Polk Vincent Roca From nobody Thu Jan 3 04:35:14 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F42D12D7F8; Thu, 3 Jan 2019 04:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq6wA6lHTNM8; Thu, 3 Jan 2019 04:35:04 -0800 (PST) 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 EB19612D4EC; Thu, 3 Jan 2019 04:35:03 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5291A13A9A; Thu, 3 Jan 2019 12:35:03 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-22.brq.redhat.com [10.40.200.22]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0BB3F5D9C5; Thu, 3 Jan 2019 12:34:56 +0000 (UTC) From: Hubert Kario To: David Mandelberg Cc: Simo Sorce , draft-ietf-curdle-gss-keyex-sha2.all@ietf.org, iesg@ietf.org, secdir@ietf.org Date: Thu, 03 Jan 2019 13:34:55 +0100 Message-ID: <3141157.mGRiuJCrJu@pintsize.usersys.redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2226211.2B9aJXgzh2"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 03 Jan 2019 12:35:03 +0000 (UTC) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-curdle-gss-keyex-sha2-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 12:35:06 -0000 --nextPart2226211.2B9aJXgzh2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 1 January 2019 21:33:31 CET David Mandelberg wrote: > On 1/1/19 9:06 AM, Simo Sorce wrote: > > On Mon, 2018-12-31 at 14:57 -0500, David Mandelberg wrote: > >> Section 5.1: When calculating H, are the boundaries between each > >> concatenated thing clear? E.g., would V_C =3D "1.21" V_S =3D "0.1" and= V_C =3D > >> "1.2" V_S =3D "10.1" result in the same value for H? > >=20 > > All else equal I think it would >=20 > Ok. I don't have any specific attacks in mind, but that seems like a > potential weak point. This probably isn't the right document to change > that in though. yes, we actually considered also making the key exchange secure against=20 quantum computer attacks, but decided to favour ease of implementation as m= ore=20 important; thus the resulting minimal changes compared to RFC 4462 =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2226211.2B9aJXgzh2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlwuAW8ACgkQkqjRuAHS 9fVGSQ//ZU80LhnbD6pse93OihTPYtwQDKmi2DLbyF1ET6I5sjoMS+hCMFWDLjzK Sj76LFjRWccgWTA7waz7STe/4Vu0gCGwy3SAqW8DDI0vZhl4pFejoLnciPPA6bp4 mNJYDPa5S7O8r9R0YudO0iMdNr0GVwn4gTGsa+Mz0FwG/by1rsYc5nlivG5o67+L dznhuZY8b1u5iIsnwfKqLnyOp00BEi6M65drunHNDJR6ZVVad9erB61ceK7Ey/XR ZcQcZToyZTS8XOqlO02EHiuRXROboWeU1+JqCmD28sh/fVx8HQ5iB9PgX4e6n/Se 7pT/7QZMSRIvgyOs1nE1JUZWoadwAyXw3V6jKWnRpMzSAtF4fWlyumr1+BpTAzzS urp45tbQcqpjpY4Rc8rTGnTPizmxxvWIvPwr8zRM2shpzQ4A18WwE+lbJLT0TgGp psVSnd6ONfyZa9WllP9LvJXDIHut4PGnE2dDzSUSZ4aPZDYTJJtETp1AxNzpnRXX p3Aa7keRo1j527PkkuzG0JQ7JqbZuPX18Ud3HrSNwm0m1wZx+EkrYXSm4FVtbnM5 +JRbGmeDWBlKgjZBmtxFwN+dXLMgPg4ibftks4Ie8BMVJfPH4yRPrnLZ0aQKy56a KllaVPR7GGnz0Vda4BoChS59AxJOX1UfgGZBLQ1dEw2oVjhaEf8= =w7mg -----END PGP SIGNATURE----- --nextPart2226211.2B9aJXgzh2-- From nobody Thu Jan 3 09:21:30 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC421311BC for ; Thu, 3 Jan 2019 09:21: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF9_68ZP3p7R for ; Thu, 3 Jan 2019 09:21:25 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 1C4D31311BA for ; Thu, 3 Jan 2019 09:21:25 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id i145so46188962ita.4 for ; Thu, 03 Jan 2019 09:21:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6vMn7htPIDVTMG3vdYiac13Q/33PjJycg5SNJcgrrOM=; b=MUFgbIbiDM5QPjHxqRvEZaAzV8QhUHTN1DUI8cXTTB4ARL8YZ8Gk2Xk0j0DZoXm2pl OxMpU69jxUMWuD3pVtkdhADY/+Bzx+mT8b9xbADC34B80JQeA7Rsn2eRoLWyiXgrYjRN Au26ssQWvmaI2w+tVGI/jTVWXGN3P/MwHP8qQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6vMn7htPIDVTMG3vdYiac13Q/33PjJycg5SNJcgrrOM=; b=aIYoy5ozoZR3WvoFVof8nOoWNouiNGKQ9N/K/ItHr1DScKQwW8KPKuqvKQiO/jbx9Q HQ7JtvzDiW8jLrulVGpQI/cSpI9fWuzyTX7qPROayRoq/jLuaOH/eCX/IB9rnNJjEBJn W0KDLohfg4JnmanLCddkrAWEgZmHgvseBBmBpGGH6dad+XOnC/O3+Qo9dxXZMWsf+bbI KCY72sysoD5T5zEoOeF91HY+SuVlpPDixmZ+CoAGkpkMp7HTlLFNjAGwSNZTx1xXw6uy PJRQEjUHUwJH3PVroQ4tp795RTwHwn0z8tOMtHph/qNZAYXjQI7A3wXD+i0fh+UiqELv MLcA== X-Gm-Message-State: AA+aEWaZmNjvL02N2A4BKJPpK/gGQhNKsk1jjl3dFJbQtiW5/Zhqzojh fl0+6TaZtE5C91ckmcNpCkyXXh5qjz7cinD1diraRQ== X-Google-Smtp-Source: AFSGD/WAe2NQou/Az76GN6+ksX6yyZtr57wB/nbOoJAe/tyCeGaQtBv1P2sXTp6wvBYNoFGo5yFRNPXmYtT/RYyUFIg= X-Received: by 2002:a24:3282:: with SMTP id j124mr31364799ita.173.1546536084187; Thu, 03 Jan 2019 09:21:24 -0800 (PST) MIME-Version: 1.0 References: <154651703823.29557.748556981627156046@ietfa.amsl.com> In-Reply-To: <154651703823.29557.748556981627156046@ietfa.amsl.com> From: "Kurt Andersen (IETF)" Date: Thu, 3 Jan 2019 09:21:12 -0800 Message-ID: To: Tero Kivinen Cc: secdir@ietf.org, IETF JMAP Mailing List , draft-ietf-jmap-core.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000ee3618057e90fd32" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 17:21:28 -0000 --000000000000ee3618057e90fd32 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen wrote: > Reviewer: Tero Kivinen > Review result: Has Issues > > This document also has quite a lot of privacy concerns which are not > addressed by it. For example email delivery and event notifications can > leak lots of information even to passive attackers. > How is this any different than the risks present in current mechanisms (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a new risk being introduced by the JMAP protocol. Of course sharing mailboxes between multiple users (one of the > examples given in 1.6.2), has lots of privacy issues. > Again, this is not a new risk being introduced by JMAP. It seems unfair to saddle the JMAP protocol with the responsibility of documenting a comprehensive set of privacy and security risks for bad or risky behaviours that have been a wide part of common practice for decades. --Kurt Andersen --000000000000ee3618057e90fd32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jan 3, 2019 at 4:04 AM Tero Kivin= en <kivinen@iki.fi> wrote:
<= /div>
Reviewer: Tero Kivinen
Review result: Has Issues

This document also has quite a lot of privacy concerns which are not
addressed by it. For example email delivery and event notifications can
leak lots of information even to passive attackers.
How is this any different than the risks present in current me= chanisms (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a ne= w risk being introduced by the JMAP protocol.

Of course sharing mailboxes between multiple users (one of the
examples given in 1.6.2), has lots of privacy issues.=C2=A0

Again, this is not a new risk being introduced by JMAP= . It seems unfair to saddle the JMAP protocol with the responsibility of do= cumenting a comprehensive set of privacy and security risks for bad or risk= y behaviours that have been a wide part of common practice for decades.

--Kurt Andersen
--000000000000ee3618057e90fd32-- From nobody Thu Jan 3 16:31:53 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E5913139F; Thu, 3 Jan 2019 16:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DfxrA0QpGJW; Thu, 3 Jan 2019 16:31:43 -0800 (PST) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (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 3B276131392; Thu, 3 Jan 2019 16:31:43 -0800 (PST) Received: by mail-io1-f43.google.com with SMTP id s22so28400127ioc.8; Thu, 03 Jan 2019 16:31:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/lHtNsfmhEuWLztp8kozShaHhIyxsp7bffxLLvOMEyM=; b=S7BWYxANcmhS/CwLz/AIt3d5h5NORzultpIMLvx04y956DvundqFt3yJwwl96vjHOZ /iEQnawqVUfVO7/e54HiGMOedbMtJyOpOPY3I1A1KF01d/gtSXevyRbve41uAVOsQjuy d2hN7hgpXRqZ6rSJ6Jpm+1bX6Nq6i9szMqGiHpnIx332GNEiPm/4+CjxDXBCLljFzPhI uu168QzrJryX1kF/OfJguDCKmbt150l/NZJOVLGK9BPNMQ/a8k+m2pIlmyXgw3FJej+M mK+nVqc3h0w4pIvzu5u/0HKlXtCHd9inbCa6cjqt3U62ABqyzPJod1q7KLFc/qrV3XMC fMiQ== X-Gm-Message-State: AJcUukeITUI5fAYiyO86C0Wn3oFYtrVuTkufjD8qLPe4ro1+ihkd7zb6 4zOg20sqNbo+xqeEoc9yeM9bUonRYQtxyTGuLTjgtsIv X-Google-Smtp-Source: ALg8bN47cmj+6JaA3NVDOxVCFEiyRVdPu1k07xUmsUnp6H0ieXZa+yexzHpHJGNm7/i1wiPS+4DE2Bab65DAkXg1eR4= X-Received: by 2002:a6b:6814:: with SMTP id d20mr26970253ioc.76.1546561902248; Thu, 03 Jan 2019 16:31:42 -0800 (PST) MIME-Version: 1.0 References: <154651703823.29557.748556981627156046@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Fri, 4 Jan 2019 08:31:31 +0800 Message-ID: To: "Kurt Andersen (IETF)" Cc: IETF JMAP Mailing List , Tero Kivinen , draft-ietf-jmap-core.all@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="000000000000ce8899057e9700a4" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 00:31:46 -0000 --000000000000ce8899057e9700a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think that advice to use TLS whenever possible is the extent of what makes sense to say here. As to shared folders, that is neither =E2=80=9Cbad=E2=80=9D nor =E2=80=9Cri= sky=E2=80=9D: it=E2=80=99s necessary for many use cases. For example, IETF itself uses shared IMAP folders to serve up our mailing lists. Help desks will use a shared inbox for, say, ithelp@example.com, to allow multiple agents to handle questions and complaints, while maintaining accountability (each agent has a separate login, so their activity is tracked). Barry On Fri, Jan 4, 2019 at 1:21 AM Kurt Andersen (IETF) wrote: > On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen wrote: > >> Reviewer: Tero Kivinen >> Review result: Has Issues >> >> This document also has quite a lot of privacy concerns which are not >> addressed by it. For example email delivery and event notifications can >> leak lots of information even to passive attackers. >> > > How is this any different than the risks present in current mechanisms > (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a new risk bein= g > introduced by the JMAP protocol. > > Of course sharing mailboxes between multiple users (one of the >> examples given in 1.6.2), has lots of privacy issues. >> > > Again, this is not a new risk being introduced by JMAP. It seems unfair t= o > saddle the JMAP protocol with the responsibility of documenting a > comprehensive set of privacy and security risks for bad or risky behaviou= rs > that have been a wide part of common practice for decades. > > --Kurt Andersen > --000000000000ce8899057e9700a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think that advice to use TLS whenever possible is = the extent of what makes sense to say here.
As to shared folders, that is neither =E2=80=9Cba= d=E2=80=9D nor =E2=80=9Crisky=E2=80=9D: it=E2=80=99s necessary for many use= cases.=C2=A0 For example, IETF itself uses shared IMAP folders to serve up= our mailing lists.=C2=A0 Help desks will use a shared inbox for, say, ithelp@example.com, to allow multiple= agents to handle questions and complaints, while maintaining accountabilit= y (each agent has a separate login, so their activity is tracked).

Barry

On Fri, Jan 4, 2019 at 1:21 AM Kurt Ander= sen (IETF) <kurta+ietf@drkurt= .com> wrote:
On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen <kivinen@iki.fi> wrote:<= br>
Reviewer: Tero Kivinen
Review result: Has Issues

This document also has quite a lot of privacy concerns which are not
addressed by it. For example email delivery and event notifications can
leak lots of information even to passive attackers.
How is this any different than the risks present in current me= chanisms (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a ne= w risk being introduced by the JMAP protocol.

Of course sharing mailboxes between multiple users (one of the
examples given in 1.6.2), has lots of privacy issues.=C2=A0

Again, this is not a new risk being introduced by JMAP= . It seems unfair to saddle the JMAP protocol with the responsibility of do= cumenting a comprehensive set of privacy and security risks for bad or risk= y behaviours that have been a wide part of common practice for decades.

--Kurt Andersen
--000000000000ce8899057e9700a4-- From nobody Fri Jan 4 11:23:12 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B05D130E85; Fri, 4 Jan 2019 11:23:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Aanchal Malhotra To: Cc: draft-ietf-curdle-rc4-die-die-die.all@ietf.org, curdle@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154662979022.18330.1962344830222794471@ietfa.amsl.com> Date: Fri, 04 Jan 2019 11:23:10 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-curdle-rc4-die-die-die-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 19:23:11 -0000 Reviewer: Aanchal Malhotra Review result: Ready I think the document is ready to advance. Just a minor editorial comment: Section 1 : There is a redundant 'the' in the third sentence. From nobody Fri Jan 4 11:46:37 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03795130E8E for ; Fri, 4 Jan 2019 11:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFU9vhn_y_GE for ; Fri, 4 Jan 2019 11:46:27 -0800 (PST) Received: from smtp98.iad3a.emailsrvr.com (smtp98.iad3a.emailsrvr.com [173.203.187.98]) (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 14A01130E8F for ; Fri, 4 Jan 2019 11:46:26 -0800 (PST) Received: from smtp13.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id CF4C756EC; Fri, 4 Jan 2019 14:46:24 -0500 (EST) Received: from app28.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B07E256F0; Fri, 4 Jan 2019 14:46:24 -0500 (EST) X-Sender-Id: scott@hyperthought.com Received: from app28.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Fri, 04 Jan 2019 14:46:24 -0500 Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app28.wa-webapps.iad3a (Postfix) with ESMTP id 9F06621A61; Fri, 4 Jan 2019 14:46:24 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Fri, 4 Jan 2019 11:46:24 -0800 (PST) X-Auth-ID: scott@hyperthought.com Date: Fri, 4 Jan 2019 11:46:24 -0800 (PST) From: "Scott G. Kelly" To: "Christer Holmberg" Cc: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-sipcore-sip-push.all@ietf.org" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: References: <1546285539.44113084@apps.rackspace.com> Message-ID: <1546631184.64914945@apps.rackspace.com> X-Mailer: webmail/15.4.8-RC Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 19:46:29 -0000 Hi Christer,=0A=0AOn Thursday, January 3, 2019 3:29am, "Christer Holmberg" = said:=0A=0A> Hi Scott,=0A> =0A> =0A> Thank= You for the review! Please see inline.=0A> =0A> =0A>>The summary of the re= view is ready with issues.=0A>>=0A>>The document describes how to enable a = push notification service (PNS) to=0A>>wake a suspended SIP user agent.=0A>= >=0A>>Due to the writing style, I found the document very difficult to unde= rstand.=0A>> Maybe=0A>>the RFC editor can help with this, but it might be b= etter if someone from the=0A>> working=0A>>group helped out with word-smith= ing.=0A> =0A> I have done quite a bit of word-smithing based on WGLC/AD rev= iews etc, but if=0A> something is unclear I am of course very happy to fix = that.=0A=0AI don't want to go through the whole document again, and I don't= want to make too big a deal of this (the RFC editor has final say) but her= e are a few examples of things I had to read more than once to understand:= =0A=0A Because of the restrictions above, Session Initiation Protocol (SI= P)=0A User Agents (UAs) [RFC3261] can not be awoken, in order to send=0A = binding-refresh SIP REGISTER requests and to receive incoming SIP=0A re= quests, without using a PNS to wake the UA in order to perform=0A those f= unctions.=0A=0A=0A In addition to the information that needs to be=0A e= xchanged between a device and the PNS in order to establish a push=0A not= ification subscription, the mechanism defined in this document=0A does no= t require any additional information to be exchanged between=0A the devic= e and the PNS.=0A=0A> =0A>>For security considerations, there are 3 entitie= s involved in the communications=0A>> defined by this document: the >user a= gent (UA), the PNS server, and the=0A>> application server (in this case, a= SIP proxy). The basic idea is that the >UA=0A>> registers with the PNS, ob= taining a Push Resource ID (PRID). The UA provides the=0A>> PRID to the SIP= proxy, and >then the SIP proxy presents the PRID to the PNS along=0A>> wit= h a message for the UA, and the PNS uses the PRID to >route the message to = the=0A>> right UA.=0A> =0A> Correct.=0A> =0A> Note, though, that the "messa= ge" is only a push notification in order to wake up=0A> the UA. The actual = SIP message (that triggered the push notification) will then be=0A> routed = to the UA using normal SIP procedures.=0A> =0A>>The security considerations= section mostly punts. With respect to UA-PNS=0A>> interactions, it says "T= he mechanisms >for authorizing and authenticating the=0A>> users are PNS-sp= ecific, and are outside the scope of this document." It >says=0A>> nothing = about how the UA authenticates the PNS.=0A> =0A> The UA-PNS interactions, i= ncluding how the UA authenticates the PNS, are PNS=0A> specific.=0A> =0A>>F= or application server (SIP proxy) to PNS interactions, it mentions the fact= that=0A>> a PNS may requires some sort of >authz/authn for the SIP proxy, = but it gives no=0A>> requirements/recommendations here. It later mentions a= JWT >mechanism for this=0A>> purposes described in RFC8292, but again, no = requirement, no recommendation.=0A> =0A> The proxy-PNS interactions are als= o PNS specific, and not defined by this=0A> document. RFC8292 is an extensi= on that can be used with the mechanism defined in=0A> RFC8030, but it canno= t be applied to any PNS on the fly. A PNS would have to=0A> explicitly supp= ort it.=0A> =0A>>Also, it says=0A>>=0A> > Operators MUST ensure that the = SIP signalling is properly secured,=0A> > e.g., using encryption, from m= alicious middlemen. TLS MUST be used,=0A> > unless the operators know t= hat the signalling is secured using some=0A> > other mechanism.=0A>>=0A>= >I don't think there is a clear requirement stated here. If an operator cho= oses a=0A>> proprietary=0A>>scheme with weak crypto and claims that is "pro= perly secured", have they met this=0A>> requirement?=0A> =0A> I could say s= omething like: "is secured using some other mechanism that provides=0A> str= ong crypto properties".=0A> =0A>>Finally, I think RFC8030 has a good descri= ption of the security considerations for=0A>> this use case, and=0A>>should= be referenced here.=0A> =0A> I can add a reference. However, while many of= the security considerations in=0A> RFC8030 probably apply to any PNS, they= are still written for a specific PNS.=0A=0A=0AI don't know what other docu= ments have been produced by the WG, so maybe this is covered elsewhere, but= there are generic security considerations that apply abstractly to this us= e case. I think this document should either point to documents that describ= e them, or explicitly describe them here. For example, 8030 lists confident= iality with respect to the PNS, privacy considerations, authorization, DoS,= and logging risks. All of those apply here.=0A=0A=0AThanks,=0A=0AScott=0A= =0A From nobody Fri Jan 4 14:10:59 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A18130E90; Fri, 4 Jan 2019 14:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_GoaJV21sNr; Fri, 4 Jan 2019 14:10:49 -0800 (PST) Received: from mauve.mrochek.com (unknown [66.159.242.17]) (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 2F7BC126BED; Fri, 4 Jan 2019 14:10:49 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1M7QJJPG000AVXT@mauve.mrochek.com>; Fri, 4 Jan 2019 14:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1546639545; bh=kkXce7HsCIDRBhoN1l8cVfW+AEXOob5s5Yj/yXjMRp0=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=gZkOylh7WTm1Wrdtb+eRtO9TdY58lY1yOL/JvQA8i2RlpnhXTfh+tzv56GmZXo4zW csfFWywde8W1esxzfgArNwTkWzbtlbW6Wu4b/191wx8okz33w8KkQPdcW/wwN+GL+D I332p1fpU3XwcMSm3E1K2oW2u+7NeGZfIcY9oDqU= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1LW7PXKJ400004R@mauve.mrochek.com>; Fri, 4 Jan 2019 14:05:41 -0800 (PST) Cc: Tero Kivinen , IETF JMAP Mailing List , draft-ietf-jmap-core.all@ietf.org, secdir@ietf.org Message-id: <01R1M7QIBP9I00004R@mauve.mrochek.com> Date: Fri, 04 Jan 2019 13:45:49 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 03 Jan 2019 09:21:12 -0800" References: <154651703823.29557.748556981627156046@ietfa.amsl.com> To: "Kurt Andersen (IETF)" Archived-At: Subject: Re: [secdir] [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 22:10:50 -0000 > On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen wrote: > > Reviewer: Tero Kivinen > > Review result: Has Issues > > > > This document also has quite a lot of privacy concerns which are not > > addressed by it. For example email delivery and event notifications can > > leak lots of information even to passive attackers. > > > How is this any different than the risks present in current mechanisms > (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a new risk being > introduced by the JMAP protocol. AFAICT it's different in the sense that this is the first push email notification mechanism we have standardized. Push notifications also aren't mentioned in RFC 5598. So we get stuck with documenting the security concerns. An update to RFC5598 may also be order, but that's a problem for another day. > > Of course sharing mailboxes between multiple users (one of the > > examples given in 1.6.2), has lots of privacy issues. > Again, this is not a new risk being introduced by JMAP. It seems unfair to > saddle the JMAP protocol with the responsibility of documenting a > comprehensive set of privacy and security risks for bad or risky behaviours > that have been a wide part of common practice for decades. I'll first note that although the JMAP specification refers to the IMAP ACL security model extensively, RFC 4314 is not in the references list. That needs to be fixed, and a note in the security considerations section saying that the security considerations for IMAP ACLs apply to JMAP would also be good. And if the security considerations in the IMAP ACL document are deemed to be insufficient, further elaboration of some additional points may also be in order. As for fairness, the goal here is to produce quality standards. Sometimes achieving that goal means you get stuck with stuff you'd rather not have to do. Ned From nobody Fri Jan 4 15:00:19 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436D5130EA1; Fri, 4 Jan 2019 15:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0e2L44XmxcYy; Fri, 4 Jan 2019 15:00:07 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 12F9C126BED; Fri, 4 Jan 2019 15:00:06 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x04N023K004057 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 5 Jan 2019 01:00:02 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x04N02MQ020933; Sat, 5 Jan 2019 01:00:02 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <23599.58738.605524.89790@fireball.acr.fi> Date: Sat, 5 Jan 2019 01:00:02 +0200 From: Tero Kivinen To: "Kurt Andersen \(IETF\)" Cc: secdir@ietf.org, IETF JMAP Mailing List , draft-ietf-jmap-core.all@ietf.org In-Reply-To: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 12 min Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 23:00:10 -0000 Kurt Andersen (IETF) writes: > On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen wrote: >=20 > Reviewer: Tero Kivinen > Review result: Has Issues > =20 > This document also has quite a lot of privacy concerns which are = not > addressed by it. For example email delivery and event notificatio= ns can > leak lots of information even to passive attackers. >=20 > How is this any different than the risks present in current mechanism= s > (websockets, HTTP, MAPI, IMAP, etc.)=3F I don't see this as a new ris= k being > introduced by the JMAP protocol. There is some similarities and differences. For example http does not have built in event notification system. In most of the other protocols the event system notification system is built on top of the other protocol running over for example http. Here if I understood correctly the event notifications are generated automatically and application writer using generic JMAP server backend might not even have any control how those events are generated and when they are generated. Because of this I think this issue belongs to the JMAP protocol document. The main difference with event notification system is, that it is not between the two peers running the JMAP protocol, or two parties running some external API connected to JMAP. It involves the third party, i.e., the party where the notifications are sent to.=20 Also the examples given in the document talk about mail, calendar, contacts etc, which all are data related to privacy and where there are lots of privacy issues, so clearly this JMAP is designed to be used in environments where privacy concerns are important, but still it is silent about them.=20 > Of course sharing mailboxes between multiple users (one of the > examples given in 1.6.2), has lots of privacy issues.=A0 >=20 > Again, this is not a new risk being introduced by JMAP. It seems unfa= ir to > saddle the JMAP protocol with the responsibility of documenting a com= prehensive > set of privacy and security risks for bad or risky behaviours that ha= ve been a > wide part of common practice for decades. If you provide example of bad and risky behaviours in your document, you need to also include the warnings about it. Thats why I did suggested you using different example (i.e., shared work calendar, shared between co-workers, or shared calendar between family members). And if you write protocol that can be used to do all kind of things you should really write comprehensive set of privacy and security risks inherintly associated with the JMAP protocol, and also include some generic warnings about common mistakes that users of JMAP can do.=20= --=20 kivinen@iki.fi From nobody Fri Jan 4 15:10:13 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACDA130EA2; Fri, 4 Jan 2019 15:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UKthjD4mCPm; Fri, 4 Jan 2019 15:10:03 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 49215126BED; Fri, 4 Jan 2019 15:10:03 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x04N9vP9021362 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 5 Jan 2019 01:09:57 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x04N9vWC011125; Sat, 5 Jan 2019 01:09:57 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <23599.59333.151268.270953@fireball.acr.fi> Date: Sat, 5 Jan 2019 01:09:57 +0200 From: Tero Kivinen To: Barry Leiba Cc: "Kurt Andersen \(IETF\)" , IETF JMAP Mailing List , draft-ietf-jmap-core.all@ietf.org, secdir@ietf.org In-Reply-To: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 8 min Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 23:10:06 -0000 Barry Leiba writes: > I think that advice to use TLS whenever possible is the extent of > what makes sense to say here. Using TLS does not help here, as this attack is traffic analysis attack, and you can do traffic analysis even when all the traffic is encrypted. The current draft already says that all request MUST use TLS. > As to shared folders, that is neither =E2=80=9Cbad=E2=80=9D nor =E2=80= =9Crisky=E2=80=9D: it=E2=80=99s necessary for > many use cases.=C2=A0 For example, IETF itself uses shared IMAP folde= rs to serve up > our mailing lists.=C2=A0 Help desks will use a shared inbox for, say,= =20 > ithelp@example.com, to allow multiple agents to handle questions and > complaints, while maintaining accountability (each agent has a separa= te login, > so their activity is tracked). Agreed. I was not saying it is bad or risky, but the none of the examples you gave are not really examples of ... if another user is sharing their mail with the logged in user, ... All of those are examples of user gaining access of group account (which is also mentioned). So my comment was that two individual users sharing their individual mails with each other is not really that common, and has much more privacy concerns than it help desk having shared inbox. Sharing calendar entries also has privacy concerns, but most people do understand them better and calendars provide ways of separating private / public entries already. So, I think changing the text: A single set of credentials may provide access to multiple accounts,= for example if another user is sharing their mail with the logged in= user, or if there is a group account. to something like this: A single set of credentials may provide access to multiple accounts, for example if another user is sharing their work calendar information with the logged in user. Another example of cases where access to multiple accounts can be useful is when logged in user can also access shared group account mailbox (for example it help desk inbox). would make the text better.=20 --=20 kivinen@iki.fi From nobody Fri Jan 4 15:10:25 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6B2130F17; Fri, 4 Jan 2019 15:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90tITB1vv8VN; Fri, 4 Jan 2019 15:10:13 -0800 (PST) Received: from relay-exchange.andrew.cmu.edu (RELAY-EXCH-06.ANDREW.CMU.EDU [128.2.157.23]) (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 E165F130F2A; Fri, 4 Jan 2019 15:10:12 -0800 (PST) Received: from dcns-msgp-05.andrew.ad.cmu.edu (DCNS-MSGP-05.ANDREW.AD.CMU.EDU [128.2.157.89]) by relay-exchange.andrew.cmu.edu (8.15.2/8.15.2) with ESMTPS id x04NABM7100878 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 4 Jan 2019 18:10:11 -0500 Received: from dcns-msgp-03.andrew.ad.cmu.edu (128.2.157.87) by dcns-msgp-05.andrew.ad.cmu.edu (128.2.157.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1591.10; Fri, 4 Jan 2019 18:10:10 -0500 Received: from dcns-msgp-03.andrew.ad.cmu.edu ([128.2.157.87]) by dcns-msgp-03.andrew.ad.cmu.edu ([128.2.157.87]) with mapi id 15.01.1591.008; Fri, 4 Jan 2019 18:10:10 -0500 From: Jeffrey Hutzelman To: Ned Freed , "Kurt Andersen (IETF)" CC: IETF JMAP Mailing List , "draft-ietf-jmap-core.all@ietf.org" , "secdir@ietf.org" Thread-Topic: [secdir] [Jmap] Secdir last call review of draft-ietf-jmap-core-12 Thread-Index: AQHUpHpfuK2jQo3itUebxw51h9uhn6Wftx/H Date: Fri, 4 Jan 2019 23:10:10 +0000 Message-ID: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> , <01R1M7QIBP9I00004R@mauve.mrochek.com> In-Reply-To: <01R1M7QIBP9I00004R@mauve.mrochek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.2.42.4] Content-Type: multipart/alternative; boundary="_000_a7fdf568d65e4d5aa60201dcfc5c45e0cmuedu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 128.2.157.23 Archived-At: Subject: Re: [secdir] [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 23:10:16 -0000 --_000_a7fdf568d65e4d5aa60201dcfc5c45e0cmuedu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: secdir on behalf of Ned Freed Sent: Friday, January 4, 2019 4:45 PM To: Kurt Andersen (IETF) Cc: IETF JMAP Mailing List; draft-ietf-jmap-core.all@ietf.org; secdir@ietf.= org Subject: Re: [secdir] [Jmap] Secdir last call review of draft-ietf-jmap-cor= e-12 > On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen wrote: > > Reviewer: Tero Kivinen > > Review result: Has Issues > > > > This document also has quite a lot of privacy concerns which are not > > addressed by it. For example email delivery and event notifications can > > leak lots of information even to passive attackers. > > > How is this any different than the risks present in current mechanisms > (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a new risk bein= g > introduced by the JMAP protocol. AFAICT it's different in the sense that this is the first push email notification mechanism we have standardized. Push notifications also aren't mentioned in RFC 5598. So we get stuck with documenting the security concerns. It may be the first such mechanism we've standardized, but it's certainly n= ot the first time we've contemplated push notification of email delivery. C= onsider RFC5435 (the Sieve notify extension), published just about 10 years= ago this month. Among other things, it contains extensive discussion of se= curity considerations surrounding push notification. > > Of course sharing mailboxes between multiple users (one of the > > examples given in 1.6.2), has lots of privacy issues. > Again, this is not a new risk being introduced by JMAP. It seems unfair t= o > saddle the JMAP protocol with the responsibility of documenting a > comprehensive set of privacy and security risks for bad or risky behaviou= rs > that have been a wide part of common practice for decades. I'll first note that although the JMAP specification refers to the IMAP ACL security model extensively, RFC 4314 is not in the references list. That ne= eds to be fixed, and a note in the security considerations section saying that = the security considerations for IMAP ACLs apply to JMAP would also be good. And if the security considerations in the IMAP ACL document are deemed to be insufficient, further elaboration of some additional points ma= y also be in order. As for fairness, the goal here is to produce quality standards. Sometimes achieving that goal means you get stuck with stuff you'd rather not have to do. True, but shared mailboxes are hardly new. They've been around pretty much = since the beginning of time. Giving advice to operators about security and = privacy issues surrounding shared mailboxes or any of a number of common us= er practices seems, to me, to be far out of scope for an access protocol sp= ecification. That's not to say that JMAP doesn't need to document security issues; of co= urse it does. If those are substantially similar to, say, IMAP, then the do= cumentation is going to be, too. And if there are issues that were missed i= n the past or have only recently become topics of discussion, that doesn't = mean they can just be ignored. But I do think it's important to keep the sc= ope manageable. -- Jeff --_000_a7fdf568d65e4d5aa60201dcfc5c45e0cmuedu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

From: secdir <secdir-b= ounces@ietf.org> on behalf of Ned Freed <ned.freed@mrochek.com>
Sent: Friday, January 4, = 2019 4:45 PM
To: Kurt Andersen (IETF)<= /font>
Cc: IETF JMAP Mailing Lis= t; draft-ietf-jmap-core.all@ietf.org; secdir@ietf.org
Subject: Re: [secdir] [Jm= ap] Secdir last call review of draft-ietf-jmap-core-12
 
> On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen &= lt;kivinen@iki.fi> wrote:

> > Reviewer: Tero Kivinen
> > Review result: Has Issues
> >
> > This document also has quite a lot of pr= ivacy concerns which are not
> > addressed by it. For example email deliv= ery and event notifications can
> > leak lots of information even to passive= attackers.
> >

> How is this any different than the risks pres= ent in current mechanisms
> (websockets, HTTP, MAPI, IMAP, etc.)? I don't= see this as a new risk being
> introduced by the JMAP protocol.

AFAICT it's different in the sense that this is th= e first push email
notification mechanism we have standardized. Push = notifications also
aren't mentioned in RFC 5598.

So we get stuck with documenting the security conc= erns.

It may be the first such mechanism we= 've standardized, but it's certainly not the first time we've contemplated = push notification of email delivery. Consider RFC5435 (the Sieve notify ext= ension), published just about 10 years ago this month. Among other things, it contains extensive discussion of se= curity considerations surrounding push notification.



> > Of course sharing mailboxes between mult= iple users (one of the
> > examples given in 1.6.2), has lots of pr= ivacy issues.

> Again, this is not a new risk being introduce= d by JMAP. It seems unfair to
> saddle the JMAP protocol with the responsibil= ity of documenting a
> comprehensive set of privacy and security ris= ks for bad or risky behaviours
> that have been a wide part of common practice= for decades.

I'll first note that although the JMAP specificati= on refers to the IMAP ACL
security model extensively, RFC 4314 is not in the= references list. That needs
to be fixed, and a note in the security considerat= ions section saying that the
security considerations for IMAP ACLs apply to JMA= P would also be good.

And if the security considerations in the IMAP ACL= document are
deemed to be insufficient, further elaboration of = some additional points may
also be in order.

As for fairness, the goal here is to produce quali= ty standards. Sometimes
achieving that goal means you get stuck with stuff= you'd rather not have
to do.

True, but shared mailboxes are hardly new. They've= been around pretty much since the beginning of time. Giving advice to oper= ators about security and privacy issues surrounding shared mailboxes or any= of a number of common user practices seems, to me, to be far out of scope for an access protocol specification.=

That's not to say that JMAP doesn't need to docume= nt security issues; of course it does. If those are substantially similar t= o, say, IMAP, then the documentation is going to be, too. And if there are = issues that were missed in the past or have only recently become topics of discussion, that doesn't mean they = can just be ignored. But I do think it's important to keep the scope manage= able.

-- Jeff
--_000_a7fdf568d65e4d5aa60201dcfc5c45e0cmuedu_-- From nobody Fri Jan 4 15:15:56 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C173126BED; Fri, 4 Jan 2019 15:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZC78ddeJUfj; Fri, 4 Jan 2019 15:15:53 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 31F1C130EA2; Fri, 4 Jan 2019 15:15:53 -0800 (PST) Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x04NFi8D023254 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 4 Jan 2019 17:15:46 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1546643747; bh=nUkiXTa7ghxtDEZfTfSt/DcfwZQRSe2zHSHFNG4JiTs=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=B70UW7MMKA7AksamQB5P1fi9NAUktRxsrCQ2h4Z8tyJPm7X0mxVrMdnZ0yygp8qjv LEv+9UCF3J3N3s4dvGsyTrUfcENMEq/azVnyc5NfjXjCWeMHqTSueWX9uiF9kBSESu WpZMUy33jx+H4w8GR+c0X+pXyxs84gws8C4HdZlo= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45] Content-Type: multipart/signed; boundary="Apple-Mail=_3C6786DD-9419-4F77-8A29-3A03954C10D8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Ben Campbell X-Priority: 3 (Normal) In-Reply-To: <1546631184.64914945@apps.rackspace.com> Date: Fri, 4 Jan 2019 17:15:43 -0600 Cc: Christer Holmberg , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-sipcore-sip-push.all@ietf.org" Message-Id: <215DF6BE-69A3-4394-9BE2-EE7751957E07@nostrum.com> References: <1546285539.44113084@apps.rackspace.com> <1546631184.64914945@apps.rackspace.com> To: "Scott G. Kelly" X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 23:15:55 -0000 --Apple-Mail=_3C6786DD-9419-4F77-8A29-3A03954C10D8 Content-Type: multipart/alternative; boundary="Apple-Mail=_66AD2885-487C-4F57-8CBC-B8EEB7736BAB" --Apple-Mail=_66AD2885-487C-4F57-8CBC-B8EEB7736BAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (Speaking as responsible ART AD) I will let Christer work through most of the comments, but I want to = comment on one in particular: > On Jan 4, 2019, at 1:46 PM, Scott G. Kelly = wrote: >=20 > I don't know what other documents have been produced by the WG, so = maybe this is covered elsewhere, but there are generic security = considerations that apply abstractly to this use case. I think this = document should either point to documents that describe them, or = explicitly describe them here. For example, 8030 lists confidentiality = with respect to the PNS, privacy considerations, authorization, DoS, and = logging risks. All of those apply here. This draft is about how to carry some parameters in SIP that get used = with an external PNS. It should definitely document security = considerations related to carrying those parameters. But I don=E2=80=99t = think it=E2=80=99s reasonable to expect this draft to document security = considerations for PNSs in general. That=E2=80=99s up to the spec for = the PNS itself. I recognize that two of the mentioned PNSs are = proprietary; but I still don=E2=80=99t think that puts the onus on the = IETF to document their security considerations. The categories you mention from 8030 do seem generic, but the text in = the respective sections of 8030 seems fairly specific to HTTP(S) Push. That all being said, I would be happy to see something to the effect of = the following in this draft: =E2=80=9CThe security considerations for = the use and operation of any particular PNS is out of scope for this = document. [RFC8030] documents the security considerations for HTTP Push. = Security considerations for other PNSs are left to their respective = specifications.=E2=80=9D Thanks! Ben. --Apple-Mail=_66AD2885-487C-4F57-8CBC-B8EEB7736BAB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 (Speaking as responsible ART AD)

I will let Christer work through most = of the comments, but I want to comment on one in particular:

On Jan 4, 2019, at 1:46 PM, Scott G. Kelly <scott@hyperthought.com> wrote:

I don't know what other = documents have been produced by the WG, so maybe this is covered = elsewhere, but there are generic security considerations that apply = abstractly to this use case. I think this document should either point = to documents that describe them, or explicitly describe them here. For = example, 8030 lists confidentiality with respect to the PNS, privacy = considerations, authorization, DoS, and logging risks. All of those = apply here.


This draft is about how = to carry some parameters in SIP that get used with an external PNS. It = should definitely document security considerations related to carrying = those parameters. But I don=E2=80=99t think it=E2=80=99s reasonable to = expect this draft to document security considerations for PNSs in = general. That=E2=80=99s up to the spec for the PNS itself. I recognize = that two of the mentioned PNSs are proprietary; but I still don=E2=80=99t = think that puts the onus on the IETF to document their security = considerations.

The categories you mention from 8030 do seem generic, but the = text in the respective sections of 8030 seems fairly specific to HTTP(S) = Push.

That all = being said, I would be happy to see something to the effect of the = following in this draft: =E2=80=9CThe security considerations for the = use and operation of any particular PNS is out of scope for this = document. [RFC8030] documents the security considerations for HTTP Push. = Security considerations for other PNSs are left to their respective = specifications.=E2=80=9D

Thanks!

Ben.
= --Apple-Mail=_66AD2885-487C-4F57-8CBC-B8EEB7736BAB-- --Apple-Mail=_3C6786DD-9419-4F77-8A29-3A03954C10D8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlwv6R8ACgkQgFZKbJXz 1A3K9BAAjS7BpmC7zLupGvGSHZQ2YlZvwZKT4pja2BDPvxnqtlrwrSLVtTWC9rvA C/bISWeYv88gmZnK7dZKePXvcOaSVhZU4wLs/kx/ugsDM984jfu7HOLMUhIR5aT2 RAQWhoJ9np6WHkKVyTq1gf9kiZe7uPETBSWan0npJUVr5KYlbJWM9+ZRf940w5/l qwdCP2ZSyqyRW8GsyYUgYCcSqFdal4LQ2wOEyr/KYqRg5O26SScVlXvsPPJ92bSE hujVCpZw6+8mwRt1AvqLo5LUR7CYmtxJauwXx5n7Nx3SaguhYI/kYlEK93N7CGoE FFMjCCkVOSXEHzoQnrJIKHRJT7FQMiHRVulNyTwnNpjnAUR+UUCEqc98Rz9Eoov0 b7rMT15mpjYyZRD8UXraPSxiTwNkiYk8C4GSrlKo91ePEcP2nlTf1S8mepjQ29W5 HM5M6fJipuQIbwu8Mvt1mNg99T8rIuCuWH7DzUYsq+VC0EK2V0rgboSx56hMgkFS DKuUuC03LhuxCbLiNInYI0qWRnxTwN1lpe2bCm+5paZLb/L1fc0lyrUcF8Cl8T6+ fB95xtFvfbC+Gtfdvo6bwKrlnzCn4yYFesu4oHW/ZFZAW1yXYnJ3PpvOO9B+gBZc UG6usYRhUq1Ri8DqvYEV1MwtuFTxgwq5+O/a5N3ZVcERIXK2Pws= =zRB/ -----END PGP SIGNATURE----- --Apple-Mail=_3C6786DD-9419-4F77-8A29-3A03954C10D8-- From nobody Sat Jan 5 06:31:26 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2D4127598; Sat, 5 Jan 2019 06:31:18 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUq7e-sUCI2j; Sat, 5 Jan 2019 06:31:17 -0800 (PST) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::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 1A3BC1277BB; Sat, 5 Jan 2019 06:31:17 -0800 (PST) Received: by mail-oi1-x235.google.com with SMTP id v6so32597178oif.2; Sat, 05 Jan 2019 06:31:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=vuXY3Y/PFjgp3G0VvfLFj/Wa0yQGu+jfw/YXYqj4Hsk=; b=MlDqvpEj49F3Hdo6exWE95701PMkp4Xjs31gzbTBkG4X81INWadb8agv+bAcaGPej4 xZiu6rD0vY7XIdMo3Dyqx6BmpdI0E5YRZ+8rz53arlLeBNgpoSjQtwipOQ10+Q4VxqtZ Gcs1IflmfRQugrGRQxnXuP9dDHso0vttEmYZhPKzEOozh0ivB57TP4RHt1QRaBBHYGQ3 itAjl4wTFlBwYjJ9G8+6kFEP96UPE5OWQGR6zOhd13kGiL8/YpIqStp4q/5FgvHy5Zxl REfc4qCt4JRuCDWdjhfLT/pmnn2p8HqNpxjYbjaE60j73t4vayen2Fe/xGptQU7S6pLV lwpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=vuXY3Y/PFjgp3G0VvfLFj/Wa0yQGu+jfw/YXYqj4Hsk=; b=bKvueJa8u7+Ww01xDDuM8SSBxkQcuGzH/U4twzxVkupRQhf1PV7TKYvus2y7LSSDhf 0LIUiW0wu/GO9Ne04jXr/XokVMg+JV331xslX2cX4UQTI2WAhDphZNe5+7uwGTDaAHjE ggJ+VDKdWzq2hyM4Yffo/kdKE978skUnpP5z7UkGWFIsQEtUjV8tee6NCWak+UIZ8JiR scKdZ+R3LM6L72cw6+DS9dWVpIm+CBI5+g2aPslQugOW5k/+Pix6BzRFSwYwLKex8oGB +3dqxEamobRBvi5eNCDPUPn/Cmpsp8trUVPMKArsr+HNSzgdSw48QJcIqkcDWYmi6Xt3 ri8Q== X-Gm-Message-State: AJcUuke/UdpONl2r5V+RMcz+9tFhjwBD4GBj9704QK6ojB2AT3G9ME5L jjGIOw6xYvyK09Y/UtHETGTBJ/2O X-Google-Smtp-Source: ALg8bN42ZUNfyCoTOB2xBX6Ix7B2MRT6+j/TNIZ/MyKq2c+ATIK77ULOWgiGpyirWF7eQhtsDqQZLQ== X-Received: by 2002:aca:b4c5:: with SMTP id d188mr3755287oif.309.1546698676215; Sat, 05 Jan 2019 06:31:16 -0800 (PST) Received: from Chriss-Air.attlocal.net ([2600:1700:12b0:adf0:6527:4c0e:b195:8b9b]) by smtp.googlemail.com with ESMTPSA id t2sm27604170otl.4.2019.01.05.06.31.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Jan 2019 06:31:15 -0800 (PST) To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-dime-doic-rate-control.all@ietf.org From: Chris Lonvick Message-ID: <5C30BFB2.2080004@gmail.com> Date: Sat, 5 Jan 2019 08:31:14 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020909010000060904020601" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-dime-doic-rate-control-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 14:31:19 -0000 This is a multi-part message in MIME format. --------------020909010000060904020601 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready. The specification proposes new AV Pairs for the Diameter Overload specification found in RFC 7683. The Security Considerations section of this Internet Draft is brief and only points to the security considerations of RFC 7683. The Security Considerations section of RFC 7683 is thorough and I believe that this is sufficient. I briefly reviewed the ID and found no nits. Best regards, Chris --------------020909010000060904020601 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

The summary of the review is Ready.

The specification proposes new AV Pairs for the Diameter Overload specification found in RFC 7683. The Security Considerations section of this Internet Draft is brief and only points to the security considerations of RFC 7683. The Security Considerations section of RFC 7683 is thorough and I believe that this is sufficient.

I briefly reviewed the ID and found no nits.

Best regards,
Chris
--------------020909010000060904020601-- From nobody Sat Jan 5 10:15:22 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9624B130E91 for ; Sat, 5 Jan 2019 10:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.365 X-Spam-Level: X-Spam-Status: No, score=-4.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=e5vZ1Tum; dkim=pass (1024-bit key) header.d=ericsson.com header.b=h0dCiwT5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmjKDjMI8a-a for ; Sat, 5 Jan 2019 10:15:14 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 6516A130E92 for ; Sat, 5 Jan 2019 10:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1546712109; x=1549304109; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8l2njNWtsmUd1MoJQy1mAY4Hw3/ETNi808F/WHNqZqc=; b=e5vZ1TumuwPT1bqY9HrZpMo4e7jo7wD5cJ12RR1VxjhLZVt8EJPo7nlDjlCBTAGV zLAhVATIzMmn74dZQjYBuy1VnA0oEDqkWWGz+jGS8i5C0uCZLud6X+dFRgCHP7hH FlA0ZEffqTgARKe/WgNV/RMy1qj9NJjXu4QiXF5K2Jc=; X-AuditID: c1b4fb25-d89ff70000005ff7-2a-5c30f42dcb73 Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 23.9B.24567.D24F03C5; Sat, 5 Jan 2019 19:15:09 +0100 (CET) Received: from ESESBMR505.ericsson.se (153.88.183.201) by ESESBMB505.ericsson.se (153.88.183.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 5 Jan 2019 19:15:08 +0100 Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESBMR505.ericsson.se (153.88.183.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 5 Jan 2019 19:15:08 +0100 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sat, 5 Jan 2019 19:15:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8l2njNWtsmUd1MoJQy1mAY4Hw3/ETNi808F/WHNqZqc=; b=h0dCiwT5+AWeABS33xskB7fSb0JiEjNKH1YLMkVXmQltUHlaPVswDRUDjJXuitPMBkptrHWSxje8KJ2G5SASPvRavibHkgnhpi9EUnLctkkl+Kb+TL63Ld5iiV0dXeh+yqyUKCLVgVWIJ6HfQIyXThZXDJTlAdwreMstzdjyu38= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3081.eurprd07.prod.outlook.com (10.170.244.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.9; Sat, 5 Jan 2019 18:15:06 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::852a:3f04:e342:cf55]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::852a:3f04:e342:cf55%3]) with mapi id 15.20.1516.010; Sat, 5 Jan 2019 18:15:06 +0000 From: Christer Holmberg To: "Scott G. Kelly" CC: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-sipcore-sip-push.all@ietf.org" Thread-Topic: secdir review of draft-ietf-sipcore-sip-push-21 Thread-Index: AQHUoUFwpb8nIR8T3kKT3FjKoKE4faWfiegKgAF0Z6k= Date: Sat, 5 Jan 2019 18:15:05 +0000 Message-ID: References: <1546285539.44113084@apps.rackspace.com> ,<1546631184.64914945@apps.rackspace.com> In-Reply-To: <1546631184.64914945@apps.rackspace.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.33.31.219] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3081; 6:EaJwzatBmUbrJ5MIAmuGclwEx0pt9nvhXfwfzwa6kf75NLaZlK0aQ88hZbkhrw+pcUGowp/b3fn1Ttbogo8PpDxZTZQFKt3YbZKDc6pTTVTJUU2IyB7xldcMuRws/0R4zsQbvP7NKH7k/qeUZCWdh7owVy2CRQFSdTg3xjGgfRqyKjnZPqZVrtICtJBddUk/mwSSzBz/Mm2IqBaQgxWzDBDn2GPDW+XZOQBMKVgW4teMD3ZHqhJAiaEstj9zjggjRVhUvsoDpVwwlw6a0NRoJ+INJtauxaexKpUqTuVT+P+/k2p7J7sSzD7TTcbgabw8YpYLHpbJ/FG5Mr4We6nYRH8TTsb6FoHFA5hafSX2udkMhMHDbWPR+FWhiQPrs7c5FWNUz1VfRLR4C/VxMq5DVeT27qODJAT+In8rt1WQnjsccW2r8Q5I5LubFWkWwCV/+K8oN1sTRUYyYN1S1TuvVA==; 5:K5GLf0XHFVqyom8dWDHt7Ohrpmh1vQ2+VrvbB28KsfcrhV2kksOVfiWIPwXlB5KbP2c+wL1MZLTXieePmFbeWlLMfZzkxv+NRHelnhwLJwtapbpH0NyzVAVnx/JxRnJYjDXB7ePaWtPBmJ5C4+bj1UQ7OjWfdfScP3XkTh/jsWV9VhUNw2IPG3yb1LBecfJTN+z2R4FlKGS8KUh0dEXalg==; 7:C5Pxeeb5c2YOBXE1aIdypcX0mFD1Th0NANMQEDVCMCYlHbjQfurfGyKpfuvkyoiToVHG8PQfDbWIvE5gv7yd2AqYEOXXkAQwLbFFI829BhNbhv+wZcFnHg8JcrYYMn3L2omETRwbOO3LLYOwYH7O/g== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0dd9d1eb-80f4-4069-5bb6-08d67339b844 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3081; x-ms-traffictypediagnostic: HE1PR07MB3081: x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231475)(944501520)(52105112)(6041310)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB3081; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB3081; x-forefront-prvs: 09086FB5C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(39860400002)(396003)(366004)(189003)(199004)(316002)(26005)(74316002)(476003)(76176011)(54906003)(7696005)(68736007)(86362001)(33656002)(66066001)(14444005)(256004)(486006)(102836004)(6346003)(6116002)(6606003)(44832011)(446003)(71200400001)(71190400001)(6506007)(97736004)(3846002)(186003)(99286004)(11346002)(53936002)(6246003)(25786009)(81156014)(81166006)(19627405001)(8676002)(54896002)(9686003)(6916009)(14454004)(478600001)(6436002)(5660300001)(229853002)(7736002)(105586002)(8936002)(55016002)(106356001)(4326008)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3081; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: U/OB/vWVoI5l25mMLyulPxnJ8g1eWQSCpbdzXQ/PHPjEMdi5yLnHaJszIYF6sVefaHOaaKPPvugOC8fwX/6E7U32FuJOwBG4Z4K3AbvWDkuMAY5iFyjIpXh7LHc142CIDT+/TWc6IeCMPysSYeOPMwBXghCyLpvy4Q1wu29ag11Zh0J4fulWbMXP3//Wp2B0TUnLaxSW/9cOSs2oeyA4V8n/OVvDQrCbImAFsQ2tIRVL7S8ubm7o/IPAGHMuCkvcRS45Bv0uqaBRsXXzdtpPbT6pxLh4dL+5aNHDpzkzspLlA9iK/el1MTHRyE52oPK3 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3161102618EA417C83C30B99938F0HE1PR07MB3161eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0dd9d1eb-80f4-4069-5bb6-08d67339b844 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2019 18:15:05.9640 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3081 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfyyUcRzH+z4/zuNy9XWRz9CyK2uj44h1ixr9UdaqaTaLbtPhCfNz91yG 1iZbbEcjpSJLl5vlyHIzLG1iaogUNiZtSI0ix+668mv1eK7mv/fn/X59Pz+2L0NKTbQ7k5Kh ZTUZ6jSZSExVXmzLlsstCpViXr9LudDah5QP1m+TSmtLGVKa9dNUGBXR3t5PRRgMv4lIIlYc msimpWSzGv8Tl8XJTeZKUda3oJzFn9V0Pmo+rEOODOAg6BmpI3RIzEhxDwKDVU8KhRWBebLA 4X+xODZnx2oJ+NVauJVQuIyE8hc6kZCUE3CrsZTkO0vxNILl8ms6xDAirITiTV/edsFyuPfs Js3zJK5FMDYwQfPMHhwKrb1HBeY4PNdZRbztgo/Bj3oVb1P4IOhsDVvdJVgFMzU37Ku2IBhf f+TAB444GIbGbYjXCO8FW38jwWsSu8HEbA0hHI3B8HKIFLQrzH/epAXtBXfz+0SC3gfDNcWI HwC4wAFWSt7YITmYKyrsj8/B2qtqWoDeI3j99iMlBD7Q0Pp06wLAqVAx6iQwH0h4YiuhBd8T plZ9ypCiatt+VX8TEmdCY5GoautOZ+irnKUERAFL72pIQftCnf67XftDs2UQbfcfIwcjcuVY Lj49KfCIH6tJSeC4zAy/DFZrQn9/UlfLmnc7GlkI70aYQTInid+kQiWl1dlcbno3AoaUuUjU hL9KKklU5+axmsw4zdU0lutGHgwlc5OsS51VUpyk1rKpLJvFav6lBOPono8KjcYc6ZmQO5+8 1qz7T1busJ6FrwTN1Vuazi/P7exc6QgwVVzIXXIL6jiVIBeNBjYEDJcODckty736sS6PDkNU /aEr68bwS4VhA0X+XLz2dH9w1MzGhslk9mzb/TCuJ6TTI6ahIEbMHRjMU0fHfZliHCOjm7XX Y+97u61qFCkyiktWB/iQGk79B3ZMytdFAwAA Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 18:15:16 -0000 --_000_HE1PR07MB3161102618EA417C83C30B99938F0HE1PR07MB3161eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Scott, =85 >I don't want to go through the whole document again, and I don't want to m= ake too big a >deal of this (the RFC editor has final say) but here are a few examples of= things I had to read >more than once to understand: > > Because of the restrictions above, Session Initiation Protocol (SIP) > User Agents (UAs) [RFC3261] can not be awoken, in order to send > binding-refresh SIP REGISTER requests and to receive incoming SIP > requests, without using a PNS to wake the UA in order to perform > those functions. > > In addition to the information that needs to be > exchanged between a device and the PNS in order to establish a push > notification subscription, the mechanism defined in this document > does not require any additional information to be exchanged between > the device and the PNS. Ok, I will look into this and see if it could be made more clear. =85 >>>Finally, I think RFC8030 has a good description of the security consider= ations for >>> this use case, and >>>should be referenced here. >> >> I can add a reference. However, while many of the security consideration= s in >> RFC8030 probably apply to any PNS, they are still written for a specific= PNS. > >I don't know what other documents have been produced by the WG, so maybe t= his is >covered elsewhere, but there are generic security considerations that appl= y abstractly >to this use case. I think this document should either point to documents t= hat describe >them, or explicitly describe them here. For example, 8030 lists confidenti= ality with respect >to the PNS, privacy considerations, authorization, DoS, and logging risks.= All of those apply >here. RFC 8030 defines an "IETF PNS". The Apple PNS and Android PNS are proprieta= ry (that existed before 8030 was even published). Also, it is important that the security considerations of 8030 mostly apply= to the PNS itself. The push draft does not define a PNS (eventhough it doe= s make some assumptions on how a PNS using the push mechanism work), but a = mechanism to transport PNS-related information over SIP, so the scope is sl= ightly different. Regards, Christer --_000_HE1PR07MB3161102618EA417C83C30B99938F0HE1PR07MB3161eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


Hi Scott,

=85

>I don't want to go through the whole document = again, and I don't want to make too big a 
>deal of this (the RFC editor has final say) but here are a few examples= of things I had to read 
>more than once to understand:
>
> Because of the restrictions above, Session Initiation Protocol (SIP)
> User Agents (UAs) [RFC3261] can not be awoken= , in order to send
> binding-refresh SIP REGISTER requests and to = receive incoming SIP
> requests, without using a PNS to wake the UA = in order to perform
> those functions.
>
> In addition to the information that needs to = be
> exchanged between a device and the PNS in ord= er to establish a push
> notification subscription, the mechanism defi= ned in this document
> does not require any additional information t= o be exchanged between
> the device and the PNS.

Ok, I will look into this and see if it could be m= ade more clear.

=85

>>>Finally, I think RFC8030 has a good de= scription of the security considerations for
>>> this use case, and
>>>should be referenced here.
>> 
>> I can add a reference. However, while many of the security conside= rations in
>> RFC8030 probably apply to any PNS, they are still written for a sp= ecific PNS.
>
>I don't know what other documents have been produced by the WG, so mayb= e this is 
>covered elsewhere, but there are generic secur= ity considerations that apply abstractly 
>to this use case. I think this document should= either point to documents that describe 
>them, or explicitly describe them here. For ex= ample, 8030 lists confidentiality with respect 
>to the PNS, privacy considerations, authorizat= ion, DoS, and logging risks. All of those apply 
>here.

RFC 8030 defines an "IETF PNS". The Appl= e PNS and Android PNS are proprietary (that existed before 8030 = was even published). 

Also, it is important that the security considerat= ions of 8030 mostly apply to the PNS itself. The push draft does not define= a PNS (eventhough it does make some assumptions on how a PNS using the pus= h mechanism work), but a mechanism to transport PNS-related information over SIP, so the scope is slightly di= fferent.

Regards,

Christer



--_000_HE1PR07MB3161102618EA417C83C30B99938F0HE1PR07MB3161eurp_-- From nobody Sat Jan 5 10:21:37 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFEC130E91; Sat, 5 Jan 2019 10:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwqED3LyJsoo; Sat, 5 Jan 2019 10:21:26 -0800 (PST) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700106.outbound.protection.outlook.com [40.107.70.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4220C130E84; Sat, 5 Jan 2019 10:21:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a+gESwFNR6wqz9t549F7qHpwgSV3oQrpj4jr0QKgRcA=; b=I2CQmChHuZHHGnBIPJzEoON9IwoIsQp0NoBZjSX5cZm6ZY2aR1YriJbOdktvNaWwFQqcsFG3Bmkut9YxpjBLqGRhWVt9hpmjVH+++YxiZLBcei+CYy6sO9q8+NH+6D45+jWxjZ/FnbDrkzf8b4+6fFZ1XOxzScNP7j22LvvIoeo= Received: from SN6PR0102CA0001.prod.exchangelabs.com (2603:10b6:805:1::14) by BL0PR01MB4804.prod.exchangelabs.com (2603:10b6:208:7c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.6; Sat, 5 Jan 2019 18:21:24 +0000 Received: from CO1NAM03FT021.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::207) by SN6PR0102CA0001.outlook.office365.com (2603:10b6:805:1::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1495.6 via Frontend Transport; Sat, 5 Jan 2019 18:21:24 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT021.mail.protection.outlook.com (10.152.80.180) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Sat, 5 Jan 2019 18:21:23 +0000 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x05ILJCD024897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 5 Jan 2019 13:21:21 -0500 Date: Sat, 5 Jan 2019 12:21:19 -0600 From: Benjamin Kaduk To: Ben Campbell CC: "Scott G. Kelly" , "secdir@ietf.org" , "draft-ietf-sipcore-sip-push.all@ietf.org" , "iesg@ietf.org" , Christer Holmberg Message-ID: <20190105182119.GA28515@kduck.kaduk.org> References: <1546285539.44113084@apps.rackspace.com> <1546631184.64914945@apps.rackspace.com> <215DF6BE-69A3-4394-9BE2-EE7751957E07@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <215DF6BE-69A3-4394-9BE2-EE7751957E07@nostrum.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(396003)(136003)(2980300002)(199004)(189003)(4326008)(1076003)(8936002)(8676002)(246002)(6246003)(6916009)(55016002)(9686003)(305945005)(356004)(26826003)(93886005)(508600001)(106466001)(336012)(33656002)(54906003)(7696005)(76176011)(88552002)(14444005)(50466002)(316002)(486006)(956004)(786003)(11346002)(126002)(476003)(36906005)(446003)(58126008)(53416004)(426003)(47776003)(2486003)(104016004)(86362001)(186003)(75432002)(2870700001)(2906002)(23676004)(26005)(106002)(5660300001)(53546011)(229853002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR01MB4804; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT021; 1:+dVYgmEsVU7k9HO6BreAzRxUWZCsOkHtH/vZXmiEeL+SQ085DeR6AOtzYscVptzfiGHyemkMBnPWnfK8aaRlwYPdiI+ojHC/nd6LiPthSd3++0JgATmU7bcYnI9U/MXc X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f6e41800-4599-4088-a4f7-08d6733a999b X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:BL0PR01MB4804; X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4804; 3:wdzI3nVYxE8FQeNh7DKVJLtmCad3h+CDNkBENZ07xfDr8Cl72ie8jJzbNKH6MvNRTJCYjwlMwSOkSXfoAkQPfVJL+NdVaqRvxC156rJ6rbMv/iEyUizjBCfcbIF5uCuy2sPd0+miPNAt3d6fbhFXnbi+50u96NbEXFXWM+HFrCK1JYNvVHwxI+8Yc66jNGq4kWTmwmICrpjSy8WV5jZiE3GmTj7aEFgyN6z24Ir7JDAeOhV9sEhEXY+x7JV9oZaa0PsZMNVpzBjyP3HVfRkoO8lXMgpmcuwCl61P9h26IUcXlcDHcdvjADybPbLCh95tqz3GR+ZYWj/eyy3t1ZQTpkCqM7KaWFqfyCf8O0wRgwtE8/yl3MQ1UZWBtou2pRIE; 25:lO92BC/M2+e3E3/g0B2JlybDkoY5aQyRUvSaUywCB+MKQ07kgoAlgLlZKPldKWlDe08EuAZoblfwN7BpHKcjVGx722Mz/AUNeoIBoZ8TITfDyrP3IJt1KO1nusxKj85ZT6Y51ZLssERX00VnaptNGhgvjOB9oH6zr90po2H92trHKe+2xYaJUtEl6xEEGtCgwsKoKcGw3+Dsff0Lwm4RJipEWaEHfwBxojdRJ1rdgqAC1qrmryS7tZZluZevSDC/eD6TZyvxn9modR/sZHsyeN7rbFdijiKgFN6VdluBfYL+kA06yaOokZuDhKEd72jsM7Tusl8VGEyq1IHeSJ85tQ== X-MS-TrafficTypeDiagnostic: BL0PR01MB4804: X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4804; 31:dxCN0Qv4oV5thuIvy2GaS7TZtorddbxamvBN677BGHdDK1RTh7YToSXyLpHxcyi7xUWHKQ2to9PANICRTLSvdUTtLHljCiDTp5GwXIwqQEFHxThcG9ggSZXFnLeERl7fxzq+/AVj8R4cYoQq5ET1+D6yU1SABf3Df1qf3yNRHzWXj6su7E2YUEpVCh+660RjBpxJyOZPBqN7meMIJ6AP6zsjFGZO0P5P6LPwQrUtlHw=; 20:Ty3TlSNf/vyfhyVI5xxPlq7ya2UGwX+CurCON3M177jeJOawlB7YUVBt1asXLlo4PgTMqoIB+8w6WYxB/+BlPUQf3xkdDYuBfkp/fal6OcTWvPurX6/mVI5Os4Q8rcS4vUbsPHKd519Uf1EcBl5PFARF8fW4XYOyyJi6axt3RJpnkKva+DjG1H+ExGDOtKotiAsxcpmZIoAltLJSrc4hKf8lhS2FwZywXTXncakzG1WaxuybaRoDGaAttUuyxsnDjq7w2kUu53n+0uvR2kphOsxEgP+PUqfEQkT/oYa9DxbbKkaJqbFWENv7YMfwytYbOHyk1F0ir4EAYvplKFpzWnB1hENfog1/7R8YLd/joEXRuK8ibm9akTaL1Cobb5mGVHi3KUWgf8mhQMpVmnl3g/rokMroMdQcgIU1MpLPera6IfAfxbJPwt0CVdldbV6egA5ttrPxONQv7EdVKfS2fPucQqUwi0aO49Zjst+N9Jb+w+Jh4tZsetmRpIR/oRgN X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(3231475)(944501520)(4982022)(52105112)(3002001)(10201501046)(93006095)(93004095)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:BL0PR01MB4804; BCL:0; PCL:0; RULEID:; SRVR:BL0PR01MB4804; X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4804; 4:uoffL5BBEeuyNGrIHPQDk0FDaccg2Gk1McVhTWFQGj8XxArJt4jQo78nG5orp7lVUhfb+ChDX0eW4+AedaDgJgeZqFVDeuXnS+ashDhnBZ4NT/znBKJ+nV6a2o0Ib8JfR2CYytsUSJAclIgDYU4ce+W97k24BZzFYNMRTf7PZ5ZGX44danUE0OI6Zp6Xi/6Wa0BIzsGg/NopDG5z1D3adPPENCpQ98bNIujXnSo1lVLC1DmmLqHv0QVIpfzZvig69IFSs78dcNig/Z6Q8pvAmmVAU1WkwRKKZ0uJleJGcvyKVv6NLr1rythEKm/YCde3 X-Forefront-PRVS: 09086FB5C5 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTDBQUjAxTUI0ODA0OzIzOnlHWE85TUdhYndiV2xOUlM5bHRBb1Yzd2dv?= =?utf-8?B?eTNNQjJXMFc3T1JzVWtId2kvKy8xWllLRE10dHV2Rjh3ZkhKSWlIL29UQ1pT?= =?utf-8?B?Z0pPY21NZmZWMGMzMkdrZzZ0cEpDUithOUZVcXRDaGZoZTRHemZXdTNGWlhN?= =?utf-8?B?RkxhOTZ1Lzl6L25VY1hhQk1DT3k4VmtuVnh2aGNTOHNHQm43WU5OSzllTm9m?= =?utf-8?B?VzlIODdwRXVvcjBUT1BQU0FtZ3Y0QkkrNmV3d1JZcnR3c3JiNUdmOWs1Qkts?= =?utf-8?B?WUk3YUd0dlBIY2NsWFBjL1RrMHBNWlAzS082YTlXQm1qZWI3bzFzcjFIQ2RM?= =?utf-8?B?MEpmVHRObzl5eDhrc0p0M000eS96RzFzZEg4Qk1vMTNCRXp0Z0NOb2JlRlZR?= =?utf-8?B?ZjVBQnM0TTY5MW9YZXlnTnZpSEFuSXZzYi9nbjdEaWQ0TUUrY0FkdUtZT0NQ?= =?utf-8?B?Q3hGRWJ0dlBjSmdLMy9CMkN3QXNxSEhqZ1I1Z2lBNlVpQjhJWXFOc3VQcStU?= =?utf-8?B?OXRMNlpTQTFiOVFCT1EvNFc3VFJZeHh4TlFQU3g4S1lkK01OcjFQa2QrNGN5?= =?utf-8?B?bThiaUU1UCtHcUVzbU1rWjBreDFXc05yYlJYSktNanlaZHhrVjFwMGdHU1hB?= =?utf-8?B?bnRLTXBTTmI1L3I2OHFMTHZ1NEVRcUxINlljTzg3NmFwd2lSUXBnYWhmUXpn?= =?utf-8?B?MWdRWkpQWWowN2kzVVRuZGRleWRYTGtUODBJZ0FBWU4yNDVTQUpldmlySzRr?= =?utf-8?B?bWsxYmM5OWJCMEhOb1NBOGpnb2pjWXBMSEdaUEtVMktZaDBVZTN5eFZZRjZG?= =?utf-8?B?TVVGeUhwS2pBcWlZY0VXcGF0UUZaS0ZwUW0rNGZUTUN3SzEvaHlmMUVqNnZu?= =?utf-8?B?b0NJTkc5YWtSd29XQllNQWtNUjM3emx3emJSYzNxOFFaVFRTZnBPZ1IrMTdw?= =?utf-8?B?d3VOcUNFalRoNjhYL2FZcXl3UjhSUDg4NGRwUVRlMUo2M0RoVzY5R2hYMDBY?= =?utf-8?B?aWh6bTJiWSsyYVhJb1VrOWFwT3JTTnowV0JjeCtKU2IydkRCd2NXR2FKOCtY?= =?utf-8?B?OGJCaHYwZTlXc2NhWTFVamh6UDlLc2VpbWNDVGJCT3VncEJraklpK09CSkVN?= =?utf-8?B?dTExVU9rN0x5UHBtTjQ1cUFkMzJsckM5VjFOTWJLQ2F6TlRpRXR3eVN3cUtO?= =?utf-8?B?cVY5SytaeUtZYkpSdkRaRGFpMUVXZzE5ZWhkMjdHNUNRcWJTd3lYZS9OQkRk?= =?utf-8?B?bXBJSG9JcnBaTy9OblhHb0xneDJLbVJIV0ZqTGxjUnl6OEVuOXFvZGhwbW5v?= =?utf-8?B?dzFRNHlWREdxOWs2YmhCNytyekJ0QzVtSUdER2pyWk8vRDZzRW9xUWF2N3VS?= =?utf-8?B?ajB1MnRMVkFja1VpOWhGWGJ5UXJFZGlEMzRFeWVIZEtlNlJGdUpsVXBSenpS?= =?utf-8?B?cGE3blAzR3g4bFBlSHY1ZEJpclFqSEwrSUdEcyt4ekdZS2tWbFMrZWIrVVlV?= =?utf-8?B?UndPcW82bDBLV1VvYjFtcXFFWmR1OTdCUlNqWE5abmkwVEZXcFRiNlRkcFdI?= =?utf-8?B?T0NadUdmMmNMQlJJaU5TaGUxVjBuVlhLK1R6dGh4Ny9ONEZjTVhWVlJVYXFt?= =?utf-8?B?cDJJbmVnY1ArQzlQVzF6UGNRenVLVzVmUVE1Vy9EOHZmMFc0cVhsT1ZxRWt5?= =?utf-8?Q?AepS1yT1MVoibdob4rAUpP+Ahrbjc2InHi3MALb?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: MFjPOjDCvxeVu+ldM6HWL5P4QmMqXLW1v1KCsj0DMAdLKfc2XxAn9IeTIpZT4VrD95Xl3M8dvil1lZV9tLQTu/3OXTMcQvfiAMkAdHHh2p8x/lKsxwJkF6CZ21mY2HSKPl/FasITfdcuJnqnyAYOOeN5Sp4TCcNylbiPGGrd+noYje2z0s0hyd8KR6ds1V7cqMmi0B3bG8F73zQUiQ6jULOXxaBg86izWhbNdFAdTygvj7+RJWtc0zzxAsIKA5Qyjui2UNJ6ZztNEIqcU4j0NJSAMMrKp1xTQyfLlW7ifXqjxt9UeXkX3K5///1IVujZ X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4804; 6:1EFJirS1AGYyfWoZ7GN5gXBCJGBEODxxVc5pue72UF5D/O01zLwJopoYkHGoJgXplE4C52BnaVhk9wE6e3pUpoqwRdypmwUmum3lVlcnfnS1ZF+zZP3Xs0saGS9tn3t1RwgYIBcb+yVCn4WnMFIDEDr5y/5lglzhPA9lqgsPAQ58XGI0bKP/AbS5BfcSJOkhn8VMSAzEA+x6qTJcG28k0FTFQ+M0FLnd7gAcJmLyXedZWJKnzIGaJw3p9xAjnYgk0xKcVwjNlB+zNvscskWofx/nBHtzWIuOSyhZQsJMZBCd9E4kPAfZSWht1mL6e/93r4pHL8lRFHC8LZe5eh8lEmLyDvW1l3iIgktzgCAXGbJxExFOIY4nV0DG81Y2q8n/oYx62tvGJOI0QEgXxxtb2lX0wPMH2EDb5rBlGlk8Qwzy2YMH5LSsvLv+NJ37Tby5GgbKcl6x74VH1TQjce9zvA==; 5:/14q+AJgGhEaATMwVkMP6GPwaEIlVdLX0dDIutDlhBDtCk+QZ+hQL+6i9XP655+JyXaewpinm0I9RWGx+TViq6i7TWLPgulOipVzBUNJku6eTjzziU7ZU7+1/p+YxuwHhdreJZ1rgnwIHJq+EsFmaW+QhgVAuyT10bxciiu2bNt3ZIxNap8+bBfSfYSulLVuTiChd0/TOfLN3OV2HVPxog==; 7:BV5vNQF15O4iSZd5TAne2lXGNO2mK8UhRA/IqF6LqEXIGhnkTH3zN8tQZUkueCtdPtbrAhgzkDcqjDGNQOvsMzxCUJj+OUKTLBs7xOmEhlvBDNqh36pcTr2HCAbatTN52x+rNJ2jbl1jzHa47jOTjw== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2019 18:21:23.7696 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f6e41800-4599-4088-a4f7-08d6733a999b X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR01MB4804 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 18:21:28 -0000 [with the caveat that I've only read the security considerations and not the whole document, yet...] On Fri, Jan 04, 2019 at 05:15:43PM -0600, Ben Campbell wrote: > (Speaking as responsible ART AD) > > I will let Christer work through most of the comments, but I want to comment on one in particular: > > > On Jan 4, 2019, at 1:46 PM, Scott G. Kelly wrote: > > > > I don't know what other documents have been produced by the WG, so maybe this is covered elsewhere, but there are generic security considerations that apply abstractly to this use case. I think this document should either point to documents that describe them, or explicitly describe them here. For example, 8030 lists confidentiality with respect to the PNS, privacy considerations, authorization, DoS, and logging risks. All of those apply here. > > > This draft is about how to carry some parameters in SIP that get used with an external PNS. It should definitely document security considerations related to carrying those parameters. But I don’t think it’s reasonable to expect this draft to document security considerations for PNSs in general. That’s up to the spec for the PNS itself. I recognize that two of the mentioned PNSs are proprietary; but I still don’t think that puts the onus on the IETF to document their security considerations. I agree that we don't need to document all general PNS security considerations here, but just because an interaction is PNS-specific does not excuse us from stating what requirements we place on that interaction. It is rather unreassuring to read statements like "[d]ifferent mechanisms exist for authenticating and authorizing devices and users registering with a PNS" and "[t]ypically, the PNS also requires the SIP proxy requesting push notifications to be authenticated and authorized by the PNS" with no requirement that such authentication and authorization actually occur. I would expect to see either a requirement for such authentication/authorization, or some indication of what risks are present when they do not (e.g., excessive resource consumption, DoS) > The categories you mention from 8030 do seem generic, but the text in the respective sections of 8030 seems fairly specific to HTTP(S) Push. > > That all being said, I would be happy to see something to the effect of the following in this draft: “The security considerations for the use and operation of any particular PNS is out of scope for this document. [RFC8030] documents the security considerations for HTTP Push. Security considerations for other PNSs are left to their respective specifications.” That seems like a pretty nice way to say it. -Benjamin From nobody Sat Jan 5 10:42:15 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C9D130E36 for ; Sat, 5 Jan 2019 10:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.365 X-Spam-Level: X-Spam-Status: No, score=-4.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=D322AKM9; dkim=pass (1024-bit key) header.d=ericsson.com header.b=iZN+b9LP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASVpJmRM5x-w for ; Sat, 5 Jan 2019 10:42:12 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 036EB130E64 for ; Sat, 5 Jan 2019 10:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1546713728; x=1549305728; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wDuKIj4fnTaQuUS9ms5D11DKZ/cCxvRw/4G6JE26pVE=; b=D322AKM9UmrDj5GpcUSWvZ8uLx8z9XACKUCeFEsEOV1T48YK56VXmho0IStcuACE EenBDz/JOlOX/JSKwkedICm9vDH7lpFrrPX+xIl3VdNTssyDYkj6u1u4+RSNOqr/ bOd/8zn3lZOBfoSKK5WvxEyPBVaf0sxJ5JGIAU8AH3I=; X-AuditID: c1b4fb2d-db5ff7000000062f-59-5c30fa8075b6 Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6D.DE.01583.08AF03C5; Sat, 5 Jan 2019 19:42:08 +0100 (CET) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 5 Jan 2019 19:42:07 +0100 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sat, 5 Jan 2019 19:42:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wDuKIj4fnTaQuUS9ms5D11DKZ/cCxvRw/4G6JE26pVE=; b=iZN+b9LP4pIrMUJjkztZ49ti8zK6fRxLG8MltfyaJ6N+IoHWmh306P8R7Uw49Ov5IWn5DkUvKGJVGTAs/6Qic02Vv7JVoW02gXkcp4NJouwsipGXZg+eYpMkvMw+g8/7N2G4K/Rah67Y02x8R/gWa4V4j49Kie0w3SGjDTwZKX8= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4156.eurprd07.prod.outlook.com (20.176.166.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.4; Sat, 5 Jan 2019 18:42:06 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::852a:3f04:e342:cf55]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::852a:3f04:e342:cf55%3]) with mapi id 15.20.1516.010; Sat, 5 Jan 2019 18:42:06 +0000 From: Christer Holmberg To: Benjamin Kaduk , Ben Campbell CC: "Scott G. Kelly" , "secdir@ietf.org" , "draft-ietf-sipcore-sip-push.all@ietf.org" , "iesg@ietf.org" Thread-Topic: [secdir] secdir review of draft-ietf-sipcore-sip-push-21 Thread-Index: AQHUoUFwpb8nIR8T3kKT3FjKoKE4faWfiegKgAF6kMCAAAUydw== Date: Sat, 5 Jan 2019 18:42:05 +0000 Message-ID: References: <1546285539.44113084@apps.rackspace.com> <1546631184.64914945@apps.rackspace.com> <215DF6BE-69A3-4394-9BE2-EE7751957E07@nostrum.com>, <20190105182119.GA28515@kduck.kaduk.org> In-Reply-To: <20190105182119.GA28515@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [37.33.31.219] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB4156; 6:Yj7XGspY4d0rrgi1yZwVnuC3DkYT6l2DHd9JMDC8OEYFSJ03sPPedzGLraDvZSyfhoG/9hV2hRcw8/Wv3666YU5XVRoYzrDmqKy5qZj1H7FP4z2ZXR72Py3vz7lJzCy6zNMUhHzcHPeemZgx01qeEXOOj79qR0IDRRU31sgA800Tjw5ulvReVzR4WQi/K2uA9iGE2zXUB9j8NXpCV5nnOD5fgteDxwUQP77I/cHLiGDsm7KGNgnuUhH+o0LPsoqgYP5ERS+NokV1aBCL9HUxAGpYcRy6XUAhEeVRyyixR4tSj450ECGEUwhv9DWqYr+29U57TdAmISIjDqe1m87jFwnR437dIE/861EG3GIYom+llvTiQd6QtBGSstc2QvDqlDnLgdqT17HEmxQTWes2QX+U+C+f+15IIcSNVnpopy5KDaiQua7E42RukDfbZf3hx0YV48H+HDFrjIz/viRt5A==; 5:Wkq51HKRwozr17462vuTaDf7TIJoL2H1P1EYx9ZlEyYM6RonVMgfVeFQ0s83r20Tlqdac2u8ZOkQfa+ZWtDWKSpKt4+r1FEL52bbmk6NKGuFafsfecUdvGaLesY3ljiz23uWIswS0BO1RmCx8AK4DvDsUgfWovDZIECWXs18zU9Ns1QOa2MKgIpQKqTGuxf1QyQBcflkkF8/gMiQlH2pYQ==; 7:fg0viVgKLAa8SrJ7G/GMNEtEHXJxgDI1+6ewQXI1/MLIOHhG1jW8ju1yhmUNwJBvEvlI/28kQdNCfOvwrAbKbr4M1JEm0izzG8rJQM5RdZSIS291ThhoOonDt/+vhB3rkKCqoFUO1aDnS3Cdz4q/ag== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 673a002e-913a-4e1e-9a3b-08d6733d7dd9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4156; x-ms-traffictypediagnostic: HE1PR07MB4156: x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(3231475)(944501520)(4982022)(52105112)(3002001)(93006095)(93001095)(10201501046)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB4156; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB4156; x-forefront-prvs: 09086FB5C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(39860400002)(396003)(376002)(366004)(199004)(189003)(25786009)(4326008)(68736007)(55016002)(74316002)(54906003)(26005)(186003)(102836004)(3846002)(6116002)(110136005)(478600001)(99286004)(486006)(11346002)(446003)(86362001)(256004)(7736002)(476003)(14444005)(44832011)(105586002)(81156014)(93886005)(8676002)(33656002)(81166006)(53936002)(6436002)(106356001)(97736004)(6606003)(6246003)(2171002)(14454004)(2906002)(229853002)(5660300001)(8936002)(6506007)(9686003)(76176011)(7696005)(316002)(71200400001)(66066001)(71190400001)(19627405001)(54896002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4156; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: xiQmUbS2H81s9jIGo+zXInVhS2Vt5q3Hknn9rGYepO+d8K1pq2R+eymh7SNzTxh4BMRkuW9mv8lj1JihX8iFCaw9cZL4faPdN0K4tRb6wchwba2t9bMZnVxnqZoAjROLzD/4Gf0D6wR7LKzCQRrAIV0H5jddAeCdksXtoaJD7Nj3RDDEsnE+vnJmFABYgnrCTG9rQZOMKvxTpISB2lId52YX2nVK6NHQaYJuf0PRlnzy5fWHlTH5l+0EvKQrRpbnvu4wHcm5SDVwCsonAKGp9HxtIaLI5bfudEa4OO0EU4vwDCbmkUpGPwGCQOlobh1s spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3161BDBB9F8931EFA3CDE608938F0HE1PR07MB3161eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 673a002e-913a-4e1e-9a3b-08d6733d7dd9 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2019 18:42:05.9905 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4156 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTURzHOffebXejyXFq/XpIMYpgppulcaPIHhSDMtIKKhZ5yZtaa8au k6yIZTDRWVxflEOdopXau0SNBGtatGkPpFoUReWEnqjRqKaO3O6E/vv8zvfzO79zDocmVY8l 8+g8UwFnNrFGtVRB1e7usiRaAzqDThBkjLN0QMZ873Qj5sJkBclcvlVLMP4OATFjTR+pdVJ9 d7eH0re0/CX0xYMPSb3jro/aTu1VrMnmjHmFnFm7NkuR2xb8SRwtiT1mfx9vRZ3RZUhOA06B 61MNZBlS0Crcj+C17TQSCz+C73UjhFg0E/CwuVUSKigskDD0wi8TkwoCArYZ7SOCLu/f6YSm pZgBezAhNCQWb4Cbj+rD+5L4KYI621kUCmLwJhi+Z6NEaTO8HB8hZxqECbcsxBReDOUvfxAh VmIDBE97pOIwgYCBMldYkuNUaBx8FGaEZ8Nvz9VwA4nnwBufkxCviqGl5xkpchx8GQ5KRJ+F 3vYPkfVFUG11S0WOhyGnPXxqwMUy+Nx7TiYGiTBWUxNpSIc2f3lEeo7gWWdVRNLAaHMfEvkw tH7ySETpDQmTb70o9EaAF8CHgEZAWsd/h3VMJyTOh6mJBEf40tHgrvVRoqKD0adOUuQEuNT0 LcJauPXrCfp/vRHJ2lEcz/H8kZzlK5I4c94Bns83JZm4gtto+n896JhI7EZXvq13IUwj9Sxl n19nUEnYQr7oiAsBTapjlSyhNaiU2WzRcc6cv99sMXK8C82nKfUc5aQq2qDCOWwBd5jjjnLm mZSg5fOsyLKrQ8fUnV29kt4QI9xIc1sqTwzcu78xKjXt2vlievAgY3p/aaH8zI5M5arSqT2O uVGn2rv6vRnOrKyRkmWvAj319m0pw0J8xskGb/rSnYfuPNkizDLeSa/2tbcu+VK1Mdajeef9 c7kxM820r9Lo6/navSnqYk1F+QpyvDLHubU5WU3xuWyyhjTz7D9ixM/JWwMAAA== Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 18:42:14 -0000 --_000_HE1PR07MB3161BDBB9F8931EFA3CDE608938F0HE1PR07MB3161eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >> That all being said, I would be happy to see something to the effect of = the following in >> this draft: =93The security considerations for the use and operation of = any particular PNS >> is out of scope for this document. [RFC8030] documents the security cons= iderations for >> HTTP Push. Security considerations for other PNSs are left to their resp= ective specifications.=94 > > That seems like a pretty nice way to say it. I'd be happy to add that. Regards, Christer --_000_HE1PR07MB3161BDBB9F8931EFA3CDE608938F0HE1PR07MB3161eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi,


>> That all being said, I would be happy to = see something to the effect of the following in 
>> this draft: =93The security consideration= s for the use and operation of any particular PNS 
>> is out of scope for this document. [RFC80= 30] documents the security considerations for 
>> HTTP Push. Security considerations for ot= her PNSs are left to their respective specifications.=94
>
> That seems like a pretty nice way to say it.

I'd be happy to add that.

Regards,

Christer

--_000_HE1PR07MB3161BDBB9F8931EFA3CDE608938F0HE1PR07MB3161eurp_-- From nobody Sat Jan 5 10:51:21 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDF1130E5F; Sat, 5 Jan 2019 10:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67JI9sr7WF7L; Sat, 5 Jan 2019 10:50:58 -0800 (PST) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690127.outbound.protection.outlook.com [40.107.69.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C3A130E36; Sat, 5 Jan 2019 10:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U4qBFEilrMVxyRi03lzFdQ/pftifXnXKPXiZf7I6wzQ=; b=xLVULcrGjY8kcZLgVmTQZlKJledGEjUFV9ZGJlZIelYdcF00xKil8tXKVm5iubTHj/sA4RvX2sjukLfErsSwvNZIB2+aj8/lSYufJ1Ea4ZCL2jQ6a27QccJkfw74qqfgLlRNQbv8Jgfi2NdOIJ8vtlF472t3oJeXi1ZLFIknK4g= Received: from BL0PR0102CA0011.prod.exchangelabs.com (2603:10b6:207:18::24) by DM6PR01MB4025.prod.exchangelabs.com (2603:10b6:5:2e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.6; Sat, 5 Jan 2019 18:50:56 +0000 Received: from CO1NAM03FT034.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::209) by BL0PR0102CA0011.outlook.office365.com (2603:10b6:207:18::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1495.6 via Frontend Transport; Sat, 5 Jan 2019 18:50:55 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT034.mail.protection.outlook.com (10.152.80.177) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Sat, 5 Jan 2019 18:50:55 +0000 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x05IookR031194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 5 Jan 2019 13:50:52 -0500 Date: Sat, 5 Jan 2019 12:50:50 -0600 From: Benjamin Kaduk To: "Kurt Andersen (IETF)" CC: Tero Kivinen , IETF JMAP Mailing List , , , Message-ID: <20190105185050.GB28515@kduck.kaduk.org> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39860400002)(136003)(396003)(376002)(346002)(2980300002)(199004)(189003)(786003)(26826003)(16586007)(58126008)(54906003)(50466002)(14444005)(26005)(5660300001)(316002)(86362001)(486006)(53546011)(47776003)(36906005)(46406003)(106002)(33656002)(8676002)(9686003)(8936002)(336012)(23726003)(106466001)(53416004)(508600001)(2906002)(186003)(476003)(305945005)(1076003)(246002)(97756001)(6246003)(76176011)(356004)(11346002)(88552002)(426003)(956004)(104016004)(446003)(55016002)(75432002)(4326008)(126002)(7696005)(229853002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR01MB4025; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT034; 1:PlfI+GeI6MxeSjShGoVlfz4+XgoxeUeT7eKrQok4qNNChohdUO+Cts4u6Tfs5G2WbIES9ZhXvAwJYYYnN2fl2BUOMNYAkxOS9fJKHsQshKhH/Nhp9ahn2XgnlUU/GdEW X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 29262ba7-f578-4174-18db-08d6733eb971 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4608076)(4709027)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060); SRVR:DM6PR01MB4025; X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4025; 3:lQALM+D9bfmBnQ7BHDYaotEZj1og8m3elrmDOz/nLj0DJZXKl2NWqRUyAk0af55dICaCkkKPPjgx6pveLZJe0DTqeICQwh1uWhZ1fpyWoAZzbPIWB+otqbYYJe9Z02Z709vrNQkCKMp1m4YZter88zhpTQFH+AZYHX8+G6C4PhBMSjFam+587JFbslIoFBqqIMT7cMURdz1Zh8/NRxN64bLItC2u960VJTnNUBy1Q6IuJycxXMtXv1Urqc2v5DpZQsHRw7SKkl8EgRkO/bmeEgKfBJJVsIdSn8aI0A2hnGQTjaJbp+lQAEFa8iAhuo/yDKSn/xp6ObbTiT2GWNVwydcIC8S3OGhlBBGMvRmpUEtSUDaJ3rRFsfUv670Vrg9s; 25:L6hPVeAggpoQBcmCRq7j+ewxAZ9DpfOSoGr2s8C3RyF+PLOFJGz22Atyo+SYigmQQKRtk1mR0dz3Nq+ZVHCHuERMb+vIfE5yEfSm9uXnkTfy3nyKprhSXXRjOjriJYTCjIBupQQXPwxjJIRH7dBjwdqovXeBPdWsH/l83chKntLb4xxqB8RynoTaZxSyv1wz3hWgOtqCwklDBPhyM0riK5OnTskuUue09OQJS15t2/sdQoqBpuAWMM3lxaVrpxOIHeBVgtMlvvnfkSXo8XTOy4R9SaHgPNtwWsYh0OvzarBRhmNLM+u5wYU29e/TZGfHUkuDNpAgI+XmHu9fqiELuw== X-MS-TrafficTypeDiagnostic: DM6PR01MB4025: X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4025; 31:d3lVnjdTDV9My1oXn50jCHXhGo0YjcbX4E3Apn6eCQM0Crvw6W+zunQ6qkpRz+wY7xXgrfdEwOPewKQb92lUridYx6JRiQS02b6ufRX0yrwCNmJlqxqWRSx7MU9yuqRfHWuKvyricwaOqCcjUFhDGhP5OF501N8l1vsl6AQXkQeqwaMVuBkjUuo8lNqCLSG67FSrFA8GxwL8emmwGzfut1nNXCWaqOBvaRXQojtdTAw=; 20:GChGfZsc7XyvPT5IbMQeIDvZQUwWOA30B8iqFQIIRYBGAnR4U9HOXVVcENAc0UaMAjL437grA5FjeSdxf9ZYIC1d4XP1890X3N/UObuUu4gZ/1bZ71dBhql2r/HoJYC9EUptjqK5bi//+YJbIevsbbgfLX4wR3WqorcI8E65HPkUVikXjzgMltrBcw2cv94GHeynQiSsAZ3iBScfg6JmG/QHfio+QTEYr8mc4yDKPyphKWb3JK/QsljFCUmLq3UijJF44DlxUzhg/j0oDbSxf7F9LxveSC3rKLUQ2tm9EUAUFhT3/4PyhgUaJEHbIfh1OypGJed935OL24Y22xuM5qBE0Ci2j3LD4gu86CcnlYR6XnKa1V/QOo1dbeEUaiaZSl7n3flq7HSKtGS0zkLNXcJdEAbivn+zbmjnVAJta+Mmhpo1Csfe1q+1W5Q9RYZPRrtedqnEwB5wzK4qJYesCUNa5EbmTrQaRXCf0DexMS/wkRjv3C7Ko4ITAR+iFbBq X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(93006095)(93004095)(3231475)(944501520)(4982022)(52105112)(10201501046)(3002001)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(201702281529075)(20161123555045)(201703061421075)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DM6PR01MB4025; BCL:0; PCL:0; RULEID:; SRVR:DM6PR01MB4025; X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4025; 4:fnwkLcuWCQXQj8yisPbcE6trpRgB/nRaJwBiKwdbCSM2rEnKhy9vifUYVWtQvHBX2hTTCxRnNf6HxzDucmU1Z1fXYP3x8P7n9d1a2A1ZzVFa7sfHNavPoFekyCZ8zeFd4Zy+CoLdBoSWhHMqUb1qkFOZRI/fwrYT1Xz4Qk0YzrUHfu7Tvdr9gbZsFfDXzRfavmg2wy59SHO8VrhNGFpWcHuaZAa6f3cVUekJZYTld+/YEynuR3FnKdlhpzguiN6r/o7y39Qf5FqjePoxLfpX3W13vCRGzb9giq3qhiuhI9L3BZ5Iu23ef3RZXJRARw4i X-Forefront-PRVS: 09086FB5C5 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM6PR01MB4025; 23:nmbYMX32bKEl9fJK1345xnMwtjIKOYVpMzBk7zaMb?= =?us-ascii?Q?Yn6slbG8fSO6G25LvkjA5I6rdfBw57NscsOdl5QwiLviuo2jtfkyTP5rN3FM?= =?us-ascii?Q?1B+dyWGkGRjkeyWwa5/PkVrSDg1WIemmh9uJbSTLGeUNAIN5w7xQ2bM22Osr?= =?us-ascii?Q?ohsCyMikJa76C5U3FrunNKbPv8bQ9/UCEbndrNY/vBrWZTrt72vTwEXlOjTo?= =?us-ascii?Q?2N0M0q8vlX4uH6RT+82OX+ySijmN4qftsD65vVS/TmT4MAhjZlb67bSyW8Ia?= =?us-ascii?Q?Zgsf03ofJPRIG+zpBrnGMy1qpk20Z5DqcsESdmy0oS5fymtDDCMQRRLVK1t1?= =?us-ascii?Q?aHkhg4Dtenay3c3qaBFPvtiL1BXCDRXTMQjWQd5MMXQmN+RAgfSCe/wn1Q67?= =?us-ascii?Q?w315/8TPD4mREAQHWs96XwavyQR2br5pBFVWmdqcU28QUgFvBR4TT8V7IZLy?= =?us-ascii?Q?MSIm2AWDoYwI2FrMwnOsueE4eZZelGbzAXssIeKgTheInGcW14oLa25ixv1h?= =?us-ascii?Q?pAmn4b93XbKdBFFJMQAIqQdpy0nwmjxbGDmQKMpETdhOtcXJ2yMlklwyguSk?= =?us-ascii?Q?KIKzKoGRd7GiMovGVKBoQDIhD0GfJBtqt3QPfBiT5WHKoU8S5BUX0E46DrwK?= =?us-ascii?Q?QQ8/k/Lkbl2AruXzunFhNNyNgUgKLV//znv5T88EWO4Eq4ndPrmWAKTdw6aq?= =?us-ascii?Q?2IZR3LIi4nYF/LRzw0iU6v0WNtYnzQJGwAAMhULUi5SHVVVaRlEr4x79mN1U?= =?us-ascii?Q?CXZBybtdu5aPMpVuJ6dkjBSZNTcKgaQQdXYBdXHnULUrEV8SkmYAdFkNm5Bq?= =?us-ascii?Q?DyfP8oKci+sYxyDbQ2hycvBeStEwulGGCWitRkc0pxXYHGXhDnQZylQXvsBb?= =?us-ascii?Q?GYx+qKIuZxaWq4SqN50B12wPZNan2OsxTH10Vh/jksPsC8m8MvGOl1iteNLd?= =?us-ascii?Q?lc+a3vn0zZisvb4ghwkd8LDtQ17ZLscku6o/xZvC1TnA5E7YpInbPBsb+olx?= =?us-ascii?Q?yxHRTKIYPhl9ZddRn6Kf79xYRnenYG9EGvfD8mPFG6Q0TN6yhJDW2Xkqnaso?= =?us-ascii?Q?EW1VZn4SiL2DZ2sGATT9UzxJaJPxMDAOCQ43qP34eut+iHC6eghK9ip/Jfx3?= =?us-ascii?Q?pj57rJM7lffHz1FjEv2hxFjadKUymBC5M7f8xY4Dx2DY4bvyoskD1WvqHT5E?= =?us-ascii?Q?iXdCnojdOMcCbGn/nKKFBfyAvdkR+pypM/j/j1ZTfdVQZUmoq9HAuo1NLcqU?= =?us-ascii?Q?2WocfZLAH5TKwi9iS4=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: PSZUr9TGyK0f9zV6t+v5V7ikLhSGDMslcAWAnKl61rXQQ9XTRD/rcj+KnnUCegDgIbxdgJIYDlmkpIqP9MXaCdzxxYHh5jp5rVngfOc0JwIanlsNB+hbjCQzGrrA03mRBBdL39b70ynO3kc7IRunwdec7Q03lNWHSYAnxAa3Sf+oDBdccZl7vkTg18REXnVS5ldHfyAacNv3pHWYsufgVyUkyrKE099HL4IVVrbBijYcMPMfHQvRP/YoI6syY1V2b8zhPoDj07hsLYJDOgj4qa2EZ1HWRM/aLMaLBQn3Mk8hMAyJc++2vXC7AcZrAPoX X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4025; 6:PB+zKsOwT4cAGY5IDB+TtnEVVINlHrJG52pX1BSgk7NMCtqwv7WQ/znmCVFYbfsZvKwO4cwKUrJzjehc8pwrsVrVNst5ibo+wRr8685nCfaaMwvPJcb/krAaB238sGnWjdh0UK2CK9bZIx3nt4cYfW24beFBRNf+O4mWFVLd/vO6oXxgwruUmlQybi5xj3b7zYG/QouT5vRp7OwmhcKSfiCVaZyea0TwjHccyEhDm8KC3eVZCJJ0bfjviUhwmgbd9C1qXPJqP3+lcjQ3RM1/otcUOKS0D5txoWbbaKAbrEzbQyeYt/+iv7hGfyfYLGFmD1cTIQh8YfgwJw+sFA00dt1J7gs3+tKH/Jfj3YuQiGOfFxiu6FC4QFYxiv+dCAM6zU2Bbu4Ib0IxUnkqTHb/dzb7smiH5RMN09yzOFuttruzJo8cue10VBhMkR413wXsMafCx1lZJL1+cZcu+8yJ0A==; 5:ipad+kuBVGpcp6J/3fOWSKcwyRXkwwTZgOgxwySBbXqOLBHTAl/4t/wLx2DO+XK+ZOR2Sa+vrMaYDxosVwCsHvFa/QKSb1LdK92/vtoI5B3PBvwU3EjVz0nL0p/c/3bUZuTn8ILg+hTbsZyYG2XKEVvKZdvTwSD3AaXxWzaP0sMNkvFasa0BFi7FuxCqWI5TS1398VtBCoTWlHPe/oHR7g==; 7:AcnpFXoZ8YQyUmZKCNHBcwom0gAhvOf7SqGXIV8ClZ5J/wu7XDxGtSifzbXUJAOamKKaERT49aiyFLBQuO6fs1tPk1T+j2GXL9+W972jxC2KgRnwDX9ODy3C+69nN67mlVzC+0yzw7uUD5po1b3zJA== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2019 18:50:55.1023 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 29262ba7-f578-4174-18db-08d6733eb971 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR01MB4025 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 18:51:01 -0000 [I wrote this before I noticed that half the thread was stuck in my spam quarantine. Some of the points were made already, but I've left my text unchanged to avoid making it even less comprehensible that it was to start with.] On Thu, Jan 03, 2019 at 09:21:12AM -0800, Kurt Andersen (IETF) wrote: > On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen wrote: > > > Reviewer: Tero Kivinen > > Review result: Has Issues > > > > This document also has quite a lot of privacy concerns which are not > > addressed by it. For example email delivery and event notifications can > > leak lots of information even to passive attackers. > > > > How is this any different than the risks present in current mechanisms > (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a new risk being > introduced by the JMAP protocol. But where is it documented for those other protocols? > Of course sharing mailboxes between multiple users (one of the > > examples given in 1.6.2), has lots of privacy issues. > > > > Again, this is not a new risk being introduced by JMAP. It seems unfair to > saddle the JMAP protocol with the responsibility of documenting a > comprehensive set of privacy and security risks for bad or risky behaviours > that have been a wide part of common practice for decades. In general, we need to either document ourselves or point to existing documentation of the security considerations relating to protocols we publish. "Everybody already does [bad practice X]" does not excuse us from ensuring that the risks are adequately documented. Is it unfair? Perhaps. But the IETF consensus so far seems to be that we need to properly document that which we cannot make secure, and if we're the first one to actually document it properly, then we do incur the extra burden of doing things right. -Benjamin From nobody Sat Jan 5 11:19:47 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6AA8130E5F; Sat, 5 Jan 2019 11:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apH3seKQLyoG; Sat, 5 Jan 2019 11:19:37 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D2BA1130E36; Sat, 5 Jan 2019 11:19:36 -0800 (PST) Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x05JJRAR016685 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 5 Jan 2019 13:19:29 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1546715970; bh=/sDvZLXsLeDqc7GNWvIsX9y5clkwNVTn0hBaOZT2MMU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=ITYU3OAR02LrfOoiAiesBtoXaYAJwHNmss9K4uirZnc08Srp9omimmiYcajpCrn2k uRARVU4lcSVHsEx1qx/JQdgxJ49p1WEEunsg10NrOIkqqnvb7cpihcA5OkSf68jhBb b8E6I2RZW1ISb978Xr+1ovzfnhg5Ja61cPk4divU= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_0582A06C-09FE-4544-8602-DA7B23F1FD95"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sat, 5 Jan 2019 13:19:27 -0600 In-Reply-To: <20190105182119.GA28515@kduck.kaduk.org> Cc: "Scott G. Kelly" , "secdir@ietf.org" , "draft-ietf-sipcore-sip-push.all@ietf.org" , "iesg@ietf.org" , Christer Holmberg To: Benjamin Kaduk References: <1546285539.44113084@apps.rackspace.com> <1546631184.64914945@apps.rackspace.com> <215DF6BE-69A3-4394-9BE2-EE7751957E07@nostrum.com> <20190105182119.GA28515@kduck.kaduk.org> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 19:19:40 -0000 --Apple-Mail=_0582A06C-09FE-4544-8602-DA7B23F1FD95 Content-Type: multipart/alternative; boundary="Apple-Mail=_E86E0E6E-F505-4339-8489-73270E327355" --Apple-Mail=_E86E0E6E-F505-4339-8489-73270E327355 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 5, 2019, at 12:21 PM, Benjamin Kaduk wrote: >=20 > [with the caveat that I've only read the security considerations and = not > the whole document, yet...] >=20 > On Fri, Jan 04, 2019 at 05:15:43PM -0600, Ben Campbell wrote: >> (Speaking as responsible ART AD) >>=20 >> I will let Christer work through most of the comments, but I want to = comment on one in particular: >>=20 >>> On Jan 4, 2019, at 1:46 PM, Scott G. Kelly = wrote: >>>=20 >>> I don't know what other documents have been produced by the WG, so = maybe this is covered elsewhere, but there are generic security = considerations that apply abstractly to this use case. I think this = document should either point to documents that describe them, or = explicitly describe them here. For example, 8030 lists confidentiality = with respect to the PNS, privacy considerations, authorization, DoS, and = logging risks. All of those apply here. >>=20 >>=20 >> This draft is about how to carry some parameters in SIP that get used = with an external PNS. It should definitely document security = considerations related to carrying those parameters. But I don=E2=80=99t = think it=E2=80=99s reasonable to expect this draft to document security = considerations for PNSs in general. That=E2=80=99s up to the spec for = the PNS itself. I recognize that two of the mentioned PNSs are = proprietary; but I still don=E2=80=99t think that puts the onus on the = IETF to document their security considerations. >=20 > I agree that we don't need to document all general PNS security > considerations here, but just because an interaction is PNS-specific = does > not excuse us from stating what requirements we place on that = interaction. > It is rather unreassuring to read statements like "[d]ifferent = mechanisms > exist for authenticating and authorizing devices and users registering = with > a PNS" and "[t]ypically, the PNS also requires the SIP proxy = requesting > push notifications to be authenticated and authorized by the PNS" with = no > requirement that such authentication and authorization actually occur. > I would expect to see either a requirement for such > authentication/authorization, or some indication of what risks are = present > when they do not (e.g., excessive resource consumption, DoS) >=20 The issue is, the IETF doesn't get to put requirements on proprietary = PNSs mechanisms, and 2 of the 3 that we are considering are proprietary. = The whole point of this is to allow SIP networks to work with the = existing PNSs. They are what they are. SIP providers would not be able = to use our recommendations to select which PNSs to use; rather they must = use the ones that their customers=E2=80=99 devices already use. Obviously we can say more for HTTP Push; RFC 8030 already does that. >> The categories you mention from 8030 do seem generic, but the text in = the respective sections of 8030 seems fairly specific to HTTP(S) Push. >>=20 >> That all being said, I would be happy to see something to the effect = of the following in this draft: =E2=80=9CThe security considerations for = the use and operation of any particular PNS is out of scope for this = document. [RFC8030] documents the security considerations for HTTP Push. = Security considerations for other PNSs are left to their respective = specifications.=E2=80=9D >=20 > That seems like a pretty nice way to say it. Would that be sufficient to resolve your concern above? Thanks! Ben. --Apple-Mail=_E86E0E6E-F505-4339-8489-73270E327355 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 5, 2019, at 12:21 PM, Benjamin Kaduk <kaduk@mit.edu> = wrote:

[with the caveat that I've only = read the security considerations and not
the whole document, yet...]

On Fri, Jan 04, 2019 at 05:15:43PM -0600, Ben Campbell = wrote:
(Speaking as responsible ART AD)

I= will let Christer work through most of the comments, but I want to = comment on one in particular:

On Jan 4, 2019, at 1:46 PM, Scott G. Kelly = <scott@hyperthought.com> wrote:

I don't know what other documents have been produced by the = WG, so maybe this is covered elsewhere, but there are generic security = considerations that apply abstractly to this use case. I think this = document should either point to documents that describe them, or = explicitly describe them here. For example, 8030 lists confidentiality = with respect to the PNS, privacy considerations, authorization, DoS, and = logging risks. All of those apply here.


This draft is about how to carry some = parameters in SIP that get used with an external PNS. It should = definitely document security considerations related to carrying those = parameters. But I don=E2=80=99t think it=E2=80=99s reasonable to expect = this draft to document security considerations for PNSs in general. = That=E2=80=99s up to the spec for the PNS itself. I recognize that two = of the mentioned PNSs are proprietary; but I still don=E2=80=99t think = that puts the onus on the IETF to document their security = considerations.

I agree that we don't need to document all general PNS = security
considerations = here, but just because an interaction is PNS-specific does
not excuse us from stating what = requirements we place on that interaction.
It is rather unreassuring to read statements like = "[d]ifferent mechanisms
exist for authenticating and authorizing devices and users = registering with
a PNS" and "[t]ypically, the PNS also requires the SIP proxy = requesting
push = notifications to be authenticated and authorized by the PNS" with = no
requirement = that such authentication and authorization actually occur.
I would expect to see either a = requirement for such
authentication/authorization, or some indication of what = risks are present
when they do not (e.g., excessive resource consumption, = DoS)


The = issue is, the IETF doesn't get to put requirements on proprietary PNSs = mechanisms, and 2 of the 3 that we are considering are proprietary. The = whole point of this is to allow SIP networks to work with the existing = PNSs. They are what they are. SIP providers would not be able to use our = recommendations to select which PNSs to use; rather they must use the = ones that their customers=E2=80=99 devices already use.

Obviously we can say more for HTTP Push; RFC 8030 = already does that.

The = categories you mention from 8030 do seem generic, but the text in the = respective sections of 8030 seems fairly specific to HTTP(S) Push.

That all being said, I would be happy to see = something to the effect of the following in this draft: =E2=80=9CThe = security considerations for the use and operation of any particular PNS = is out of scope for this document. [RFC8030] documents the security = considerations for HTTP Push. Security considerations for other PNSs are = left to their respective specifications.=E2=80=9D

That seems like a pretty nice way to say it.

Would that = be sufficient to resolve your concern above?

Thanks!

Ben.

= --Apple-Mail=_E86E0E6E-F505-4339-8489-73270E327355-- --Apple-Mail=_0582A06C-09FE-4544-8602-DA7B23F1FD95 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlwxAz8ACgkQgFZKbJXz 1A37TBAAqS9ANUKFrP7D5EpYbsNK5WMfChge9eNbknDAFPuWrFhzLTRveLJBm13Y 9epxey9jElWfy6Ip8EsAzLxnMPOj9B7eJX2aDzvNbpVkBh2CUz7CY2lXuVr3URRn r65m5HEXb6CONNwpEXwoXbk1Zan+gV9NmQne6ylSCbWGPAblj0bLQ4AeEjJgG9Yf flyDcBEDobo+GpiMfgzYmzMjvNtPXEaKeO6grV9UU/HrtIo7e/airj1Dz0Lv5s8g DJtTI0z6GEsmcxMM1R4eMCJRioixHOz95lNjXeSVX2wrc8uLpGa6+A04hDtPSSv2 Dmnp409M0nc+/ERlwjIN4Y24v5bVw8pNYAdzJEhZKycPLZyuZ9LRoPYMLCLenpCD qNPIRLLbQkrj0aFwfB/assBgpKKZZ8LVUWpNfOi1gI0wvYf7s6qmejpJq2/M9xeN thbxjmfDqkiJ3PmAwyFufOakYQmvQ5HOUET2l18lTYsdL7jJvFurG38Y9XzTcjjz wMfBEjZnrRDcOf3lowxfOGU1uX/67iVFV6O9XmOiNwybSmGXAgaGg1bLjFYiq39Q Qo66IgRwLHYeovH59IFs/d5o4gRtVNa0OTCx9VGbO+b7AHyG+0+vYiiXR0u3Fhfy ZI2CbZYugRSa+FTEA2UHxzq+YLjLYKyBT8vN2UhopDNyEOQnm0s= =5ewU -----END PGP SIGNATURE----- --Apple-Mail=_0582A06C-09FE-4544-8602-DA7B23F1FD95-- From nobody Sat Jan 5 11:34:05 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073F6130DD7; Sat, 5 Jan 2019 11:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdGC95HLfrlr; Sat, 5 Jan 2019 11:33:53 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810119.outbound.protection.outlook.com [40.107.81.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38FA112872C; Sat, 5 Jan 2019 11:33:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F9apMGvKodqsZiWQRGboulzoofoLpOYieycsA9v11SY=; b=ChIqNgr5qWqe3c5zz1WeuXbW+QEqBd/CJR0xXE26ZrU9hcu5i4Qr40c767e/Scc4Y0efoTavxcNA8N/UvMCRpvqd/pvEYJ0we+Mm0WSxdE4Rn0OX/IGQScRW+9PBmiFPL8tkg+cYKsYF05Ni7Xj/rmxVTHaTPpMeaosH9Vky2Ts= Received: from BL0PR0102CA0061.prod.exchangelabs.com (2603:10b6:208:25::38) by BL0PR01MB4018.prod.exchangelabs.com (2603:10b6:208:41::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.7; Sat, 5 Jan 2019 19:33:51 +0000 Received: from DM3NAM03FT050.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::205) by BL0PR0102CA0061.outlook.office365.com (2603:10b6:208:25::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1495.6 via Frontend Transport; Sat, 5 Jan 2019 19:33:51 +0000 Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT050.mail.protection.outlook.com (10.152.82.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Sat, 5 Jan 2019 19:33:50 +0000 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x05JXkBH007985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 5 Jan 2019 14:33:48 -0500 Date: Sat, 5 Jan 2019 13:33:46 -0600 From: Benjamin Kaduk To: Ben Campbell CC: "Scott G. Kelly" , "secdir@ietf.org" , "draft-ietf-sipcore-sip-push.all@ietf.org" , "iesg@ietf.org" , Christer Holmberg Message-ID: <20190105193346.GC28515@kduck.kaduk.org> References: <1546285539.44113084@apps.rackspace.com> <1546631184.64914945@apps.rackspace.com> <215DF6BE-69A3-4394-9BE2-EE7751957E07@nostrum.com> <20190105182119.GA28515@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(346002)(39860400002)(396003)(376002)(136003)(2980300002)(189003)(199004)(9686003)(14444005)(86362001)(356004)(104016004)(126002)(58126008)(476003)(93886005)(956004)(6246003)(229853002)(11346002)(446003)(106466001)(426003)(1076003)(53416004)(55016002)(7696005)(2906002)(305945005)(23676004)(47776003)(2486003)(6916009)(76176011)(246002)(88552002)(26826003)(4326008)(2870700001)(33656002)(508600001)(8676002)(336012)(8936002)(106002)(36906005)(54906003)(316002)(486006)(786003)(6346003)(53546011)(50466002)(26005)(5660300001)(186003)(75432002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR01MB4018; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT050; 1:h2t8S5Gri5Xoi/kUF/sqSWyKOMUGtw6o6+qYoo/d3mKhvj9UaTcuQIBDTWveYU8SvlvNfObyHbjPLT9XYbAqGpFAy6AHTyI+oGKwQ7Uqa6mHe//RougUQrs+9aSYzYvm X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f4a670e0-76ac-404f-4c03-08d67344b87e X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4608076)(4709027)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060); SRVR:BL0PR01MB4018; X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4018; 3:VeWoN7cb/t0f9hPcuZPMs+QkYh4KuZdMrgq8v1wFoqOFemzqUQegi/4v/vlAjpEjNq0GeMF0Qu9HlHntQd6lJAIckiKzvCHwUcRv1H86Bv+Sn5+O/Z07S4VpTxd9+7a0IdKVEKql7p6VSb5TmyAmrIfy4Gia+tfo31nWx2AgBkE84Nr2Vl0dlHtxbQW/n9XdHFjjO7zSpY5EJ7O+wA2L2Xq2d6fst0ggV93YBf+TgnSXVdpZz193ikvhIePKRm6jLlMQJuU7EXBqsyXm39iiy/ra46f9vLEob1Ifev77l8CFuj/uPOa0LxeeOTiDKvO98hKV0GTtf5VK2z5mJs8W8XbuqWrQZbbcfWgui2sBDk5WVQps5q05zRZ0O0OqpgpG; 25:qbtvyAfeC2hpPlw3eStSW4R/7XKNxJZWBOs15GlSwVZ09EdlMcyAzfYxL28/OsgT1nEVfEMSJbL/I6qc9vJYXw/Mm8LYkHbflOac0tOi/JKvFJ7+gY7fJFDkZu+r1rW0FL5dabtilfE41otVeZGDvZWc+R7tqe7ykbTZEBP0pNo16DjHO4wVRr+5RoeAPvB5hD2Tn5wwhUS9+lVpO/z2IqDX5rjJEVKaa9h6TSQHYd5Kxjc9SUIm1HRhv8IcLNcVK/cLYM3JQ9BpsuSIwiYDl4rAOjRcvMeEcLnca65WBOi5bcw1LiPf0OPCyZdgRJwkeaai+U5OUdiOWb0aeQdQfQ== X-MS-TrafficTypeDiagnostic: BL0PR01MB4018: X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4018; 31:p4o37T9HMKHJCLMvNBpq9R2cSDlIkmwwiczG0PR1jCaJc75N02SwtRBzDKWWlMwr+OotB5F/MVYPOBQQe7fODFTZktbwRq60EK61VWJsFnAfC8HjxZdt2h/QbfPNOaaVsSX5kaukmwDeCwVFFRWFnSEulnlB9C/6SCiTXblIOLd1SUrVTZ24/mktUZYOweEzNOe4bzDiPQCq0fMjBLJll7WEYIgx/ksZAP+OsAPeux8=; 20:xtbozoXlnoPi7dz8SbFv6rd1BnBvDgLRMXdxdx1PH/h084JtowRwCEAs5MVo5zXYVOAW6BvlwzfKUvsfNmFtYO5f7vgcBOxAc1lTmi26LAXrecyfLgGeuYwyBS3UXresVCv/OiQj5KExRfDV5sZzMlpKEM7mEtmsKfRApf4z82r3Ht49PfaUV/ueEzutupZO2ScMmdXHJ8Y8I78OZ3IVG8MurTJ9NldcNoavCDP6KW0DE5aQvsIzzXhzNqvH0GacUeIL/UXIL4uT1Gnr66I25vkBBF9+4WiZMHDC2TF8/u2rzwjGSJqRU09GJRqgw0AqJePAGqMek6rH9Jc4y53VMkR+NWiKqt7R9kArlkyuvN98q5twVgZfXDAw5oTKvIGDVeL68zVMunF+AOER5o7nFd+GMdJgX9R1h59vEtvBKG/Z6xOwNkUYCF6MeBXNDTmATzSyrQMrFVfSPUR173Hi37IPXxdEvhi/lUIGhJmPTuwpnMI8yKihwJVB5R8w+DaF X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(10201501046)(3002001)(93006095)(93004095)(3231475)(944501520)(4982022)(52105112)(6041310)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(201702281529075)(20161123555045)(201703061421075)(201708071742011)(7699051)(76991095); SRVR:BL0PR01MB4018; BCL:0; PCL:0; RULEID:; SRVR:BL0PR01MB4018; X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4018; 4:x/ujCYhaXliL+l2TCgGPWjznYN3b1tYFFUkjZ54GlerwG43vI8VsLPT6RZPJbMN3MI8yaoYCRxwHLJyqew19XyPDD93gHhs2amenW0NrMohUrk6DyXuTc/hIPvF8of2MHK8V75aPnre+z9rALpbhHssLildiaDbadfzeigfw3YCx3iNDjSjdcRmPmQ8w8cP2iugwpEIIkFgHgonyiTw6uXJruN+/RxLPwTb8KvZPtXqcN85SfYVD98BSdjRY4ufXjXbvxFoto3BdOK+IELqpcfUr0Jt8sI+rF6ZktqP095o= X-Forefront-PRVS: 09086FB5C5 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTDBQUjAxTUI0MDE4OzIzOnk1UG1nMjZFUGk1MmpCYndjVlE0ZUg4b2I0?= =?utf-8?B?OCtzeU9NaklmejNMcnZxSmZDcmdtSFQ1NnAvdkVkajh0eDE2K29kWWxFNHI2?= =?utf-8?B?cXBHVkJ3NXhrU3c1UG9URW54Z1dxa3h5RnBYejkxODlpWmNJSDRmR0hYOFp4?= =?utf-8?B?ZnptRllaWkIxQVUrcGlRbzZzQnZVMWxRaGlmdVY4MmxZc25pK3M2ZDNBWVpB?= =?utf-8?B?dkw4QVlyVEhiYm0zRkkvLzJtS1BpaS9WejhyVFlKRDF3andaTmhQUEl5WGww?= =?utf-8?B?UGE1Y1hxUWR4aWRHNzU3b0tnTU9HZnI3Y2J1UkExbkFwNDlpZkdXRjNISVQ0?= =?utf-8?B?UnJrWUg5eXgxbXJTdk5YRGJUbHdiUTVEUkQ3eU81b1VsVE9taFlSOVQ4dURx?= =?utf-8?B?Rm1zK29jb0FrQ3QydXRwTFJYOHZlYnNoazZBNkVBT3J4emI5L0RiY2krVFpR?= =?utf-8?B?VElCcVRaU1NsZHB3WHRDMHFDZEJRckc3T1V5WjlNc0NYTmU1eTkzS25NY0sz?= =?utf-8?B?NldyQy9TdkhHUWlGQXpzVENwSUc2YVFxa2ZjSlI2UG5RUFdabWk0aks3R05p?= =?utf-8?B?dk9OY3RlS0s4azZmcWdJb0tEdGhHSnpqK0tta3VqRS9DUlhaWWJYNjRvdkJs?= =?utf-8?B?K3ZCcjhwb0dpdUxNZy9iTUtPVzZ6U1o0VTFWcmkwK1lQNW14dElaQ24xb2l2?= =?utf-8?B?c1JDTzRYdTJ0M0FzSHFDWHg0ZEIvN0M4NjBrNjJqMjdNZTArQjJJUzFxUm5Y?= =?utf-8?B?M00zbW5WRHZud2FHQitwOXhrTnM1ZTdjc3dQWldxdXFXSStFdCs1OGpvMm9V?= =?utf-8?B?M3Q0MkFSWVpzRklqV0VVMHBOWGVZKzkyL0RvZ0lWOHBibGJYL2hKdUZWY05B?= =?utf-8?B?Y3Z2aks4a0I2VkltUVU1UjlqMHU0dzg5bG1JcFEzUksrc3FsTExPVkxkQkxI?= =?utf-8?B?KytYTFUzT29GcHF4RTFDeVZ0U051QytISXMxeXhEcU1WaUNucW81bHpUaWYy?= =?utf-8?B?V3ZLQmJ2SXRmakVaR1VpcDEzTkQ0MDYwLysrN28yZmxSSnhtaWNQb0JTK1V4?= =?utf-8?B?eCs4MkhOdWdxSWZHVmJQSUswbFhiUVNJcXlrbmQzNEVzVFpmWmVRZC92UTc0?= =?utf-8?B?bW5wZWhFRDhuZVllN2xObHRYeXlqNGdBZkJkeThiTjM1bzB3UTFGVm1GTEZE?= =?utf-8?B?UkVMcTVyZWtqeDkrTUNzMTlwMkpoVDFOR21LNm82Z1ppWHVJV0pFVjV2QnVn?= =?utf-8?B?R3Z5VzAwbHhqa1ZhWlYyVXJxT3kwb1lSQ1dCYjVRdFZOKzEwYXBxZFhlTTZJ?= =?utf-8?B?Wnp3SDN0WUJFM2Y2RWtrMHJaSXFnSFdsVXVsUzJOd0M2dEtpcklueHFZc1hy?= =?utf-8?B?STROTWtWTVdpU3hkUHprRlJsSVhhTDcxWURjQjBkVUpWVmNkbm1FMnRZZUtu?= =?utf-8?B?ZFhsRjA2eHNISStmdTg1dUl1NHdoWmVpZ0xsb2NjNmJMZG1Uck5tVUt3a3VI?= =?utf-8?B?aE4wRStaYk50ejN2ZDFYSmZyOVVFblg0RWswTTRZOHdRM1hXU3RZSmpDeHEr?= =?utf-8?B?TGYvV0V5RzkyaW5qYXlFSERyajhFTzFXYVdkK0M3Ryt2RmVwRHRST2RkWkl0?= =?utf-8?B?c1dKYjZtZ25ySjhMTXMxdS9ybi91OStsS3I2S0lZZWZLWk1hTU5NQ1NFM0gz?= =?utf-8?B?dFpNUm5RRnFhNjVJTHp2K3ZiWUd0eHpYazdYUkFYQWRJOUVWdWF0ZnBRT2E5?= =?utf-8?B?dWdzNE93WEdQWWtCdWlJUT09?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: unaPHBXqufEflZi2O2tModX8xvpVCse7TZtxvZEc+hyszXN1ptZUCO/JxDyQT/SiK+8NwAdR9KbK3Eto7yqtzaF4ix9VqbOHG/XdNM5KZK4sq4LEgMB8ydLgnni20hiZLFr2NHEnZt7ykYYoHREdbKBK442IU3bAia+gGtSGuNygYhGQuhYdknbwcEgyVMLTmPCfY/6Xe1fbsrsbAlcg3xfve6/e77md5pLexcMrvyEwvD36s9zWM+EEA3OywT662oxkebZ5yrrUfh2CiXt05MfWw6AHVwwcf2MZwt3BPJvHAis9pujAqsZgKnTFvrpl X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4018; 6:MdvIVLnq83Ezwn0SnAyEPvUPmyX1Utbc5clUKK5Gl8mC+K7aXXrENX/YuOUGdQjFFjO84eA8Et8Sw4dTsnsV50G7RMi9QyYLkGgBkArrMhYtbF3v7Bq0h2TYGUu/H/ECJK6M2y0hO0ks10JpKFAfSBo7mYD/0iUpiMpJUR9zPVWp2yq7bjiNNeBEwjxANCIlDrx8P1EdukHrbwFmPr1vsD0psRCONbYqDIX46YhEHUX81Qk4e6WqwpEgp23BiT78K4Q03ZRHhNtPhyt/BjvYKsu1wFd9GkL4gIazZBrrTv/MDRvmwvHs5kSyzcufzvlzecRS2b9Ak5iCphC6dTjqMlYWKz7E1swAOIykpxNhBFfVlvYegNE6sAnlBh4Lq8Jf2bIS5X+KvBn6tA8K8Nky0KDEyR9kvzMdR+z5Y7+zMbYF9o8xn9nEQVjm/UeeqG7PaDMji9gHrICQH3uJQHFpRA==; 5:MhKZnG7lO9RbVxbNuYOYNW/8ndj6eKa8yZQuQiz/C3pGjtANuTh1X2/vhdJnzzTwbILySjd5S4VGVvjkBbi27VXZiMqPvoobxv+Aj0BmuHe//Mj/WjazMr6UyXtCbigNKKP3YBsho3yZj+j2npakml8LNxZnrirfwxyp5jAYW+Jw3xZuTkf8ADzzvQCfDPL/riCsPIE19gbA6tAYvo5g9Q==; 7:yXpe1J+p07pybjy25j96WIXP88Dj1kjfBlOTIPK7sRyj0WVVZbF7bH6LjRXL37rZklmdGI2A/4oGH+tUc61h5L0MfTWlYFRMcM0jVodcPBLJSijaJSKF8P7j3xQOzt2K1jZq0drJv+iDlYyc673gHg== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2019 19:33:50.4758 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f4a670e0-76ac-404f-4c03-08d67344b87e X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR01MB4018 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 19:33:56 -0000 On Sat, Jan 05, 2019 at 01:19:27PM -0600, Ben Campbell wrote: > > > > On Jan 5, 2019, at 12:21 PM, Benjamin Kaduk wrote: > > > > [with the caveat that I've only read the security considerations and not > > the whole document, yet...] > > > > On Fri, Jan 04, 2019 at 05:15:43PM -0600, Ben Campbell wrote: > >> (Speaking as responsible ART AD) > >> > >> I will let Christer work through most of the comments, but I want to comment on one in particular: > >> > >>> On Jan 4, 2019, at 1:46 PM, Scott G. Kelly wrote: > >>> > >>> I don't know what other documents have been produced by the WG, so maybe this is covered elsewhere, but there are generic security considerations that apply abstractly to this use case. I think this document should either point to documents that describe them, or explicitly describe them here. For example, 8030 lists confidentiality with respect to the PNS, privacy considerations, authorization, DoS, and logging risks. All of those apply here. > >> > >> > >> This draft is about how to carry some parameters in SIP that get used with an external PNS. It should definitely document security considerations related to carrying those parameters. But I don’t think it’s reasonable to expect this draft to document security considerations for PNSs in general. That’s up to the spec for the PNS itself. I recognize that two of the mentioned PNSs are proprietary; but I still don’t think that puts the onus on the IETF to document their security considerations. > > > > I agree that we don't need to document all general PNS security > > considerations here, but just because an interaction is PNS-specific does > > not excuse us from stating what requirements we place on that interaction. > > It is rather unreassuring to read statements like "[d]ifferent mechanisms > > exist for authenticating and authorizing devices and users registering with > > a PNS" and "[t]ypically, the PNS also requires the SIP proxy requesting > > push notifications to be authenticated and authorized by the PNS" with no > > requirement that such authentication and authorization actually occur. > > I would expect to see either a requirement for such > > authentication/authorization, or some indication of what risks are present > > when they do not (e.g., excessive resource consumption, DoS) > > > > The issue is, the IETF doesn't get to put requirements on proprietary PNSs mechanisms, and 2 of the 3 that we are considering are proprietary. The whole point of this is to allow SIP networks to work with the existing PNSs. They are what they are. SIP providers would not be able to use our recommendations to select which PNSs to use; rather they must use the ones that their customers’ devices already use. > > Obviously we can say more for HTTP Push; RFC 8030 already does that. > > >> The categories you mention from 8030 do seem generic, but the text in the respective sections of 8030 seems fairly specific to HTTP(S) Push. > >> > >> That all being said, I would be happy to see something to the effect of the following in this draft: “The security considerations for the use and operation of any particular PNS is out of scope for this document. [RFC8030] documents the security considerations for HTTP Push. Security considerations for other PNSs are left to their respective specifications.” > > > > That seems like a pretty nice way to say it. > > Would that be sufficient to resolve your concern above? I think I would still like to see some indication of the potential consequences for the mechanism defined in this document, if a PNS does not (properly) perform authentication and authorization between UA/proxy and PNS. (Having not yet read the whole spec I don't have a great picture of exactly what those consequences are.) -Benjamin From nobody Sat Jan 5 11:34:12 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDA5130DD7; Sat, 5 Jan 2019 11:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Se7xloCgjvoG; Sat, 5 Jan 2019 11:34:02 -0800 (PST) Received: from mauve.mrochek.com (unknown [66.159.242.17]) (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 9176B130EBE; Sat, 5 Jan 2019 11:34:02 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1NGKEZT6O00CU83@mauve.mrochek.com>; Sat, 5 Jan 2019 11:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1546716534; bh=sf4c36YZ4BNCMpQJ5V5igQn3Ldam/WhPWvkvpXIiZ/I=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=ZSTpVD8P5VUslVAyBlJ9Xs6X28+x6NMouWyQMA2dJ5GBeP9M8DtAIBvTaZ25Q/idR FYMHUyMhczd8Wdb9WCZ/pbLJP+TPhCs/iNpikkJFc3vG81ACGX/HHPqI1w+WVPqVV6 APOvuz5PZ4gUgglioX7ClZW4jLAssQexc6lXs5EE= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com>; Sat, 5 Jan 2019 11:28:47 -0800 (PST) Cc: Ned Freed , "Kurt Andersen (IETF)" , IETF JMAP Mailing List , "draft-ietf-jmap-core.all@ietf.org" , "secdir@ietf.org" Message-id: <01R1NGKAIUZQ00004L@mauve.mrochek.com> Date: Sat, 05 Jan 2019 11:15:43 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 04 Jan 2019 23:10:10 +0000" References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> To: Jeffrey Hutzelman Archived-At: Subject: Re: [secdir] [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 19:34:04 -0000 > It may be the first such mechanism we've standardized, but it's certainly not > the first time we've contemplated push notification of email delivery. Consider > RFC5435 (the Sieve notify extension), published just about 10 years ago this > month. Among other things, it contains extensive discussion of security > considerations surrounding push notification. Not really. The security considerations, while extensive, do not cover traffic analysis of notifications pushed directly to the client, which is the main concern here. And neither do the other RFCs defining specific sieve notification mechanisms. This is likely because all of the mechanisms we were standardizing have a different set of security issues. Indeed, almost all of the considerations covered in RFC 5435 et al. are orthogonal to the current case, which is why I didn't suggest citing RFC 5435 et al. in the current document. Ned From nobody Sat Jan 5 12:00:57 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB96512872C; Sat, 5 Jan 2019 12:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUvwUIZsq1oR; Sat, 5 Jan 2019 12:00:53 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D27DB130E91; Sat, 5 Jan 2019 12:00:53 -0800 (PST) Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x05K0jUi023332 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 5 Jan 2019 14:00:46 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1546718447; bh=ltHKy8yNvaCcVmu66A/AT9wiO4/+GPxRkXl2LVh4yNw=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=lTR4uG3LjGh+jTjgLoGCDluvaCXMUCNXwc3CvqQ+Z9qRkPYkSfIuJuq/vM/2Sydz6 OU83lF3/6wX6Zs3plxwA+oZjkmSIKADHl+y6363K74Y1UTLsUHKkOAAjZZwBL5FSEU 8GG3yL/y13xvQ3Ec8WRKEbY1EzTgrALtGOKNxAmk= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45] From: Ben Campbell Message-Id: <8D02428A-AC2F-4D80-A108-CE55833CFAFE@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_83359410-8352-4D44-9652-2772D7B7E86E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sat, 5 Jan 2019 14:00:44 -0600 In-Reply-To: <20190105193346.GC28515@kduck.kaduk.org> Cc: "Scott G. Kelly" , "secdir@ietf.org" , "draft-ietf-sipcore-sip-push.all@ietf.org" , "iesg@ietf.org" , Christer Holmberg To: Benjamin Kaduk References: <1546285539.44113084@apps.rackspace.com> <1546631184.64914945@apps.rackspace.com> <215DF6BE-69A3-4394-9BE2-EE7751957E07@nostrum.com> <20190105182119.GA28515@kduck.kaduk.org> <20190105193346.GC28515@kduck.kaduk.org> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 20:00:56 -0000 --Apple-Mail=_83359410-8352-4D44-9652-2772D7B7E86E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 5, 2019, at 1:33 PM, Benjamin Kaduk wrote: >=20 > On Sat, Jan 05, 2019 at 01:19:27PM -0600, Ben Campbell wrote: >>=20 >>=20 >>> On Jan 5, 2019, at 12:21 PM, Benjamin Kaduk wrote: >>>=20 >>> [with the caveat that I've only read the security considerations and = not >>> the whole document, yet...] >>>=20 >>> On Fri, Jan 04, 2019 at 05:15:43PM -0600, Ben Campbell wrote: >>>> (Speaking as responsible ART AD) >>>>=20 >>>> I will let Christer work through most of the comments, but I want = to comment on one in particular: >>>>=20 >>>>> On Jan 4, 2019, at 1:46 PM, Scott G. Kelly = wrote: >>>>>=20 >>>>> I don't know what other documents have been produced by the WG, so = maybe this is covered elsewhere, but there are generic security = considerations that apply abstractly to this use case. I think this = document should either point to documents that describe them, or = explicitly describe them here. For example, 8030 lists confidentiality = with respect to the PNS, privacy considerations, authorization, DoS, and = logging risks. All of those apply here. >>>>=20 >>>>=20 >>>> This draft is about how to carry some parameters in SIP that get = used with an external PNS. It should definitely document security = considerations related to carrying those parameters. But I don=E2=80=99t = think it=E2=80=99s reasonable to expect this draft to document security = considerations for PNSs in general. That=E2=80=99s up to the spec for = the PNS itself. I recognize that two of the mentioned PNSs are = proprietary; but I still don=E2=80=99t think that puts the onus on the = IETF to document their security considerations. >>>=20 >>> I agree that we don't need to document all general PNS security >>> considerations here, but just because an interaction is PNS-specific = does >>> not excuse us from stating what requirements we place on that = interaction. >>> It is rather unreassuring to read statements like "[d]ifferent = mechanisms >>> exist for authenticating and authorizing devices and users = registering with >>> a PNS" and "[t]ypically, the PNS also requires the SIP proxy = requesting >>> push notifications to be authenticated and authorized by the PNS" = with no >>> requirement that such authentication and authorization actually = occur. >>> I would expect to see either a requirement for such >>> authentication/authorization, or some indication of what risks are = present >>> when they do not (e.g., excessive resource consumption, DoS) >>>=20 >>=20 >> The issue is, the IETF doesn't get to put requirements on proprietary = PNSs mechanisms, and 2 of the 3 that we are considering are proprietary. = The whole point of this is to allow SIP networks to work with the = existing PNSs. They are what they are. SIP providers would not be able = to use our recommendations to select which PNSs to use; rather they must = use the ones that their customers=E2=80=99 devices already use. >>=20 >> Obviously we can say more for HTTP Push; RFC 8030 already does that. >>=20 >>>> The categories you mention from 8030 do seem generic, but the text = in the respective sections of 8030 seems fairly specific to HTTP(S) = Push. >>>>=20 >>>> That all being said, I would be happy to see something to the = effect of the following in this draft: =E2=80=9CThe security = considerations for the use and operation of any particular PNS is out of = scope for this document. [RFC8030] documents the security considerations = for HTTP Push. Security considerations for other PNSs are left to their = respective specifications.=E2=80=9D >>>=20 >>> That seems like a pretty nice way to say it. >>=20 >> Would that be sufficient to resolve your concern above? >=20 > I think I would still like to see some indication of the potential > consequences for the mechanism defined in this document, if a PNS does = not > (properly) perform authentication and authorization between UA/proxy = and > PNS. >=20 > (Having not yet read the whole spec I don't have a great picture of > exactly what those consequences are.) >=20 That=E2=80=99s reasonable, and I think fits into the category of = consequences to the SIP network due to the interface. Thinking out loud: One thing that comes to mind would be the insertion = of false push notifications by an unauthorized 3rd party. It seems like = the 3rd party would have to learn the necessary parameters, which might = be difficult. How guessable these parameters might be would have an = impact. If someone succeeded in this, I imagine it mostly as a DoS attack on = handset battery life. It could possibly be a DoS on the registrar. =46rom a privacy perspective, an eavesdropper might be able to infer = something about the number of incoming calls to a handset. Hopefully = there=E2=80=99s not much in the way of PSI in the push request or = notification themselves. Ben. --Apple-Mail=_83359410-8352-4D44-9652-2772D7B7E86E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlwxDOwACgkQgFZKbJXz 1A1zAw/9GipNnpq3TV5iZnawYXNLt9rmoaVOu6/NIGmBZsYy7ridiPw850YiYAZV 5htPfB4fDgGFt8NNHvbjXcoQ6NstZKRy2BFrPBOKTtKLNFEr9/tNHB+aQYkGXKvX rZ77KVI423EkLKwWSdT0hyTNb4uKKqBufdBVL9EafSSaPWZisaPFIdvyGEGgNivs qILZHL+KeziGLZxVLDX9BWH0lLx7f03ATA++Cl9aZp4v1qikcY4rx7kU+2sdU1iS wjU0YIgbjXrsk8MxQpLbkBHvnUB/Qk/d1wUaKytXMOwPIfV/AZNY+FJINhdxzTPU OT/tALVECPvnaCJmlqUdN4vIYSNEWAMuKAKNuwOs4vb+OeVQMeIOntpeDy/0PQ/g Gn+9OQuNaZTwSb8ljpwYxeFdSu5LnShu4vCYxib4rXSx5ZSVbZeROsqXF8wlH2/E Bol+PtLfBcjqvw0FTdm1cTbn9TZVyhJ757AuGA+lKL0OhsD6CGiyK+gTBeZCQnGY Gfsn6z0MiRgs0Pj9cho21eaDGRPO7Df3iOyHyEFmu0f/1k+DTqqX1qgUC+DFUV3X 9e2d7Pyh8t9Q15JZgg+qZjYF92MEQBfA7e11kb52C06ngwCXA8ysNrfoL/EkBvHI ErcD0Wp626l1kpxfvd580uDZmwauj9sxM7a6q3HTbKOEqXAz2UU= =AXhF -----END PGP SIGNATURE----- --Apple-Mail=_83359410-8352-4D44-9652-2772D7B7E86E-- From nobody Sat Jan 5 14:26:46 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C380130DEC; Sat, 5 Jan 2019 14:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Ac4vhkIE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=drCyqhnm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYkH6VPj7H7R; Sat, 5 Jan 2019 14:26:31 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2681B130E8A; Sat, 5 Jan 2019 14:26:31 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id B88D312C9; Sat, 5 Jan 2019 17:26:29 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sat, 05 Jan 2019 17:26:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=RA/AtDvOddrtwaEJnPyOwwlLq tPh2E+UNyhNmoL2zIM=; b=Ac4vhkIEAy4QOpwI3K9l4IVC6VzTyAqf8qaILCS64 dgM3Em022YZ95SNVsHgASCpil2Wbt8ayBf9c2y8EyYNGnvwHxF21Q6N30bdFTpm6 KoYP5ZcyjFypBhKuYolwoAyCekLbHq6HLpNDZo7gqIdJelYTUouNzkADSAlCFNRC kEhaOm6o4A3aBE2Ajb6Hh2PxxklILeDWGC2D/vHBg03FlpbdcGetXgzvTxfMWaEO wkP+Bdo+HRqH4uatMKTY/IYcc9KtE3LrzUakW9BoRXUATdisnpK4bBKQgvZGT7dd 7sB9XXdVAqfM9CJ94k1yhNvZmCTA2vl2SQftI3/EV//Qw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=RA/AtDvOddrtwaEJn PyOwwlLqtPh2E+UNyhNmoL2zIM=; b=drCyqhnmP2kHjXeozWqlLkLp6uKAajKDi uEvqM7ywNGbdGc7JevytpjGUBZd6LIgAygycbOYLQLLiFJyEnxYox10doWhk4Iz0 ZYViESAaUm9Jue+PoFMTfmeVZTms1k5gxBz+846xOfsKztaRPPZ5/BE3ddinMqZe FDhblK7VQcASkAYwuXPIpaBnd7cp2gscrX09xRSKtkFBUy/YRJk0sW8H5v2AjiOe j281un2VHamfJlpnIGUIrzcYZdXN0kVRSdaeZ+ytHpy4WuS7QXhauyXJJlDZZ6Yk W1yf2AVTi6ZJv5wvwH+A6wM9R2paZqMmVaMRACRTrXnr1Jnos+CeA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdefgdduieegucdltddurdegtdekrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhht necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfrrghrrghmpehmrghilhhfrhho mhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuih iivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7BCFF203BE; Sat, 5 Jan 2019 17:26:28 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 56629417 Message-Id: In-Reply-To: <154651703823.29557.748556981627156046@ietfa.amsl.com> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> Date: Sat, 05 Jan 2019 17:26:26 -0500 From: "Bron Gondwana" To: secdir@ietf.org, "Tero Kivinen" Cc: jmap@ietf.org, draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=8cb4414092ff4b229d537eb89e72113d Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 22:26:34 -0000 --8cb4414092ff4b229d537eb89e72113d Content-Type: text/plain Hi All, sorry for the late reply - I'm on vacation with spotty internet. I am replying to the original message to retain the full CC list, but will mention things in the followup emails I have seen as well. Regarding RFC4314 - that should definitely be referenced, but by jmap-mail, not jmap-core. I don't believe that that we should change the sharing example from mail to calendar - shared mail accounts are a common thing in the business world as well as in universities. I take exception to calling that "bad or risky behaviour", not all email is private personal email. It's not unreasonable to have another personal account shared with somebody though - the secretary use case often works like this, where the secretary has read access to the boss's Inbox. I've added the discussion to the ticket for RFC4314 anyway, and created it here: https://github.com/jmapio/jmap/issues/274 We definitely need to document the security considerations for immediate third party push. https://github.com/jmapio/jmap/issues/275 And look at making the push protocol have a confirmation step: https://github.com/jmapio/jmap/issues/276 I believe that's everything from the thread - please let me know if I've missed any actions we need the authors to take. Thanks, Bron. On Thu, Jan 3, 2019, at 23:04, Tero Kivinen wrote: > Reviewer: Tero Kivinen > Review result: Has Issues > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This is quite complicated JSON based meta application protocol, which > allows all kind of operations to be done on the server. The security > considerations lists most of the security concerns, including the fact > that owner of the account can use push event notifications to cause > denial of service attacks against 3rd party. > > Instead of just pointing it out, I think we should disallow that kind > of DoS options, i.e., I think the push subscription needs to be > extended to include initial verification step, i.e., when client > registers a PushSubscription the server should immediately send one > "event" notifying the creation of the push subscription and then when > client sees that event it could verify that it can see it (this would > also allow easy way to find out whether the given url actually works) > and send verification token given in the first event back to server > confirming that it can actually see the events. > > This would forbid client to set up denial service attacks against 3rd > parties, and would also verify that the event channel is actually > working, i.e. the url is accessible by the server and that the keys > are correct etc. > > This document also has quite a lot of privacy concerns which are not > addressed by it. For example email delivery and event notifications can > leak lots of information even to passive attackers. I.e., if someone > can see that wikileaks smtp server sends email to corporate smtp > server, but the smtp traffic is encrypted so they do not know the > recipient of the email, but then few seconds later see push event > notification stream going to the Joe's laptop indicating something has > happened in his mail box, they can find out the who the recipient was. > > Of course sharing mailboxes between multiple users (one of the > examples given in 1.6.2), has lots of privacy issues. Perhaps some > text explaining these issues would be needed in the security > considerations section. Also I think it would be better example to say > people share calendars, not mailboxes, as sharing calendars between > different users is much more common than sharing mails. > > Group mailboxes do have their uses in cases of shared support mailbox, > but it might be good idea to use that example instead of the current > text in 1.6.2. I.e., user has their own primary mailbox, and then they > also have access to shared support mailbox. > > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --8cb4414092ff4b229d537eb89e72113d Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi All, sorry for the la= te reply - I'm on vacation with spotty internet.  I am replying to = the original message to retain the full CC list, but will mention things= in the followup emails I have seen as well.

Regarding RFC4314 - that should definitely b= e referenced, but by jmap-mail, not jmap-core.  I don't believe tha= t that we should change the sharing example from mail to calendar - shar= ed mail accounts are a common thing in the business world as well as in = universities.  I take exception to calling that "bad or risky behav= iour",  not all email is private personal email.  It's not unr= easonable to have another personal account shared with somebody though -= the secretary use case often works like this, where the secretary has r= ead access to the boss's Inbox.  I've added the discussion to the t= icket for RFC4314 anyway, and created it here:

https://github.com/jmapio/jmap/issues/274

We definitely need to document the se= curity considerations for immediate third party push.


And look at making t= he push protocol have a confirmation step:


I believe that's everything from the thread= - please let me know if I've missed any actions we need the authors to = take.

Thanks,

Bron.


On Thu, Jan 3, 2019, at 23:04, Tero Kivinen wro= te:
Reviewer: Tero Kivinen
Review result: Has Issues

I have review= ed this document as part of the security directorate's
ongoing effort to review all IETF documents be= ing processed by the
IESG.&nb= sp; These comments were written primarily for the benefit of the
security area directors.  Docum= ent editors and WG chairs should treat
these comments just like any other last call comments.

This is quite complicated JSON based meta application protocol, = which
allows all kind of oper= ations to be done on the server. The security
considerations lists most of the security concerns, inc= luding the fact
that owner of= the account can use push event notifications to cause
denial of service attacks against 3rd party.

Instead of just pointing it out, I think we should disallo= w that kind
of DoS options, i= .e., I think the push subscription needs to be
extended to include initial verification step, i.e., w= hen client
registers a PushSu= bscription the server should immediately send one
"event" notifying the creation of the push subscrip= tion and then when
client see= s that event it could verify that it can see it (this would
also allow easy way to find out whether t= he given url actually works)
= and send verification token given in the first event back to server
<= /div>
confirming that it can actually s= ee the events.

This would forbid client to set up denial = service attacks against 3rd
p= arties, and would also verify that the event channel is actually
working, i.e. the url is accessible = by the server and that the keys
are correct etc.

This document also has quite a lot of= privacy concerns which are not
addressed by it. For example email delivery and event notifications c= an
leak lots of information e= ven to passive attackers. I.e., if someone
can see that wikileaks smtp server sends email to corporat= e smtp
server, but the smtp t= raffic is encrypted so they do not know the
recipient of the email, but then few seconds later see pu= sh event
notification stream = going to the Joe's laptop indicating something has
happened in his mail box, they can find out the who= the recipient was.

Of course sharing mailboxes between m= ultiple users (one of the
exa= mples given in 1.6.2), has lots of privacy issues. Perhaps some
text explaining these issues would be= needed in the security
consi= derations section. Also I think it would be better example to say
people share calendars, not mailbox= es, as sharing calendars between
different users is much more common than sharing mails.

Group mailboxes do have their uses in cases of shared support mailbox= ,
but it might be good idea t= o use that example instead of the current
text in 1.6.2. I.e., user has their own primary mailbox, an= d then they
also have access = to shared support mailbox.


--
  Bron Gondwana, C= EO, FastMail Pty Ltd
  brong@fast= mailteam.com


--8cb4414092ff4b229d537eb89e72113d-- From nobody Sat Jan 5 15:06:31 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81698130DEC; Sat, 5 Jan 2019 15:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=mDdSEfhh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IHD3uDuQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GB-62YSS4cUz; Sat, 5 Jan 2019 15:06:13 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1509B129AB8; Sat, 5 Jan 2019 15:06:12 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B8A0B21B74; Sat, 5 Jan 2019 18:06:10 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sat, 05 Jan 2019 18:06:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=u10ZO7RBHZdaC77a8j3ab0x+y QvjokmxPWqgeB1HlGU=; b=mDdSEfhhj5EYH9tvHZfcF+Uy0Vb70ANrur0CAcmbE gL8GAoW1gIjekEU5U82H8ybmAQDLGKfQWaNBKMroePBtIoVykVDpNkLJ5e1h+MKM DG2AZzkyPzxNn+Bj1BDOHI42ISuiV4Jdy2bQc7TG1S2uryVsLY90ssDpx42QteQA gF7ahWTSb47dYUhzJNs+dUGbR6Hwk71fPO4Mxenx2lTk6X/BjKhLyfcNY4nuetp7 8nxVt7BQpsxvxvt3byujcw3Sy0cZU5MQ7IspzB45LS0ShYE4U9OBU7fdx3prGbRj WdNn4pKRXgXAVJGqKsyNzCQsg+soD0O2L9WaDCPi9b84A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=u10ZO7RBHZdaC77a8 j3ab0x+yQvjokmxPWqgeB1HlGU=; b=IHD3uDuQpBQPEEN14s0/gxdGenvCCAGK2 aviekS2mWXTei8jp8072GHrcw+kH9hwYfgqER9MfltfNwEffiQMGWYq/V/ouVYYe 1clgCMnsikYJ1ASAzBPoIX6GwbKVPHmOvanPDJL3cxi2x4OJh4FtMNXD38zvYq2G dJPd1tcxbPsigXnLzXl0Jmfz04AJTZH3WSRKkG4j+cYExPDFxFxJ5/OuxU18oOXr 7JoQ7/vLXEOv9Lox6QN+TXRpGAHKKvB6+5ddmufET6LjeGkT3McMtTDWZZheVfgY 9clqUcJGfI4RfKCl84Tp+VlwANxKcFvXEeHOAQwDqmzhFdek9KJJA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdeggddtjeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuffhomhgrihhnpehhthhtphhrvghquhgvshhtshdrhihouhdpghhithhhuhgsrdgtohhm necurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmh drtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A8B5D203BE; Sat, 5 Jan 2019 18:06:09 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 64588216 Message-Id: <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> In-Reply-To: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> Date: Sat, 05 Jan 2019 18:06:09 -0500 From: "Neil Jenkins" To: secdir@ietf.org, "Tero Kivinen" , "Bron Gondwana" Cc: "IETF JMAP Mailing List" , draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=579f7d2c679049869e501976f579f99c Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 23:06:15 -0000 --579f7d2c679049869e501976f579f99c Content-Type: text/plain On Sun, 6 Jan 2019, at 9:26 AM, Bron Gondwana wrote: > And look at making the push protocol have a confirmation step: > https://github.com/jmapio/jmap/issues/276 I'm not convinced this is necessary and/or helpful. In the current system, the first time a push is triggered the application (JMAP) server sends a request to the push server (the URL registered by the client); if this is not accepted with a reasonable HTTP response, it would automatically disable it. The danger is meant to be DOSing this URL (it's not really a push server); however with a confirmation step, you still need to do that first request so you're not reducing the number of HTTP requests. You are however relying on the push being received by the client in order for it to be able to complete registration, and all common push services do not guarantee delivery, so this becomes much less reliable. (With this in mind, the JMAP push system happily copes with dropped push packets while still guaranteeing full resynchronisation.) I note this issue doesn't really seem to be specific to JMAP, and yet RFC8030 (which is what the push system is implementing) does not require a confirmation step. Neil. --579f7d2c679049869e501976f579f99c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Sun, 6 = Jan 2019, at 9:26 AM, Bron Gondwana wrote:
And look at making the push protocol have a con= firmation step:

I'm not convinced this is necessary an= d/or helpful. In the current system, the first time a push is triggered = the application (JMAP) server sends a request to the push server (the UR= L registered by the client); if this is not accepted with a reasonable H= TTP response, it would automatically disable it. The danger is meant to = be DOSing this URL (it's not really a push server); however with a confi= rmation step, you still need to do that first request so you're not redu= cing the number of HTTP requests. You are however relying on the push be= ing received by the client in order for it to be able to complete regist= ration, and all common push services do not guarantee delivery, so this = becomes much less reliable. (With this in mind, the JMAP push system hap= pily copes with dropped push packets while still guaranteeing full resyn= chronisation.)

I note this issue doesn't re= ally seem to be specific to JMAP, and yet RFC8030 (which is what the pus= h system is implementing) does not require a confirmation step.

Neil.
--579f7d2c679049869e501976f579f99c-- From nobody Sat Jan 5 16:00:52 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23B7130E69; Sat, 5 Jan 2019 16:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zug7dMOq0QLj; Sat, 5 Jan 2019 16:00:31 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760117.outbound.protection.outlook.com [40.107.76.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A0E0130DEC; Sat, 5 Jan 2019 16:00:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5kXkK6pOozKOmRfutAp2L/sYddZOOpmaL1QpEWzQxWs=; b=xshPANlrVmpFiXCZ4vPuoQ4tWSKLL7XoHckuDkahwVhDcKvtWh+oQavH70ZlUvA1lkWR4iU5AmnL1gD43MWvQF54HZIYZtu0qWdaILZ9PwQwJruBuf59DzfOu00z7O+lQWQjSF9avLtwpYsPqCcbJkbXSeZDg0+RJhHLtXWmm8E= Received: from BYAPR01CA0012.prod.exchangelabs.com (2603:10b6:a02:80::25) by DM5PR0101MB2954.prod.exchangelabs.com (2603:10b6:4:2b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.8; Sun, 6 Jan 2019 00:00:29 +0000 Received: from CO1NAM03FT006.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::207) by BYAPR01CA0012.outlook.office365.com (2603:10b6:a02:80::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1495.6 via Frontend Transport; Sun, 6 Jan 2019 00:00:28 +0000 Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT006.mail.protection.outlook.com (10.152.80.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Sun, 6 Jan 2019 00:00:28 +0000 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0600Osm030491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 5 Jan 2019 19:00:26 -0500 Date: Sat, 5 Jan 2019 18:00:24 -0600 From: Benjamin Kaduk To: CC: , , , Stephen Kent Message-ID: <20190106000023.GD28515@kduck.kaduk.org> References: <154473564505.32043.14717744747073496646@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <154473564505.32043.14717744747073496646@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(39860400002)(136003)(396003)(346002)(2980300002)(199004)(189003)(446003)(11346002)(956004)(8936002)(75432002)(106466001)(46406003)(26826003)(8676002)(966005)(126002)(476003)(33656002)(4001150100001)(336012)(47776003)(426003)(55016002)(6916009)(97756001)(5660300001)(88552002)(2906002)(2351001)(6246003)(54906003)(76176011)(53416004)(106002)(316002)(786003)(36906005)(50466002)(7696005)(356004)(6306002)(9686003)(58126008)(16586007)(86362001)(23726003)(26005)(229853002)(486006)(246002)(478600001)(1076003)(104016004)(186003)(450100002)(6346003)(305945005)(4326008)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR0101MB2954; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT006; 1:jftVYN/kjNPnjm6Uzwun7UzP+QAubQrGvrKPRqaXbxS7Y9NOS8LvoI+NU1RcIZ+6ekF7AQfHlTZvgK5yI2PZpgbU2T46lrggmPWbUdiu2oAGKHet503g9/C4jsXZgGkY X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fc21df53-0f05-4525-54e0-08d67369f7d1 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:DM5PR0101MB2954; X-Microsoft-Exchange-Diagnostics: 1; DM5PR0101MB2954; 3:dLXmdn/iIQzG2gouaE7O5VjGht7iLPPQ8Dj7JOzQtqxa1KI3MTPLpBBpyvgj4w+BH++A2xmsuBE5FeY0vPsojFE0ZFcaztXtWFF8UtwWm/IcTDK9Jx5c5Jt2fqC8ori5rQEm9lLuv4M4aJAAwgcy5e47eFulk6dsVWKn8690jOK+FFFg/8WM/1kJLCFVUgrl93/CarEQMXKJJCWeKemggLXYEIuyoRh4WB2YzKCQFujYeuaBt8mxfRN/L2U8rF7Wd/sDxpIQZr4OERPHswGac5sMOU7TmAgz6tn7gYV23Alap4RhDajkrz5uT42j0NoZe3SS92Vi9tqiN1Y0bNS8m2L3Kmzku7HeaBmk7JlKWJwSWk3b0769izPLR5yB1QI7; 25:fyuOOTN50WnicO2KaDAgqMV0QdvAdVgdSsDsqoGY0QhPIJH70lWD5pmVJWj0dLKWIEPJEAT6Gs6jCD28cD+XIGu5++tcSXwz5oI96EWrq8jigirTNFmhVavrmpOBqp5M7+uqYN8pr0YWgYY7e99swUs+0/2J2sWhyEIcivzWkkYtRhg0tqgP82OesKbI/rCRfpmaVyQvR+1sKC1i42pOvxmi6NWWk8xUBNfbP5bg6m6MK4v6gCbpK6qvbiBTuuVnrTsG3shcig2GJVbhuFZuyxqkbArKjfj5EIco18WHEiYoEiJEr8Y3CR6K5depcMBRUYnx2SvIsxquDxLhp0pBxA== X-MS-TrafficTypeDiagnostic: DM5PR0101MB2954: X-Microsoft-Exchange-Diagnostics: 1; DM5PR0101MB2954; 31:0I1/cAz+kGP9guS60PQrJy82S4B1HXO936E6elGF0xY1EukJN7dN1Htm+qhFqURybDuhD3fMYZWjrVrWJ1cFUnuvOwwcyeIgVimITl6jHi7einCgSuxxQW6EmW71i8BGQXwer3HYppGpxFSET3p88VE8AiDFCkfY7mD0lwruY7BxQCpvn0yjQiymvA5c9cRZDgAMQKbqyvVZvckpS4QJWX3Qx1+hxfxYqyrS4qbIUWM=; 20:uqKbY5u+YLkmORtj7BwtpuJ7omVSPEbaxiRrZjGI/sWHZmaMbY8APY4hKGUh2QL7w2iuc+Nv8ljYBkE1fsy4u0El3PPwDjD7hNSPDbzbo7M6SAwvdgCrkNLYF4mQnt//Vb2ilM+IXHLR/0TYRIk9XU05bCgv5BGp1pzqD0btw+3hlmU2V9+3Ge7fbctXwN7XVxI0ncyB3lTPC+nwgjfCIJqrKwgs6Q/HTdmBDHr1IaQ/I3rFjtAybfsEjhNwqjc/L+AGnsCdvaMSo5Hl4jgCdAbBGlXNh0YWqeOKeXrMpBiaaWAfI2trwdTuokXkIeA3sGonNGwZtXbTD9WgubJHbi1QEPiAuumKpLlo/so5Lxk4d+Z34OVFO3DnWQqOvYgBs32FTJIxWD3k6bcwVRj01kbeRldidSi5frH6D2yYXK5hkusQglkSC7dzKaIZBBx/10cxsYke/GQ9eloUt5lIZxPideeOGhm0Td7mZBT7fs7ag8AcDCUb4zhdw0BiAInS X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(3002001)(10201501046)(93006095)(93004095)(3231475)(944501520)(52105112)(6041310)(201703131423095)(201702281528075)(201702281529075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DM5PR0101MB2954; BCL:0; PCL:0; RULEID:; SRVR:DM5PR0101MB2954; X-Microsoft-Exchange-Diagnostics: 1; DM5PR0101MB2954; 4:siqYK9m80RYC5XVGyziodtvV62PHY6axG42P6ikrq/4BqAdVJzpeYnzEnc+K/xELZbomTX8kgSQXXtpfIkoXz3JqNEvOeU0i2km2e9hY5Yq4hmytdoK+BPeEhOAGWEvZhdayzjEA22XyKc433qF4xK9JtzYQYPvWnykN8Gy696Xbm4sgdwv3edSyIpvv0WvGittTNxNcMkWPiG+D5jBgjyBJkbONlXYKQUZBKLUjarTtJ7GNqwcT13qbqyzTAc44bzfjelo64k3TjnOhh/FN1y8dVFQSnuaRNyeph4Wpq+0= X-Forefront-PRVS: 09090B6B69 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR0101MB2954; 23:pCjJXXp8ZQ0Gbs9Ov4b3QyYSi62WLbhgk3sjZja?= =?us-ascii?Q?pbaWAcWq2Baq4YqXSK9ti2r1/JgzAWeddr/7ollhfVC8mJh3zMtLUQm+uTjI?= =?us-ascii?Q?Lp7Z45NlGgvcZhmjCO7cHGQFWZzs8/z7BGZ6L6+n2zKiIxH+QmPrKyeKAQXB?= =?us-ascii?Q?P+RKc5509hkHCfkq9l4wumwGaUAr+Adw8uGecDMvqDtpvxP5vNqAPHOBDNBw?= =?us-ascii?Q?lCFOjK9qusSDWLtO8aZ5c7cMudzMKXCwsauwRWPXECpcZIdTadGc8/PKnc80?= =?us-ascii?Q?L7cGKzIJiRtXAixVPlz/J78WTemKd+TLl/OagDy5kFo2Vg4K8zLpDY5DNgKa?= =?us-ascii?Q?Cdfo28CDHx+SM6yO9YdSu7Nr8uFXEAAMqnmQLtMrtc03dfSzC9U0cqp3y3+b?= =?us-ascii?Q?RRrxiAqN2fHhXky9dGSMcclqxOqJKIvm6ZCM4pOSCNPji2nJLsWkfcM9dsvF?= =?us-ascii?Q?PsWiZ2Vqar7gZPyUzUM8j4hshMRC+JQr3oTN7YlgkNS7OR/NsfkCmqSPbMFb?= =?us-ascii?Q?rUDlLTAI/DhWTOUiBPHUsLSA71JjD7N0k1b/SVb8/1ThKxJWm7UCIeLQSX9n?= =?us-ascii?Q?k9AiaNUiRYECbwPiHbxqFYomqHjzPXUScq5fqW7z4XhJXRgaoP1zPxQKDJwZ?= =?us-ascii?Q?k0cEZtHgwM4bg+vNvdC8mXfs8oDrkuK8BHeyn/v/4Y/yXprDAZYuj2MVLzkk?= =?us-ascii?Q?FbXhBsfn8MBX7RlyEaPOY/4ahH+Xj/6ukTYHsnaAED1rey6Yip+x+N+dSVKa?= =?us-ascii?Q?PFUK3fIFQ1seYJM5RVhrj/SQ7nEAOmHtQ1oZJwmni3UslUj5H60bPonedzm3?= =?us-ascii?Q?8HRgIPVnS/zf5qEbnmCwRfO0MeNWTBzqRSDy97OpAwxgqHy0hcW0Tn7rc2tS?= =?us-ascii?Q?Pq05BNSpPQ2aBHREOF5ypHp0oJl4sBSPrq+zITzx3KcSjOWfHpsvzd27tgd2?= =?us-ascii?Q?EUZNFdpDtgfqU6tMGZkvkGqnk1F6iRMAxBLbYBdaVJtzb0MiT5b7/hvHvS+1?= =?us-ascii?Q?c3QfD7axFDzH5HDMVVbY5vKPa88J0ERi9uHgf+1XDXD5dSAozOCMmP1hi3Yy?= =?us-ascii?Q?P8SO1MMDl+ZWoVgWpNs2bQOfxQX84t1OgDJRoYOqwMmrFDEgHIrixuN4AJl1?= =?us-ascii?Q?PX0NsAVgrW4ZEkgx2uoXXLaVsof3OjO07lb/b/xyUNhN+8nKQQS1C0EOOvV8?= =?us-ascii?Q?tuJlVMcjmvvR+mrCG1i98a06Smwz8F6/pBnTPQNN+gGtFNHvkHzUBwXIa4Dd?= =?us-ascii?Q?Q8pLYQpPJbh0HFX9AVLVQPXVL9olY0bXjLCF+QFX2MPm47/Ak07O6XPNM7PZ?= =?us-ascii?Q?AVWierqUJsQbOpO2ZUWL05/vbGGeI/98J0chZK40d4Ct+7oCt17IlsZpX1jc?= =?us-ascii?Q?3l6M1zw=3D=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: R27jU9AdCW7p3GezokmynW/NTFOHUKEJ1+QIGFiGxmccmjB0jN6XmWQr6+MeS4YmmXBTGCxDqdTUyfyThQJvTXM3ZWbROX4xJy+/y4idntSfgIWsREi8lLEgd1Ewb9T34Gcr6Ugd0yCFiNfeL9C0J/T17o863IwPfEP/E4oOlE/Cp2GPcjzanHkYamMwfI5Ir/JiQZAT0DzFrT9rHqwfSy24Y8N2cEh3Q6HaOjz2IXe4HwVwMv7u9Ial/v9o7B26nOJoavlgdBEQrz1gSc1lw1kD4dh+Fp2o9BxGFv/Ocd4VKSNohHhU4YaNES1JUe9S X-Microsoft-Exchange-Diagnostics: 1; DM5PR0101MB2954; 6:ue2sohdhpqdiTUM7Ae7cb1GCFZ+wNsSupua74195ABDLZkUCIB6ZiBfPmGslNOjKnpv6xn9N5icalpIFoBYu07tQLrOE4ooa2NoNQ9Vvug/uZxY9HmkbU3gWxFj1VGJF0COpSuzKneoPFfhAPKv6VqBxNzFYaxV1j2lUl9mkJB3kjsz3VlgTqh/Z48IiXDUCHCH9AQOIv2DvOgnO8E4Heb5Yoy674peTHsMZWRO82ghs6tn9TDIFb55jU2i4DMFGpY/4Slv8896/9DocwrBUlSGmUXEqXwo2rBFNOwaA/COJU4XB1uz3zBC6Q6cc1NFSNFBT6sk/RyUCTLDIuHaLPMvCjwv+xGV6m3AVsuHpXRxu1TV4l69CA2j0EFbcxNM6v3r8OoYazzPIkXGPU/OW1R2jTtI21ITFwxZG+L7TKbk22Q2G5t6kyGkVWjCmsIWeRKKL5FpMJ2V7MxiWFb1pjQ==; 5:6QhKNpRQ+0doiyjZLIPqMjLOManTGE8GDSY0DVQvUokeRb5t3GZVm5cGmpPVUBkSWlj9HkAUSQaT4tE4QJuACYMrtfMmQoBvyYJNwvekCxKBcEOd/Keq9ugLMzgpAVkfd7mE8gX6zcs4AYatOfz/lDDDdVnXEj/UYDNPPu+S4xuJifVpA1yZFp8SnrvmF0xLkzpDdzsw0g7+hzqtuhAxdA==; 7:3y8En5UY7JfAn1iFBJTdopo0yZmnid6/vSEggab0XNe70w4UGB0G1iMXdHQ7EBHKFGMKjcGh/4M1KDCuAX+GtbiSeQNcaMFtGJMfCeuv5Ie+cCrjX6q2qoo3WOkxWB1zhKozN7TEU8MAGLAav0rbZQ== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2019 00:00:28.2356 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fc21df53-0f05-4525-54e0-08d67369f7d1 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0101MB2954 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-bess-evpn-vpls-seamless-integ-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2019 00:00:34 -0000 On Thu, Dec 13, 2018 at 01:14:05PM -0800, Stephen Kent wrote: > Reviewer: Stephen Kent > Review result: Has Nits > Note that the text of the review (as opposed to the draft being reviewed) is visible at https://datatracker.ietf.org/doc/review-ietf-bess-evpn-vpls-seamless-integ-05-secdir-lc-kent-2018-12-13/ -Ben From nobody Sat Jan 5 17:01:34 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360F0130ED9; Sat, 5 Jan 2019 17:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqdWx6ntjU9T; Sat, 5 Jan 2019 17:01:15 -0800 (PST) Received: from mail-it1-f173.google.com (mail-it1-f173.google.com [209.85.166.173]) (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 B59E3130ED4; Sat, 5 Jan 2019 17:01:15 -0800 (PST) Received: by mail-it1-f173.google.com with SMTP id i145so6433696ita.4; Sat, 05 Jan 2019 17:01:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YsAUkMcUOqZMdFK1YecIWKd8txpq7HeDgJYQou/tk8w=; b=H5wLMLouvSdcGk50sLTpAPV5IDGfg3IVuG4QT1XFnlgSnrjwwVXpmHck/m/ONVAmAL gPe3Bh3cZaC2qLTEJXO5EagUMeXUA7fwIFcxhKf8GwJg6QmsJEK7cBpPoeCgxduKJGqf 5o0ygtN4unjIHj0tKBbZw+KnR5G+Q73yUz6H+a3zEBlS+IWjIv3+PiRoqubYBzxu/EyD Ie5ZgXMd6tcxWXZbLZWNbSa/nMbRrZO9L/T1tTbMUn+VcmunX+JsIjmg5H8Eiqj8U/y+ cZ5tyLV7L7S2i4EBC62kAqxuVr3dEwTziD5RFjzwzBzBUAcMKwWbiKLsCEMuPoTAdJ+2 kncw== X-Gm-Message-State: AJcUukfEixiiYD26s/gdfuSRKgGE9T5N32/CrZ0lyTDiC9so4NdV0ukP ISkaQ0RtlWzYx8DPzo/LhXdSR+bvbpDxFXp+uX8= X-Google-Smtp-Source: ALg8bN6NVr0yZbxhykAk6YAFcOPSFUGFublIW5Uw0kTWcIYYD01tFEEzsARTpjLBqcZmPr9HLKpVeT7Cdwm6CpcOCd8= X-Received: by 2002:a24:a04:: with SMTP id 4mr4271565itw.122.1546736473687; Sat, 05 Jan 2019 17:01:13 -0800 (PST) MIME-Version: 1.0 References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <20190105185050.GB28515@kduck.kaduk.org> In-Reply-To: <20190105185050.GB28515@kduck.kaduk.org> From: Barry Leiba Date: Sun, 6 Jan 2019 09:01:02 +0800 Message-ID: To: Benjamin Kaduk Cc: IETF JMAP Mailing List , "Kurt Andersen (IETF)" , Tero Kivinen , draft-ietf-jmap-core.all@ietf.org, iesg@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="000000000000134dbe057ebfa6be" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2019 01:01:18 -0000 --000000000000134dbe057ebfa6be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Ben that when documentation has been lacking in the past we may need to fix that in current documents. The problem, I fear, is that we write much of this, especially at the app layer, to the wrong readers, so let=E2=80=99s think about the shared mailbox case, for example, and see if = we know what will actually help, rather than tick off some IETF-process-related box= . What we write in RFCs is primarily for software developers. It would be truly bad if security/privacy warnings dissuaded developers from supporting shared mailboxes: any mail system that lacks such support would be hobbled and bad. So the best we could try would be to get vendors to copy or paraphrase our warnings in their documents, and/or to show warnings when the features are configured at installation. I think it=E2=80=99s unlikely to happen. Simi= larly, when a user shares a mailbox a popup could show... also unlikely. And what are we going to say? That sharing a mailbox that contains personal mail can expose private information? That=E2=80=99s at the same t= ime so obvious as to be silly, and entirely irrelevant to the actual shared-mailbox use cases. I think the best approach is to give examples of common use cases for sharing. That might be informative and might actually prompt some vendors to include similar examples in their doc. Barry On Sun, Jan 6, 2019 at 2:51 AM Benjamin Kaduk wrote: > [I wrote this before I noticed that half the thread was stuck in my spam > quarantine. Some of the points were made already, but I've left my text > unchanged to avoid making it even less comprehensible that it was to star= t > with.] > > On Thu, Jan 03, 2019 at 09:21:12AM -0800, Kurt Andersen (IETF) wrote: > > On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen wrote: > > > > > Reviewer: Tero Kivinen > > > Review result: Has Issues > > > > > > This document also has quite a lot of privacy concerns which are not > > > addressed by it. For example email delivery and event notifications c= an > > > leak lots of information even to passive attackers. > > > > > > > How is this any different than the risks present in current mechanisms > > (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a new risk > being > > introduced by the JMAP protocol. > > But where is it documented for those other protocols? > > > Of course sharing mailboxes between multiple users (one of the > > > examples given in 1.6.2), has lots of privacy issues. > > > > > > > Again, this is not a new risk being introduced by JMAP. It seems unfair > to > > saddle the JMAP protocol with the responsibility of documenting a > > comprehensive set of privacy and security risks for bad or risky > behaviours > > that have been a wide part of common practice for decades. > > In general, we need to either document ourselves or point to existing > documentation of the security considerations relating to protocols we > publish. "Everybody already does [bad practice X]" does not excuse us fr= om > ensuring that the risks are adequately documented. Is it unfair? Perhap= s. > But the IETF consensus so far seems to be that we need to properly docume= nt > that which we cannot make secure, and if we're the first one to actually > document it properly, then we do incur the extra burden of doing things > right. > > -Benjamin > --000000000000134dbe057ebfa6be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Ben that when documentation has been la= cking in the past we may need to fix that in current documents.=C2=A0 The p= roblem, I fear, is that we write much of this, especially at the app layer,= to the wrong readers, so let=E2=80=99s think about the shared mailbox case= , for example, and see if we know what will actually help, rather than tick= off some IETF-process-related box.

=
What we write in RFCs is primarily for software developer= s.=C2=A0 It would be truly bad if security/privacy warnings dissuaded devel= opers from supporting shared mailboxes: any mail system that lacks such sup= port would be hobbled and bad.

So the best we could try would be to get vendors to copy or paraphra= se our warnings in their documents, and/or to show warnings when the featur= es are configured at installation.=C2=A0 I think it=E2=80=99s unlikely to h= appen.=C2=A0 Similarly, when a user shares a mailbox a popup could show... = also unlikely.

And what = are we going to say?=C2=A0 That sharing a mailbox that contains personal ma= il can expose private information?=C2=A0 That=E2=80=99s at the same time so= obvious as to be silly, and entirely irrelevant to the actual shared-mailb= ox use cases.

I think th= e best approach is to give examples of common use cases for sharing.=C2=A0 = That might be informative and might actually prompt some vendors to include= similar examples in their doc.

Barry

O= n Sun, Jan 6, 2019 at 2:51 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
[I wrote this before I noticed that half the thread was stuck in my spam quarantine.=C2=A0 Some of the points were made already, but I've left m= y text
unchanged to avoid making it even less comprehensible that it was to start<= br> with.]

On Thu, Jan 03, 2019 at 09:21:12AM -0800, Kurt Andersen (IETF) wrote:
> On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen <kivinen@iki.fi> wrote:
>
> > Reviewer: Tero Kivinen
> > Review result: Has Issues
> >
> > This document also has quite a lot of privacy concerns which are = not
> > addressed by it. For example email delivery and event notificatio= ns can
> > leak lots of information even to passive attackers.
> >
>
> How is this any different than the risks present in current mechanisms=
> (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a new ri= sk being
> introduced by the JMAP protocol.

But where is it documented for those other protocols?

> Of course sharing mailboxes between multiple users (one of the
> > examples given in 1.6.2), has lots of privacy issues.
> >
>
> Again, this is not a new risk being introduced by JMAP. It seems unfai= r to
> saddle the JMAP protocol with the responsibility of documenting a
> comprehensive set of privacy and security risks for bad or risky behav= iours
> that have been a wide part of common practice for decades.

In general, we need to either document ourselves or point to existing
documentation of the security considerations relating to protocols we
publish.=C2=A0 "Everybody already does [bad practice X]" does not= excuse us from
ensuring that the risks are adequately documented.=C2=A0 Is it unfair?=C2= =A0 Perhaps.
But the IETF consensus so far seems to be that we need to properly document=
that which we cannot make secure, and if we're the first one to actuall= y
document it properly, then we do incur the extra burden of doing things
right.

-Benjamin
--000000000000134dbe057ebfa6be-- From nobody Sun Jan 6 02:57:51 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E485E130E3F; Sun, 6 Jan 2019 02:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=VQ1Q7woz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sbeBd6uZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXbS6QQBsqb1; Sun, 6 Jan 2019 02:57:48 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C4E130DE9; Sun, 6 Jan 2019 02:57:47 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CFFEB219EB; Sun, 6 Jan 2019 05:57:46 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sun, 06 Jan 2019 05:57:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=V9Bz/qfjju61fPu2n254j5uAu ftijAlE1hA8rSWR1qw=; b=VQ1Q7wozh1lYxD+J8KZDfRmu0kPhs55IuX8AI7F3Q hGJ9O4NT0gyBjAkOlC2DAVQjCZIyGAo4dklQsW54sl2gmZtd7Z1h/VJO/03TJp/l g3JYNVmXuqUqNBFVR0fT+IXrB0DLaT2zO8uNHB4HqAc8+B7L1u0OpQzTQIqrZ+gM Cac2qQYArwEQzezCNYMDgItDJtbPMiBYRUodVMszEJlWcU7DiHSixZYysIoXu4nU T+x2rxg3iVobUbjhjE/pKUx3vdfAHp1LpnBAjL/BGNhVkLeBBTret1C5wt4GFGf2 KaF2b0sBw59T+rmKr+sPsZ99EYPzEsBomhTEwCrljXDAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=V9Bz/qfjju61fPu2n 254j5uAuftijAlE1hA8rSWR1qw=; b=sbeBd6uZVF3DgoYmdJ2iWQGSovin/axdo xijKMyD8g/cv4TA2HVpeYKTingN69P20FHxkzONdEgASeKROVyAAh6JtqUqEvBdu vRG0G6aB/7tuaA77/C8cki1xOWvveDh5vam7mFZGm46NZsNcNRh/lL6vEZ3SiqKM 0oQDKOUeOpk55cVsi2XdkUk/QYKeQJHZUtlbkdQoDDA3/Ka9JKZFt1aWzQSriQEg 2FOULZDbDFUJErZfF9mclbiOB9fDYqeRlEFbs0WMWRkSpVkGRvcRUfqqibnysKMz HSJPI7qY9jm0VLR07atXItrv+yNABhb/d089a6A5c+qG27zrszWng== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdehgddvfeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucffohhmrghinhephhhtthhprhgvqhhuvghsthhsrdihohhupdhgihhthhhusgdrtgho mhenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrg hmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 28A38203BE; Sun, 6 Jan 2019 05:57:46 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 56629417 Message-Id: <5c5a39bb-96e9-4a2f-bf20-4fdb1bbb6f6d@www.fastmail.com> In-Reply-To: <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> Date: Sun, 06 Jan 2019 05:57:43 -0500 From: "Bron Gondwana" To: secdir@ietf.org, "Tero Kivinen" , "Neil Jenkins" Cc: "IETF JMAP Mailing List" , draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=8c1e39e2af2d404592cdcc3be2a22ea6 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2019 10:57:50 -0000 --8c1e39e2af2d404592cdcc3be2a22ea6 Content-Type: text/plain On Sun, Jan 6, 2019, at 10:06, Neil Jenkins wrote: > On Sun, 6 Jan 2019, at 9:26 AM, Bron Gondwana wrote: >> And look at making the push protocol have a confirmation step: >> https://github.com/jmapio/jmap/issues/276 > > I'm not convinced this is necessary and/or helpful. In the current system, the first time a push is triggered the application (JMAP) server sends a request to the push server (the URL registered by the client); if this is not accepted with a reasonable HTTP response, it would automatically disable it. The danger is meant to be DOSing this URL (it's not really a push server); however with a confirmation step, you still need to do that first request so you're not reducing the number of HTTP requests. You are however relying on the push being received by the client in order for it to be able to complete registration, and all common push services do not guarantee delivery, so this becomes much less reliable. (With this in mind, the JMAP push system happily copes with dropped push packets while still guaranteeing full resynchronisation.) > > I note this issue doesn't really seem to be specific to JMAP, and yet RFC8030 (which is what the push system is implementing) does not require a confirmation step. Tero - are you satisfied with this response? The fact that RFC8030 didn't see the need to add a confirmation step suggests that not having a confirmation step in JMAP isn't wildly different from current practice or current IETF standards, and Neil's justification that it makes setup less reliable for common push services seems reasonable. If we need to beef up the language that the server MUST disable the push channel if the endpoint URL doesn't reply correctly, and maybe even a suggestion that the server rate limit individual authenticated users and similarly detect weird behaviour and limit it. It would be great to solve this with clear advice to server implementations on how to not become a DOS amplifier rather than hobble the protocol. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --8c1e39e2af2d404592cdcc3be2a22ea6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Sun, Jan 6, 2019, at 10:06, Neil Jenkins wrote:
On Sun, 6 J= an 2019, at 9:26 AM, Bron Gondwana wrote:
And look at making the push prot= ocol have a confirmation step:

I'm not convinced this = is necessary and/or helpful. In the current system, the first time a pus= h is triggered the application (JMAP) server sends a request to the push= server (the URL registered by the client); if this is not accepted with= a reasonable HTTP response, it would automatically disable it. The dang= er is meant to be DOSing this URL (it's not really a push server); howev= er with a confirmation step, you still need to do that first request so = you're not reducing the number of HTTP requests. You are however relying= on the push being received by the client in order for it to be able to = complete registration, and all common push services do not guarantee del= ivery, so this becomes much less reliable. (With this in mind, the JMAP = push system happily copes with dropped push packets while still guarante= eing full resynchronisation.)

I note this i= ssue doesn't really seem to be specific to JMAP, and yet RFC8030 (which = is what the push system is implementing) does not require a confirmation= step.

Tero - are you satisfied with this re= sponse?  The fact that RFC8030 didn't see the need to add a confirm= ation step suggests that not having a confirmation step in JMAP isn't wi= ldly different from current practice or current IETF standards, and Neil= 's justification that it makes setup less reliable for common push servi= ces seems reasonable.

If we need to beef up the language = that the server MUST disable the push channel if the endpoint URL doesn'= t reply correctly, and maybe even a suggestion that the server rate limi= t individual authenticated users and similarly detect weird behaviour an= d limit it.  It would be great to solve this with clear advice to s= erver implementations on how to not become a DOS amplifier rather than h= obble the protocol.

Cheers,

Bron.

<= /div>
--
  Bron Gondwana, CEO, FastMail Pty Ltd
=
  brong@fastmailteam.com


<= /div> --8c1e39e2af2d404592cdcc3be2a22ea6-- From nobody Sun Jan 6 08:10:40 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074CC126CB6 for ; Sun, 6 Jan 2019 08:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.355 X-Spam-Level: X-Spam-Status: No, score=-4.355 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=N6k4ZpBr; dkim=pass (1024-bit key) header.d=ericsson.com header.b=VNesi/Qi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6esMmhxIxN0 for ; Sun, 6 Jan 2019 08:10:30 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 24389127B4C for ; Sun, 6 Jan 2019 08:10:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1546791025; x=1549383025; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4zOOA/pR7jEkz6tvmzTd5VGyFJYRHq408lr9ATxA+N8=; b=N6k4ZpBr8NcIvKtgcqVwDLov2p3LVrUJmscPr0m8Y8Il/q3sLfnMInwMi1iTNo8R ow65jPrwPQNlcBqTf3z+j4H9I9knl7g4XOQlgDx1JtQ+daU1IfFdGmqb3x8NYeCW wEsJ2pKXV7DNU83We/bWd7X5A9gDgLgflazTMW6ZP+s=; X-AuditID: c1b4fb25-209009e000005ff7-0e-5c32287184f2 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 51.B1.24567.178223C5; Sun, 6 Jan 2019 17:10:25 +0100 (CET) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sun, 6 Jan 2019 17:10:13 +0100 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sun, 6 Jan 2019 17:10:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4zOOA/pR7jEkz6tvmzTd5VGyFJYRHq408lr9ATxA+N8=; b=VNesi/QierCXYKFlDKzS3JJZogEDFOEkZtSi5jzIJ9N1XiYlYM+XuEaz289/Bk+vUs6rXVVRyZ8uhzi5rDSkmCa069D1Pe3GpKNNTIlKyfOIoWwSTnXkt1cKzPi86QkSoRbaHG4aklqtuirrSHAkbauytpgSS0gYY/la76l9Gm0= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3273.eurprd07.prod.outlook.com (10.170.246.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.10; Sun, 6 Jan 2019 16:10:11 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::852a:3f04:e342:cf55]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::852a:3f04:e342:cf55%3]) with mapi id 15.20.1516.010; Sun, 6 Jan 2019 16:10:11 +0000 From: Christer Holmberg To: Ben Campbell , Benjamin Kaduk CC: "Scott G. Kelly" , "secdir@ietf.org" , "draft-ietf-sipcore-sip-push.all@ietf.org" , "iesg@ietf.org" Thread-Topic: [secdir] secdir review of draft-ietf-sipcore-sip-push-21 Thread-Index: AQHUoUFwpb8nIR8T3kKT3FjKoKE4faWfiegKgAF6kMCAABArgIAABAAAgAAHiQCAAT1LfA== Date: Sun, 6 Jan 2019 16:10:11 +0000 Message-ID: References: <1546285539.44113084@apps.rackspace.com> <1546631184.64914945@apps.rackspace.com> <215DF6BE-69A3-4394-9BE2-EE7751957E07@nostrum.com> <20190105182119.GA28515@kduck.kaduk.org> <20190105193346.GC28515@kduck.kaduk.org>, <8D02428A-AC2F-4D80-A108-CE55833CFAFE@nostrum.com> In-Reply-To: <8D02428A-AC2F-4D80-A108-CE55833CFAFE@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [37.33.31.219] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3273; 6:XTudyhe9EP6RwiIDsbfBrgpyfaIkLwDuU3h81Khs8xkWycN+BIxG+qUvlVMPF319pLaexKBtq+OzBiMbzvP0bMHpOL22X6blgSAWAVP18D0AiZD0u4iA+/FdR47dUt21IqwBpfm/EfNZRTfEBsf8IjodSzyG8It+Cc1hjpVl+6lNLuDMSL58lGaKkFh7TXDRfJconFb0ZEEHby5Q5DJS54oKkSOxQoJUzbsf+0OEADORQEJIVXC/z4XKTO9K3waBA08yCHnD7i196VmIoVEntfuGn41nKbRLhuPinIePzQSBXL5/wi2pBBBmX3MPjC54vfIAeD1L85G7L7Nye4o+F9vxScsfLNQMklveqiOSR65GFsqA1SkzSRoaxdVCtr+f0u/x63+ZgqmWUBwts8boeYsXflnr9lU4ueYI+/08USV2PskrasigJ3LR07Zp8xL4WNV5ld5WnlZSGSwbRxz6ag==; 5:2GSD5NQpwuzxNjw2fyM+vX6Wl2PkYi/MXUKLC6bjYW4MTIgCC74As98Yqw/wIgqWqnHn0s8iPK51PqcuBJ+i+KrM1Qqy0rCzg8w5Ifj1iQ3F8E6065u28Xywf+d4F6v8rS2xr2u44pfEg8gaf1ynWEb8jKMj39WhfYUde4BOHKWHrqELQzqANvi7Dd/KaEyBsn4diZdtcP2zxjXRUsIZaA==; 7:CZ0jOaiLWJ/szRUlS2DQMPppyWLT29LUR80NkgaxdvqQaIfRFuMtoQT8z2q1unlZMAjhZ3Fod/vxO2Sk0L6SM+li0BD/V0peh3nVr645cr3WmKIPcd2Ql/HlH3d6tjKeS+q+WnQ4+fYHt3j9WT4IWQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 47004fb4-5603-4c53-fefe-08d673f16f87 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3273; x-ms-traffictypediagnostic: HE1PR07MB3273: x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(10201501046)(3002001)(3231475)(944501520)(4982022)(52105112)(93006095)(93001095)(6041310)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB3273; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB3273; x-forefront-prvs: 09090B6B69 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(376002)(346002)(136003)(199004)(189003)(6436002)(76176011)(229853002)(6486002)(316002)(256004)(105586002)(66066001)(446003)(19627405001)(476003)(486006)(26005)(186003)(99286004)(102836004)(6506007)(6116002)(3846002)(106356001)(14444005)(6606003)(33656002)(68736007)(44832011)(11346002)(25786009)(81156014)(53946003)(81166006)(86362001)(2171002)(8676002)(71190400001)(71200400001)(54896002)(4326008)(8936002)(6512007)(9686003)(53936002)(7736002)(5660300001)(6246003)(93886005)(2906002)(110136005)(54906003)(478600001)(14454004)(97736004)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3273; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: wIDdGHCWq7KkhtEGr8ykrwOFE1rxqXwhn28ZLfkPOzyqERsTYSdqObhDwUT8X2d3Ujg3mMFa+TPfMP8zUJbp42l68pSRZB62DI/LKUfBYUU2YEFrbyExpsaiH/X6CU9SEyRUjDSNdEbPy+AmHt/mhmRU2YjUI80prT9o3w0xk6c/lGscBW9ZJbJIylFuBV9LJjS05VcJzAHgMYFvWnvUGvygSvtcgQEZ+ZZdbMVSJlIEYKckEm1N8AH/epriE7LwyghzhFLOvSUeFN+vvdXBNYQM+PugPaU6VxTx7Ym9vNnTPBDqWEH/g972CFwI3hyC spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB31674B4B0085EC2B6F4B385B93880VI1PR07MB3167eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 47004fb4-5603-4c53-fefe-08d673f16f87 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2019 16:10:11.3589 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3273 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHe885m8fR8HV5edBEGYqleI/Yhy4WKIsQIsIiB7n0oKJutmOW fQgxHKgpU+d0oi3NMswwy2sl0bzkzEspVoqQsqmEo1Q0E4fUdhb47ff8///3eZ/n5aVJ0SjP h85Q5DIqhTxLzBdQ+is9t8JuHImWRbYOhEsMxR9dJNZuE5LU2ipISUuHnpBsdWqQZK1xkYrl S3t7Rylpc/MOIS0cGyKldX0W6gJ1VXAilcnKyGNUEaeSBemajRUip7ifuF2xm1KA/tQSJciV BnwM9tq6qBIkoEV4EEHfjAlxxRYCi/UDyRWPCDBXTDsKCmtIaB60unBOJQE1Zr0ztoigxjjJ K0E0zccSKN0LtV/igc/CPV0Lz54h8QSCenUZshuHcByY36gpLhQPM+tLJMeJoJuecegUDoTF tQHHtEIsg36bkW9nEX5MwmiDwM6u+DQ06ZocZxH2gu3RNkeexN4wZzE4N8XQ/HaS5NgTfpj3 eFxeDu9aF5x6AGgLTHyO/WDKUOp4DMCFLlDQscLjjDBYq652HkiALrXOyZ8Q2Oo9OQ6BV+Pf nI0yYaRHz+cazZGwOj/kbHQYepfMfA2KqNs3LMdK2NlbpOocS7uDSW+hOD0Sfk0YSI5D4Unj qpMjoGNzHO3XHyKXVuTJMuz17LTomHBGlZHCskpFuILJfYn+/bD3nbtBvWjaesaIMI3EB4Xn faNlIp48j83PNiKgSbGHMGspSiYSpsrz7zAq5TXVzSyGNSJfmhJ7C20id5kIp8lzmUyGyWFU /12CdvUpQJdWS0O1r+8u+5sOlEu1w7ZWP8PTIl3IcnfRxaRgt4lkt+Awj/ovC3xx9dfZgLTf YyP5lFtQYIL1Wbuxymv55OUHz+fZkM8/X0DM7PfNiUpPU3x66v1ztbFxVRb/jamZ9W2tuqTP FIvU7eU5wXVlRzurjYnigSS5bHiaON7QohRTbLo8KoRUsfK/A+NR6l0DAAA= Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2019 16:10:32 -0000 --_000_VI1PR07MB31674B4B0085EC2B6F4B385B93880VI1PR07MB3167eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, For some reasons all replies were not delivered to me yesterday, but I hope= I am now replying to the latest one. =85 >>>>> That all being said, I would be happy to see something to the effect = of the following >>>>> in this draft: =93The security considerations for the use and operati= on of any particular >>>>> PNS is out of scope for this document. [RFC8030] documents the securi= ty considerations >>>>> for HTTP Push. Security considerations for other PNSs are left to the= ir respective specifications.=94 >>>> >>>> That seems like a pretty nice way to say it. As indicated yesterday, I would be happy to add such text. >>>>> Would that be sufficient to resolve your concern above? >>>> >>>> I think I would still like to see some indication of the potential >>>> consequences for the mechanism defined in this document, if a PNS does= not >>>> (properly) perform authentication and authorization between UA/proxy a= nd >>>> PNS. >>> >>> (Having not yet read the whole spec I don't have a great picture of >>> exactly what those consequences are.) >> >> That=92s reasonable, and I think fits into the category of consequences = to the SIP network >> due to the interface. >> >> Thinking out loud: One thing that comes to mind would be the insertion o= f false push >> notifications by an unauthorized 3rd party. It seems like the 3rd party = would have to >> learn the necessary parameters, which might be difficult. How guessable = these parameters >> might be would have an impact. >> >> If someone succeeded in this, I imagine it mostly as a DoS attack on han= dset battery life. It >> could possibly be a DoS on the registrar. >> >> From a privacy perspective, an eavesdropper might be able to infer somet= hing about the number >> of incoming calls to a handset. Hopefully there=92s not much in the way = of PSI in the push request >> or notification themselves. What about something like the following: OLD: "Operators MUST ensure that the SIP signalling is properly secured, e.g., using encryption, from malicious middlemen. TLS MUST be used, unless the operators know that the signalling is secured using some other mechanism. [RFC8292] defines a mechanism which allows a proxy to identity itself to a PNS, by signing a JWT sent to the PNS using a key pair. The public key serves as an identifier of the proxy, and can be used by devices to restrict push notifications to the proxy associated with the key." NEW: "The security considerations for the use and operation of any particular PNS is out of scope for this document. [RFC8030] documents the security considerations for the PNS defined in that specification. Security cons= iderations for other PNSs are left to their respective specifications. Operators MUST ensure that the SIP signalling is properly secured, e.g., using encryption, from malicious middlemen. TLS MUST be used, unless the operators know that the signalling is secured using some other mechanism that provides strong crypto properties. Unless the PNS authenticates and authorizes the PNS, malicious users tha= t managed to get access to the parameters transported in the SIP signalling might = be able to request push notifications towards a UA. Which such push notifications w= ill not have any security related impacts, they will impact the battery life of = the UA and trigger unnecessary SIP traffic. [RFC8292] defines a mechanism which allows a proxy to identity itself to a PNS, by signing a JWT sent to the PNS using a key pair. The public key serves as an identifier of the proxy, and can be used by devices to restrict push notifications to the proxy associated with the key." Regards, Christer --_000_VI1PR07MB31674B4B0085EC2B6F4B385B93880VI1PR07MB3167eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi,


For some reasons all replies wer= e not delivered to me yesterday, but I hope I am now replying to the latest= one.


=85

 

>>>>> That all being said, I would be happy to see something to the effect of th= e following 
>>>>> in this draft: =93The security considerations for the use and operation of= any particular 
>>>>> PNS is out of scope for this document. [RFC8030] documents the security co= nsiderations 
>>>>> for HTTP Push. Security considerations for other PNSs are left to their re= spective specifications.=94
>>>> 
>>>> That seems like a pretty nice way to say it.

As indicated yesterday, I would be happy to add su= ch text.

>>>>> Would that be sufficient to resolve your concern above?
>>>> 
&= gt;>>> I think I would still like to see some indication of the potential
&= gt;>>> consequences for the mechanism defined in this document, if a PNS does not
&= gt;>>> (properly) perform authentication and authorization between UA/proxy and
&= gt;>>> PNS.
>>>
>>> (Having not yet read the whole spec I don't have a great picture of
>>> exactly what those consequences are.)
>>
>= > That=92s reasonable, and I think fits into the category of consequen= ces to the SIP network 
>> due to the interface.
>>
>> Thinking out loud: One thing that comes to mind would be the insertion of = false push 
>> notifications by an unauthorized 3rd party. It seems like the 3rd party wo= uld have to 
>> learn the necessary parameters, which might be difficult. How guessable th= ese parameters 
>> might be would have an impact.
>>
>> If someone succeeded in this, I imagine it mostly as a DoS attack on hands= et battery life. It 
>> could possibly be a DoS on the registrar.
>>
>= > From a privacy perspective, an eavesdropper might be able to infer = something about the number 
>> of incoming calls to a handset. Hopefully there=92s not much in the way of= PSI in the push request 
>> or notification themselves.

What about something like the following:

OLD:

   "Operators MUST ensure that the SIP signalling is pr= operly secured,
   e.g., using encryption, from malicious middlemen.  TLS MU= ST be used,
   unless the operators know that the signalling is secured using= some
   other mechanism.

   [RFC8292] defines a mechanism which allows a proxy to identity= itself
   to a PNS, by signing a JWT sent to the PNS using a key pair.&n= bsp; The
   public key serves as an identifier of the proxy, and can be us= ed by
   devices to restrict push notifications to the proxy associated= with
   the key."

NEW:

  "The security considerations for the use and operation of any p= articular 
    PNS is out of scope for this document. [RFC8030] documents th= e security 
    considerations for the PNS defined in that specification. Sec= urity considerations 
    for other PNSs are left to their respective specifications.

   Operators MUST ensure that the SIP signalling is properly secu= red,
   e.g., using encryption, from malicious middlemen.  TLS MU= ST be used,
   unless the operators know that the signalling is secured using= some
   other mechanism that provides strong crypto properties.

   Unless the PNS authenticates and authorizes the PNS, malicious= users that managed
   to get access to the parameters transported in the SIP signall= ing might be able to
   request push notifications towards a UA. Which such push notif= ications will not
   have any security related impacts, they will impact the batter= y life of the UA and trigger
   unnecessary SIP traffic.

   [RFC8292] defines a mechanism which allows a proxy to identity= itself
   to a PNS, by signing a JWT sent to the PNS using a key pair.&n= bsp; The
   public key serves as an identifier of the proxy, and can be us= ed by
   devices to restrict push notifications to the proxy associated= with
   the key."

Regards,

Christer

--_000_VI1PR07MB31674B4B0085EC2B6F4B385B93880VI1PR07MB3167eurp_-- From nobody Sun Jan 6 10:05:30 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842581200B3; Sun, 6 Jan 2019 10:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fz5KfcjGkGxO; Sun, 6 Jan 2019 10:05:27 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750099.outbound.protection.outlook.com [40.107.75.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9A8127B4C; Sun, 6 Jan 2019 10:05:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oK2zvbCKSWr/6y6OtKXUybAmqNtGp3pXbcc5QPwenuQ=; b=rewQJ14r9QdjCSOVghQ2fVguBO90gKyWcmgNMMs+m4+IFhdey8McuunwU/yTRlErYTRM9hrBvGUIiARoidCV4AmCzxasaXCLTSM60qJCU70Z5DGdPoSzSXqb86nSxuDiyPCWmgtYoOiqUc7FKNlzz2NOquL4u9mKnv2FHDWFwcw= Received: from DM5PR0102CA0006.prod.exchangelabs.com (2603:10b6:4:9c::19) by DM6PR01MB4025.prod.exchangelabs.com (2603:10b6:5:2e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.6; Sun, 6 Jan 2019 18:05:19 +0000 Received: from CO1NAM03FT023.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::202) by DM5PR0102CA0006.outlook.office365.com (2603:10b6:4:9c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1495.6 via Frontend Transport; Sun, 6 Jan 2019 18:05:19 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT023.mail.protection.outlook.com (10.152.80.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Sun, 6 Jan 2019 18:05:19 +0000 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x06I5FjY023682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 6 Jan 2019 13:05:17 -0500 Date: Sun, 6 Jan 2019 12:05:15 -0600 From: Benjamin Kaduk To: Christer Holmberg CC: Ben Campbell , "Scott G. Kelly" , "secdir@ietf.org" , "draft-ietf-sipcore-sip-push.all@ietf.org" , "iesg@ietf.org" Message-ID: <20190106180514.GM28515@kduck.kaduk.org> References: <1546285539.44113084@apps.rackspace.com> <1546631184.64914945@apps.rackspace.com> <215DF6BE-69A3-4394-9BE2-EE7751957E07@nostrum.com> <20190105182119.GA28515@kduck.kaduk.org> <20190105193346.GC28515@kduck.kaduk.org> <8D02428A-AC2F-4D80-A108-CE55833CFAFE@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(376002)(39860400002)(346002)(136003)(2980300002)(199004)(189003)(786003)(26826003)(14444005)(50466002)(58126008)(54906003)(229853002)(26005)(86362001)(47776003)(316002)(5660300001)(36906005)(486006)(8676002)(9686003)(8936002)(93886005)(336012)(106466001)(53416004)(2906002)(106002)(33656002)(478600001)(186003)(476003)(6916009)(1076003)(305945005)(6246003)(246002)(76176011)(356004)(88552002)(11346002)(2870700001)(426003)(956004)(104016004)(446003)(55016002)(75432002)(4326008)(2486003)(23676004)(126002)(7696005)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR01MB4025; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT023; 1:kZ5ZpKEukuvaBXBYVpvxD1zgTZKz213/JAp4Ma2vdovSfIJv90yUq7x2C1rEYKWmFHeh+k+CAiM28xk6Ltpqgz9olpTDvhtKoNnfKGn8raUYYH1mYyd2xx0tNTLwQ6/E X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5ea75551-e944-4934-b345-08d67401850a X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4608076)(4709027)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060); SRVR:DM6PR01MB4025; X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4025; 3:cRv9gOQfrT6HKj11N3cEnO0vc7oBq1RMTHuj+epdN8AWkMyhhsF+kQWOtlbvPbfis3yiwTjzP9k3gIhHBO5Sg2m0dXHtJwG+aoHF2r9zkiu47yqY0SCx2u+WyHF7C7Fb8sS6Qm9azMaj6h6gVH/SDiXnkse8XyHqjnvh1giiY+xspQ/+xw7DPwI5udr+EqXoNNhCMEu2+FlxydWep/CX/h4dwj9M/Wfz7LainR0+471rqinredxj/xi6CafnPGp1MW4cbzSw0rXO4qwv0CxOBSUAygycmPWkNANS6cbtuA42fXrTlZ8tVPbFPM8Vytx3TAHyqP1DJLFLyTUZhhwzsfqVlGp+zFIRf744mDAMUuVAiz650mj7kJeoygMwerv2; 25:k3PFETf2bNtbp8h9N6uGAOXFraWMP4n37K1s3ScBagsB7qLUbUgCktaVS+qXTWnNystsBmA2m0YhCT0xaCmJUuVtht68ki99MtpqcROXLAl6V7xBEsaLCT2zIbK4H1JiwMWaza0gtKfcz6eDgtQps53wV8QlfkGncGYZIPsJzyubNxbnSlDjmrzdfYkXRh4fn2xl9lnTJeMz6IlANE0z/MZdJjCaGFfGwahKhN14RaCAaBk6ZcB8ywShgqCHyGKa25ikVqKYqAyu5Z+0LfyftpvepAdpBviAoExwGHPW2TR0nOrgay35dxeyEiDJSzVav7CqJkPzQYuGbJCyvP+KzA== X-MS-TrafficTypeDiagnostic: DM6PR01MB4025: X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4025; 31:0fwopJpJP/th+c6Xs+4x6zrv3+EwaBvrs2T+2Pr0EGKdvPsZDcUwCiR6EHZWowwYaHNHFSbNPsYRd7UFd+KqxD8jEuI2CkwusDZQnd77pi/5Ko3s9FIALfd2wGrAI9thETQa3WpLFbYDLQFQMFpdx1cP7j9s1UZpOM4N/I6uf3fSBIRR2E4wTx+xLlfVfzYsDWKd/eH+91OWWgtJ/veXLtXgjSi0OZ4q3zDbg1gsTks=; 20:1PZ3JNNbMT8dBfVwXb1DwUivGgaC5/utRlGwyrLnSgpjnE4eaQJxdLkKaywbZR/1enLqWViB2zToFyJ7J87wZxwqXExNmtySWKp+4C7w2DeJ8xscYnPIlzDRBRc27U7zM+GASksHnmT9J0e2UVvEFNgSrogAoK567OEz3sWGXjKD57YOKo0BpaF50+r0M89MXmIqH5U6MzUKrmEvOLDoTU2ZrPkT8tUtDfSjrbhjxP2veJS+4T/BjVU1bEYxPZcVKF6UGeRsWHUsHIiaNk1peZGCXjNq+LHOk1H15cB80SfWbi+NeNpMhlLFH0KgGSm6Gm2uB/LCMpRAKsn4/pOUCvO0PEzL3+TaWZRJ9jt/PUTKy2fKnjzNi3PrjGJTyzS8gMgrSlyXQ44BhwpyjBT10piKESI0qB6qA0yz3SnrNwXE4xMLtR1xbT6HH150dwdXqmFtz6u8RcxrMBd7gUc7pRHgFLRsOoChQ8Bhhl2GJYHp4Dy81a1ykbpxVwv7xgHw X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(93006095)(93004095)(3231475)(944501520)(4982022)(52105112)(3002001)(10201501046)(6041310)(20161123558120)(201703131423095)(201702281528075)(201702281529075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DM6PR01MB4025; BCL:0; PCL:0; RULEID:; SRVR:DM6PR01MB4025; X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4025; 4:nLl4Bd8gjfgQ3PuxhMZftbIZknVx96RbWSHBVRytawCH9oVQ03r1KuUmQHyuoTimjoFGdBaXnLdMiNlOfd/8kmrxaXfW+HnQq+0hNluWPZ8hMuYdMWgB8Gy2swzj2otgqsFOhMq/eGDAdaLQMrminBCLmPF068xoq77vh+b0mS/5cYlCU7fcNhQwAD+w0VKt3eS9fvOwD1zRZ/Nth7JjKPYBx2zTj5aD6meeMZzV/SkMRXIm/T5ey4K/kYe51pAZXOi3SfBFbUus9HvbK53LW3dR1sOHkRd9Q9kQ8foX+40+eeOGoKikTxuo4rBlp6/U X-Forefront-PRVS: 09090B6B69 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTZQUjAxTUI0MDI1OzIzOkZJR1BRaENQTkdTMzFyc3NXZXZyR0w2UjRk?= =?utf-8?B?aEp6S0hLZkFLa3dZR2lVNktDRW9VS1l5SE80WTh5N1RiSXZsYmU5VnBsZEMy?= =?utf-8?B?WGlsTDNoeDhYcmZsS2NWdTUzTWlEdUZqajh5QmFNMGFkSmJlS09NSVZGQ0dQ?= =?utf-8?B?c0Z2WFptWjBLM0lhM1FLTTVZOFl0YTE1SS9VWk8zSlJoRk1TaGxUS2FSbXJY?= =?utf-8?B?Rnl6RjlTU0dqYnBHRlJLYndhKzI5dWtYY2REZEh6eFdNaDM5SzNwSXppS25E?= =?utf-8?B?RTA5d1BJamUvdmtvSlBFcTd3VUh1OEtpNzVGZzZiUm9ESUVER0ZWYm1yb3NT?= =?utf-8?B?NXQwMFBNdGMzWFdsa2JxYkMrZjhvTFV5dFVjVEZXQjFGbnNkK2hpczhpQ2I2?= =?utf-8?B?N0VmbGFLUzh1SlFVSVhrWjZIRDlsQ0JlM04reS92ZnBVZ1g2a28wdlV1SXZo?= =?utf-8?B?ZjRGVHg3dnh5TlNEd2xkNjZxSE14MG5aZmgrWGpnV2cxMURpWklkV3lZWG9h?= =?utf-8?B?WHZ3Y2VPYVZYeldzNDJiQmxRUDI4bEZkSGxCaytxY1hlT1hnUlpDZEFIcm1G?= =?utf-8?B?UktpejdyemhFY0VyTHNsbGtpTXJ4UlBVNXNxb1RjQzY4SFpxU201NTM0SnYy?= =?utf-8?B?dGp6QmlvamdyZ3doVEFLNS9jVTVKSjQ4WlFLbk9DZVFEL0pMUGYxamhkVFFi?= =?utf-8?B?SW5LTjBidWFiUnM2bWxCQjJMS1pzNkQrV0ZRSkt1TjJkNFd4d01sdnFvREFQ?= =?utf-8?B?bjNqNWZaS0dsNHZka1BkNEFuSFJhdzYxdVllS0krdXg4V2YvbnQ1K2hXQWdZ?= =?utf-8?B?TGZhOVpSb1Z3a01RUWl6SmdxU1pFR1FwS3Zpbi80ZTljaVcrZnh0TW9lQVlN?= =?utf-8?B?YktBNmJWQ0tqYXlET1ZRV2RqNmwxOGlxM0NLWWZndVE2Mjl5eWpvL0VkVHgr?= =?utf-8?B?SXNtL1BMZ3ZqZFQ3cjQzY05tSUZJOVNObjl2THlUNzVVZXhhLzVPS1lEN2Nh?= =?utf-8?B?MTl4U3JqOWV6Vk1JVFhsK2VHT2J3M3ZzTDJLQ25wZGlpU0NrT1B1Qm0yVk1m?= =?utf-8?B?TS9KbXM5U2lUMEpLUHJZcnY1eDRrSEFXUlVCdGtUd29IcDJKdnlWbHpjb0FL?= =?utf-8?B?WndKSkxOT0J3enlubUJ4YWc5ZmhoYkN4NE0vNGVOM2VnbUVsY3RoemV6bFV0?= =?utf-8?B?a0dUa2NZd3RwNTM4OUEraFE5MnJvOGZjMFhabUt4bXFlelVsbzNuK0R2ajRF?= =?utf-8?B?TnNtSVd2QWxjNjQ2L0Z3Q2tYYTBYeVV4aWNZZG9BS3phTHpaaklOODdoS0xw?= =?utf-8?B?bnBrOUIxWGVMa0VUeCtCWmd4b2VNMHlJa2dHUUZmN0lnTUFOQkdqWmxENnQ5?= =?utf-8?B?SHhzZmh4NkJRbFEvUDk0MjdIMjMxazBMOTY1STMvRVU3eDEyWXJRM3B6NnQ2?= =?utf-8?B?SkViWHBEd1hjWGkrOGJ1aWx2WDZMZk1sYUVZeXdaKzNxRFNRTTZKNkRRc2Fi?= =?utf-8?B?c0NIMVpQREJQdFlFMjArb3Rpb0R4N2E1YmQrZVlRNzVjSkl5QzdFbHhoa3Y5?= =?utf-8?B?SWF2OTRyNHU5K25wNzJ0a1hMeHMzRGxTY3A2T2Y3aXh2bk1NZTZCb2xiditm?= =?utf-8?B?MmFiNUZYY1N0eWlsTDdyVmd5WnU0c0lWdldQRFBENnNrMDRrNGVoUGcvN2Ex?= =?utf-8?Q?6BdZXQsGcxe45cO2Cc=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: tQsKDrpjszGs/fdFN/XFlWhDu9d78iIlzScGhuY3JYVTMVWy0hGOfdLjHo+miaSgK2XloIUM/3hjzBtXXcnfLFyYvbrkJZSNke9uCIogtsJAFYEnL8BZ+FPPCdSjSZByEWKfzArVl9Z+Myq/eNHbZo+puP+2Z38UMDRrSgqe7jVbJ2hHGILowvAKt820+OWRG5DHC725gLWDwZMzJswYrsicGGY4EzCQ2mGSVRRIQIQbGVdkXquvRTch/ew7227yC3HeswGFCOYlU7S/1qjB5vpFcg5Lff7hX8lwSl+dsSuBT4YJ0wRy72xtdc7+zK9a X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4025; 6:+vCEVpquKjo2xy01nWbByhFMDf5iyxRtRetqysHLtpgkOiNcrVmydpfvgkGi6b+LjQuWwVYRDA0EPJt0Cla5ni5WssvqP95Bs1CHpkLWP7ue4iMYRRXS/5dYWXZYaS2RLBTJpMhloup4DxvTprwKaezK5MCz+STSRnMYfCNu7eLVO5acRWQO19W+2psAlQP+LcLXLf1gyJE8RH7wAdLR/4R791lEiZJblabaD2DGoeKlAwwIkpZe9fsTp9otlXRKazqdXEi/B+E36/fSaB8EoDp/2D70T5q1iZfCuEJatPdvr/kreqi4PpEj2dXDChnWys6aI0KQdz4TZqn0wdTwtU+3P1UeSlcf+x9aXKcDx0a6QeQmT/BKJNC8twRsDwli39HjJzJSkIOQZE9lfqeHq4nhh5vaoBQGO18zITSySG1E9LNkMt3G1szLvqOtnEhqkC/Hw8ceYpAqQBVtA3Wq/Q==; 5:vikZ4KoKsxj7P5J2cGErGwWXIt6gMUtbqmj7rBWxpe+69jTQoYGHrKntpdSlpn9Qo5SXEEBeSkeG5QUEdkr+VSAmyaxM+nJIJWOcjLOY9288M01lK/JyGoJlSk1cH/WNwM74ZTxylT+mSRZLLKeOYIGJj6MmRl2xFp0p1xJitxI9uFT4njG5sucaWD2kKeEi6BQqAwxzaanijY39BP4v6Q==; 7:cBbKVmFZ6H2w1dPqQ+WUP1fuEWXi4H4wbfAdm3zBglz3YU6+K7ptz0NfKz/0LRn9RAFS6z0U29DBjtai0h4mFzlvK41wHsQdcH95MVjFSFNYDFJEGucGdgkeJyI3VFSAyoml3gzxhMf5M8EKeKlDEA== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2019 18:05:19.1301 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5ea75551-e944-4934-b345-08d67401850a X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR01MB4025 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2019 18:05:29 -0000 On Sun, Jan 06, 2019 at 04:10:11PM +0000, Christer Holmberg wrote: > Hi, > > > For some reasons all replies were not delivered to me yesterday, but I hope I am now replying to the latest one. > > > … > > > > >>>>> That all being said, I would be happy to see something to the effect of the following > >>>>> in this draft: “The security considerations for the use and operation of any particular > >>>>> PNS is out of scope for this document. [RFC8030] documents the security considerations > >>>>> for HTTP Push. Security considerations for other PNSs are left to their respective specifications.” > >>>> > >>>> That seems like a pretty nice way to say it. > > As indicated yesterday, I would be happy to add such text. > > >>>>> Would that be sufficient to resolve your concern above? > >>>> > >>>> I think I would still like to see some indication of the potential > >>>> consequences for the mechanism defined in this document, if a PNS does not > >>>> (properly) perform authentication and authorization between UA/proxy and > >>>> PNS. > >>> > >>> (Having not yet read the whole spec I don't have a great picture of > >>> exactly what those consequences are.) > >> > >> That’s reasonable, and I think fits into the category of consequences to the SIP network > >> due to the interface. > >> > >> Thinking out loud: One thing that comes to mind would be the insertion of false push > >> notifications by an unauthorized 3rd party. It seems like the 3rd party would have to > >> learn the necessary parameters, which might be difficult. How guessable these parameters > >> might be would have an impact. > >> > >> If someone succeeded in this, I imagine it mostly as a DoS attack on handset battery life. It > >> could possibly be a DoS on the registrar. > >> > >> From a privacy perspective, an eavesdropper might be able to infer something about the number > >> of incoming calls to a handset. Hopefully there’s not much in the way of PSI in the push request > >> or notification themselves. > > What about something like the following: The general trend is looking good. I'll probably have some wordsmithing suggestions for "TLS MUST be used, unless [...]" in my ballot but don't have a great suggestion right now. -Benjamin > OLD: > > "Operators MUST ensure that the SIP signalling is properly secured, > e.g., using encryption, from malicious middlemen. TLS MUST be used, > unless the operators know that the signalling is secured using some > other mechanism. > > [RFC8292] defines a mechanism which allows a proxy to identity itself > to a PNS, by signing a JWT sent to the PNS using a key pair. The > public key serves as an identifier of the proxy, and can be used by > devices to restrict push notifications to the proxy associated with > the key." > > NEW: > > "The security considerations for the use and operation of any particular > PNS is out of scope for this document. [RFC8030] documents the security > considerations for the PNS defined in that specification. Security considerations > for other PNSs are left to their respective specifications. > > Operators MUST ensure that the SIP signalling is properly secured, > e.g., using encryption, from malicious middlemen. TLS MUST be used, > unless the operators know that the signalling is secured using some > other mechanism that provides strong crypto properties. > > Unless the PNS authenticates and authorizes the PNS, malicious users that managed > to get access to the parameters transported in the SIP signalling might be able to > request push notifications towards a UA. Which such push notifications will not > have any security related impacts, they will impact the battery life of the UA and trigger > unnecessary SIP traffic. > > [RFC8292] defines a mechanism which allows a proxy to identity itself > to a PNS, by signing a JWT sent to the PNS using a key pair. The > public key serves as an identifier of the proxy, and can be used by > devices to restrict push notifications to the proxy associated with > the key." > > Regards, > > Christer > From nobody Sun Jan 6 13:00:06 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A235C130E3D for ; Sun, 6 Jan 2019 13:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.364 X-Spam-Level: X-Spam-Status: No, score=-4.364 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=IomMZSj+; dkim=pass (1024-bit key) header.d=ericsson.com header.b=EsjaXUcH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNpqFP9ijSXj for ; Sun, 6 Jan 2019 13:00:03 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 89CDF130DBE for ; Sun, 6 Jan 2019 13:00:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1546808400; x=1549400400; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uxqcacGE/FKRYGEv4DwPeGT50OhJWPpMrzrc6V7nnec=; b=IomMZSj+T7jPfwC0w6+h7UT+0BFBi46kb0KYBoPsOny7kNVUnl/sdML8kjbKguo5 Ekv/Q8mx3aAkjFKW1fMkLACOA3jY5LV2ndXs7iSCm4kiLdoC1W8UZhqhA+068kO+ vhEBqGuadPFg/0ZV5KIis1YL3jBAgyYk61XP1pR30co=; X-AuditID: c1b4fb30-fabff7000000355c-ef-5c326c506828 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 69.0B.13660.05C623C5; Sun, 6 Jan 2019 22:00:00 +0100 (CET) Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sun, 6 Jan 2019 22:00:00 +0100 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sun, 6 Jan 2019 22:00:00 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uxqcacGE/FKRYGEv4DwPeGT50OhJWPpMrzrc6V7nnec=; b=EsjaXUcHq2dCrSk5bmWA4AuLPBZiUfMVAejHuap71tpSHEiiDsmsqG5HL4a9QfCpnKRzlgdgiAp0P762dtv6icEuYbw70fgVqtwcVpbYTvtdswYj6R6cuZt0plr3L0Mi58qniA4EkX62QU05CR1mE6HRJfRzwSnCo9VhDdjXKVw= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3130.eurprd07.prod.outlook.com (10.170.245.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.9; Sun, 6 Jan 2019 20:59:58 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::852a:3f04:e342:cf55]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::852a:3f04:e342:cf55%3]) with mapi id 15.20.1516.010; Sun, 6 Jan 2019 20:59:58 +0000 From: Christer Holmberg To: Benjamin Kaduk CC: Ben Campbell , "Scott G. Kelly" , "secdir@ietf.org" , "draft-ietf-sipcore-sip-push.all@ietf.org" , "iesg@ietf.org" Thread-Topic: [secdir] secdir review of draft-ietf-sipcore-sip-push-21 Thread-Index: AQHUoUFwpb8nIR8T3kKT3FjKoKE4faWfiegKgAF6kMCAABArgIAABAAAgAAHiQCAAT1LfIAANMWAgAAwVcc= Date: Sun, 6 Jan 2019 20:59:57 +0000 Message-ID: References: <1546285539.44113084@apps.rackspace.com> <1546631184.64914945@apps.rackspace.com> <215DF6BE-69A3-4394-9BE2-EE7751957E07@nostrum.com> <20190105182119.GA28515@kduck.kaduk.org> <20190105193346.GC28515@kduck.kaduk.org> <8D02428A-AC2F-4D80-A108-CE55833CFAFE@nostrum.com> , <20190106180514.GM28515@kduck.kaduk.org> In-Reply-To: <20190106180514.GM28515@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.33.31.219] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3130; 6:xgvKH5/sJk23vmNIkDeFnPvsUJoQjE31185Oi8jxHdEulAq1N8LBb3DAp6OwIk65NC5Z9DqyV5rAy+4LXDHHOcizaA7F0xOPFtLd8JNqZfm1pRT6eDrLI/tO3O4oHAOx+RDq1/8ItedEBYwguiaCCmnLscuehm6/zXXLmkmqiqifbawuyE7JGtwdn+7pkO3xxqI6rh7Tmf1PfDjiYoo4ZJh+t4d6W1v58nEAJcBXZijn6i46SYnLg6kSJ5vHJQx525PLkSqq8NwOlr8NRjPPJ5jhEqqXpU1QsM2iA9etqNiTSZECTR8HYRSRQALHV/j+QY9XCBqqT4937fpF6EtAh+1JJlR3OTfV/oHy9tRVHuC0nWEfTZFNRjoba09KdpmRZjyVdns/5O1QBPQJPMVzmVbo9f68wYnPySDOCuPtuVA9FQi7fbPKAcQpxY8G4pUd5z+tXf74OCfA1ID7J8cQSw==; 5:lDJcyBKiM4/YtzjgfbzDtxCOxE+GHg3JIH7UAcGnZgwdSExaN/l+FmGsqn0IlkX+H7nRv2i8534vexzOtmdjK17y21j6i85/wrL1CdgKOcm9Q0trH5PL5Y19ih/IXvNiypNJuBlTagwqV4/CBX/z2E2Y8B2vhf05lh5t7PzJIt34ENsDU0zozk3fqHSwJszv+d7fitGJFsPDcRO0xveibQ==; 7:MVaWPGkEouszfvAbkR0k3JVenQUGtg2teMN8eOOFxWNT96LlnBhNqrNRds3Kws+oPfnt+vz/TJJuq96XEYSF1lxf/zgZMBHLxCusPx9u5AX4PkHgeytKBaHPRSQDcseG0sXMA05908QeEtMAZ5gmog== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 9a059e3c-63e8-4d18-4d9e-08d67419eac1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3130; x-ms-traffictypediagnostic: HE1PR07MB3130: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(93006095)(93001095)(10201501046)(3231475)(944501520)(4982022)(52105112)(3002001)(6041310)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB3130; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB3130; x-forefront-prvs: 09090B6B69 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(366004)(39860400002)(346002)(396003)(199004)(189003)(19627405001)(68736007)(54906003)(105586002)(106356001)(66066001)(6916009)(1015004)(71190400001)(71200400001)(229853002)(236005)(9686003)(54896002)(6306002)(6606003)(2906002)(14444005)(8936002)(6116002)(256004)(3846002)(7736002)(8676002)(74316002)(14454004)(81156014)(81166006)(966005)(5660300001)(93886005)(606006)(6436002)(2171002)(53936002)(33656002)(55016002)(4326008)(6246003)(478600001)(76176011)(6506007)(53546011)(86362001)(99286004)(7696005)(102836004)(476003)(11346002)(446003)(25786009)(26005)(44832011)(186003)(97736004)(316002)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3130; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: larT4k0bCwnFmWj/++4Nm7uznvTQWNr+rF3zsXq2CKC2aDnEHufg9//TjWMDZ2U6CCRM4pQVItEHhTVczzbZxcvwQrTVcKC1RkicGQhU1TKmMRIgy5C0LQP7MneJ3GGIhy+mCQPnhOjkZnJ5SzugNGQYBWJCkhjGojch9ESccNl9PsQknZBT9s7msNyDClzNIVCfSkBBvERFCEqJFFH/ZoXrI3Nu9KgWScSLBwxdvZdCCCIkXkOvASjcJaJgtxbBEXgJAUlMlw1H+XaSsGuATh8WBLPJLaeD5bDDSkQMi88jwTHDYF4d2Jk6FW62tkoC spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB316172AB7FA4157AADC0310093880HE1PR07MB3161eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9a059e3c-63e8-4d18-4d9e-08d67419eac1 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2019 20:59:57.9594 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3130 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHee69u7tag+vUPPkSMQJh4ttSGCKWmLE+CJZREsuaeVFxTts1 SS2YokX6Rc1RLmIul5YEqZiaFerSQqcz01CM8G0qopJiYpZZzmeB337n/M//vDw8DCnuF3gz 6ZocTqtRqSW0K1Wd2MYHxqtlypAe3RG58Z5VKF9u7UPyh9sVpLy+qZqQb7SUI/mqaZo6SSva 2/sphdm8RSiKBnpJheG1nYqnLrlGpnDq9FxOGxx11TXN0j9MZVen36ybNAl0qOpiKXJhgA2D lfsGohS5MmK2B4HNaqdxsIFgTD8qxEEtAUNbO7TDQrHlJIzUnMVCBQGDjfUCHEwj6DKZdqsY hmblULYT4DB4sBKoHSzea0uyqwiafrwXOgR3NhZm39yhcNFp+LI2R2JOhg7rjHPaMViZ6hY4 WMQqobLD8n8lCj4u6fYMLmw4/FlY3mPEHoLN/heEg0nWCybsRgJfyoL57RCJ2RMWZ3cEmI9C la6PxuwHn41lyDEA2CIhLHTanUIgrOr1TnMcvNPbhLjoE4KBGRvCghTM31oQ3kIFnQ1TTkMG NLdt0tgwQULtsNXZ1Rfa52bpchRs2Lct5iwoNr9Chr2z3aCv2k7hfAh8txlJzAFQZ1pycvDu sw6i/fkaJGxAnjzHJ2emymRBnDb9Gs9naYI0XE4z2v1h3S2/Q9rR4kK0BbEMkhwUqVUypVig yuXzMi0IGFLiIVLPhSrFohRVXj6nzbqivaHmeAvyYSiJl2hb7KYUs6mqHC6D47I57X+VYFy8 dSjCuDD+aC3yuI/mSVfR/HyJYjOG8i8sjH7GmE6MybqKQyvrowtm1j80Xoi7lXi+7fDLB/zz yz0xfvm0LVoj7Srx/TrpkpQVe53IjvJMGF+/GxKVMEKWHYgsmD1322p5GvZ3w1DY2uu/nGQs PDMSMfrLlqH/aUt0l4brAwoeS9xOSSg+TRUqJbW86h/TsbWWXQMAAA== Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2019 21:00:06 -0000 --_000_HE1PR07MB316172AB7FA4157AADC0310093880HE1PR07MB3161eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Based on the sec-dir comments, I have updated the pull request: https://github.com/cdh4u/draft-sip-push/pull/31/files I modified my suggested changes to the security considerations, in order to= make everything fit with the existing text. Ben, I think it would be useful to submit a new version of the draft before= the IESG review. Regards, Christer ________________________________ From: Benjamin Kaduk Sent: Sunday, January 6, 2019 8:05 PM To: Christer Holmberg Cc: Ben Campbell; Scott G. Kelly; secdir@ietf.org; draft-ietf-sipcore-sip-p= ush.all@ietf.org; iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-21 On Sun, Jan 06, 2019 at 04:10:11PM +0000, Christer Holmberg wrote: > Hi, > > > For some reasons all replies were not delivered to me yesterday, but I ho= pe I am now replying to the latest one. > > > =85 > > > > >>>>> That all being said, I would be happy to see something to the effec= t of the following > >>>>> in this draft: =93The security considerations for the use and opera= tion of any particular > >>>>> PNS is out of scope for this document. [RFC8030] documents the secu= rity considerations > >>>>> for HTTP Push. Security considerations for other PNSs are left to t= heir respective specifications.=94 > >>>> > >>>> That seems like a pretty nice way to say it. > > As indicated yesterday, I would be happy to add such text. > > >>>>> Would that be sufficient to resolve your concern above? > >>>> > >>>> I think I would still like to see some indication of the potential > >>>> consequences for the mechanism defined in this document, if a PNS do= es not > >>>> (properly) perform authentication and authorization between UA/proxy= and > >>>> PNS. > >>> > >>> (Having not yet read the whole spec I don't have a great picture of > >>> exactly what those consequences are.) > >> > >> That=92s reasonable, and I think fits into the category of consequence= s to the SIP network > >> due to the interface. > >> > >> Thinking out loud: One thing that comes to mind would be the insertion= of false push > >> notifications by an unauthorized 3rd party. It seems like the 3rd part= y would have to > >> learn the necessary parameters, which might be difficult. How guessabl= e these parameters > >> might be would have an impact. > >> > >> If someone succeeded in this, I imagine it mostly as a DoS attack on h= andset battery life. It > >> could possibly be a DoS on the registrar. > >> > >> From a privacy perspective, an eavesdropper might be able to infer som= ething about the number > >> of incoming calls to a handset. Hopefully there=92s not much in the wa= y of PSI in the push request > >> or notification themselves. > > What about something like the following: The general trend is looking good. I'll probably have some wordsmithing suggestions for "TLS MUST be used, unless [...]" in my ballot but don't have a great suggestion right now. -Benjamin > OLD: > > "Operators MUST ensure that the SIP signalling is properly secured, > e.g., using encryption, from malicious middlemen. TLS MUST be used, > unless the operators know that the signalling is secured using some > other mechanism. > > [RFC8292] defines a mechanism which allows a proxy to identity itself > to a PNS, by signing a JWT sent to the PNS using a key pair. The > public key serves as an identifier of the proxy, and can be used by > devices to restrict push notifications to the proxy associated with > the key." > > NEW: > > "The security considerations for the use and operation of any particula= r > PNS is out of scope for this document. [RFC8030] documents the securi= ty > considerations for the PNS defined in that specification. Security co= nsiderations > for other PNSs are left to their respective specifications. > > Operators MUST ensure that the SIP signalling is properly secured, > e.g., using encryption, from malicious middlemen. TLS MUST be used, > unless the operators know that the signalling is secured using some > other mechanism that provides strong crypto properties. > > Unless the PNS authenticates and authorizes the PNS, malicious users t= hat managed > to get access to the parameters transported in the SIP signalling migh= t be able to > request push notifications towards a UA. Which such push notifications= will not > have any security related impacts, they will impact the battery life o= f the UA and trigger > unnecessary SIP traffic. > > [RFC8292] defines a mechanism which allows a proxy to identity itself > to a PNS, by signing a JWT sent to the PNS using a key pair. The > public key serves as an identifier of the proxy, and can be used by > devices to restrict push notifications to the proxy associated with > the key." > > Regards, > > Christer > --_000_HE1PR07MB316172AB7FA4157AADC0310093880HE1PR07MB3161eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi,


Based on the sec-dir comments, I = have updated the pull request:


https://github.com/cdh4u/draft-sip-push/pull/31/file= s


I modified my suggested changes t= o the security considerations, in order to make everything fit with the exi= sting text.


Ben, I think it would be useful t= o submit a new version of the draft before the IESG review.


Regards,


Christer



From: Benjamin Kaduk <ka= duk@mit.edu>
Sent: Sunday, January 6, 2019 8:05 PM
To: Christer Holmberg
Cc: Ben Campbell; Scott G. Kelly; secdir@ietf.org; draft-ietf-sipcor= e-sip-push.all@ietf.org; iesg@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-2= 1
 
On Sun, Jan 06, 2019 at 04:10:11PM +0000, Chri= ster Holmberg wrote:
> Hi,
>
>
> For some reasons all replies were not delivered to me yesterday, but I= hope I am now replying to the latest one.
>
>
> =85
>
>
>
> >>>>> That all being said, I would be happy to see some= thing to the effect of the following
> >>>>> in this draft: =93The security considerations for= the use and operation of any particular
> >>>>> PNS is out of scope for this document. [RFC8030] = documents the security considerations
> >>>>> for HTTP Push. Security considerations for other = PNSs are left to their respective specifications.=94
> >>>>
> >>>> That seems like a pretty nice way to say it.
>
> As indicated yesterday, I would be happy to add such text.
>
> >>>>> Would that be sufficient to resolve your concern = above?
> >>>>
> >>>> I think I would still like to see some indication of = the potential
> >>>> consequences for the mechanism defined in this docume= nt, if a PNS does not
> >>>> (properly) perform authentication and authorization b= etween UA/proxy and
> >>>> PNS.
> >>>
> >>> (Having not yet read the whole spec I don't have a great = picture of
> >>> exactly what those consequences are.)
> >>
> >> That=92s reasonable, and I think fits into the category of co= nsequences to the SIP network
> >> due to the interface.
> >>
> >> Thinking out loud: One thing that comes to mind would be the = insertion of false push
> >> notifications by an unauthorized 3rd party. It seems like the= 3rd party would have to
> >> learn the necessary parameters, which might be difficult. How= guessable these parameters
> >> might be would have an impact.
> >>
> >> If someone succeeded in this, I imagine it mostly as a DoS at= tack on handset battery life. It
> >> could possibly be a DoS on the registrar.
> >>
> >> From a privacy perspective, an eavesdropper might be able to = infer something about the number
> >> of incoming calls to a handset. Hopefully there=92s not much = in the way of PSI in the push request
> >> or notification themselves.
>
> What about something like the following:

The general trend is looking good.  I'll probably have some wordsmithi= ng
suggestions for "TLS MUST be used, unless [...]" in my ballot but= don't
have a great suggestion right now.

-Benjamin

> OLD:
>
>    "Operators MUST ensure that the SIP signalling = is properly secured,
>    e.g., using encryption, from malicious middlemen.&nb= sp; TLS MUST be used,
>    unless the operators know that the signalling is sec= ured using some
>    other mechanism.
>
>    [RFC8292] defines a mechanism which allows a proxy t= o identity itself
>    to a PNS, by signing a JWT sent to the PNS using a k= ey pair.  The
>    public key serves as an identifier of the proxy, and= can be used by
>    devices to restrict push notifications to the proxy = associated with
>    the key."
>
> NEW:
>
>   "The security considerations for the use and operatio= n of any particular
>     PNS is out of scope for this document. [RFC803= 0] documents the security
>     considerations for the PNS defined in that spe= cification. Security considerations
>     for other PNSs are left to their respective sp= ecifications.
>
>    Operators MUST ensure that the SIP signalling is pro= perly secured,
>    e.g., using encryption, from malicious middlemen.&nb= sp; TLS MUST be used,
>    unless the operators know that the signalling is sec= ured using some
>    other mechanism that provides strong crypto properti= es.
>
>    Unless the PNS authenticates and authorizes the PNS,= malicious users that managed
>    to get access to the parameters transported in the S= IP signalling might be able to
>    request push notifications towards a UA. Which such = push notifications will not
>    have any security related impacts, they will impact = the battery life of the UA and trigger
>    unnecessary SIP traffic.
>
>    [RFC8292] defines a mechanism which allows a proxy t= o identity itself
>    to a PNS, by signing a JWT sent to the PNS using a k= ey pair.  The
>    public key serves as an identifier of the proxy, and= can be used by
>    devices to restrict push notifications to the proxy = associated with
>    the key."
>
> Regards,
>
> Christer
>
--_000_HE1PR07MB316172AB7FA4157AADC0310093880HE1PR07MB3161eurp_-- From nobody Sun Jan 6 22:27:25 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F71130DE5; Sun, 6 Jan 2019 22:27:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema To: Cc: v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-transition-ipv4aas.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154684244329.17044.2866311660755291596@ietfa.amsl.com> Date: Sun, 06 Jan 2019 22:27:23 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 06:27:23 -0000 Reviewer: Christian Huitema Review result: Ready I already reviewed the version 11 of this draft. From a security point of view, the main change between the two versions is the addition of a paragraph acknowledging the potential risks of relying on DHCP for configuration. To quote: "As described in [RFC8026] and [RFC8026] Security Consideration sections, there are generic DHCP security issues, which in the case of this document means that malicious nodes may alter the priority of the transition mechanisms." Well, on the one hand, this does directly address the point I raised in the previous review. On the other hand, it is a bit sad to have a dry acknowledgement like that, without any hint at mitigations. If I was writing an April's fool RFC, I would qualify that as one of those security sections that seem written primarily for appeasing the security reviewer. But then, do we want to give some advice to implementers? For example, do we want to tell them that it is OK to deploy compliant devices in a basic home network? Probably. In the branch office of a financial institution? Most probably not. Do we have a way to convey that in simple terms? I would add something like: "As stated in the introduction, this document addresses deployment of IPv4 as a service in a residential or small-office network. Deployment in more challenging environments would require additional security analysis." From nobody Sun Jan 6 23:15:05 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84AE12D4E9; Sun, 6 Jan 2019 23:14:58 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0d2Slk1T81cK; Sun, 6 Jan 2019 23:14:57 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25125126BED; Sun, 6 Jan 2019 23:14:57 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 43Y68v0Wh4z5x3J; Mon, 7 Jan 2019 08:14:55 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 43Y68t6rdtzBrLp; Mon, 7 Jan 2019 08:14:54 +0100 (CET) Received: from OPEXCAUBM8F.corporate.adroot.infra.ftgroup (10.114.13.107) by OPEXCLILM6C.corporate.adroot.infra.ftgroup (10.114.31.21) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 7 Jan 2019 08:14:54 +0100 Received: from OPEXCAUBM41.corporate.adroot.infra.ftgroup ([fe80::857d:4f67:b0a7:10d7]) by OPEXCAUBM8F.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0415.000; Mon, 7 Jan 2019 08:14:54 +0100 From: To: Chris Lonvick , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-dime-doic-rate-control.all@ietf.org" Thread-Topic: =?iso-8859-1?Q?Re=A0:_SECDIR_review_of_draft-ietf-dime-doic-rate-control-?= =?iso-8859-1?Q?10?= Thread-Index: AQHUplivKBJnJye7aEK+diresqNzCg== Date: Mon, 7 Jan 2019 07:14:53 +0000 Message-ID: <23140_1546845295_5C32FC6E_23140_49_1_-sp22evww0mewcrd8ntm8lo0u-uy3uqt-oucx4m-4svon1n9pr-t6bz1y5xht88-fwnmsf-g2k503-u5f9nq-g8dq2qp2he5b4uxf3d-v4errb-utlf18ewruasbyvwxk-wmn70o33ydtr-ylrf933poh3x.1546845289253@email.android.com> References: <5C30BFB2.2080004@gmail.com> In-Reply-To: <5C30BFB2.2080004@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_sp22evww0mewcrd8ntm8lo0uuy3uqtoucx4m4svon1n9prt6bz1y5xh_" MIME-Version: 1.0 Archived-At: Subject: [secdir] =?iso-8859-1?q?Re=A0=3A_SECDIR_review_of_draft-ietf-dim?= =?iso-8859-1?q?e-doic-rate-control-10?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 07:14:59 -0000 --_000_sp22evww0mewcrd8ntm8lo0uuy3uqtoucx4m4svon1n9prt6bz1y5xh_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you for the review and the feedback. Regards, Lionel -------- Message original -------- Objet : SECDIR review of draft-ietf-dime-doic-rate-control-10 De : Chris Lonvick =C0 : secdir@ietf.org,iesg@ietf.org,draft-ietf-dime-doic-rate-control.all@i= etf.org Cc : Hi, I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments. The summary of the review is Ready. The specification proposes new AV Pairs for the Diameter Overload specifica= tion found in RFC 7683. The Security Considerations section of this Interne= t Draft is brief and only points to the security considerations of RFC 7683= . The Security Considerations section of RFC 7683 is thorough and I believe= that this is sufficient. I briefly reviewed the ID and found no nits. Best regards, Chris ___________________________________________________________________________= ______________________________________________ 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. --_000_sp22evww0mewcrd8ntm8lo0uuy3uqtoucx4m4svon1n9prt6bz1y5xh_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you for the review and the feedback.

Regards,

Lionel


-------- Message original --------
Objet : SECDIR review of draft-ietf-dime-doic-rate-control-10
De : Chris Lonvick
=C0 : secdir@ietf.org,iesg@ietf.org,draft-ietf-dime-doic-rate-control.= all@ietf.org
Cc :

Hi,

I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any other last call comments.

The summary of the review is Ready.

The specification proposes new AV Pairs for the Diameter Overload specifica= tion found in RFC 7683. The Security Considerations section of this Interne= t Draft is brief and only points to the security considerations of RFC 7683= . The Security Considerations section of RFC 7683 is thorough and I believe that this is sufficient.

I briefly reviewed the ID and found no nits.

Best regards,
Chris
______________________________________________________________________=
___________________________________________________

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.
--_000_sp22evww0mewcrd8ntm8lo0uuy3uqtoucx4m4svon1n9prt6bz1y5xh_-- From nobody Mon Jan 7 02:16:54 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412AE130DE7; Mon, 7 Jan 2019 02:16:40 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXQsd49MkI5g; Mon, 7 Jan 2019 02:16:37 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FE8130DE3; Mon, 7 Jan 2019 02:16:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1546856194; x=1547460994; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=bfAIMBKwhh4VLBVSyNDelIAJmfwQeZEScWgL0/CJg7A=; b=XK4/K+BTPwe2e NzCqOTB2qWptbMZ86iEu9DgWsk6gxArUhDsUG0GPkvHa2i9HyzhvyfAYq/ta4tQe vt2nKsDrMGU4ClqTpyiD5L8JDUXzRxSlZVcRoBPuSPzLAuUqtbBxwOhLe2+vvmCF 5boCSgAC/cOQTAz2Eq5YJsr1ephjAw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 07 Jan 2019 11:16:34 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 07 Jan 2019 11:16:34 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006100193.msg; Mon, 07 Jan 2019 11:16:33 +0100 X-MDRemoteIP: 2001:470:1f09:495:b467:f4bf:e908:d5fd X-MDHelo: [10.10.10.140] X-MDArrival-Date: Mon, 07 Jan 2019 11:16:33 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=19105d24b1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Mon, 07 Jan 2019 11:16:32 +0100 From: JORDI PALET MARTINEZ To: Christian Huitema , CC: , Message-ID: Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> In-Reply-To: <154684244329.17044.2866311660755291596@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 10:16:40 -0000 Hi Christian, Thanks for your review. There is a typo there, wrong copy and paste. It should be RFC8415 and RFC80= 26, as we discussed after your review. My point, as discussed in the previous email exchange, is that this is a ge= neric issue of DHCP. DHCP is used by both residential and non-residential s= ervice provisioning, and I don't see how we can solve that problem unless w= e implement some new DHCP "extension" that apply end-to-end encryption betw= een, in this case, the CEs and the servers. I can have a security section with basically replicates the text available = in RFC8415 Security Section, including considerations of using IEEE-802.1X,= DHCP snooping/guard/access control mechanisms, use of TR-069 access contro= l mechanisms, etc. I'm also happy to add your suggested paragraph regarding additional securit= y analysis in more challenging environments. Or maybe the correction of the RFC8415 references is sufficient in your opi= nion or you will prefer some additional text to summarize the RFC8415 secur= ity considerations/mitigations? I'm going to wait a couple of days, in case there are further inputs, befor= e uploading a new version correcting the mistake and also take in considera= tions the suggestions from the Gen-ART review a couple of days ago. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Christian Huitema Fecha: lunes, 7 de enero de 2019, 7:28 Para: CC: , , Asunto: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4a= as-12 Reviewer: Christian Huitema Review result: Ready =20 I already reviewed the version 11 of this draft. From a security point = of view, the main change between the two versions is the addition of a paragraph acknowledging the potential risks of relying on DHCP for configuration.= To quote: "As described in [RFC8026] and [RFC8026] Security Consideration sections, there are generic DHCP security issues, which in the case of = this document means that malicious nodes may alter the priority of the trans= ition mechanisms." =20 Well, on the one hand, this does directly address the point I raised in= the previous review. On the other hand, it is a bit sad to have a dry acknowledgement like that, without any hint at mitigations. If I was wr= iting an April's fool RFC, I would qualify that as one of those security section= s that seem written primarily for appeasing the security reviewer. But then, d= o we want to give some advice to implementers? For example, do we want to te= ll them that it is OK to deploy compliant devices in a basic home network? Prob= ably. In the branch office of a financial institution? Most probably not. Do we = have a way to convey that in simple terms? I would add something like: =20 "As stated in the introduction, this document addresses deployment of I= Pv4 as a service in a residential or small-office network. Deployment in more challenging environments would require additional security analysis." =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Jan 7 02:38:43 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C41F12D4F1; Mon, 7 Jan 2019 02:38:42 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmaDl5Uh37VH; Mon, 7 Jan 2019 02:38:40 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BA8129AA0; Mon, 7 Jan 2019 02:38:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1546857515; x=1547462315; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=qdf+atTfShMJ7kXOJy+MpCTDAZ2kI1uh++fEGfcc9mw=; b=GG0Y2SAufIeSD cPYFGchc5iZu4gtuCMQnnddy1zJqFEVn+840yp2k5uFxqvBF/z+pCIL4+HsGNiJN 7WZKDCu80fdMItBO1jcntXGIfQUiTMah9s4GEVFRGjgoLIe5c4Ns8WisUq0pc3Ot 5ns/xsJGMWNu5YZ1w2ZmWdnaw1xBMk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 07 Jan 2019 11:38:35 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 07 Jan 2019 11:38:35 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006100209.msg; Mon, 07 Jan 2019 11:38:33 +0100 X-MDRemoteIP: 2001:470:1f09:495:b467:f4bf:e908:d5fd X-MDHelo: [10.10.10.140] X-MDArrival-Date: Mon, 07 Jan 2019 11:38:33 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=19105d24b1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Mon, 07 Jan 2019 11:38:33 +0100 From: JORDI PALET MARTINEZ To: Christian Huitema , CC: , Message-ID: <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 10:38:42 -0000 Hi Christian, I've drafted this at the moment. Let me know if you think now this is bette= r and if you think anything else is needed. 8. Security Considerations The IPv6 Transition CE Router must comply with the Security Considerations as stated in [RFC7084], as well as those stated by each transition mechanism implemented by the IPv6 Transition CE Router. As described in [RFC8026] and [RFC8415] Security Consideration sections, there are generic DHCP security issues, which in the case of this document means that malicious nodes may alter the priority of the transition mechanisms. Considering that, networks using DHCPv6, depending on their specific topologies, should consider using authentication mechanisms such as those based on IEEE-802.1X or access control mechanisms such as DHCP snooping, DHCP guard, or TR-069, among other possible choices. As stated in the introduction, this document addresses deployment of IPv4aaS in residential, SOHO and SME networks. Deployment in more challenging environments would require additional security analysis. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: ietf en nombre de JORDI PALET MARTINEZ Fecha: lunes, 7 de enero de 2019, 11:17 Para: Christian Huitema , CC: , Asunto: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-i= pv4aas-12 Hi Christian, =20 Thanks for your review. =20 There is a typo there, wrong copy and paste. It should be RFC8415 and R= FC8026, as we discussed after your review. =20 My point, as discussed in the previous email exchange, is that this is = a generic issue of DHCP. DHCP is used by both residential and non-residenti= al service provisioning, and I don't see how we can solve that problem unle= ss we implement some new DHCP "extension" that apply end-to-end encryption = between, in this case, the CEs and the servers. =20 I can have a security section with basically replicates the text availa= ble in RFC8415 Security Section, including considerations of using IEEE-802= .1X, DHCP snooping/guard/access control mechanisms, use of TR-069 access co= ntrol mechanisms, etc. =20 I'm also happy to add your suggested paragraph regarding additional sec= urity analysis in more challenging environments. =20 Or maybe the correction of the RFC8415 references is sufficient in your= opinion or you will prefer some additional text to summarize the RFC8415 s= ecurity considerations/mitigations? =20 I'm going to wait a couple of days, in case there are further inputs, b= efore uploading a new version correcting the mistake and also take in consi= derations the suggestions from the Gen-ART review a couple of days ago. =20 Regards, Jordi =20 =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Christian Huitema Fecha: lunes, 7 de enero de 2019, 7:28 Para: CC: , , Asunto: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-i= pv4aas-12 =20 Reviewer: Christian Huitema Review result: Ready =20 I already reviewed the version 11 of this draft. From a security po= int of view, the main change between the two versions is the addition of a parag= raph acknowledging the potential risks of relying on DHCP for configurat= ion. To quote: "As described in [RFC8026] and [RFC8026] Security Considerat= ion sections, there are generic DHCP security issues, which in the case= of this document means that malicious nodes may alter the priority of the t= ransition mechanisms." =20 Well, on the one hand, this does directly address the point I raise= d in the previous review. On the other hand, it is a bit sad to have a dry acknowledgement like that, without any hint at mitigations. If I wa= s writing an April's fool RFC, I would qualify that as one of those security sec= tions that seem written primarily for appeasing the security reviewer. But the= n, do we want to give some advice to implementers? For example, do we want t= o tell them that it is OK to deploy compliant devices in a basic home network? = Probably. In the branch office of a financial institution? Most probably not. Do= we have a way to convey that in simple terms? I would add something like: =20 "As stated in the introduction, this document addresses deployment = of IPv4 as a service in a residential or small-office network. Deployment in mor= e challenging environments would require additional security analysis= ." =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited and will be = considered a criminal offense. If you are not the intended recipient be awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Jan 7 04:25:06 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45823130E97; Mon, 7 Jan 2019 04:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RBHtaXQKxKP; Mon, 7 Jan 2019 04:25:02 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 47057130E0A; Mon, 7 Jan 2019 04:25:02 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:38462) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1ggTxd-000fRl-05 (Exim 4.91) (return-path ); Mon, 07 Jan 2019 12:24:53 +0000 Date: Mon, 7 Jan 2019 12:24:52 +0000 From: Tony Finch To: Ned Freed cc: "Kurt Andersen (IETF)" , IETF JMAP Mailing List , draft-ietf-jmap-core.all@ietf.org, Tero Kivinen , secdir@ietf.org In-Reply-To: <01R1M7QIBP9I00004R@mauve.mrochek.com> Message-ID: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [secdir] [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 12:25:04 -0000 Ned Freed wrote: > > AFAICT it's different in the sense that this is the first push email > notification mechanism we have standardized. What about RFC 2177 IMAP IDLE? Tony. -- f.anthony.n.finch http://dotat.at/ Southeast Iceland: Northwesterly 7 to severe gale 9, decreasing 5 or 6, becoming variable 4 later. Rough or very rough, becoming moderate later in west. Showers at first. Poor, becoming good. From nobody Mon Jan 7 05:18:14 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9614E130E90; Mon, 7 Jan 2019 05:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpdoSxIE68DB; Mon, 7 Jan 2019 05:18:01 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 37CAB130E46; Mon, 7 Jan 2019 05:18:01 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x07DHpjx010998 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Jan 2019 15:17:51 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x07DHp4c022960; Mon, 7 Jan 2019 15:17:51 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23603.20862.976183.378013@fireball.acr.fi> Date: Mon, 7 Jan 2019 15:17:50 +0200 From: Tero Kivinen To: "Neil Jenkins" Cc: secdir@ietf.org, "Bron Gondwana" , "IETF JMAP Mailing List" , draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org In-Reply-To: <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 89 min X-Total-Time: 25 min Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 13:18:05 -0000 Neil Jenkins writes: > On Sun, 6 Jan 2019, at 9:26 AM, Bron Gondwana wrote: > > And look at making the push protocol have a confirmation step: > https://github.com/jmapio/jmap/issues/276 > > I'm not convinced this is necessary and/or helpful. In the current system, the > first time a push is triggered the application (JMAP) server sends a request to > the push server (the URL registered by the client); if this is not accepted > with a reasonable HTTP response, it would automatically disable it. The danger > is meant to be DOSing this URL (it's not really a push server); however with a > confirmation step, you still need to do that first request so you're not > reducing the number of HTTP requests. You are however relying on the push being > received by the client in order for it to be able to complete registration, and > all common push services do not guarantee delivery, so this becomes much less > reliable. (With this in mind, the JMAP push system happily copes with dropped > push packets while still guaranteeing full resynchronisation.) Actually I think adding confirmation step will make the push notifications more reliable, as that will give you positive feedback that your push notifications do work. It is really annoying trying to debug which firewall / proxy / encryption is causing the notification to be blocked, if I need to reregister again for every time and need to then somehow still cause one push notification to be sent before I can see does it work. > I note this issue doesn't really seem to be specific to JMAP, and yet RFC8030 > (which is what the push system is implementing) does not require a confirmation > step. My understanding is that RFC8030 does not connect random urls, the push notifications are received by client doing GET request to the subscription server and then later server using server push to that connection or something like that (in section 6 of the RFC8030). Usually that is only way things can work, as most of the people are behind firewalls / NATs / Proxies etc, thus connecting to them from outside is impossible or hard. The interaction between UA and the Application server is using "an application-specific method" which is not described in the RFC8030: An application-specific method is used to distribute the push URI to the application server. Confidentiality protection and application server authentication MUST be used to ensure that this URI is not disclosed to unauthorized recipients (Section 8.3). The verification would be inside this application-specific method, thus it is not covered in the 8030 because of that. In Jmap case the URL can be anything in the network and server is assumed to connect to that URL every time something happens. Yes, if something goes wrong in that url then notifications are disabled, but if server just answers HTTP ok 200 back, and JMAP server will be happy to keep sending notifications. With verification step the amplification factor would be around 1, as attacker does subscription registration (small packet), JMAP server sends first notification indication subscription is registed to given url (small packet), and when JMAP server does not get confirmation back from the attacker (which most likely cannot see the notifications), then it will delete subscription. Attacker can also do 10000 subscriptions to same victim (perhaps using different URLs, but destioned to same victim). It can do this overnight, and then on the morning when someone triggers event the victim will suddenly receive 10000 event notifications (https-connections) from the well connected JMAP server farm, and will be completely swamped before it can even respond to any errors to those notifications. -- kivinen@iki.fi From nobody Mon Jan 7 05:23:00 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661A6130E46; Mon, 7 Jan 2019 05:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMEPjOpsJ0vA; Mon, 7 Jan 2019 05:22:47 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 0983E130DE9; Mon, 7 Jan 2019 05:22:46 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x07DMehU002280 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Jan 2019 15:22:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x07DMeBW003930; Mon, 7 Jan 2019 15:22:40 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <23603.21152.388621.403480@fireball.acr.fi> Date: Mon, 7 Jan 2019 15:22:40 +0200 From: Tero Kivinen To: Barry Leiba Cc: Benjamin Kaduk , IETF JMAP Mailing List , "Kurt Andersen \(IETF\)" , draft-ietf-jmap-core.all@ietf.org, iesg@ietf.org, secdir@ietf.org In-Reply-To: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <20190105185050.GB28515@kduck.kaduk.org> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 26 min X-Total-Time: 4 min Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 13:22:48 -0000 Barry Leiba writes: > I agree with Ben that when documentation has been lacking in the past= we may > need to fix that in current documents.=C2=A0 The problem, I fear, is = that we write > much of this, especially at the app layer, to the wrong readers, so l= et=E2=80=99s think > about the shared mailbox case, for example, and see if we know what w= ill > actually help, rather than tick off some IETF-process-related box. >=20 > What we write in RFCs is primarily for software developers.=C2=A0 It = would be truly > bad if security/privacy warnings dissuaded developers from supporting= shared > mailboxes: any mail system that lacks such support would be hobbled a= nd bad. >=20 > So the best we could try would be to get vendors to copy or paraphras= e our > warnings in their documents, and/or to show warnings when the feature= s are > configured at installation.=C2=A0 I think it=E2=80=99s unlikely to ha= ppen.=C2=A0 Similarly, when > a user shares a mailbox a popup could show... also unlikely. >=20 > And what are we going to say=3F=C2=A0 That sharing a mailbox that con= tains personal > mail can expose private information=3F=C2=A0 That=E2=80=99s at the sa= me time so obvious as to > be silly, and entirely irrelevant to the actual shared-mailbox use ca= ses. >=20 > I think the best approach is to give examples of common use cases for= sharing.=C2=A0 > That might be informative and might actually prompt some vendors to i= nclude > similar examples in their doc. There is already huge difference in sharing mail and sharing calendars. Most of the calendars support easy way of sharing only limited set of data, i.e., you can mark entries as private where those will not be shared out, or will be shared out only as "busy", i.e., you can only see person is not available but not what calendar entry is. In mailboxes we do not have that kind of features. One thing we could suggest to implementors to allow sharing subfolders of the actual account instead of full mailbox, i.e., allow filtering rules to mark emails to specific folders, and only share those folders. I.e., create rules that puts all emails with specific keywords / or from specific users etc to subfolder and share this. This would allow solving some of the privacy issues when sharing mailboxes. The same privacy issues are mostly already solved for calendar, but not at all for mail... So if we provide such examples and features in our protocols, perhaps the implementors would implement them, and perhaps then we can actually make people to get some privacy... --=20 kivinen@iki.fi From nobody Mon Jan 7 08:11:48 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FC9130EFE; Mon, 7 Jan 2019 08:11:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Phillip Hallam-Baker To: Cc: draft-ietf-rtgwg-spf-uloop-pb-statement.all@ietf.org, ietf@ietf.org, rtgwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154687749567.23321.13207113394828941966@ietfa.amsl.com> Date: Mon, 07 Jan 2019 08:11:35 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 16:11:36 -0000 Reviewer: Phillip Hallam-Baker Review result: Has Issues The document describes the problem and solution pretty clearly. Unfortunately, there is no discussion of the security considerations which is not appropriate for a document addressing an availability which is a security issue. While microloops can form by chance, some consideration should be given to the possibility that an attacker could induce a loop to perform a DoS attack. From nobody Mon Jan 7 08:22:16 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC94126C7E; Mon, 7 Jan 2019 08:22:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Phillip Hallam-Baker To: Cc: softwires@ietf.org, draft-ietf-softwire-yang.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154687813459.23265.13403466946569558605@ietfa.amsl.com> Date: Mon, 07 Jan 2019 08:22:14 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-softwire-yang-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 16:22:15 -0000 Reviewer: Phillip Hallam-Baker Review result: Has Nits The document describes a schema and has appropriately identified the read/write security concerns arising from it. One issue that I thing could be usefully spelled out is that the use of automated tools to decode structures of this type is not merely a programming convenience. Attempts to parse length delimited objects nested in length delimited structures using handwritten code is error prone and has led to introduction of numerous buffer overrun vulnerabilities. From nobody Mon Jan 7 08:57:47 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9A0130F61; Mon, 7 Jan 2019 08:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DlhREjP8Y8S; Mon, 7 Jan 2019 08:57:44 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.218.59.24]) (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 F2C86130F4D; Mon, 7 Jan 2019 08:57:43 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1Q3OCHS8000CGN6@mauve.mrochek.com>; Mon, 7 Jan 2019 08:52:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1546879959; bh=O47qt/JpRE5dpigGQmc6Fub8funuTwzLroQn+ERfi3k=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Kx/ezKI2hTaHnkWKIZ1OfY4ov0aB5DSBbgrLTZrCpyzUtd3oR4FdN0/bZ7Oa2jKJ5 r1Di8IPu01R+WNyBCFzTO9r+DAKHT0m+9CYxUn9xBvT4nLeo8K/TMIaXJisF7ptYts luHWgsuYCBRhK4fcrHFCwquGV8GnNF55gxUL6ZYA= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com>; Mon, 7 Jan 2019 08:52:32 -0800 (PST) Cc: Ned Freed , "Kurt Andersen (IETF)" , IETF JMAP Mailing List , draft-ietf-jmap-core.all@ietf.org, Tero Kivinen , secdir@ietf.org Message-id: <01R1Q3OA5O7800004L@mauve.mrochek.com> Date: Mon, 07 Jan 2019 08:43:59 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 07 Jan 2019 12:24:52 +0000" References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> To: Tony Finch Archived-At: Subject: Re: [secdir] [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 16:57:46 -0000 > Ned Freed wrote: > > > > AFAICT it's different in the sense that this is the first push email > > notification mechanism we have standardized. > What about RFC 2177 IMAP IDLE? IDLE is an odd mix of pull and push. I don't think it really meets the criteria for a pure push mechanism, although on futher consideration I suppose with some persistance and careful observation of multiple IMAP streams you could perform this sort of traffic analysis on it. That said, the fact that the security considerations section in RFC 2177 says in its entirety: There are no known security issues with this extension. is pretty disturbing regardless. At a minimum an IDLE stream leaks information about a particular mailbox's activity, even when uncorrelated with incoming messages. Ned From nobody Mon Jan 7 09:05:23 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B623D130F75; Mon, 7 Jan 2019 09:05:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGt7xlck-RGm; Mon, 7 Jan 2019 09:05:14 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 5CE9A130F72; Mon, 7 Jan 2019 09:05:13 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id m22so1646379wml.3; Mon, 07 Jan 2019 09:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=htJjBNEDOMa4tWyDUHG8Y1pOE/x+Z9E2l8IMVgiTLT4=; b=NB7oIvOk0lc33pkb316H8iWpU7SEASTIYt6Xe6M0BqdzkcDnRiJ77HtJhJW6hgx5Zv HJpEqgR+uPuXY13Ab0AewFl9Vwv2nLnbKwHNKC7BqFiH2cLjBirYNqn+abBROq768ubi 6N/bcKTr+WlILB0sSabRZa5xTBF/0gbI8eeFm05jgh2IyCa5IQqN2jh3Ap7cql/M1/hA ZtlbCjuu3eXIqqsEGhBZaDTiczdLqET6N2/BpdCyOSQ4V9lonn4yJ/Oy2zxlksoKdURx Zfq2bs9YhI2g9InfrL9sRMUdXsGCWHjs9U+TOBIzCW4SMDpKV6BSiaQjTq+O5lpE2OHK TkMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=htJjBNEDOMa4tWyDUHG8Y1pOE/x+Z9E2l8IMVgiTLT4=; b=Sdz9tcmLrepDlbDoc4HLXm0+3Pm7UDfMMvWFgHOJdDXasOALA0yutEwzSr6e5qWbhw DZEDaCeW7OrIsg8/O5kUM+vzqOHmWNXKVNNBP0OHJ+JsFxkfJGyA78D/+Y8eRLFzKt3j kEpFSb/VPNafTPqiv60m4Tlk3Z34g9br8rDkes8kMvsS28l/0ZPZQovKQX2ZeYI003ZH QwOEgsvTOsR9n/bAvA/DRrOiaJ6r7EzJj6cqstJfRNeeiHrb1qh3er03O7ynYFz6UTIj KvagZtrVrIwYEXq8TavN732t1NvaIyiuvA0wxv7adbyy+kZULE0uge4f2PxDDtQ/nwce LQNg== X-Gm-Message-State: AJcUukc2P5dd8AQOVRJubPbYPKJ/fyV6DdCqB9b2G/m5jDwqVwJEV7se pYPXIzt2zFvqjcPU/3rNskiYvz5b X-Google-Smtp-Source: ALg8bN6/+W/lJIZpdF/6r5eC6yrdm7yJ5sWgyTHuYl8f4J2fEkhRz7SsrB+Tcv1N1Z2xZU7PBFG0fA== X-Received: by 2002:a7b:c315:: with SMTP id k21mr8939699wmj.145.1546880711273; Mon, 07 Jan 2019 09:05:11 -0800 (PST) Received: from [192.168.2.198] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id m193sm8413808wmb.26.2019.01.07.09.05.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Jan 2019 09:05:10 -0800 (PST) To: Phillip Hallam-Baker , secdir@ietf.org Cc: draft-ietf-rtgwg-spf-uloop-pb-statement.all@ietf.org, ietf@ietf.org, rtgwg@ietf.org References: <154687749567.23321.13207113394828941966@ietfa.amsl.com> From: Stewart Bryant Message-ID: <62c9b5fb-5c03-0747-fa1e-a513118a35a8@gmail.com> Date: Mon, 7 Jan 2019 17:05:09 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <154687749567.23321.13207113394828941966@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------6794F38D0BBE857931E87236" Content-Language: en-GB Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 17:05:16 -0000 This is a multi-part message in MIME format. --------------6794F38D0BBE857931E87236 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 07/01/2019 16:11, Phillip Hallam-Baker wrote: > Reviewer: Phillip Hallam-Baker > Review result: Has Issues > > The document describes the problem and solution pretty clearly. Unfortunately, > there is no discussion of the security considerations which is not appropriate > for a document addressing an availability which is a security issue. > > While microloops can form by chance, some consideration should be given to the > possibility that an attacker could induce a loop to perform a DoS attack. In section 1 the text says: [RFC8405] defines a solution that satisfies this problem statement and this document captures the reasoning of the provided solution. It is safe to assume that the reader of this text would have read normative reference RFC8405 and thus would be fully aware of the security issues related to the solution being analysed. An attacker that had access to a network such that they could induce microloops would have the ability to do many worse things to the network. If they were able to attack in-band they could poison the routing system to take it down in far more interesting ways. Operators use security at the physical and network layer to prevent this. If they were operating at the physical layer then they could take circuits down at will and cause microloops in the base protocol, traffic overloads and application malfunction. Thus if the attacker could deploy either of those attacks in a network to induce micro-loops, then any security considerations in this draft would count for nothing. The draft is an analysis, and thus I think that it correctly states that it introduces no additional matters for security consideration. - Stewart --------------6794F38D0BBE857931E87236 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 07/01/2019 16:11, Phillip Hallam-Baker wrote:
Reviewer: Phillip Hallam-Baker
Review result: Has Issues

The document describes the problem and solution pretty clearly. Unfortunately,
there is no discussion of the security considerations which is not appropriate
for a document addressing an availability which is a security issue.

While microloops can form by chance, some consideration should be given to the
possibility that an attacker could induce a loop to perform a DoS attack.

In section 1 the text says:

[RFC8405] defines a solution that satisfies this problem statement
   and this document captures the reasoning of the provided solution.

It is safe to assume that the reader of this text would have read normative reference RFC8405 and thus would be fully aware of the security issues related to the solution being analysed.

An attacker that had access to a network such that they could induce microloops would have the ability to do many worse things to the network.

If they were able to attack in-band they could poison the routing system to take it down in far more interesting ways. Operators use security at the physical and network layer to prevent this.

If they were operating at the physical layer then they could take circuits down at will and cause microloops in the base protocol, traffic overloads and application malfunction.

Thus if the attacker could deploy either of those attacks in a network to induce micro-loops, then any security considerations in this draft would count for nothing.

The draft is an analysis, and thus I think that it correctly states that it introduces no additional matters for security consideration.

- Stewart

--------------6794F38D0BBE857931E87236-- From nobody Mon Jan 7 10:02:42 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC00130EC6 for ; Mon, 7 Jan 2019 10:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7EVxi0aSOdP for ; Mon, 7 Jan 2019 10:02:38 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 C36B41277BB for ; Mon, 7 Jan 2019 10:02:37 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx66.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ggZEP-0001jA-Fm for secdir@ietf.org; Mon, 07 Jan 2019 19:02:35 +0100 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ggZEH-0004WS-1a for secdir@ietf.org; Mon, 07 Jan 2019 13:02:29 -0500 Received: (qmail 6632 invoked from network); 7 Jan 2019 18:02:21 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.39]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 Jan 2019 18:02:21 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (16C101) In-Reply-To: <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> Date: Mon, 7 Jan 2019 10:02:19 -0800 Cc: secdir@ietf.org, v6ops@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> To: JORDI PALET MARTINEZ X-Originating-IP: 168.144.250.230 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.23) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5jHkVeuB2ZXQ1iguQK3r7Pt602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzniiMFxnOFMHTZqw+apvQzTV/3OdXD2Xdo8CfrY5CQS7yDa+vCBJ0/aDVBkmz2qAIyz NJVaeAWax4WOe4pTBX2DwIE7VKe+bqpcdCns72R1myoI6HG8RgZGnUdJnKT7IqXe0Of4jddu9xC8 8+iQ5nb6BRFVjXUbiREH8mlR1JtPfYZ1V10x8j0kNETJD+nyXtcV2Hz37FuQUlYMDMlHwjIJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+1QmdZsu6 kxo/qWEj6Z1d7VIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdsewzRmhoeKlCpofGlp99T8RpJ5xYPZNRoOw1IxzkiGadCrr1g0oxQ4Hx 9ZbEd6A0pApl7B1QQuoPmRqW5R/J2U16th3iHXgtR+Y1L+Zzkg9a2/EwurjXBahe19+jBD7VuIee yrhzWminYO4gRGXn3bDVvCoqfGflxbtjudA02/m3s27IkHT4SMXRhQ/EkhkuGAO4aeVKjbQuc4NX lvv7E2xuaQzHYV6GCBsvo7Vn8xH1W6M5+kaZuEXO0wMN9NIDORBy2DNwOgV373pfDhBQ21OdM8gu ipSMnc4a1vOLkZpIf7UyEpcn4vR70ZwyprD5IJ34YaYZ30wD+IYKdMuYOSaM5ZxrRnRt4PqMzH3k 7hTkr8kPb2KLnZ2Xht3zA75VehhIcJfl9xjKxh+F8kIXLdZND3rjHB4Yc+TqdazcMI41sA2AfTJ2 5W/vzfaHf3wr2m4mbmeTgFKBgc4kmBS2brusOVZrHRzE6blhEo+mN1j1Fw== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [secdir] [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 18:02:41 -0000 Yes, that would work fine. If it could help convince these routers to implem= ent DHCP guard or RA guard, that would be a great result. I am not so sure about 802.1x. The routers could of course support a setting= like that of the IETF network, and that would have some advantage over WPA r= esidential, but it would not address an important threat: local device compr= omised by some virus and engaging in DHCP spoofing. DHCP guard or RA guard w= ould still be needed. -- Christian Huitema=20 > On Jan 7, 2019, at 2:38 AM, JORDI PALET MARTINEZ wrote: >=20 > Hi Christian, >=20 > I've drafted this at the moment. Let me know if you think now this is bett= er and if you think anything else is needed. >=20 > 8. Security Considerations >=20 > The IPv6 Transition CE Router must comply with the Security > Considerations as stated in [RFC7084], as well as those stated by > each transition mechanism implemented by the IPv6 Transition CE > Router. >=20 > As described in [RFC8026] and [RFC8415] Security Consideration > sections, there are generic DHCP security issues, which in the case > of this document means that malicious nodes may alter the priority of > the transition mechanisms. >=20 > Considering that, networks using DHCPv6, depending on their specific > topologies, should consider using authentication mechanisms such as > those based on IEEE-802.1X or access control mechanisms such as DHCP > snooping, DHCP guard, or TR-069, among other possible choices. >=20 > As stated in the introduction, this document addresses deployment of > IPv4aaS in residential, SOHO and SME networks. Deployment in more > challenging environments would require additional security analysis. >=20 >=20 > Regards, > Jordi >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- > De: ietf en nombre de JORDI PALET MARTINEZ > Fecha: lunes, 7 de enero de 2019, 11:17 > Para: Christian Huitema , > CC: , > Asunto: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-= ipv4aas-12 >=20 > Hi Christian, >=20 > Thanks for your review. >=20 > There is a typo there, wrong copy and paste. It should be RFC8415 and R= FC8026, as we discussed after your review. >=20 > My point, as discussed in the previous email exchange, is that this is a= generic issue of DHCP. DHCP is used by both residential and non-residential= service provisioning, and I don't see how we can solve that problem unless w= e implement some new DHCP "extension" that apply end-to-end encryption betwe= en, in this case, the CEs and the servers. >=20 > I can have a security section with basically replicates the text availa= ble in RFC8415 Security Section, including considerations of using IEEE-802.= 1X, DHCP snooping/guard/access control mechanisms, use of TR-069 access cont= rol mechanisms, etc. >=20 > I'm also happy to add your suggested paragraph regarding additional sec= urity analysis in more challenging environments. >=20 > Or maybe the correction of the RFC8415 references is sufficient in your= opinion or you will prefer some additional text to summarize the RFC8415 se= curity considerations/mitigations? >=20 > I'm going to wait a couple of days, in case there are further inputs, b= efore uploading a new version correcting the mistake and also take in consid= erations the suggestions from the Gen-ART review a couple of days ago. >=20 > Regards, > Jordi >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de Christian Huitema > Fecha: lunes, 7 de enero de 2019, 7:28 > Para: > CC: , , > Asunto: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-i= pv4aas-12 >=20 > Reviewer: Christian Huitema > Review result: Ready >=20 > I already reviewed the version 11 of this draft. =46rom a security p= oint of view, > the main change between the two versions is the addition of a parag= raph > acknowledging the potential risks of relying on DHCP for configurat= ion. To > quote: "As described in [RFC8026] and [RFC8026] Security Considerat= ion > sections, there are generic DHCP security issues, which in the case= of this > document means that malicious nodes may alter the priority of the t= ransition > mechanisms." >=20 > Well, on the one hand, this does directly address the point I raise= d in the > previous review. On the other hand, it is a bit sad to have a dry > acknowledgement like that, without any hint at mitigations. If I wa= s writing an > April's fool RFC, I would qualify that as one of those security sec= tions that > seem written primarily for appeasing the security reviewer. But the= n, do we > want to give some advice to implementers? For example, do we want t= o tell them > that it is OK to deploy compliant devices in a basic home network? P= robably. In > the branch office of a financial institution? Most probably not. Do= we have a > way to convey that in simple terms? I would add something like: >=20 > "As stated in the introduction, this document addresses deployment o= f IPv4 as a > service in a residential or small-office network. Deployment in mor= e > challenging environments would require additional security analysis= ." >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company >=20 > This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of th= e individual(s) named above and further non-explicilty authorized disclosure= , copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be consi= dered a criminal offense. If you are not the intended recipient be aware tha= t any disclosure, copying, distribution or use of the contents of this infor= mation, even if partially, including attached files, is strictly prohibited,= will be considered a criminal offense, so you must reply to the original se= nder to inform about this communication and delete it. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company >=20 > This electronic message contains information which may be privileged or co= nfidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, c= opying, distribution or use of the contents of this information, even if par= tially, including attached files, is strictly prohibited and will be conside= red a criminal offense. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informat= ion, even if partially, including attached files, is strictly prohibited, wi= ll be considered a criminal offense, so you must reply to the original sende= r to inform about this communication and delete it. >=20 >=20 >=20 From nobody Mon Jan 7 11:17:36 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D13712D4EA; Mon, 7 Jan 2019 11:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiIskYABxodV; Mon, 7 Jan 2019 11:17:16 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 B8EFE1310F4; Mon, 7 Jan 2019 11:17:15 -0800 (PST) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x07JFuuF029964; Mon, 7 Jan 2019 14:17:07 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2pvcm58asv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Jan 2019 14:17:06 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x07JH52h001302; Mon, 7 Jan 2019 14:17:06 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x07JH2hR001272; Mon, 7 Jan 2019 14:17:03 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 9DC88400579E; Mon, 7 Jan 2019 19:17:02 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30488.vci.att.com (Service) with ESMTPS id 8B9EA40002C2; Mon, 7 Jan 2019 19:17:02 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0415.000; Mon, 7 Jan 2019 14:17:02 -0500 From: "STARK, BARBARA H" To: "'Christian Huitema'" , JORDI PALET MARTINEZ CC: "v6ops@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 Thread-Index: AQHUplIxzMK3YDjZl0aLw/nLjmGiN6Wj60wAgAAGJ4CAAHv9gP//vwTw Date: Mon, 7 Jan 2019 19:17:01 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.202.237] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=602 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901070161 Archived-At: Subject: Re: [secdir] [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 19:17:24 -0000 PiBGcm9tOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIENocmlz dGlhbiBIdWl0ZW1hDQouLi4NCj4gSSBhbSBub3Qgc28gc3VyZSBhYm91dCA4MDIuMXguIFRoZSBy b3V0ZXJzIGNvdWxkIG9mIGNvdXJzZSBzdXBwb3J0IGEgc2V0dGluZw0KPiBsaWtlIHRoYXQgb2Yg dGhlIElFVEYgbmV0d29yaywgYW5kIHRoYXQgd291bGQgaGF2ZSBzb21lIGFkdmFudGFnZSBvdmVy DQo+IFdQQSByZXNpZGVudGlhbCwgYnV0IGl0IHdvdWxkIG5vdCBhZGRyZXNzIGFuIGltcG9ydGFu dCB0aHJlYXQ6IGxvY2FsIGRldmljZQ0KPiBjb21wcm9taXNlZCBieSBzb21lIHZpcnVzIGFuZCBl bmdhZ2luZyBpbiBESENQIHNwb29maW5nLiBESENQIGd1YXJkIG9yDQo+IFJBIGd1YXJkIHdvdWxk IHN0aWxsIGJlIG5lZWRlZC4NCg0KODAyLjFYIGlzIHZlcnkgd2lkZWx5IHVzZWQgaW4gR1BPTiBh bmQgRFNMIG5ldHdvcmtzIGFuZCBJIGhhdmVuJ3QgaGVhcmQgb2YgaXQgaGF2aW5nIGFueSBpc3N1 ZXMuIEknbSBub3QgdW5kZXJzdGFuZGluZyB0aGUgcmVmZXJlbmNlIHRvIFdQQSBhbmQgbG9jYWwg ZGV2aWNlcywgc2luY2UgSSB0aGluayB3ZSdyZSB0YWxraW5nIGFib3V0IHRoZSBXQU4gYW5kIG5v dCB0aGUgTEFOIGludGVyZmFjZSBoZXJlPyANCg0KLi4uLi4uLi4uLg0KPiA+IE9uIEphbiA3LCAy MDE5LCBhdCAyOjM4IEFNLCBKT1JESSBQQUxFVCBNQVJUSU5FWg0KLi4uDQo+ID4gICBDb25zaWRl cmluZyB0aGF0LCBuZXR3b3JrcyB1c2luZyBESENQdjYsIGRlcGVuZGluZyBvbiB0aGVpciBzcGVj aWZpYw0KPiA+ICAgdG9wb2xvZ2llcywgc2hvdWxkIGNvbnNpZGVyIHVzaW5nIGF1dGhlbnRpY2F0 aW9uIG1lY2hhbmlzbXMgc3VjaCBhcw0KPiA+ICAgdGhvc2UgYmFzZWQgb24gSUVFRS04MDIuMVgg b3IgYWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNtcyBzdWNoIGFzIERIQ1ANCj4gPiAgIHNub29waW5n LCBESENQIGd1YXJkLCBvciBUUi0wNjksIGFtb25nIG90aGVyIHBvc3NpYmxlIGNob2ljZXMuDQoN ClRSLTA2OSBpcyBhIG1hbmFnZW1lbnQgcHJvdG9jb2wgKHRoYXQgZ29lcyBvdmVyIEhUVFAsIHVz aW5nIFRMUyBmb3Igc2VjdXJpdHkpLCBhbmQgbm90IGFuIGFjY2VzcyBjb250cm9sIG1lY2hhbmlz bS4gSSBzdWdnZXN0IGl0IGJlIHJlbW92ZWQgZnJvbSB0aGlzIGxpc3QuDQoNCkJhcmJhcmENCg0K From nobody Mon Jan 7 11:58:29 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7474D12008A; Mon, 7 Jan 2019 11:58:21 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FzzF1Dh1qEn; Mon, 7 Jan 2019 11:58:18 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6404124C04; Mon, 7 Jan 2019 11:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1546891094; x=1547495894; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=L4E9job2HdDnkFUeE2oXTo/ELS7SU5jTi299G1MwtjA=; b=QHpjO8l/AxPRi GvPmmO4ROhLZFBizW3gMrR9Zm19h4S5tDGUbacABlFhg0Ym1a+lbfs/fTzlWfX66 HcWNjStYWizFKtUV0gV/MH4GwhadnP+goY5SPytnKxmW1k8XmfelpbZr4Ag9GbpN XN70cB7AsVJLnf8x6V9eRy6XqPZppE= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 07 Jan 2019 20:58:14 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 07 Jan 2019 20:58:14 +0100 Received: from [10.10.10.131] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006100772.msg; Mon, 07 Jan 2019 20:58:13 +0100 X-MDRemoteIP: 2001:470:1f09:495:707a:ed9e:3096:7905 X-MDHelo: [10.10.10.131] X-MDArrival-Date: Mon, 07 Jan 2019 20:58:13 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=19105d24b1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Mon, 07 Jan 2019 20:58:10 +0100 From: JORDI PALET MARTINEZ To: "STARK, BARBARA H" , 'Christian Huitema' CC: "v6ops@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Message-ID: Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 19:58:22 -0000 Hi Barbara, I agree with your regarding the WPA, not sure to understand the point from = Christian. If a local device is compromised, that happens in the LANs and this will on= ly affect the CE, if the "virus" or "bot" or whatever is able to compromise= the CE configuration and then replace some of the settings done by the pro= visioning system. This is something that may happen regardless of using DHCP in the WAN or ot= her protocols. I recall having seen some TR-069 mechanism (maybe it was proprietary) to pr= ovide something related to access control security, but if it is not standa= rd, I will remove it. Let's see if someone in the list can provide some inf= o and I will also try to recall what was in the case I've in mind. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: ietf en nombre de "STARK, BARBARA H" Fecha: lunes, 7 de enero de 2019, 20:20 Para: 'Christian Huitema' , JORDI PALET MARTINEZ CC: "v6ops@ietf.org" , "ietf@ietf.org" , "se= cdir@ietf.org" Asunto: RE: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-i= pv4aas-12 > From: v6ops On Behalf Of Christian Huitema ... > I am not so sure about 802.1x. The routers could of course support a = setting > like that of the IETF network, and that would have some advantage ove= r > WPA residential, but it would not address an important threat: local = device > compromised by some virus and engaging in DHCP spoofing. DHCP guard o= r > RA guard would still be needed. =20 802.1X is very widely used in GPON and DSL networks and I haven't heard= of it having any issues. I'm not understanding the reference to WPA and lo= cal devices, since I think we're talking about the WAN and not the LAN inte= rface here?=20 =20 .......... > > On Jan 7, 2019, at 2:38 AM, JORDI PALET MARTINEZ ... > > Considering that, networks using DHCPv6, depending on their speci= fic > > topologies, should consider using authentication mechanisms such = as > > those based on IEEE-802.1X or access control mechanisms such as D= HCP > > snooping, DHCP guard, or TR-069, among other possible choices. =20 TR-069 is a management protocol (that goes over HTTP, using TLS for sec= urity), and not an access control mechanism. I suggest it be removed from t= his list. =20 Barbara =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Jan 7 15:46:52 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD7712008A; Mon, 7 Jan 2019 15:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_jeNkXYZJqc; Mon, 7 Jan 2019 15:46:48 -0800 (PST) Received: from mail-it1-f182.google.com (mail-it1-f182.google.com [209.85.166.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 97413124408; Mon, 7 Jan 2019 15:46:48 -0800 (PST) Received: by mail-it1-f182.google.com with SMTP id i145so3797290ita.4; Mon, 07 Jan 2019 15:46:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VXjr4S+tIR7RyNjfIppAlE1Nw8gJi9rLPZrAyGgcJX8=; b=STOloBCi1Ycyv33UTq0qINVbWeU+/zqwpmT/1jUjFqGHDJEBtcFdZmn4DPtSph2vY2 XRAFXSrz/Z2V5A2NXYA+aQgnrbrFBWqYOULwh/USXjM1D7NpwZs2JstkoL+7bddGnp9j AnaZ28e5iqNp4BfVNDXS+gQ5gJ1Ui12R3g0rbCTx64CxmcLoHG2u1MMquQwGkCBfJNa4 K54DleUbh3zx4oGXTv2GxIwSNuELb0npSsMRJh/mrBgoSR6j9NTJU42UlaPwbxOISpD/ SUvP2PwDT/vzJOxqaOXtxKifSfNRPd9myokEc7/5lrNvllY0Z4Q3OddIiJNl82GhpV8/ ZuEA== X-Gm-Message-State: AJcUukcf9INsRNltY6XVjb8Hmz2o0IjkFpD9HHE01mgXAzHwDigVAZ5x GnPFrI3UxHfG/x82ZLOMisbAUWMDHv0+m9gm1/8= X-Google-Smtp-Source: ALg8bN61Uf7w4fd3vFHraGIfI42dqdeWymqPpTDfeJMx3G4pnqluhJ7Ygx3vTXp9iOsw+RUXtvYye/9z/xeu9ZLb0vw= X-Received: by 2002:a24:dd8d:: with SMTP id t135mr8175177itf.84.1546904807539; Mon, 07 Jan 2019 15:46:47 -0800 (PST) MIME-Version: 1.0 References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> <01R1Q3OA5O7800004L@mauve.mrochek.com> In-Reply-To: <01R1Q3OA5O7800004L@mauve.mrochek.com> From: Barry Leiba Date: Tue, 8 Jan 2019 07:46:36 +0800 Message-ID: To: Ned Freed Cc: IETF JMAP Mailing List , "Kurt Andersen (IETF)" , Tero Kivinen , Tony Finch , draft-ietf-jmap-core.all@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="0000000000008e07f0057ee6d79c" Archived-At: Subject: Re: [secdir] [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 23:46:51 -0000 --0000000000008e07f0057ee6d79c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hm. I don=E2=80=99t see that. All you get in response to the IDLE command= is the same stuff you get from the NOOP command or from any other IMAP command: untagged FETCH and EXPUNGE responses. Technically, they=E2=80=99re not act= ually responses to the command: they=E2=80=99re unsolicited messages in the IMAP = protocol. What security considerations should there be for IDLE that are beyond those for NOOP (that is, IMAP itself? Barry On Tue, Jan 8, 2019 at 12:58 AM Ned Freed wrote: > > Ned Freed wrote: > > > > > > AFAICT it's different in the sense that this is the first push email > > > notification mechanism we have standardized. > > > What about RFC 2177 IMAP IDLE? > > IDLE is an odd mix of pull and push. I don't think it really meets the > criteria > for a pure push mechanism, although on futher consideration I suppose wit= h > some > persistance and careful observation of multiple IMAP streams you could > perform > this sort of traffic analysis on it. > > That said, the fact that the security considerations section in RFC 2177 > says in its entirety: > > There are no known security issues with this extension. > > is pretty disturbing regardless. At a minimum an IDLE stream leaks > information > about a particular mailbox's activity, even when uncorrelated with incomi= ng > messages. > > Ned > --0000000000008e07f0057ee6d79c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hm.=C2=A0 I don=E2=80=99t see that.=C2=A0 All you ge= t in response to the IDLE command is the same stuff you get from the NOOP c= ommand or from any other IMAP command: untagged FETCH and EXPUNGE responses= .=C2=A0 Technically, they=E2=80=99re not actually responses to the command:= they=E2=80=99re unsolicited messages in the IMAP protocol.

What security considerations should t= here be for IDLE that are beyond those for NOOP (that is, IMAP itself?

Barry

On Tue, Jan 8, 2019 at 12:58 AM N= ed Freed <ned.freed@mrochek.com= > wrote:
> Ned Freed <= ned.freed@mroche= k.com> wrote:
> >
> > AFAICT it's different in the sense that this is the first pus= h email
> > notification mechanism we have standardized.

> What about RFC 2177 IMAP IDLE?

IDLE is an odd mix of pull and push. I don't think it really meets the = criteria
for a pure push mechanism, although on futher consideration I suppose with = some
persistance and careful observation of multiple IMAP streams you could perf= orm
this sort of traffic analysis on it.

That said, the fact that the security considerations section in RFC 2177 says in its entirety:

=C2=A0 There are no known security issues with this extension.

is pretty disturbing regardless. At a minimum an IDLE stream leaks informat= ion
about a particular mailbox's activity, even when uncorrelated with inco= ming
messages.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ned
--0000000000008e07f0057ee6d79c-- From nobody Mon Jan 7 18:30:20 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F364C130EA8; Mon, 7 Jan 2019 18:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=wt8WQvpN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=L5rWvRS9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ3VSUumH6Oy; Mon, 7 Jan 2019 18:30:11 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB0D130EA3; Mon, 7 Jan 2019 18:30:10 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8A4D124537; Mon, 7 Jan 2019 21:30:09 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 07 Jan 2019 21:30:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=hBmqAZEWT4x1NqB554GwLTo2o c0z4YvHBuLTf3vqLyU=; b=wt8WQvpN5CNhDbKsyYLbwvFyaX1wzrl+N+4YQQfIG /dYGtj1gnd3RaraL3c5TqV+g4vLLP5LH0o2SSGs8U4iJ1520cWxrYhLqAg+zHkQK WLYDyPnibe8ZMSB2R6AH6lHhE07FlhCFkEuirhMInIUOlu9TvTDZLW3ZfduNAFXb xd+NogF7ADXavL/fVM9q/9ZUMvIc3YGqZ/RySRuXdJ1mMUuEZVVxRLLoDei3wrPS ffL6fRH1QcbQjN+G7RDit4fF8KTigH1vsSHVtx2WP5kaKPxnn6cTw39xlcpxNgaI 8WvVKxoMxi9n1wc0VIDp0UAQyhMGHNC7TNT5rTtgtUY8A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=hBmqAZEWT4x1NqB55 4GwLTo2oc0z4YvHBuLTf3vqLyU=; b=L5rWvRS9NAUFEi6qFlDpC+v48mg53NSop NW39Y+/a04emD3Au03o9V6TT0d5S5IklQ9MclnnP++Omn38Oon3Ovz+TZe4Lzj9r 8F1+qEfUspNeNJTn2OaAOOnsdJxIcWmgAXJfeGKlnL0tGxJjRbcXaNCg/kDfy59k 2w5olju3RH3XTAu2Ud+dqis5d9vHD+9hzSkPBZsaAg7rRpRdZPFvKi6De+Uloc8Z ALRLulfBMKTBv/SFMXk4WnJni267UJAhLXiDl86b5x5q+VKkfjMupIgdn8VuKQTF m8lGXEB1I+E0i9oHzp+8VXolPJpt6b6RVhZMr33OjkBFih5OcFDlw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdekgdegleculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goufhushhpvggtthffohhmrghinhculdegledmnecujfgurhepofgfkfgjfhffhffvufgt segrtderreerreejnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilh hjsehfrghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehgihhthhhusgdr ihhonecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvg grmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A5D6F203BE; Mon, 7 Jan 2019 21:30:08 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 64588216 Message-Id: In-Reply-To: <23603.20862.976183.378013@fireball.acr.fi> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> <23603.20862.976183.378013@fireball.acr.fi> Date: Mon, 07 Jan 2019 21:30:07 -0500 From: "Neil Jenkins" To: "Tero Kivinen" Cc: secdir@ietf.org, "Bron Gondwana" , "IETF JMAP Mailing List" , draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=9ebb9715cf3f4a36b4e65b8b9eecb72d Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 02:30:13 -0000 --9ebb9715cf3f4a36b4e65b8b9eecb72d Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, 8 Jan 2019, at 12:17 AM, Tero Kivinen wrote: > Actually I think adding confirmation step will make the push > notifications more reliable, as that will give you positive feedback > that your push notifications do work. The issue is that push services (e.g. Apple's APNS and Google's FCM) do = not guarantee that any particular push will be received. They normally w= ill, but may not, especially if the device goes offline for a while. So = if your first push doesn't make it through your push never works. It's l= ikely to be rare, but painful when it happens and makes it feel unreliab= le. > It is really annoying trying to debug which firewall / proxy / encrypt= ion is causing the notification to be blocked, if I need to reregister a= gain for every time and need to then somehow still cause one push notifi= cation to be sent before I can see does it work.=20 I'm not sure what you're referring to here. Do you mean the JMAP (applic= ation) server connecting to the push server? Or the push server connecti= ng to the client (which is not part of JMAP at all, but where you're mor= e likely to run into issues with corporate firewalls and the like)? > My understanding is that RFC8030 does not connect random urls, My understanding is that is incorrect. There are three entities involved= in an 8030 push system, and JMAP is only involved with two of them: * The client, which wants to receive the push notifications (the JMAP c= lient) * The application server which contains the data and wants to send the = push notifications (the JMAP server)=20 * The push server (3rd party, depends on the device what is possible) The situation of the client/application server being one entity and the = push server being a completely unrelated entity is what 8030 is designed= for. For example, each browser implements the Push API , whereby if you have a web app you can ask the browser= for a push subscription endpoint, then send it to your application serv= er to connect to. The application server does not know in advance which = browser the user has or what domains that browser currently uses for pus= h subscriptions. It simply gets given an arbitrary URL to post to.=20 JMAP is not defining anything new here. It is just defining the applicat= ion server portion exactly as expected by RFC8030. > the push notifications are received by client doing GET request to the= > subscription server and then later server using server push to that > connection or something like that (in section 6 of the RFC8030). > Usually that is only way things can work, as most of the people are > behind firewalls / NATs / Proxies etc, thus connecting to them from > outside is impossible or hard. Yes, this is how the client receives the data from the push server in RF= C8030. This is entirely orthogonal to what we are discussing though. > The interaction between UA and the Application server is using > "an application-specific method" =E2=80=A6 > The verification would be inside this application-specific method, > thus it is not covered in the 8030 because of that. Hmm, yes I see your point, although it seems odd for it not to mention a= t all given this is going to apply to pretty much every app that uses th= is system; not specifically JMAP. > but if server just answers HTTP ok 200 back, and JMAP server will be > happy to keep sending notifications. Yes, this is indeed a risk, and I agree that a confirmation step would b= e the only way to mitigate this. > Attacker can also do 10000 subscriptions to same victim (perhaps using= > different URLs, but destioned to same victim). It can do this > overnight, and then on the morning when someone triggers event the > victim will suddenly receive 10000 event notifications > (https-connections) from the well connected JMAP server farm, and will= > be completely swamped before it can even respond to any errors to > those notifications. I would expect the JMAP server to rate limit the number of push subscrip= tions any one user may have to something considerably lower than that. I= f the attacker had compromised many accounts on the JMAP server though, = it could set up push subscriptions with each of them but then it would h= ave to coordinate making a change in each of those accounts at the same = time in order to flood the target server with a large single burst of re= quests, which is a much harder thing to do. Summing up, I think that adding a confirmation step removes a small risk= of being able to use a JMAP application server as a DDOS vector, but ad= ds a small risk of the push not being received and the push system faili= ng to establish. (Although, the client would at least know this was the = case so could alert the user and give them the option to try again.) Wou= ld anyone else like to weigh in on the relative merits of the options he= re to help come to a consensus on the way forward? I would be particular= ly interested to hear if this was discussed at all, and any conclusions = reached, in the development of RFC8030. Neil. --9ebb9715cf3f4a36b4e65b8b9eecb72d Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Tue, 8 = Jan 2019, at 12:17 AM, Tero Kivinen wrote:
Actually I think adding confirmation s= tep will make the push
notifications more reliable, as tha= t will give you positive feedback
that your push notificat= ions do work.

The issue is tha= t push services (e.g. Apple's APNS and Google's FCM) do not guarantee th= at any particular push will be received. They normally will, but may not= , especially if the device goes offline for a while. So if your first pu= sh doesn't make it through your push never works. It's likely to be rare= , but painful when it happens and makes it feel unreliable.

It is = really annoying trying to debug which firewall / proxy / encryption is c= ausing the notification to be blocked, if I need to reregister again for= every time and need to then somehow still cause one push notification t= o be sent before I can see does it work. 

I'm not sure what you're referring to here. Do you mean= the JMAP (application) server connecting to the push server? Or the pus= h server connecting to the client (which is not part of JMAP at all, but= where you're more likely to run into issues with corporate firewalls an= d the like)?

My understanding is that RFC8030 does not connect ran= dom urls,

My understanding is = that is incorrect. There are three entities involved in an 8030 push sys= tem, and JMAP is only involved with two of them:

  • The client, which wants to receive the push notifications (the = JMAP client)
  • The application server which contains the data = and wants to send the push notifications (the JMAP server) 
  • The push server (3rd party, depends on the device what is possible)=

The situation of the client/applicatio= n server being one entity and the push server being a completely unrelat= ed entity is what 8030 is designed for. For example, each browser implem= ents the Push API, where= by if you have a web app you can ask the browser for a push subscription= endpoint, then send it to your application server to connect to. The ap= plication server does not know in advance which browser the user has or = what domains that browser currently uses for push subscriptions. It simp= ly gets given an arbitrary URL to post to.

JMAP is not defining anything new here. It is just defining the applica= tion server portion exactly as expected by RFC8030.

the push notif= ications are received by client doing GET request to the
s= ubscription server and then later server using server push to that
connection or something like that (in section 6 of the RFC8030)= .
Usually that is only way things can work, as most of the= people are
behind firewalls / NATs / Proxies etc, thus co= nnecting to them from
outside is impossible or hard.

Yes, this is how the client receive= s the data from the push server in RFC8030. This is entirely orthogonal = to what we are discussing though.

The interaction between UA and t= he Application server is using
"an application-specific me= thod" =E2=80=A6
The verification would be inside this application-spe= cific method,
thus it is not covered in the 8030 because o= f that.

Hmm, yes I see your po= int, although it seems odd for it not to mention at all given this is go= ing to apply to pretty much every app that uses this system; not specifi= cally JMAP.

but if server just answers HTTP ok 200 back, and JMAP = server will be
happy to keep sending notifications.

Yes, this is indeed a risk, and I ag= ree that a confirmation step would be the only way to mitigate this.
=

Attacker can also do 10000 subscriptions to same victim (perhaps usin= g
different URLs, but destioned to same victim). It can do= this
overnight, and then on the morning when someone trig= gers event the
victim will suddenly receive 10000 event no= tifications
(https-connections) from the well connected JM= AP server farm, and will
be completely swamped before it c= an even respond to any errors to
those notifications.
<= /div>

I would expect the JMAP server to = rate limit the number of push subscriptions any one user may have to som= ething considerably lower than that. If the attacker had compromised man= y accounts on the JMAP server though, it could set up push subscriptions= with each of them but then it would have to coordinate making a change = in each of those accounts at the same time in order to flood the target = server with a large single burst of requests, which is a much harder thi= ng to do.

Summing up, I think that adding a= confirmation step removes a small risk of being able to use a JMAP appl= ication server as a DDOS vector, but adds a small risk of the push not b= eing received and the push system failing to establish. (Although, the c= lient would at least know this was the case so could alert the user and = give them the option to try again.) Would anyone else like to weigh in o= n the relative merits of the options here to help come to a consensus on= the way forward? I would be particularly interested to hear if this was= discussed at all, and any conclusions reached, in the development of RF= C8030.

Neil.
--9ebb9715cf3f4a36b4e65b8b9eecb72d-- From nobody Mon Jan 7 18:53:05 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BD2130E76; Mon, 7 Jan 2019 18:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=TAl0w3Mk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GuivZxBf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22ctcsTmRfyY; Mon, 7 Jan 2019 18:52:52 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D8212D4EB; Mon, 7 Jan 2019 18:52:52 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 17CC422075; Mon, 7 Jan 2019 21:52:51 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 07 Jan 2019 21:52:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=HL4BTD2SkBjgXcL7t7ukDcUKv wF2DsDxizyTIpzuHq0=; b=TAl0w3Mk9GOTBLTs4hLxgrZc4xoRR8kHChdg80i6u JZ+pke6qzBDTbQNMLrT1wM5gDRErqgwUdb4/G8DK9nGlecwe3ZibOtAC5LJL2AE4 +5dD2+S3LGjuvYuxJa+q20a8Qb2FeSyclWwd+e2zrzdmn1XMVv2wIqeFaEgeMqAf Q5+M2kxXP9ebcvf6my6oEv4nrwJduPeBrVC8MnLRT9t8hmDRS/BuWzB/xCMTrexO J9fRnoBRPUc9Koyzt3gbIfuzDUZ3V2ZE88xO6pCQF4QmFoHYyf0Rk83MnwIsonSd iEezp08qIlgYioZuxYukdxW5ZlrtPTtR6tOtXepi9LeLw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=HL4BTD2SkBjgXcL7t 7ukDcUKvwF2DsDxizyTIpzuHq0=; b=GuivZxBfoDUOgdATqgbeMZ0ac12c/XW+j 60h/SqREKkQdi27aU/6QR1jEabhLHZi4c+aPOqtuT6azZf5Yv7F+ebi4Eo9eq8/o loYiOBBavo9zprjQXIyy0fsWS8U3XrqXg+x08E2sjmI8JboNjZChaSh2Xv1jHJxQ 6eVyNsSldstK6uxma2k5NnkyJj2V1QZIMM8kGrfmKYVni3OcXyBUIEv7wXxJjrp/ f/6kECkDnPkYnbYupbHHasePrjS+arThc8/1u/LBbXDYfBaFoeHcEOXBgT3xHYZp xxWexkfdGggAA3hT68vmMB7Vud+oBCBZd/w6Al6SnPmI5usZ6tU/g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdekgdehgeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghm rdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3DDC1203BE; Mon, 7 Jan 2019 21:52:50 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 56629417 Message-Id: In-Reply-To: <23603.21152.388621.403480@fireball.acr.fi> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <20190105185050.GB28515@kduck.kaduk.org> <23603.21152.388621.403480@fireball.acr.fi> Date: Mon, 07 Jan 2019 21:52:48 -0500 From: "Bron Gondwana" To: "Barry Leiba" , "Tero Kivinen" Cc: "Benjamin Kaduk" , "IETF JMAP Mailing List" , "Kurt Andersen (IETF)" , draft-ietf-jmap-core.all@ietf.org, iesg@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary=f800bcbd89b2475e9e7a25f195986367 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 02:52:53 -0000 --f800bcbd89b2475e9e7a25f195986367 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 8, 2019, at 00:22, Tero Kivinen wrote: > Barry Leiba writes: > > I agree with Ben that when documentation has been lacking in the pas= t we may > > need to fix that in current documents. The problem, I fear, is that = we write > > much of this, especially at the app layer, to the wrong readers, so = let=E2=80=99s think > > about the shared mailbox case, for example, and see if we know what = will > > actually help, rather than tick off some IETF-process-related box. > >=20 > > What we write in RFCs is primarily for software developers. It would= be truly > > bad if security/privacy warnings dissuaded developers from supportin= g shared > > mailboxes: any mail system that lacks such support would be hobbled = and bad. > >=20 > > So the best we could try would be to get vendors to copy or paraphra= se our > > warnings in their documents, and/or to show warnings when the featur= es are > > configured at installation. I think it=E2=80=99s unlikely to happen.= Similarly, when > > a user shares a mailbox a popup could show... also unlikely. > >=20 > > And what are we going to say? That sharing a mailbox that contains p= ersonal > > mail can expose private information? That=E2=80=99s at the same time= so obvious as to > > be silly, and entirely irrelevant to the actual shared-mailbox use c= ases. > >=20 > > I think the best approach is to give examples of common use cases fo= r sharing.=20 > > That might be informative and might actually prompt some vendors to = include > > similar examples in their doc. >=20 > There is already huge difference in sharing mail and sharing > calendars. Most of the calendars support easy way of sharing only > limited set of data, i.e., you can mark entries as private where those= > will not be shared out, or will be shared out only as "busy", i.e., > you can only see person is not available but not what calendar entry > is. >=20 > In mailboxes we do not have that kind of features. One thing we could > suggest to implementors to allow sharing subfolders of the actual > account instead of full mailbox, i.e., allow filtering rules to mark > emails to specific folders, and only share those folders. I.e., create= > rules that puts all emails with specific keywords / or from specific > users etc to subfolder and share this. >=20 > This would allow solving some of the privacy issues when sharing > mailboxes. The same privacy issues are mostly already solved for > calendar, but not at all for mail... I feel like we're talking at cross purposes here. I'm not sure which mai= l services you've used before, but every mail services I've used with ma= il sharing allows you to share individual sub-mailboxes only. I've been = using JMAP in exactly that way, with individual notifications folders sh= ared to me from other accounts, and not the full contents of those accou= nts. > So if we provide such examples and features in our protocols, perhaps > the implementors would implement them, and perhaps then we can > actually make people to get some privacy... Sharing individual folder is precisely what RFC3501 specifies and RFC431= 4 expands on, and JMAP is duplicating that same pattern. I don't like th= e idea of changing the examples just because one reviewer has not person= ally experienced a use-case for a feature. I have never heard of a case = of people feeling that their privacy is negatively impacted by the fact = that there are ACLs on their mailboxes. A server could easily provide ba= ckdoor access into data WITHOUT telling users via the protocol, so as Ba= rry said - not having that ability just makes a less useful server, not = an increase in privacy. Regards, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --f800bcbd89b2475e9e7a25f195986367 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 8, 2019, at 00:22, Tero Kivinen wrote:
Barry Leiba writes:
> I agree with Ben that when documentation has been lacking in th= e past we may
> need to fi= x that in current documents.  The problem, I fear, is that we write=
> much of this, especiall= y at the app layer, to the wrong readers, so let=E2=80=99s think
> about the shared mailbox case, = for example, and see if we know what will
> actually help, rather than tick off some IETF-process-= related box.
> 
> What we write in RFCs is prim= arily for software developers.  It would be truly
> bad if security/privacy warnings dissuade= d developers from supporting shared
> mailboxes: any mail system that lacks such support would be = hobbled and bad.
> 
> So the best we could try = would be to get vendors to copy or paraphrase our
> warnings in their documents, and/or to show wa= rnings when the features are
= > configured at installation.  I think it=E2=80=99s unlikely to = happen.  Similarly, when
> a user shares a mailbox a popup could show... also unlikely.
> 
> And what are we going to say?  That sharin= g a mailbox that contains personal
> mail can expose private information?  That=E2=80=99s at = the same time so obvious as to
> be silly, and entirely irrelevant to the actual shared-mailbox us= e cases.
> 
=
> I think the best approach is to g= ive examples of common use cases for sharing. 
> That might be informative and might actually p= rompt some vendors to include
> similar examples in their doc.

There is already hug= e difference in sharing mail and sharing
calendars. Most of the calendars support easy way of sharing= only
limited set of data, i.= e., you can mark entries as private where those
will not be shared out, or will be shared out only as= "busy", i.e.,
you can only s= ee person is not available but not what calendar entry
is.

In mailboxes we do not have= that kind of features. One thing we could
suggest to implementors to allow sharing subfolders of the= actual
account instead of fu= ll mailbox, i.e., allow filtering rules to mark
emails to specific folders, and only share those fold= ers. I.e., create
rules that = puts all emails with specific keywords / or from specific
users etc to subfolder and share this.
<= /div>

This would allow solving some of the privacy issues when shar= ing
mailboxes. The same priva= cy issues are mostly already solved for
calendar, but not at all for mail...

I feel like we're talking at cross purposes here.  I'm not sure= which mail services you've used before, but every mail services I've us= ed with mail sharing allows you to share individual sub-mailboxes only.&= nbsp; I've been using JMAP in exactly that way, with individual notifica= tions folders shared to me from other accounts, and not the full content= s of those accounts.

So if we provide such examples and features in our protocol= s, perhaps
the implementors w= ould implement them, and perhaps then we can
actually make people to get some privacy...

Sharing individual folder is precisely what RFC3501 spec= ifies and RFC4314 expands on, and JMAP is duplicating that same pattern.=   I don't like the idea of changing the examples just because one r= eviewer has not personally experienced a use-case for a feature.  I= have never heard of a case of people feeling that their privacy is nega= tively impacted by the fact that there are ACLs on their mailboxes. = ; A server could easily provide backdoor access into data WITHOUT tellin= g users via the protocol, so as Barry said - not having that ability jus= t makes a less useful server, not an increase in privacy.

Regards,

Bron.
=

--
  Bron Go= ndwana, CEO, FastMail Pty Ltd
  b= rong@fastmailteam.com

=

--f800bcbd89b2475e9e7a25f195986367-- From nobody Mon Jan 7 18:54:38 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF51F130E76; Mon, 7 Jan 2019 18:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=wdk5fro2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ujouY7TQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQqRzuaehgBJ; Mon, 7 Jan 2019 18:54:34 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C12712D4EB; Mon, 7 Jan 2019 18:54:34 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5B91D22121; Mon, 7 Jan 2019 21:54:33 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 07 Jan 2019 21:54:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=6b4RKDgrT+BoEsocznT42ngk1 fKjwJ/wLg30YLinRsc=; b=wdk5fro2cGhjvhtv4cHv3D25KJMlymVeDvAlRVoYE JFVPwXr19LuO12PlIOEIBo0diVD3Z8Lwc/+AyMklSzYMfJEuG/RhP1ZANRbiRuLh 8o+BELZOrO3JDQOFbfxXPwppiXxWXtTI7sUFT1I+F8Eo8Ic0T2Svs4KIArU7eDBF fuPIew5BthM7Xvx7IrkeN+oJ8xtQq3M2FiL8wJCFkmS9Ir0zuLVldUP4lXD1hmtn s3j9fAhyz5bNQMqd0OTe2ctZC6NmW9gNvSER3OQPk2j3lVuR+pAC27fdwpebe368 6lcNwfodyutnSZH6BWKqn3dHAuGO+RcC/JrryuaodxslA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=6b4RKDgrT+BoEsocz nT42ngk1fKjwJ/wLg30YLinRsc=; b=ujouY7TQECjMuCRmgGmTMkiFk+O1zD4Gy aFhTn4WzNrg1qjVPDuzsHYSDVTriSsVJ2sWWz+69WpWxF2WDlg8CHvggwbZNmnHQ 6rFI1OBkK1aqQdG52WRlaP1Pi0p+IPDtH/BZQofAyB9id7boc5gmcyUzKnYnlWfl JPuticx4z/kLhhFTGyrcNh/V83fXZXQo240Ncaf4eP7I+H+aMUok33gxk4cDXUFD 5BjRDZfqHPj+QJVdExrFBtWUAtyJbjcS/XolSVhC9WXf8LpRVTDwKxlNV5YKg+VW PHH1nP3DW/AbV3ECFmF52fz8hGbd0yH4faYf0gdogGoJHG29AHTEA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdekgdehgeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne curfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdr tghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0B6E6203BE; Mon, 7 Jan 2019 21:54:33 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 64588216 Message-Id: In-Reply-To: <23603.21152.388621.403480@fireball.acr.fi> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <20190105185050.GB28515@kduck.kaduk.org> <23603.21152.388621.403480@fireball.acr.fi> Date: Mon, 07 Jan 2019 21:54:32 -0500 From: "Neil Jenkins" To: "Barry Leiba" , "Tero Kivinen" Cc: "Benjamin Kaduk" , "IETF JMAP Mailing List" , "Kurt Andersen (IETF)" , draft-ietf-jmap-core.all@ietf.org, iesg , secdir@ietf.org Content-Type: multipart/alternative; boundary=bfdcece0f01540669854ff55535653f2 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 02:54:36 -0000 --bfdcece0f01540669854ff55535653f2 Content-Type: text/plain On Tue, 8 Jan 2019, at 12:22 AM, Tero Kivinen wrote: > There is already huge difference in sharing mail and sharing > calendars. Most of the calendars support easy way of sharing only > limited set of data, i.e., you can mark entries as private where those > will not be shared out, or will be shared out only as "busy", i.e., > you can only see person is not available but not what calendar entry > is. > > In mailboxes we do not have that kind of features. One thing we could > suggest to implementors to allow sharing subfolders of the actual > account instead of full mailbox, Err, not sure what you're talking about here. Most email systems already support sharing on a per-folder (or *mailbox* as they're called in IMAP and JMAP) granularity. That's why JMAP and IMAP can return you a "myRights" object with your permissions for each mailbox. Calendars are identical; you generally share on a per-calendar basis (which acts the same as a mailbox for mail; a collection of individual data items). Neil. --bfdcece0f01540669854ff55535653f2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, 8 Jan 2= 019, at 12:22 AM, Tero Kivinen wrote:
There is already huge difference in sharing= mail and sharing
calendars. Most of the calendars support= easy way of sharing only
limited set of data, i.e., you c= an mark entries as private where those
will not be shared = out, or will be shared out only as "busy", i.e.,
you can o= nly see person is not available but not what calendar entry
is.

In mailboxes we do not have that kind= of features. One thing we could
suggest to implementors t= o allow sharing subfolders of the actual
account instead o= f full mailbox,

Err, not sure = what you're talking about here. Most email systems already support shari= ng on a per-folder (or mailbox as they're called in IMAP and JMAP= ) granularity. That's why JMAP and IMAP can return you a "myRights" obje= ct with your permissions for each mailbox. Calendars are identical; you = generally share on a per-calendar basis (which acts the same as a mailbo= x for mail; a collection of individual data items).

Neil.
--bfdcece0f01540669854ff55535653f2-- From nobody Mon Jan 7 19:42:44 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E961310A6; Mon, 7 Jan 2019 19:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=wHowMhW3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gWB6JYDA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15JuApIsRbet; Mon, 7 Jan 2019 19:42:33 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D66D1310A9; Mon, 7 Jan 2019 19:42:33 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9EEDF24667; Mon, 7 Jan 2019 22:42:32 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 07 Jan 2019 22:42:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=KGqT6qxaz7JMUM/+QKSHddOJ1 jCloi2BdoFe/V+stV8=; b=wHowMhW34C2izZ+tqkylnZDFCcsx1jLS9dYSeiwea ZN8IVv06iV8mwie0pI6Hqy9KLadcigw5x0kKwxt3aQGZMgEUsG5yCviZDghY4LQq E/8wgxAEWA8sGKQgGZFI7bWdtNQcLg0ZaqzZMCWowOnd2ZYRY4Z1mbnaSIaxjIvw e7Edw+T2vWrG7Y4na93tbSZ5tfEtm30MWFxrsL0ba0kI2Iv22heCgTomq23Gffdd YoxuYGHlj52NX8G6/c2+j7rqMwscQ8UQpzYm0NOgRt3eenQJ+C/+p9QN1UpwfHna OBFPKjm1TAflM9hBZ1DmMkNBr8VcPFEZGMr9LUXRumZiQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=KGqT6qxaz7JMUM/+Q KSHddOJ1jCloi2BdoFe/V+stV8=; b=gWB6JYDA53hw1FZbvMpjaKRupjHoE/tXU KhGb43NYsOWF4HDf/DQEeuCac+2SaI8alZ7WzyRRx93bzsGZeyozoj47Qup0wIID NmpgGg8YfQqkijhsV77M//8WONYWhEJFtYArOZbBDNB5l25UCFwESZ+OPjpqD0o7 BIA+TXlTKokKQ8TwAs5amVQzbr0pvlkRl3xxVzGboNKTi8SHsr/8z7Eaq0r7KT4S yvKkbHClz9YLzxFUrtTn6nwyKPv7JQHusvWgo80fLTXKmMn3Y4xDn8VkpzoIKd6a FRYXwZTbNFNCIc5i/Yly3/IlfUKYRzNNYQFhtQUlSyAspLpFMhgWQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdekgdeiheculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne curfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdr tghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 93B5F203BE; Mon, 7 Jan 2019 22:42:31 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 64588216 Message-Id: <77c37c56-a40a-4a52-95a0-553e63dc6a08@beta.fastmail.com> In-Reply-To: <01R1M7QIBP9I00004R@mauve.mrochek.com> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> Date: Mon, 07 Jan 2019 22:42:31 -0500 From: "Neil Jenkins" To: "Kurt Andersen (IETF)" , "Ned Freed" Cc: "Tero Kivinen" , "IETF JMAP Mailing List" , draft-ietf-jmap-core.all@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary=20b0ab2b3c2e4a4f907bd6c328212b8f Archived-At: Subject: Re: [secdir] [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 03:42:35 -0000 --20b0ab2b3c2e4a4f907bd6c328212b8f Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, 5 Jan 2019, at 9:10 AM, Ned Freed wrote: > I'll first note that although the JMAP specification refers to the IMA= P ACL > security model extensively, RFC 4314 is not in the references list. Th= at needs > to be fixed, Agreed, I have now added a reference to this. > and a note in the security considerations section saying that the > security considerations for IMAP ACLs apply to JMAP would also be good= . I've read through the security considerations section here and I don't a= ctually think any of them apply to JMAP; bear in mind the current spec d= oes not have any way to set ACLs, it just exposes the user's current rig= hts. (Setting ACLs is left to a future extension.) --- I have added the following section to the JMAP Core security considerati= ons: *8.8 Push traffic analysis* While the data is encrypted, a passive observer with the ability to moni= tor network traffic may be able to glean information from the timing of = push notifications. For example, suppose an email or calendar invitation= is sent from User A (hosted on Server X) to User B (hosted on Server Y)= . If Server X hosts data for many users, a passive observer can see that= the two servers connected but does not know who the data was for. Howev= er, if a push notification is immediately sent to User B and the attacke= r can observe this as well, they may reasonably conclude that someone on= Server X is connecting to User B. This can be partially mitigated by the JMAP server applying some random = jitter before sending out push notifications, however the jitter would h= ave to be small so as not to affect quality of service. This is also mit= igated inately on large services with high traffic flows hosting data fo= r many users, as it becomes much harder for an attacker to correlate inc= oming data events with outgoing push notifications, allowing users to =E2= =80=9Chide in the crowd=E2=80=9D. --- I await the conclusion on whether we should add a confirmation step to p= ush notifications, but other than that I don't believe there are any out= standing issues to address from this review. Please let me know if I've = missed something. Neil. --20b0ab2b3c2e4a4f907bd6c328212b8f Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Sat, 5 Jan 2= 019, at 9:10 AM, Ned Freed wrote:
I'll first note that although the JMAP specificat= ion refers to the IMAP ACL
security model extensively, RFC= 4314 is not in the references list. That needs
to be fixe= d,

Agreed, I have now added a = reference to this.

and a note in the security considerations sectio= n saying that the
security considerations for IMAP ACLs ap= ply to JMAP would also be good.

I've read through the security considerations section here and I don't= actually think any of them apply to JMAP; bear in mind the current spec= does not have any way to set ACLs, it just exposes the user's current r= ights. (Setting ACLs is left to a future extension.)

<= /div>
---

I have added the following se= ction to the JMAP Core security considerations:

=
8.8 Push traffic analysis

While= the data is encrypted, a passive observer with the ability to monitor n= etwork traffic may be able to glean information from the timing of push = notifications. For example, suppose an email or calendar invitation is s= ent from User A (hosted on Server X) to User B (hosted on Server Y). If = Server X hosts data for many users, a passive observer can see that the = two servers connected but does not know who the data was for. However, i= f a push notification is immediately sent to User B and the attacker can= observe this as well, they may reasonably conclude that someone on Serv= er X is connecting to User B.

This can be p= artially mitigated by the JMAP server applying some random jitter before= sending out push notifications, however the jitter would have to be sma= ll so as not to affect quality of service. This is also mitigated inatel= y on large services with high traffic flows hosting data for many users,= as it becomes much harder for an attacker to correlate incoming data ev= ents with outgoing push notifications, allowing users to =E2=80=9Chide i= n the crowd=E2=80=9D.

---
I await the conclusion on whether we should add a confirmati= on step to push notifications, but other than that I don't believe there= are any outstanding issues to address from this review. Please let me k= now if I've missed something.

Neil.
--20b0ab2b3c2e4a4f907bd6c328212b8f-- From nobody Mon Jan 7 20:14:12 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4522A1310A6 for ; Mon, 7 Jan 2019 20:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSiaT4i3uUmV for ; Mon, 7 Jan 2019 20:14:08 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 4E89512D4E7 for ; Mon, 7 Jan 2019 20:14:08 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx66.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ggimD-000Cb9-LY for secdir@ietf.org; Tue, 08 Jan 2019 05:14:06 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ggimA-0002rj-BU for secdir@ietf.org; Mon, 07 Jan 2019 23:14:03 -0500 Received: (qmail 7258 invoked from network); 8 Jan 2019 04:14:00 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.39]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 8 Jan 2019 04:14:00 -0000 To: JORDI PALET MARTINEZ , "STARK, BARBARA H" Cc: "v6ops@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Mon, 7 Jan 2019 20:13:58 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 168.144.250.230 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.26) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5iiHH+MW+amS96XrHYgInOZ602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzniiMFxnOFMHTZqw+apvQzTV/3OdXD2Xdo8CfrY5CQSnj88Owhl1aue+pxa11EFWoyz NJVaeAWax4WOe4pTBX2DwIE7VKe+bqpcdCns72R1myoI6HG8RgZGnUdJnKT7IqXe0Of4jddu9xC8 8+iQ5nb6BRFVjXUbiREH8mlR1JtPfYZ1V10x8j0kNETJD+nyXtcV2Hz37FuQUlYMDMlHwjIJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+1QmdZsu6 kxo/qWEj6Z1d7VIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdsewzRmhoeKlCpofGlp99T8RpJ5xYPZNRoOw1IxzkiGadCuy7H5hgdt+5 vcUfEdVaEfxl7B1QQuoPmRqW5R/J2U16th3iHXgtR+Y1L+Zzkg9a2/EwurjXBahe19+jBD7VuIee yrhzWminYO4gRGXn3bDVvCoqfGflxbtjudA02/m3s27IkHT4SMXRhQ/EkhkuGAO4aeVKjbQuc4NX lvv7E2xutplXFSLPWNAde/KcfYA5LyVL/f6KOJaZV6OtAP2Q+QBy2DNwOgV373pfDhBQ21OdM8gu ipSMnc4a1vOLkZpIf7UyEpcn4vR70ZwyprD5IJ34YaYZ30wD+IYKdMuYOSaM5ZxrRnRt4PqMzH3k 7hTkr8kPb2KLnZ2Xht3zA75VehhIcJfl9xjKxh+F8kIXLdZND3rjHB4Yc+TqdazcMI41sA2AfTJ2 5W/vzfaHf3wr2m4mbmeTgFKBgc4kmBS2brusOVZrHRzE6blhEo+mN1j1Fw== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [secdir] [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 04:14:10 -0000 On 1/7/2019 11:58 AM, JORDI PALET MARTINEZ wrote: > Hi Barbara, > > I agree with your regarding the WPA, not sure to understand the point f= rom Christian. > > If a local device is compromised, that happens in the LANs and this wil= l only affect the CE, if the "virus" or "bot" or whatever is able to comp= romise the CE configuration and then replace some of the settings done by= the provisioning system. > > This is something that may happen regardless of using DHCP in the WAN o= r other protocols. > > I recall having seen some TR-069 mechanism (maybe it was proprietary) t= o provide something related to access control security, but if it is not = standard, I will remove it. Let's see if someone in the list can provide = some info and I will also try to recall what was in the case I've in mind= =2E Maybe I was not clear. I am not overly concerned with what happens on the WAN side -- I assume that the ISP deploying customer premise devices will find a way to provision them securely. I am concerned that using DHCPv6 to provision networking parameters on the local hosts exposes these hosts to generic DHCP spoofing attacks. To mount the DHCP spoofing attacks, the attacker will need to either gain connectivity to the local network, or gain controlled of a local device. Access control protocols like 802.1x will prevent unauthorized devices from connecting to the local network; they will not close the second avenue of attack, something that solutions like DHCP guard would do. The local router can filter which packets are relayed between Wi-Fi devices, and can filter out spoofed DHCP packets. That's reasonably easy to deploy in small networks, where the only authorized DHCP server is located on the router itself. Of course, the current document is not meant as a general home router requirement draft -- it just specifies the narrow problem of how these routers should facilitate deployment of IPv4 as a service. I do like Jordi's succession to refer to DHCP Guard as a potential mitigation of DHCPv6 issues, because it can be deployed simply and it would thwart a series of potential attacks. I am less enthusiastic about 802.1x, because as I said above it addresses a fraction of the problem, but not the whole problem. Standard deployment of 802.1x requires an authentication server, which currently does not come with small routers. It also requires management of this authentication server, which is a tall order in these small networks. There have been attempts to define a simpler profile of 802.1x, in which all users have the same ID and the same password -- such as what is used in the IETF Wi-Fi networks. This does improve somewhat over the residential version of WPA, in which all users share the same "Wi-Fi password", because it provides better isolation between users. But I would have a hard time recommending 802.1x deployment in residential networks "because of DHCPv6 security". While I do like the "DHCP Guard" class of solutions, I am also concerned that the DHCP Guard concept is only defined by the commercial literature of some vendors -- and the same goes for DHCP Snooping, which could have a variety of meanings. If you want to use that term, then you should add a reference to the paper where this is defined. Or you could use neutral language, like: Considering that, networks using DHCPv6, depending on their specific topologies, should consider using access control mechanisms such as those based on IEEE-802.1X, and DHCPv6 filtering mechanisms designed to= prevent forwarding of spoofed DHCPv6 packets through the router, often referred to as "DHCP Guard." I am also skeptical of the mention of "SME" in the last paragraph, in "deployment of IPv4aaS in residential, SOHO and SME networks". The definition of what is a small or medium enterprise varies by countries. In the European Union, it is up to 250 employees. In the US, it is defined by revenues and employees limit, typically fewer than 500 employees. In other part of the world, it can be fewer than 50 employees, or maybe it is just defined by a limit on revenues. In any case, I would personally be reluctant to deploy simple devices like described in the draft in a network with 100 to 200 people, let alone 500. That would be pushing luck a bit too far. The introduction of the draft says "This document defines IPv4 service continuity features over an IPv6-only network, for a residential or small-office router..." I would suggest using exactly the same language, as in: As stated in the introduction, this document addresses deployment of IPv4aaS in residential or small-office networks. Deployment in more challenging environments would require additional security analysis. -- Christian Huitema From nobody Tue Jan 8 00:44:28 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BF51310F3; Tue, 8 Jan 2019 00:44:21 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWIcThuNzdrT; Tue, 8 Jan 2019 00:44:18 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4C3131102; Tue, 8 Jan 2019 00:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1546937054; x=1547541854; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=WpQTsSbxqLYLfXsxPD/b57tv5OkQwTE1wEfxivSAIkI=; b=jzgTh/cxbVE37 9OlpWTF9RzqivC8y2keW/jgiCaDU6Px9GtLTPT9rMmFckz6f+KKOCx9VTfpKd0fJ 22XwF3/5KwI7FzVCy1QjOODvP/ZLNJYJ4NTuJO6jRLhhQs/2gBt6AH90fy1zX+hd B+YhjfK9t6tprxSSNUFXOPNcQ12tJ4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 08 Jan 2019 09:44:14 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 08 Jan 2019 09:44:14 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006101437.msg; Tue, 08 Jan 2019 09:44:12 +0100 X-MDRemoteIP: 2001:470:1f09:495:78d5:b4a1:adaa:b67c X-MDHelo: [10.10.10.140] X-MDArrival-Date: Tue, 08 Jan 2019 09:44:12 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1911ba6fdf=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Tue, 08 Jan 2019 09:44:11 +0100 From: JORDI PALET MARTINEZ To: Christian Huitema , "STARK, BARBARA H" CC: "v6ops@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Message-ID: Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 08:44:21 -0000 Hi Christian, While I'm sympathetic with all what you said, this document is not adding/c= hanging anything regarding the LAN-side configuration related to DHCP, and = from that perspective, we refer to what is already required by RFC7084, whi= ch in turn calls to RFC6092. If I recall correctly, RFC6092 doesn't say anything about DHCP/RA security. I see SMEs with hundreds of employees, using this kind of routers connected= to 600 Mbps FTTH symmetric links (Spain, but I'm sure is the same case in = many other countries). However, in those cases, the router is only used a "= pure router", and there is a server(s) providing DHCP, NAT, firewall, etc.,= switches (which in many cases do DHCP-guard features as well as RA-Guard). The reason for it, is that those organizations don't have a "critical" need= to connect to internet (if it fails a few hours is not a problem, they don= 't host internal services to be accessed from Internet), or even it is much= cheaper to have 2 or 3 of those links (in Spain the cost is about 40 Euros= per month, including flat rate VoIP for national calls, any kind of failur= e needs to be fixed in a maximum of 24 hours, by law, while typically is le= ss than 8 hours) for backup/load balancing. If they choose a "corporate" link type, they will get a "business" router, = the link is the same (connecting to the same access/core infrastructure), j= ust they get a "promise" of a better SLA, but then they will need to pay 40= 0 Euros/month for the link. Anyway, I agree with the suggested changes, as it doesn't harm if we don't = explicitly say in the security section that the text is related to the LAN = or WAN side. Is up to the implementor in this case, to decide if they want = to offer a "better" CE firmware supporting those additional features. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: ietf en nombre de Christian Huitema Fecha: martes, 8 de enero de 2019, 6:04 Para: JORDI PALET MARTINEZ ,= "STARK, BARBARA H" CC: "v6ops@ietf.org" , "ietf@ietf.org" , "se= cdir@ietf.org" Asunto: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-i= pv4aas-12 =20 On 1/7/2019 11:58 AM, JORDI PALET MARTINEZ wrote: > Hi Barbara, > > I agree with your regarding the WPA, not sure to understand the point= from Christian. > > If a local device is compromised, that happens in the LANs and this w= ill only affect the CE, if the "virus" or "bot" or whatever is able to comp= romise the CE configuration and then replace some of the settings done by t= he provisioning system. > > This is something that may happen regardless of using DHCP in the WAN= or other protocols. > > I recall having seen some TR-069 mechanism (maybe it was proprietary)= to provide something related to access control security, but if it is not = standard, I will remove it. Let's see if someone in the list can provide so= me info and I will also try to recall what was in the case I've in mind. =20 Maybe I was not clear. I am not overly concerned with what happens on the WAN side -- I assume that the ISP deploying customer premise device= s will find a way to provision them securely. I am concerned that using DHCPv6 to provision networking parameters on the local hosts exposes these hosts to generic DHCP spoofing attacks. To mount the DHCP spoofin= g attacks, the attacker will need to either gain connectivity to the loca= l network, or gain controlled of a local device. Access control protocols like 802.1x will prevent unauthorized devices from connecting to the local network; they will not close the second avenue of attack, something that solutions like DHCP guard would do. =20 The local router can filter which packets are relayed between Wi-Fi devices, and can filter out spoofed DHCP packets. That's reasonably eas= y to deploy in small networks, where the only authorized DHCP server is located on the router itself. Of course, the current document is not meant as a general home router requirement draft -- it just specifies the narrow problem of how these routers should facilitate deployment of IPv4 as a service. I do like Jordi's succession to refer to DHCP Guard as a potential mitigation of DHCPv6 issues, because it can be deployed simply and it would thwart a series of potential attacks. =20 I am less enthusiastic about 802.1x, because as I said above it addresses a fraction of the problem, but not the whole problem. Standar= d deployment of 802.1x requires an authentication server, which currently does not come with small routers. It also requires management of this authentication server, which is a tall order in these small networks. There have been attempts to define a simpler profile of 802.1x, in whic= h all users have the same ID and the same password -- such as what is use= d in the IETF Wi-Fi networks. This does improve somewhat over the residential version of WPA, in which all users share the same "Wi-Fi password", because it provides better isolation between users. But I would have a hard time recommending 802.1x deployment in residential networks "because of DHCPv6 security". =20 While I do like the "DHCP Guard" class of solutions, I am also concerne= d that the DHCP Guard concept is only defined by the commercial literatur= e of some vendors -- and the same goes for DHCP Snooping, which could hav= e a variety of meanings. If you want to use that term, then you should ad= d a reference to the paper where this is defined. Or you could use neutra= l language, like: =20 Considering that, networks using DHCPv6, depending on their specific topologies, should consider using access control mechanisms such as those based on IEEE-802.1X, and DHCPv6 filtering mechanisms designed = to prevent forwarding of spoofed DHCPv6 packets through the router, ofte= n referred to as "DHCP Guard." =20 I am also skeptical of the mention of "SME" in the last paragraph, in "deployment of IPv4aaS in residential, SOHO and SME networks". The definition of what is a small or medium enterprise varies by countries. In the European Union, it is up to 250 employees. In the US, it is defined by revenues and employees limit, typically fewer than 500 employees. In other part of the world, it can be fewer than 50 employees, or maybe it is just defined by a limit on revenues. In any case, I would personally be reluctant to deploy simple devices like described in the draft in a network with 100 to 200 people, let alone 500. That would be pushing luck a bit too far. =20 The introduction of the draft says "This document defines IPv4 service continuity features over an IPv6-only network, for a residential or small-office router..." I would suggest using exactly the same language= , as in: =20 As stated in the introduction, this document addresses deployment of IPv4aaS in residential or small-office networks. Deployment in more challenging environments would require additional security analysis. =20 -- Christian Huitema =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Jan 8 00:49:31 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD221131047; Tue, 8 Jan 2019 00:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 939zNdOyOTDN; Tue, 8 Jan 2019 00:49:14 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3167D129B88; Tue, 8 Jan 2019 00:49:14 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 43YmCD20CMz8v8T; Tue, 8 Jan 2019 09:49:12 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 43YmCD0JCvzCqkc; Tue, 8 Jan 2019 09:49:12 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0415.000; Tue, 8 Jan 2019 09:49:11 +0100 From: To: Stewart Bryant , Phillip Hallam-Baker , "secdir@ietf.org" CC: "draft-ietf-rtgwg-spf-uloop-pb-statement.all@ietf.org" , "ietf@ietf.org" , "rtgwg@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-09 Thread-Index: AQHUpqOrlIzo84RMM0uZoVXfweW0vKWj+D+AgAEWX4A= Date: Tue, 8 Jan 2019 08:49:11 +0000 Message-ID: <8227_1546937352_5C346408_8227_283_1_9E32478DFA9976438E7A22F69B08FF924B78BD8B@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <154687749567.23321.13207113394828941966@ietfa.amsl.com> <62c9b5fb-5c03-0747-fa1e-a513118a35a8@gmail.com> In-Reply-To: <62c9b5fb-5c03-0747-fa1e-a513118a35a8@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF924B78BD8BOPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 08:49:17 -0000 --_000_9E32478DFA9976438E7A22F69B08FF924B78BD8BOPEXCLILMA4corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgZnVsbHkgYWdyZWUgd2l0aCB3aGF0IFN0ZXdhcnQgaGFzIG1lbnRpb25lZC4NClRo ZSBkb2N1bWVudCBkb2VzIG5vdCBpbnRyb2R1Y2UgYW55dGhpbmcgbmV3IHJlZ2FyZGluZyBtaWNy b2xvb3BzLg0KVGhlcmUgaXMgbm8gd2F5IGZvciBhbiBhdHRhY2tlciB0byB0cmlnZ2VyIGEgbWlj cm9sb29wIGV4Y2VwdCBieSBjcmVhdGluZyBzb21lIElHUCBldmVudHMgKGxpbmsgb3Igbm9kZSBk b3duIGZvciBleGFtcGxlKS4gSW4gYWRkaXRpb24sIHRoZXJlIHdpbGwgbmV2ZXIgYmUgYSBndWFy YW50ZWUgdGhhdCB0aGVyZSB3aWxsIGJlIGEgbWljcm9sb29wLg0KQWdhaW4gYXMgU3Rld2FydCBo YXMgbWVudGlvbmVkLCBpZiBzdWNoIGFuIGF0dGFja2VyIGNhbiBhY2Nlc3MgdG8gYSByb3V0ZXIg dG8gY3JlYXRlIElHUCBldmVudHMsIGl0IHdvdWxkIGJlIGVhc2llciBmb3IgaGltIHRvIGJyaW5n IHRoZSBuZXR3b3JrIGRvd24gKGVyYXNpbmcgcm91dGVyIGNvbmZpZywgY2hhbmdpbmcgY3JpdGlj YWwgcGFyYW1ldGVyc+KApikgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIHBsYXkgd2l0aCBtaWNyb2xv b3BzLg0KDQpCcmdkcywNCg0KDQpGcm9tOiBTdGV3YXJ0IEJyeWFudCBbbWFpbHRvOnN0ZXdhcnQu YnJ5YW50QGdtYWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAwNywgMjAxOSAxODowNQ0K VG86IFBoaWxsaXAgSGFsbGFtLUJha2VyOyBzZWNkaXJAaWV0Zi5vcmcNCkNjOiBkcmFmdC1pZXRm LXJ0Z3dnLXNwZi11bG9vcC1wYi1zdGF0ZW1lbnQuYWxsQGlldGYub3JnOyBpZXRmQGlldGYub3Jn OyBydGd3Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9m IGRyYWZ0LWlldGYtcnRnd2ctc3BmLXVsb29wLXBiLXN0YXRlbWVudC0wOQ0KDQoNCg0KT24gMDcv MDEvMjAxOSAxNjoxMSwgUGhpbGxpcCBIYWxsYW0tQmFrZXIgd3JvdGU6DQoNClJldmlld2VyOiBQ aGlsbGlwIEhhbGxhbS1CYWtlcg0KDQpSZXZpZXcgcmVzdWx0OiBIYXMgSXNzdWVzDQoNCg0KDQpU aGUgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBwcm9ibGVtIGFuZCBzb2x1dGlvbiBwcmV0dHkgY2xl YXJseS4gVW5mb3J0dW5hdGVseSwNCg0KdGhlcmUgaXMgbm8gZGlzY3Vzc2lvbiBvZiB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgd2hpY2ggaXMgbm90IGFwcHJvcHJpYXRlDQoNCmZvciBhIGRv Y3VtZW50IGFkZHJlc3NpbmcgYW4gYXZhaWxhYmlsaXR5IHdoaWNoIGlzIGEgc2VjdXJpdHkgaXNz dWUuDQoNCg0KDQpXaGlsZSBtaWNyb2xvb3BzIGNhbiBmb3JtIGJ5IGNoYW5jZSwgc29tZSBjb25z aWRlcmF0aW9uIHNob3VsZCBiZSBnaXZlbiB0byB0aGUNCg0KcG9zc2liaWxpdHkgdGhhdCBhbiBh dHRhY2tlciBjb3VsZCBpbmR1Y2UgYSBsb29wIHRvIHBlcmZvcm0gYSBEb1MgYXR0YWNrLg0KDQpJ biBzZWN0aW9uIDEgdGhlIHRleHQgc2F5czoNCg0KW1JGQzg0MDVdIGRlZmluZXMgYSBzb2x1dGlv biB0aGF0IHNhdGlzZmllcyB0aGlzIHByb2JsZW0gc3RhdGVtZW50DQoNCiAgIGFuZCB0aGlzIGRv Y3VtZW50IGNhcHR1cmVzIHRoZSByZWFzb25pbmcgb2YgdGhlIHByb3ZpZGVkIHNvbHV0aW9uLg0K DQpJdCBpcyBzYWZlIHRvIGFzc3VtZSB0aGF0IHRoZSByZWFkZXIgb2YgdGhpcyB0ZXh0IHdvdWxk IGhhdmUgcmVhZCBub3JtYXRpdmUgcmVmZXJlbmNlIFJGQzg0MDUgYW5kIHRodXMgd291bGQgYmUg ZnVsbHkgYXdhcmUgb2YgdGhlIHNlY3VyaXR5IGlzc3VlcyByZWxhdGVkIHRvIHRoZSBzb2x1dGlv biBiZWluZyBhbmFseXNlZC4NCg0KQW4gYXR0YWNrZXIgdGhhdCBoYWQgYWNjZXNzIHRvIGEgbmV0 d29yayBzdWNoIHRoYXQgdGhleSBjb3VsZCBpbmR1Y2UgbWljcm9sb29wcyB3b3VsZCBoYXZlIHRo ZSBhYmlsaXR5IHRvIGRvIG1hbnkgd29yc2UgdGhpbmdzIHRvIHRoZSBuZXR3b3JrLg0KDQpJZiB0 aGV5IHdlcmUgYWJsZSB0byBhdHRhY2sgaW4tYmFuZCB0aGV5IGNvdWxkIHBvaXNvbiB0aGUgcm91 dGluZyBzeXN0ZW0gdG8gdGFrZSBpdCBkb3duIGluIGZhciBtb3JlIGludGVyZXN0aW5nIHdheXMu IE9wZXJhdG9ycyB1c2Ugc2VjdXJpdHkgYXQgdGhlIHBoeXNpY2FsIGFuZCBuZXR3b3JrIGxheWVy IHRvIHByZXZlbnQgdGhpcy4NCg0KSWYgdGhleSB3ZXJlIG9wZXJhdGluZyBhdCB0aGUgcGh5c2lj YWwgbGF5ZXIgdGhlbiB0aGV5IGNvdWxkIHRha2UgY2lyY3VpdHMgZG93biBhdCB3aWxsIGFuZCBj YXVzZSBtaWNyb2xvb3BzIGluIHRoZSBiYXNlIHByb3RvY29sLCB0cmFmZmljIG92ZXJsb2FkcyBh bmQgYXBwbGljYXRpb24gbWFsZnVuY3Rpb24uDQoNClRodXMgaWYgdGhlIGF0dGFja2VyIGNvdWxk IGRlcGxveSBlaXRoZXIgb2YgdGhvc2UgYXR0YWNrcyBpbiBhIG5ldHdvcmsgdG8gaW5kdWNlIG1p Y3JvLWxvb3BzLCB0aGVuIGFueSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiB0aGlzIGRyYWZ0 IHdvdWxkIGNvdW50IGZvciBub3RoaW5nLg0KDQpUaGUgZHJhZnQgaXMgYW4gYW5hbHlzaXMsIGFu ZCB0aHVzIEkgdGhpbmsgdGhhdCBpdCBjb3JyZWN0bHkgc3RhdGVzIHRoYXQgaXQgaW50cm9kdWNl cyBubyBhZGRpdGlvbmFsIG1hdHRlcnMgZm9yIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24uDQoNCi0g U3Rld2FydA0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWly ZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVl cyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29w aWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jhbmdl IGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFu Z2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_9E32478DFA9976438E7A22F69B08FF924B78BD8BOPEXCLILMA4corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZv cm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkkgZnVsbHkgYWdyZWUgd2l0aCB3aGF0IFN0ZXdhcnQgaGFzIG1lbnRpb25lZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGRvY3VtZW50IGRvZXMgbm90IGludHJv ZHVjZSBhbnl0aGluZyBuZXcgcmVnYXJkaW5nIG1pY3JvbG9vcHMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoZXJlIGlzIG5vIHdheSBmb3IgYW4gYXR0YWNrZXIgdG8gdHJpZ2dlciBh IG1pY3JvbG9vcCBleGNlcHQgYnkgY3JlYXRpbmcgc29tZSBJR1AgZXZlbnRzIChsaW5rIG9yIG5v ZGUgZG93biBmb3IgZXhhbXBsZSkuIEluIGFkZGl0aW9uLCB0aGVyZSB3aWxsIG5ldmVyIGJlDQog YSBndWFyYW50ZWUgdGhhdCB0aGVyZSB3aWxsIGJlIGEgbWljcm9sb29wLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5BZ2FpbiBhcyBTdGV3YXJ0IGhhcyBtZW50aW9uZWQsIGlmIHN1Y2gg YW4gYXR0YWNrZXIgY2FuIGFjY2VzcyB0byBhIHJvdXRlciB0byBjcmVhdGUgSUdQIGV2ZW50cywg aXQgd291bGQgYmUgZWFzaWVyIGZvciBoaW0gdG8gYnJpbmcgdGhlIG5ldHdvcmsgZG93biAoZXJh c2luZw0KIHJvdXRlciBjb25maWcsIGNoYW5naW5nIGNyaXRpY2FsIHBhcmFtZXRlcnPigKYpIHJh dGhlciB0aGFuIHRyeWluZyB0byBwbGF5IHdpdGggbWljcm9sb29wcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJyZ2Rz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gU3Rld2FydCBCcnlhbnQgW21haWx0 bzpzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBK YW51YXJ5IDA3LCAyMDE5IDE4OjA1PGJyPg0KPGI+VG86PC9iPiBQaGlsbGlwIEhhbGxhbS1CYWtl cjsgc2VjZGlyQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC1pZXRmLXJ0Z3dnLXNwZi11 bG9vcC1wYi1zdGF0ZW1lbnQuYWxsQGlldGYub3JnOyBpZXRmQGlldGYub3JnOyBydGd3Z0BpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1ydGd3Zy1zcGYtdWxvb3AtcGItc3RhdGVtZW50LTA5PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gMDcvMDEvMjAxOSAxNjoxMSwgUGhpbGxpcCBIYWxsYW0tQmFrZXIgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5SZXZpZXdlcjogUGhpbGxpcCBIYWxsYW0t QmFrZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SZXZpZXcgcmVzdWx0OiBIYXMgSXNzdWVzPG86 cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhlIGRv Y3VtZW50IGRlc2NyaWJlcyB0aGUgcHJvYmxlbSBhbmQgc29sdXRpb24gcHJldHR5IGNsZWFybHku IFVuZm9ydHVuYXRlbHksPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhlcmUgaXMgbm8gZGlzY3Vz c2lvbiBvZiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgd2hpY2ggaXMgbm90IGFwcHJvcHJp YXRlPG86cD48L286cD48L3ByZT4NCjxwcmU+Zm9yIGEgZG9jdW1lbnQgYWRkcmVzc2luZyBhbiBh dmFpbGFiaWxpdHkgd2hpY2ggaXMgYSBzZWN1cml0eSBpc3N1ZS48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5XaGlsZSBtaWNyb2xvb3BzIGNhbiBm b3JtIGJ5IGNoYW5jZSwgc29tZSBjb25zaWRlcmF0aW9uIHNob3VsZCBiZSBnaXZlbiB0byB0aGU8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wb3NzaWJpbGl0eSB0aGF0IGFuIGF0dGFja2VyIGNvdWxk IGluZHVjZSBhIGxvb3AgdG8gcGVyZm9ybSBhIERvUyBhdHRhY2suPG86cD48L286cD48L3ByZT4N CjwvYmxvY2txdW90ZT4NCjxwPkluIHNlY3Rpb24gMSB0aGUgdGV4dCBzYXlzOjxvOnA+PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6OC4wcHQgOC4wcHQgOC4wcHQgOC4wcHQ7YmFja2dyb3Vu ZDojRkZGREY1Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDoj RkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluO2JveC1z aXppbmc6IGJvcmRlci1ib3g7b3ZlcmZsb3ctd3JhcDogYnJlYWstd29yZDtib3JkZXItcmFkaXVz OiA0cHg7Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7b3JwaGFuczogMjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOiBpbml0aWFsO3RleHQtZGVj b3JhdGlvbi1jb2xvcjogaW5pdGlhbDtvdmVyZmxvdzphdXRvO3dvcmQtc3BhY2luZzowcHgiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5bUkZDODQwNV0gZGVmaW5lcyBhIHNvbHV0aW9u IHRoYXQgc2F0aXNmaWVzIHRoaXMgcHJvYmxlbSBzdGF0ZW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1 O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IGFuZCB0aGlzIGRvY3VtZW50IGNhcHR1 cmVzIHRoZSByZWFzb25pbmcgb2YgdGhlIHByb3ZpZGVkIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPC9kaXY+DQo8cD5JdCBpcyBzYWZlIHRvIGFzc3VtZSB0aGF0IHRoZSByZWFk ZXIgb2YgdGhpcyB0ZXh0IHdvdWxkIGhhdmUgcmVhZCBub3JtYXRpdmUgcmVmZXJlbmNlIFJGQzg0 MDUgYW5kIHRodXMgd291bGQgYmUgZnVsbHkgYXdhcmUgb2YgdGhlIHNlY3VyaXR5IGlzc3VlcyBy ZWxhdGVkIHRvIHRoZSBzb2x1dGlvbiBiZWluZyBhbmFseXNlZC48bzpwPjwvbzpwPjwvcD4NCjxw PkFuIGF0dGFja2VyIHRoYXQgaGFkIGFjY2VzcyB0byBhIG5ldHdvcmsgc3VjaCB0aGF0IHRoZXkg Y291bGQgaW5kdWNlIG1pY3JvbG9vcHMgd291bGQgaGF2ZSB0aGUgYWJpbGl0eSB0byBkbyBtYW55 IHdvcnNlIHRoaW5ncyB0byB0aGUgbmV0d29yay48bzpwPjwvbzpwPjwvcD4NCjxwPklmIHRoZXkg d2VyZSBhYmxlIHRvIGF0dGFjayBpbi1iYW5kIHRoZXkgY291bGQgcG9pc29uIHRoZSByb3V0aW5n IHN5c3RlbSB0byB0YWtlIGl0IGRvd24gaW4gZmFyIG1vcmUgaW50ZXJlc3Rpbmcgd2F5cy4gT3Bl cmF0b3JzIHVzZSBzZWN1cml0eSBhdCB0aGUgcGh5c2ljYWwgYW5kIG5ldHdvcmsgbGF5ZXIgdG8g cHJldmVudCB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPHA+SWYgdGhleSB3ZXJlIG9wZXJhdGluZyBh dCB0aGUgcGh5c2ljYWwgbGF5ZXIgdGhlbiB0aGV5IGNvdWxkIHRha2UgY2lyY3VpdHMgZG93biBh dCB3aWxsIGFuZCBjYXVzZSBtaWNyb2xvb3BzIGluIHRoZSBiYXNlIHByb3RvY29sLCB0cmFmZmlj IG92ZXJsb2FkcyBhbmQgYXBwbGljYXRpb24gbWFsZnVuY3Rpb24uPG86cD48L286cD48L3A+DQo8 cD5UaHVzIGlmIHRoZSBhdHRhY2tlciBjb3VsZCBkZXBsb3kgZWl0aGVyIG9mIHRob3NlIGF0dGFj a3MgaW4gYSBuZXR3b3JrIHRvIGluZHVjZSBtaWNyby1sb29wcywgdGhlbiBhbnkgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgaW4gdGhpcyBkcmFmdCB3b3VsZCBjb3VudCBmb3Igbm90aGluZy48bzpw PjwvbzpwPjwvcD4NCjxwPlRoZSBkcmFmdCBpcyBhbiBhbmFseXNpcywgYW5kIHRodXMgSSB0aGlu ayB0aGF0IGl0IGNvcnJlY3RseSBzdGF0ZXMgdGhhdCBpdCBpbnRyb2R1Y2VzIG5vIGFkZGl0aW9u YWwgbWF0dGVycyBmb3Igc2VjdXJpdHkgY29uc2lkZXJhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxw Pi0gU3Rld2FydDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl cgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4K SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91 Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_9E32478DFA9976438E7A22F69B08FF924B78BD8BOPEXCLILMA4corp_-- From nobody Tue Jan 8 06:16:22 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D931276D0; Tue, 8 Jan 2019 06:16:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Montville To: Cc: spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154695697211.25494.5342366287090150478@ietfa.amsl.com> Date: Tue, 08 Jan 2019 06:16:12 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 14:16:12 -0000 Reviewer: Adam Montville Review result: Ready This draft is ready. It's a clever (though not foolproof) way to prime the pump for root certificate updates. I'm not an ASN.1 expert, so I can't really opine on the structure in Section 3, but from what I can tell it looks sane. Operational considerations seems sane. Security considerations rely on those from RFC5280, and additionally addresses: 1) analysis before the next-generation root certificate is released, 2) key strength considerations (equal or greater than current), 3) unforeseen cryptoanalytic advances, 4) typical hash pre-image attacks, and 5) early release of the next-generation public key. One area in the security considerations that could be enhanced is the recommended action to take in the case of an early next-generation public key release. The language in the draft states: "The second transition occurs when the Root CA is confident that the population of relying parties have completed the first transition, and it takes the Root CA to the freshly generated key pair." The question that came to mind was: What might bring about such confidence? I'm not sure that it's possible to generalize an answer to that question, however. Kind regards, Adam From nobody Tue Jan 8 06:28:25 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DCC1200B3; Tue, 8 Jan 2019 06:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qSKSJhTOo7i; Tue, 8 Jan 2019 06:28:14 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 E08F91200D7; Tue, 8 Jan 2019 06:28:13 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x08ES5gQ020863 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Jan 2019 16:28:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x08ES5QJ022217; Tue, 8 Jan 2019 16:28:05 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <23604.45941.279266.464196@fireball.acr.fi> Date: Tue, 8 Jan 2019 16:28:05 +0200 From: Tero Kivinen To: "Neil Jenkins" Cc: secdir@ietf.org, "Bron Gondwana" , "IETF JMAP Mailing List" , draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org In-Reply-To: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> <23603.20862.976183.378013@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 183 min X-Total-Time: 45 min Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 14:28:18 -0000 Neil Jenkins writes: > On Tue, 8 Jan 2019, at 12:17 AM, Tero Kivinen wrote: >=20 > Actually I think adding confirmation step will make the push > notifications more reliable, as that will give you positive feedb= ack > that your push notifications do work. >=20 > The issue is that push services (e.g. Apple's APNS and Google's FCM) = do not > guarantee that any particular push will be received. They normally wi= ll, but > may not, especially if the device goes offline for a while. So if you= r first > push doesn't make it through your push never works. It's likely to be= rare, but > painful when it happens and makes it feel unreliable. When you are subscribing the push notifications your devices should be running and not offline. Note, that you do not need reconfirmation if you extended the time, but only when new URL is given. If client gives url, it should make sure it can actually receive those notifications in the given url for few seconds...=20 > It is really annoying trying to debug which firewall / proxy / en= cryption > is causing the notification to be blocked, if I need to reregiste= r again > for every time and need to then somehow still cause one push noti= fication > to be sent before I can see does it work.=20 >=20 > I'm not sure what you're referring to here. Do you mean the JMAP (app= lication) > server connecting to the push server=3F Or the push server connecting= to the > client (which is not part of JMAP at all, but where you're more likel= y to run > into issues with corporate firewalls and the like)=3F Perhaps my understanding of the jmap push service is then wrong, or perhaps it is badly defined in JMAP.=20 > My understanding is that RFC8030 does not connect random urls, >=20 > My understanding is that is incorrect. There are three entities invol= ved in an > 8030 push system, and JMAP is only involved with two of them: >=20 > * The client, which wants to receive the push notifications (the JM= AP client) > * The application server which contains the data and wants to send = the push > notifications (the JMAP server)=20 > * The push server (3rd party, depends on the device what is possibl= e) But client and application server protocol is not defined in RFC8030. It is left outside the scope of that document. RFC8030 seems to only document interaction between the client and push service, and interaction between application and push service. The URL returned from the push service is somehow magically given to the application server and whatever verification happens there is not covered.=20 > The situation of the client/application server being one entity and t= he push > server being a completely unrelated entity is what 8030 is designed f= or. For > example, each browser implements the Push API, whereby if you have a = web app > you can ask the browser for a push subscription endpoint, then send i= t to your > application server to connect to. The application server does not kno= w in > advance which browser the user has or what domains that browser curre= ntly uses > for push subscriptions. It simply gets given an arbitrary URL to post= to. Looking at the text in jmap. It says in section 7.2: A push subscription is a message delivery context established betwee= n the client and a push service. Push service is not defined in this document, and it does not refer to RFC8030 for that term. My understanding was that push worked as follows: Client does PushSubscription as defined in 7.2 to JMAP server: Clients may create a push subscription on the JMAP server, which wil= l then make a POST request to the associated push endpoint whenever an= event occurs. This push subscription includes an url and when something happens the JMAP server will connect to that url and send some random garbage (from the receiver point of view if it does not assume receiveing push notications) to it using POST. If the receiver end is proper push service then it will notify the client using some other means. I.e., when email etc is received the JMAP server will then push StateChange object (section 7.1): When something changes on the server, the server pushes a *StateChange* object to the client. Actually that says "to the client" not to the "push service". Which one should it be=3F I always assumed this StateChange object is sent to= the url given in the PushSubscription. Hmm... and 7.2 then also uses term "push endpoint" which is not defined anywhere=3F Is that the same as push service at given url or something else: Clients may create a push subscription on the JMAP server, which wil= l then make a POST request to the associated push endpoint whenever an= event occurs. Then section 7.2 seems to also describe things not related to the PushSubscription but instead to the notifications sent by the JMAP server. Perhaps it would be better to move that to the StateChange object section, i.e., put all things related to the "push service" in same place. Now it is split in two places, i.e., StateChange is defined in section 7.1, but how to transmit that inside https POST with content type of application/json is described in 7.2. Also it is not clear which server this is talking about: =09=09=09=09=09=09=09The server is expected to understand and handle HTTP status responses in a reasonable manner. Is it push service server, JMAP server, Application server (same as JMAP server in this case=3F). My guess it is supposed to be JMAP server= which is actually acting as http-client and making https request to push service, and if push service returns http errors JMAP server acting as http-client will process those in reasonable manner. Is that understaning correct=3F Perhaps rewording it a bit to make it clear. Then I have no idea what this text is trying to say: The use of this push endpoint conforms with the use of a push endpoint by an Application Server as defined in [RFC8030]. what push endpoint=3F JMAP server=3F URL given by the client to JMAP server=3F=20 > JMAP is not defining anything new here. It is just defining the appli= cation > server portion exactly as expected by RFC8030. >=20 > the push notifications are received by client doing GET request t= o the > subscription server and then later server using server push to th= at > connection or something like that (in section 6 of the RFC8030). > Usually that is only way things can work, as most of the people a= re > behind firewalls / NATs / Proxies etc, thus connecting to them fr= om > outside is impossible or hard. >=20 > Yes, this is how the client receives the data from the push server in= RFC8030. > This is entirely orthogonal to what we are discussing though. >=20 > The interaction between UA and the Application server is using > "an application-specific method" =E2=80=A6 > The verification would be inside this application-specific method= , > thus it is not covered in the 8030 because of that. >=20 > Hmm, yes I see your point, although it seems odd for it not to mentio= n at all > given this is going to apply to pretty much every app that uses this = system; > not specifically JMAP. Most likely it is not describied in the RFC8030 because the details depends on the application server.=20 > but if server just answers HTTP ok 200 back, and JMAP server will= be > happy to keep sending notifications. >=20 > Yes, this is indeed a risk, and I agree that a confirmation step > would be the only way to mitigate this. I would expect it to be very easy to find urls in host that will return success to http posts with application/json and ignore contents. >=20 > Attacker can also do 10000 subscriptions to same victim (perhaps = using > different URLs, but destioned to same victim). It can do this > overnight, and then on the morning when someone triggers event th= e > victim will suddenly receive 10000 event notifications > (https-connections) from the well connected JMAP server farm, and= will > be completely swamped before it can even respond to any errors to= > those notifications. >=20 > I would expect the JMAP server to rate limit the number of push > subscriptions any one user may have to something considerably lower > than that. There is text saying frequency of pushes to be rate limited, but there is no limit for number of subscriptions account can have, or even suggestion that there should be limit. This kind of attacks can also use multiple accounts especially if there is some kind of public services available.=20 > If the attacker had compromised many accounts on the JMAP > server though, it could set up push subscriptions with each of them > but then it would have to coordinate making a change in each of > those accounts at the same time in order to flood the target server > with a large single burst of requests, which is a much harder thing > to do. As people pointed out we have imap server providing access to ietf mailing lists. There is lots of people on those lists, and even if we require datatracker account to be able to make subscriptions, making those accounts require just email address and ability to receive emails. Most likely datatracker allows creating accounts for: example+1@gmail.com example+2@gmail.com example+3@gmail.com ... example+99999@gmail.com and then making subscription for all of those accounts to all ietf mailing lists and sending notifications to same url x... Verification step would disable that attack vector too.=20 > Summing up, I think that adding a confirmation step removes a small > risk of being able to use a JMAP application server as a DDOS > vector, but adds a small risk of the push not being received and the > push system failing to establish. Actually I think it will make push system much more reliable, as it immediately verifies that the system is working, and you will not have silent failure, where you just notice few days later that I have not received any notifications, something must be broken. > (Although, the client would at least know this was the case so could > alert the user and give them the option to try again.) Would anyone > else like to weigh in on the relative merits of the options here to > help come to a consensus on the way forward=3F I would be particularl= y > interested to hear if this was discussed at all, and any conclusions > reached, in the development of RFC8030. --=20 kivinen@iki.fi From nobody Tue Jan 8 06:49:34 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFD1124C04; Tue, 8 Jan 2019 06:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lquTl9uVbM2T; Tue, 8 Jan 2019 06:49:17 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 578BE124BF6; Tue, 8 Jan 2019 06:49:17 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x08En3Sc005729 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Jan 2019 16:49:03 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x08En2Gh009000; Tue, 8 Jan 2019 16:49:02 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23604.47198.503637.521152@fireball.acr.fi> Date: Tue, 8 Jan 2019 16:49:02 +0200 From: Tero Kivinen To: "Neil Jenkins" Cc: "Barry Leiba" , "Benjamin Kaduk" , "IETF JMAP Mailing List" , "Kurt Andersen \(IETF\)" , draft-ietf-jmap-core.all@ietf.org, iesg , secdir@ietf.org In-Reply-To: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <20190105185050.GB28515@kduck.kaduk.org> <23603.21152.388621.403480@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 59 min X-Total-Time: 15 min Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 14:49:19 -0000 Neil Jenkins writes: > Err, not sure what you're talking about here. Most email systems > already support sharing on a per-folder (or mailbox as they're > called in IMAP and JMAP) granularity. I have no idea how to do that for example in gmail. The imap server I am running does not list support for 4314, and as I have never needed such feature I have never checked if or how it can be done. On the other hand I did not see any support for that in ipad or android mail software either (or it might be well hidden in those things, they are not very easy to use). > That's why JMAP and IMAP can return you a "myRights" object with > your permissions for each mailbox. Calendars are identical; you > generally share on a per-calendar basis (which acts the same as a > mailbox for mail; a collection of individual data items). Calendars usually have separate per item flag that tells whether event is private, i.e., it is not only per calendar or per mailbox level. Anyways, I have seen several cases where people share their personal calendars, I have not seen cases where people share their personal mailboxes. There cases where family members know other members passwords, and can login if needed. Also group mailboxes, or reading mail from multiple accounts in same mail software is very common, sharing private mail boxes not so. I.e., is it really common that: ... another user is sharing their mail with the logged in user,... when not talking about group (support etc) or role (secretary) based mail boxes? If so, I am happy that I live in places where people do value privacy, and I have not seen such things done... -- kivinen@iki.fi From nobody Tue Jan 8 09:15:11 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE69130F0B; Tue, 8 Jan 2019 09:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIAmrMs33CuS; Tue, 8 Jan 2019 09:15:02 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 540E7130F08; Tue, 8 Jan 2019 09:15:02 -0800 (PST) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x08H6vm1030116; Tue, 8 Jan 2019 12:14:56 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2pvxy9jeab-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Jan 2019 12:14:56 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x08HEswA025760; Tue, 8 Jan 2019 12:14:55 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x08HEoSR025670; Tue, 8 Jan 2019 12:14:50 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 176D040F6CE3; Tue, 8 Jan 2019 17:14:50 +0000 (GMT) Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (unknown [130.8.218.153]) by zlp30485.vci.att.com (Service) with ESMTPS id 0025340D4417; Tue, 8 Jan 2019 17:14:50 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0415.000; Tue, 8 Jan 2019 12:14:49 -0500 From: "STARK, BARBARA H" To: "'Christian Huitema'" , JORDI PALET MARTINEZ CC: "v6ops@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 Thread-Index: AQHUplIxzMK3YDjZl0aLw/nLjmGiN6Wj60wAgAAGJ4CAAHv9gP//vwTwgABhWgCAAIqGAIAAVx6w Date: Tue, 8 Jan 2019 17:14:49 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF88094@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.241] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-08_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=755 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901080139 Archived-At: Subject: Re: [secdir] [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 17:15:03 -0000 PiBNYXliZSBJIHdhcyBub3QgY2xlYXIuIEkgYW0gbm90IG92ZXJseSBjb25jZXJuZWQgd2l0aCB3 aGF0IGhhcHBlbnMgb24gdGhlDQo+IFdBTiBzaWRlIC0tIEkgYXNzdW1lIHRoYXQgdGhlIElTUCBk ZXBsb3lpbmcgY3VzdG9tZXIgcHJlbWlzZSBkZXZpY2VzIHdpbGwNCj4gZmluZCBhIHdheSB0byBw cm92aXNpb24gdGhlbSBzZWN1cmVseS4gSSBhbSBjb25jZXJuZWQgdGhhdCB1c2luZw0KPiBESENQ djYgdG8gcHJvdmlzaW9uIG5ldHdvcmtpbmcgcGFyYW1ldGVycyBvbiB0aGUgbG9jYWwgaG9zdHMg ZXhwb3Nlcw0KPiB0aGVzZSBob3N0cyB0byBnZW5lcmljIERIQ1Agc3Bvb2ZpbmcgYXR0YWNrcy4g VG8gbW91bnQgdGhlIERIQ1Agc3Bvb2ZpbmcNCj4gYXR0YWNrcywgdGhlIGF0dGFja2VyIHdpbGwg bmVlZCB0byBlaXRoZXIgZ2FpbiBjb25uZWN0aXZpdHkgdG8gdGhlIGxvY2FsDQo+IG5ldHdvcmss IG9yIGdhaW4gY29udHJvbGxlZCBvZiBhIGxvY2FsIGRldmljZS4gQWNjZXNzIGNvbnRyb2wgcHJv dG9jb2xzIGxpa2UNCj4gODAyLjF4IHdpbGwgcHJldmVudCB1bmF1dGhvcml6ZWQgZGV2aWNlcyBm cm9tIGNvbm5lY3RpbmcgdG8gdGhlIGxvY2FsDQo+IG5ldHdvcms7IHRoZXkgd2lsbCBub3QgY2xv c2UgdGhlIHNlY29uZCBhdmVudWUgb2YgYXR0YWNrLCBzb21ldGhpbmcgdGhhdA0KPiBzb2x1dGlv bnMgbGlrZSBESENQIGd1YXJkIHdvdWxkIGRvLg0KDQpJIGFncmVlIGNvbXBsZXRlbHkgdGhhdCA4 MDIuMVggaXMgaXJyZWxldmFudCB0byB0aGUgdHlwZXMgb2YgTEFOcyB0aGUgQ0Ugcm91dGVycyBk ZXNjcmliZWQgYnkgdGhpcyBkcmFmdCBhcmUgdXNlZCBpbiwgYW5kIHNob3VsZG4ndCBiZSBtZW50 aW9uZWQgaW4gcmVmZXJlbmNlIHRvIHRoZSBMQU4gaW50ZXJmYWNlcyBvZiB0aGVzZSBDRSByb3V0 ZXJzLg0KSG93ZXZlciwgSU1PLCB0aGUgc2VjdXJpdHkgc2VjdGlvbiBzaG91bGQgYmUgZGlzY3Vz c2luZyBzZWN1cml0eSBjb25jZXJucyB0aGF0IGFyaXNlIHNwZWNpZmljYWxseSBhcyBhIHJlc3Vs dCBvZiB0aGUgcmVxdWlyZW1lbnRzIGluIHRoZSBkcmFmdC4gQ29uY2VybnMgdGhhdCBhcmUgaW5k ZXBlbmRlbnQgb2YgdGhlc2UgcmVxdWlyZW1lbnRzIGFyZSBvdXQgb2Ygc2NvcGUuIEFGQUlDVCwg bm9uZSBvZiB0aGUgcmVxdWlyZW1lbnRzIGluIHRoaXMgZHJhZnQgY3JlYXRlL2VuYWJsZSBuZXcg dGhyZWF0cyBvciBhdHRhY2sgdmVjdG9ycyByZWxhdGVkIHRvIExBTiBESENQIHNwb29maW5nIGF0 dGFja3M7IHRoZXJlZm9yZSBMQU4gREhDUCBzcG9vZmluZyBhdHRhY2tzIChkaXNjdXNzaW5nIHRo ZW0gYW5kIHByb3Bvc2luZyBob3cgdG8gYWRkcmVzcyB0aGVtKSBhcmUgb3V0IG9mIHNjb3BlLg0K IA0KPiBUaGUgbG9jYWwgcm91dGVyIGNhbiBmaWx0ZXIgd2hpY2ggcGFja2V0cyBhcmUgcmVsYXll ZCBiZXR3ZWVuIFdpLUZpIGRldmljZXMsDQo+IGFuZCBjYW4gZmlsdGVyIG91dCBzcG9vZmVkIERI Q1AgcGFja2V0cy4gVGhhdCdzIHJlYXNvbmFibHkgZWFzeSB0byBkZXBsb3kgaW4NCj4gc21hbGwg bmV0d29ya3MsIHdoZXJlIHRoZSBvbmx5IGF1dGhvcml6ZWQgREhDUCBzZXJ2ZXIgaXMgbG9jYXRl ZCBvbiB0aGUNCj4gcm91dGVyIGl0c2VsZi4gT2YgY291cnNlLCB0aGUgY3VycmVudCBkb2N1bWVu dCBpcyBub3QgbWVhbnQgYXMgYSBnZW5lcmFsDQo+IGhvbWUgcm91dGVyIHJlcXVpcmVtZW50IGRy YWZ0IC0tIGl0IGp1c3Qgc3BlY2lmaWVzIHRoZSBuYXJyb3cgcHJvYmxlbSBvZiBob3cNCj4gdGhl c2Ugcm91dGVycyBzaG91bGQgZmFjaWxpdGF0ZSBkZXBsb3ltZW50IG9mDQo+IElQdjQgYXMgYSBz ZXJ2aWNlLiBJIGRvIGxpa2UgSm9yZGkncyBzdWNjZXNzaW9uIHRvIHJlZmVyIHRvIERIQ1AgR3Vh cmQgYXMgYQ0KPiBwb3RlbnRpYWwgbWl0aWdhdGlvbiBvZiBESENQdjYgaXNzdWVzLCBiZWNhdXNl IGl0IGNhbiBiZSBkZXBsb3llZCBzaW1wbHkgYW5kDQo+IGl0IHdvdWxkIHRod2FydCBhIHNlcmll cyBvZiBwb3RlbnRpYWwgYXR0YWNrcy4NCg0KSW50cmEtTEFOIHJvdXRpbmcvYnJpZGdpbmcvc3dp dGNoaW5nL2ZpbHRlcmluZy9yZWxheWluZyBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBkcmFmdC4g SW50cmEtTEFOIGJlaGF2aW9ycyBhcmUgbm90IHJlbGV2YW50IHRvIElQdjRhYVMuIFRoZXJlIGlz IG5vIG1lbnRpb24gb2YgTEFOLXNpZGUgREhDUHY2IChvciBESENQdjQpIGluIHRoZSBkcmFmdC4g QWxsIG1lbnRpb24gb2YgREhDUHY2IGlzIFdBTiBpbnRlcmZhY2UgREhDUHY2IGNsaWVudCBiZWhh dmlvci4gREhDUCh2NikgZ3VhcmQgaXNuJ3QgYSBjbGllbnQgYmVoYXZpb3IuIEkgZG9uJ3QgbGlr ZSBKb3JkaSdzIHN1Z2dlc3RlZCB0ZXh0LCBiZWNhdXNlICgxKSBhcyBhIFdBTiBiZWhhdmlvciAo d2hpY2ggaXMgaG93IG1vc3QgcGVvcGxlIHdpbGwgaW50ZXJwcmV0IGl0KSBESENQIGd1YXJkIG1h a2VzIG5vIHNlbnNlLCBhbmQgKDIpIGFzIGEgTEFOIGJlaGF2aW9yIGl0J3Mgb3V0IG9mIHNjb3Bl LiANCg0KPiBJIGFtIGxlc3MgZW50aHVzaWFzdGljIGFib3V0IDgwMi4xeCwgYmVjYXVzZSBhcyBJ IHNhaWQgYWJvdmUgaXQgYWRkcmVzc2VzIGENCj4gZnJhY3Rpb24gb2YgdGhlIHByb2JsZW0sIGJ1 dCBub3QgdGhlIHdob2xlIHByb2JsZW0uIFN0YW5kYXJkIGRlcGxveW1lbnQgb2YNCj4gODAyLjF4 IHJlcXVpcmVzIGFuIGF1dGhlbnRpY2F0aW9uIHNlcnZlciwgd2hpY2ggY3VycmVudGx5IGRvZXMg bm90IGNvbWUgd2l0aA0KPiBzbWFsbCByb3V0ZXJzLiBJdCBhbHNvIHJlcXVpcmVzIG1hbmFnZW1l bnQgb2YgdGhpcyBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIsDQo+IHdoaWNoIGlzIGEgdGFsbCBvcmRl ciBpbiB0aGVzZSBzbWFsbCBuZXR3b3Jrcy4NCj4gVGhlcmUgaGF2ZSBiZWVuIGF0dGVtcHRzIHRv IGRlZmluZSBhIHNpbXBsZXIgcHJvZmlsZSBvZiA4MDIuMXgsIGluIHdoaWNoIGFsbA0KPiB1c2Vy cyBoYXZlIHRoZSBzYW1lIElEIGFuZCB0aGUgc2FtZSBwYXNzd29yZCAtLSBzdWNoIGFzIHdoYXQg aXMgdXNlZCBpbiB0aGUNCj4gSUVURiBXaS1GaSBuZXR3b3Jrcy4gVGhpcyBkb2VzIGltcHJvdmUg c29tZXdoYXQgb3ZlciB0aGUgcmVzaWRlbnRpYWwNCj4gdmVyc2lvbiBvZiBXUEEsIGluIHdoaWNo IGFsbCB1c2VycyBzaGFyZSB0aGUgc2FtZSAiV2ktRmkgcGFzc3dvcmQiLCBiZWNhdXNlDQo+IGl0 IHByb3ZpZGVzIGJldHRlciBpc29sYXRpb24gYmV0d2VlbiB1c2Vycy4gQnV0IEkgd291bGQgaGF2 ZSBhIGhhcmQgdGltZQ0KPiByZWNvbW1lbmRpbmcgODAyLjF4IGRlcGxveW1lbnQgaW4gcmVzaWRl bnRpYWwgbmV0d29ya3MgImJlY2F1c2Ugb2YNCj4gREhDUHY2IHNlY3VyaXR5Ii4NCj4gDQo+IFdo aWxlIEkgZG8gbGlrZSB0aGUgIkRIQ1AgR3VhcmQiIGNsYXNzIG9mIHNvbHV0aW9ucywgSSBhbSBh bHNvIGNvbmNlcm5lZCB0aGF0DQo+IHRoZSBESENQIEd1YXJkIGNvbmNlcHQgaXMgb25seSBkZWZp bmVkIGJ5IHRoZSBjb21tZXJjaWFsIGxpdGVyYXR1cmUgb2YNCj4gc29tZSB2ZW5kb3JzIC0tIGFu ZCB0aGUgc2FtZSBnb2VzIGZvciBESENQIFNub29waW5nLCB3aGljaCBjb3VsZCBoYXZlIGENCj4g dmFyaWV0eSBvZiBtZWFuaW5ncy4gSWYgeW91IHdhbnQgdG8gdXNlIHRoYXQgdGVybSwgdGhlbiB5 b3Ugc2hvdWxkIGFkZCBhDQo+IHJlZmVyZW5jZSB0byB0aGUgcGFwZXIgd2hlcmUgdGhpcyBpcyBk ZWZpbmVkLiBPciB5b3UgY291bGQgdXNlIG5ldXRyYWwNCj4gbGFuZ3VhZ2UsIGxpa2U6DQo+IA0K PiAgIENvbnNpZGVyaW5nIHRoYXQsIG5ldHdvcmtzIHVzaW5nIERIQ1B2NiwgZGVwZW5kaW5nIG9u IHRoZWlyIHNwZWNpZmljDQo+ICAgdG9wb2xvZ2llcywgc2hvdWxkIGNvbnNpZGVyIHVzaW5nIGFj Y2VzcyBjb250cm9sIG1lY2hhbmlzbXMgc3VjaCBhcw0KPiAgIHRob3NlIGJhc2VkIG9uIElFRUUt ODAyLjFYLCBhbmQgREhDUHY2IGZpbHRlcmluZyBtZWNoYW5pc21zIGRlc2lnbmVkIHRvDQo+ICAg cHJldmVudCBmb3J3YXJkaW5nIG9mIHNwb29mZWQgREhDUHY2IHBhY2tldHMgdGhyb3VnaCB0aGUg cm91dGVyLCBvZnRlbg0KPiAgIHJlZmVycmVkIHRvIGFzICJESENQIEd1YXJkLiINCg0KVGhlcmUg YXJlIG5vIGV4cGVjdGF0aW9ucyBleHByZXNzZWQgZWl0aGVyIGluIHRoaXMgZHJhZnQgb3IgUkZD IDcwODQgKHdoaWNoIHRoaXMgZHJhZnQgYnVpbGRzIHVwb24pIHRoYXQgdGhlIENFIHJvdXRlciBt aWdodCBiZSBmb3J3YXJkaW5nIChvciByZWxheWluZykgREhDUHY2IHBhY2tldHMgdGhyb3VnaCB0 aGUgcm91dGVyLiBSRkMgNzA4NCByZXF1aXJlcyB0aGUgQ0Ugcm91dGVyIHRvIGhhdmUgaXRzIG93 biBXQU4tZmFjaW5nIERIQ1B2NiBjbGllbnQuIElmIGl0IHdhbnRzIHRvIHN1cHBvcnQgYW55IHNv cnQgb2YgTEFOLXNpZGUgREhDUHY2LCBpdCBTSE9VTEQgaGF2ZSBhIERIQ1B2NiBzZXJ2ZXIuIE5v dGhpbmcgYWJvdXQgZm9yd2FyZGluZyBvciByZWxheWluZy4gQWdhaW4sIEkgY29udGVuZCB0aGF0 IGRpc2N1c3NpbmcgREhDUCBHdWFyZCBpbiB0aGUgU2VjdXJpdHkgc2VjdGlvbiBpcyBvdXQgb2Yg c2NvcGUuDQoNCkJhcmJhcmENCg0KPiBJIGFtIGFsc28gc2tlcHRpY2FsIG9mIHRoZSBtZW50aW9u IG9mICJTTUUiIGluIHRoZSBsYXN0IHBhcmFncmFwaCwgaW4NCj4gImRlcGxveW1lbnQgb2YgSVB2 NGFhUyBpbiByZXNpZGVudGlhbCwgU09ITyBhbmQgU01FIG5ldHdvcmtzIi4gVGhlDQo+IGRlZmlu aXRpb24gb2Ygd2hhdCBpcyBhIHNtYWxsIG9yIG1lZGl1bSBlbnRlcnByaXNlIHZhcmllcyBieSBj b3VudHJpZXMuDQo+IEluIHRoZSBFdXJvcGVhbiBVbmlvbiwgaXQgaXMgdXAgdG8gMjUwIGVtcGxv eWVlcy4gSW4gdGhlIFVTLCBpdCBpcyBkZWZpbmVkIGJ5DQo+IHJldmVudWVzIGFuZCBlbXBsb3ll ZXMgbGltaXQsIHR5cGljYWxseSBmZXdlciB0aGFuIDUwMCBlbXBsb3llZXMuIEluIG90aGVyDQo+ IHBhcnQgb2YgdGhlIHdvcmxkLCBpdCBjYW4gYmUgZmV3ZXIgdGhhbiA1MCBlbXBsb3llZXMsIG9y IG1heWJlIGl0IGlzIGp1c3QNCj4gZGVmaW5lZCBieSBhIGxpbWl0IG9uIHJldmVudWVzLiBJbiBh bnkgY2FzZSwgSSB3b3VsZCBwZXJzb25hbGx5IGJlIHJlbHVjdGFudCB0bw0KPiBkZXBsb3kgc2lt cGxlIGRldmljZXMgbGlrZSBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0IGluIGEgbmV0d29yayB3aXRo IDEwMCB0byAyMDANCj4gcGVvcGxlLCBsZXQgYWxvbmUgNTAwLiBUaGF0IHdvdWxkIGJlIHB1c2hp bmcgbHVjayBhIGJpdCB0b28gZmFyLg0KPiANCj4gVGhlIGludHJvZHVjdGlvbiBvZiB0aGUgZHJh ZnQgc2F5cyAiVGhpcyBkb2N1bWVudCBkZWZpbmVzIElQdjQgc2VydmljZQ0KPiBjb250aW51aXR5 IGZlYXR1cmVzIG92ZXIgYW4gSVB2Ni1vbmx5IG5ldHdvcmssIGZvciBhIHJlc2lkZW50aWFsIG9y IHNtYWxsLQ0KPiBvZmZpY2Ugcm91dGVyLi4uIiBJIHdvdWxkIHN1Z2dlc3QgdXNpbmcgZXhhY3Rs eSB0aGUgc2FtZSBsYW5ndWFnZSwgYXMgaW46DQo+IA0KPiAgIEFzIHN0YXRlZCBpbiB0aGUgaW50 cm9kdWN0aW9uLCB0aGlzIGRvY3VtZW50IGFkZHJlc3NlcyBkZXBsb3ltZW50IG9mDQo+ICAgSVB2 NGFhUyBpbiByZXNpZGVudGlhbCBvciBzbWFsbC1vZmZpY2UgbmV0d29ya3MuICBEZXBsb3ltZW50 IGluIG1vcmUNCj4gICBjaGFsbGVuZ2luZyBlbnZpcm9ubWVudHMgd291bGQgcmVxdWlyZSBhZGRp dGlvbmFsIHNlY3VyaXR5IGFuYWx5c2lzLg0KPiANCj4gLS0gQ2hyaXN0aWFuIEh1aXRlbWENCj4g DQo+IA0KDQo= From nobody Tue Jan 8 09:22:37 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D61130F0B; Tue, 8 Jan 2019 09:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWAIxI9tmppO; Tue, 8 Jan 2019 09:22:35 -0800 (PST) Received: from mauve.mrochek.com (unknown [66.159.242.17]) (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 CFD56130F08; Tue, 8 Jan 2019 09:22:34 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1RITPR28000DL4N@mauve.mrochek.com>; Tue, 8 Jan 2019 09:16:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1546967843; bh=YlmX2BSOFsNN3GP6rqL6fsCWlPdXnoDAor4nhcv9/LY=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=K/5tbu6n+deV3YKpbscIujqHwySaZpKv33Yqmgm/NfzAAlWeQjXCjKx4Pq/WUH9wI Y+2dvBXkkjBgGsWPwNWdIHqnqbLs8XC/clJOmjsGaYE6fIunu/BApYzzU9dOSwqaid PqhocFAch1HMjE5o/5+Qa/ehvnHJx7o2NksvAOAw= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=UTF-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com>; Tue, 8 Jan 2019 09:16:43 -0800 (PST) Cc: Ned Freed , IETF JMAP Mailing List , "Kurt Andersen (IETF)" , Tero Kivinen , Tony Finch , draft-ietf-jmap-core.all@ietf.org, secdir@ietf.org Message-id: <01R1RITKNL3G00004L@mauve.mrochek.com> Date: Tue, 08 Jan 2019 08:04:29 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 08 Jan 2019 07:46:36 +0800" References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> <01R1Q3OA5O7800004L@mauve.mrochek.com> To: Barry Leiba Archived-At: Subject: Re: [secdir] [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 17:22:36 -0000 > Hm. I don’t see that. All you get in response to the IDLE command is the > same stuff you get from the NOOP command or from any other IMAP command: > untagged FETCH and EXPUNGE responses. If IDLE was the same as NOOP then we wouldn't have added the IDLE command to the protocol. > Technically, they’re not actually > responses to the command: they’re unsolicited messages in the IMAP protocol. It's right there in the abstract: The Internet Message Access Protocol [IMAP4] requires a client to poll the server for changes to the selected mailbox (new mail, deletions). It's often more desirable to have the server transmit updates to the client in real time. This allows a user to see new mail immediately. It also helps some real-time applications based on IMAP, which might otherwise need to poll extremely often (such as every few seconds). (While the spec actually does allow a server to push EXISTS responses aysynchronously, a client can't expect this behaviour and must poll.) Note the last sentence: If accepted IDLE requires that the server return changes in mailbox state in real time. That opens the door to certain types of traffic analysis. Now, since the protocol does allow EXISTS responses to be pushed regardless of IDLE, you can include RFC 3501 in having deficient security considerations in this regard. The fact remains that there's a missing security consideration here. > What security considerations should there be for IDLE that are beyond those > for NOOP (that is, IMAP itself? NOOP is pull and done at the client's discretion, IDLE is push and triggered by server changes. Ned From nobody Tue Jan 8 09:40:11 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74C3130F28 for ; Tue, 8 Jan 2019 09:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zHE12BtM-is for ; Tue, 8 Jan 2019 09:40:07 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C078D130F27 for ; Tue, 8 Jan 2019 09:40:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 610EA300AA2 for ; Tue, 8 Jan 2019 12:15:31 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id J9PEYMsd-RPu for ; Tue, 8 Jan 2019 12:15:29 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 4743F30005C; Tue, 8 Jan 2019 12:15:29 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <154695697211.25494.5342366287090150478@ietfa.amsl.com> Date: Tue, 8 Jan 2019 12:33:45 -0500 Cc: IETF SecDir , spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF Content-Transfer-Encoding: quoted-printable Message-Id: <38C4C1A8-42E9-4F50-B4F1-356909D81AC9@vigilsec.com> References: <154695697211.25494.5342366287090150478@ietfa.amsl.com> To: Adam Montville X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 17:40:09 -0000 > On Jan 8, 2019, at 9:16 AM, Adam Montville = wrote: >=20 > Reviewer: Adam Montville > Review result: Ready >=20 > This draft is ready. It's a clever (though not foolproof) way to prime = the pump > for root certificate updates. I'm not an ASN.1 expert, so I can't = really opine > on the structure in Section 3, but from what I can tell it looks sane. > Operational considerations seems sane. Security considerations rely on = those > from RFC5280, and additionally addresses: 1) analysis before the > next-generation root certificate is released, 2) key strength = considerations > (equal or greater than current), 3) unforeseen cryptoanalytic = advances, 4) > typical hash pre-image attacks, and 5) early release of the = next-generation > public key. >=20 > One area in the security considerations that could be enhanced is the > recommended action to take in the case of an early next-generation = public key > release. The language in the draft states: "The second transition = occurs when > the Root CA is confident that the population of relying parties have = completed > the first transition, and it takes the Root CA to the freshly = generated key > pair." The question that came to mind was: What might bring about such > confidence? I'm not sure that it's possible to generalize an answer to = that > question, however. Adam: Thanks for the review. I can assure you that I compiled the ASN.1 module. This paragraph is the result of the discussion in the LAMPS WG session = in London. The timing is not that critical if the oldWithNew and = newWithOld advice from RFC 2510 (updated to RFC 4210) is followed. This = is talked about in Section 5 on "Operational Considerations". I have an = update to the paragraph in Section 5 based on other comments: Guidance on the transition from one trust anchor to another is available in Section 4.4 of [RFC4210]. In particular, the oldWithNew and newWithOld advice ensures that relying parties are able to validate certificates issued under the current Root CA certificate and the next generation Root CA certificate throughout the transition. Further, this advice avoids the need for all relying parties to make the transition at the same time. Russ From nobody Tue Jan 8 10:38:53 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82B6130F7B; Tue, 8 Jan 2019 10:38:44 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9NQsfahmUCS; Tue, 8 Jan 2019 10:38:41 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42B2130F7C; Tue, 8 Jan 2019 10:38:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1546972717; x=1547577517; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=NWHTAjpB3qgF9RIdvIm5gVBi9kigqLV1nQcvxISA548=; b=icgLx3vD/73Ik WT7CVo/UcuZ9ZZns2kOxZOqfqJ5NvwGfSfNi6X/x5j/bCmYYR/+KGWCk56wNU99i deV5XjFB4/9ZDJd0Y3ZufA7O/91l9f8DIAy3FB03jKGdqgdjlV0mMAhm+Cfrakcn JLalSVriJ1TkIMzpDKPdEDJdkAXXYY= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 08 Jan 2019 19:38:37 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 08 Jan 2019 19:38:36 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006102125.msg; Tue, 08 Jan 2019 19:38:34 +0100 X-MDRemoteIP: 2001:470:1f09:495:3c42:f3de:5da6:6fc4 X-MDHelo: [10.10.10.140] X-MDArrival-Date: Tue, 08 Jan 2019 19:38:34 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1911ba6fdf=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Tue, 08 Jan 2019 19:38:30 +0100 From: JORDI PALET MARTINEZ To: "STARK, BARBARA H" , 'Christian Huitema' CC: "v6ops@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Message-ID: Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF88094@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF88094@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 18:38:45 -0000 Hi Barbara, The security concerns raised *initially* by Christian were related to the u= se of DHCP for configuring the WAN. At least that was what I understood. Th= en we continued discussing about the LAN, which I agree with you, is not a = requirement on this document. I guess the right way to approach this will be to update RFC6092 with new m= inimum security requirements, but this is out of the scope of this thread. This is what I'm proposing, making sure that we are speaking about the DHCP= v6 requirements from this document, but at the same time remembering that t= he LAN side is also important (but not in the scope of this document): 8. Security Considerations The IPv6 Transition CE Router must comply with the Security Considerations as stated in [RFC7084], as well as those stated by each transition mechanism implemented by the IPv6 Transition CE Router. As described in [RFC8026] and [RFC8415] Security Consideration sections, there are generic DHCP security issues, which in the case of this document means that malicious nodes may alter the priority of the transition mechanisms. Considering that, networks using DHCPv6 as indicated in this document,= =20 depending on their specific topologies, should consider using access control mechanisms such as those based on IEEE-802.1X, and DHCPv6 filtering mechanisms designed to prevent forwarding of spoofed DHCPv6 packets to the IPv6 Transition CE, often referred to as "DHCP Guard". Those can be used as well, in the=20 LAN side, but this is out of the scope of this document. As stated in the introduction, this document addresses deployment of IPv4aaS in residential or SOHO networks. Deployment in more challenging environments would require additional security analysis. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de "STARK, BARBARA H" Fecha: martes, 8 de enero de 2019, 18:16 Para: 'Christian Huitema' , JORDI PALET MARTINEZ CC: "v6ops@ietf.org" , "ietf@ietf.org" , "se= cdir@ietf.org" Asunto: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-i= pv4aas-12 > Maybe I was not clear. I am not overly concerned with what happens on= the > WAN side -- I assume that the ISP deploying customer premise devices = will > find a way to provision them securely. I am concerned that using > DHCPv6 to provision networking parameters on the local hosts exposes > these hosts to generic DHCP spoofing attacks. To mount the DHCP spoof= ing > attacks, the attacker will need to either gain connectivity to the lo= cal > network, or gain controlled of a local device. Access control protoco= ls like > 802.1x will prevent unauthorized devices from connecting to the local > network; they will not close the second avenue of attack, something t= hat > solutions like DHCP guard would do. =20 I agree completely that 802.1X is irrelevant to the types of LANs the C= E routers described by this draft are used in, and shouldn't be mentioned i= n reference to the LAN interfaces of these CE routers. However, IMO, the security section should be discussing security concer= ns that arise specifically as a result of the requirements in the draft. Co= ncerns that are independent of these requirements are out of scope. AFAICT,= none of the requirements in this draft create/enable new threats or attack= vectors related to LAN DHCP spoofing attacks; therefore LAN DHCP spoofing = attacks (discussing them and proposing how to address them) are out of scop= e. =20 > The local router can filter which packets are relayed between Wi-Fi d= evices, > and can filter out spoofed DHCP packets. That's reasonably easy to de= ploy in > small networks, where the only authorized DHCP server is located on t= he > router itself. Of course, the current document is not meant as a gene= ral > home router requirement draft -- it just specifies the narrow problem= of how > these routers should facilitate deployment of > IPv4 as a service. I do like Jordi's succession to refer to DHCP Guar= d as a > potential mitigation of DHCPv6 issues, because it can be deployed sim= ply and > it would thwart a series of potential attacks. =20 Intra-LAN routing/bridging/switching/filtering/relaying is out of scope= of this draft. Intra-LAN behaviors are not relevant to IPv4aaS. There is n= o mention of LAN-side DHCPv6 (or DHCPv4) in the draft. All mention of DHCPv= 6 is WAN interface DHCPv6 client behavior. DHCP(v6) guard isn't a client be= havior. I don't like Jordi's suggested text, because (1) as a WAN behavior = (which is how most people will interpret it) DHCP guard makes no sense, and= (2) as a LAN behavior it's out of scope.=20 =20 > I am less enthusiastic about 802.1x, because as I said above it addre= sses a > fraction of the problem, but not the whole problem. Standard deployme= nt of > 802.1x requires an authentication server, which currently does not co= me with > small routers. It also requires management of this authentication ser= ver, > which is a tall order in these small networks. > There have been attempts to define a simpler profile of 802.1x, in wh= ich all > users have the same ID and the same password -- such as what is used = in the > IETF Wi-Fi networks. This does improve somewhat over the residential > version of WPA, in which all users share the same "Wi-Fi password", b= ecause > it provides better isolation between users. But I would have a hard t= ime > recommending 802.1x deployment in residential networks "because of > DHCPv6 security". >=20 > While I do like the "DHCP Guard" class of solutions, I am also concer= ned that > the DHCP Guard concept is only defined by the commercial literature o= f > some vendors -- and the same goes for DHCP Snooping, which could have= a > variety of meanings. If you want to use that term, then you should ad= d a > reference to the paper where this is defined. Or you could use neutra= l > language, like: >=20 > Considering that, networks using DHCPv6, depending on their specifi= c > topologies, should consider using access control mechanisms such as > those based on IEEE-802.1X, and DHCPv6 filtering mechanisms designe= d to > prevent forwarding of spoofed DHCPv6 packets through the router, of= ten > referred to as "DHCP Guard." =20 There are no expectations expressed either in this draft or RFC 7084 (w= hich this draft builds upon) that the CE router might be forwarding (or rel= aying) DHCPv6 packets through the router. RFC 7084 requires the CE router t= o have its own WAN-facing DHCPv6 client. If it wants to support any sort of= LAN-side DHCPv6, it SHOULD have a DHCPv6 server. Nothing about forwarding = or relaying. Again, I contend that discussing DHCP Guard in the Security se= ction is out of scope. =20 Barbara =20 > I am also skeptical of the mention of "SME" in the last paragraph, in > "deployment of IPv4aaS in residential, SOHO and SME networks". The > definition of what is a small or medium enterprise varies by countrie= s. > In the European Union, it is up to 250 employees. In the US, it is de= fined by > revenues and employees limit, typically fewer than 500 employees. In = other > part of the world, it can be fewer than 50 employees, or maybe it is = just > defined by a limit on revenues. In any case, I would personally be re= luctant to > deploy simple devices like described in the draft in a network with 1= 00 to 200 > people, let alone 500. That would be pushing luck a bit too far. >=20 > The introduction of the draft says "This document defines IPv4 servic= e > continuity features over an IPv6-only network, for a residential or s= mall- > office router..." I would suggest using exactly the same language, as= in: >=20 > As stated in the introduction, this document addresses deployment o= f > IPv4aaS in residential or small-office networks. Deployment in mor= e > challenging environments would require additional security analysis= . >=20 > -- Christian Huitema >=20 >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Jan 8 11:28:58 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58423130FE1; Tue, 8 Jan 2019 11:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKe2qmqsiLfj; Tue, 8 Jan 2019 11:28:52 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 C5CE2130FD7; Tue, 8 Jan 2019 11:28:47 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x08JPmmE000967; Tue, 8 Jan 2019 14:28:34 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2pw0wh2asm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Jan 2019 14:28:33 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x08JSWrN014604; Tue, 8 Jan 2019 14:28:33 -0500 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x08JSMDc014339; Tue, 8 Jan 2019 14:28:23 -0500 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 4122E4048B5B; Tue, 8 Jan 2019 19:28:22 +0000 (GMT) Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (unknown [130.8.218.150]) by zlp30486.vci.att.com (Service) with ESMTPS id 22F744048B58; Tue, 8 Jan 2019 19:28:22 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0415.000; Tue, 8 Jan 2019 14:28:21 -0500 From: "STARK, BARBARA H" To: "'JORDI PALET MARTINEZ'" , "'Christian Huitema'" CC: "v6ops@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 Thread-Index: AQHUplIxzMK3YDjZl0aLw/nLjmGiN6Wj60wAgAAGJ4CAAHv9gP//vwTwgABhWgCAAIqGAIAAVx6wgACabgD//7QMIA== Date: Tue, 8 Jan 2019 19:28:20 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF886D9@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF88094@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.241] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-08_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901080153 Archived-At: Subject: Re: [secdir] [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 19:28:56 -0000 PiBUaGUgc2VjdXJpdHkgY29uY2VybnMgcmFpc2VkICppbml0aWFsbHkqIGJ5IENocmlzdGlhbiB3 ZXJlIHJlbGF0ZWQgdG8gdGhlIHVzZSBvZg0KPiBESENQIGZvciBjb25maWd1cmluZyB0aGUgV0FO LiBBdCBsZWFzdCB0aGF0IHdhcyB3aGF0IEkgdW5kZXJzdG9vZC4gVGhlbiB3ZQ0KPiBjb250aW51 ZWQgZGlzY3Vzc2luZyBhYm91dCB0aGUgTEFOLCB3aGljaCBJIGFncmVlIHdpdGggeW91LCBpcyBu b3QgYQ0KPiByZXF1aXJlbWVudCBvbiB0aGlzIGRvY3VtZW50Lg0KPiANCj4gSSBndWVzcyB0aGUg cmlnaHQgd2F5IHRvIGFwcHJvYWNoIHRoaXMgd2lsbCBiZSB0byB1cGRhdGUgUkZDNjA5MiB3aXRo IG5ldw0KPiBtaW5pbXVtIHNlY3VyaXR5IHJlcXVpcmVtZW50cywgYnV0IHRoaXMgaXMgb3V0IG9m IHRoZSBzY29wZSBvZiB0aGlzIHRocmVhZC4NCj4gDQo+IFRoaXMgaXMgd2hhdCBJJ20gcHJvcG9z aW5nLCBtYWtpbmcgc3VyZSB0aGF0IHdlIGFyZSBzcGVha2luZyBhYm91dCB0aGUNCj4gREhDUHY2 IHJlcXVpcmVtZW50cyBmcm9tIHRoaXMgZG9jdW1lbnQsIGJ1dCBhdCB0aGUgc2FtZSB0aW1lDQo+ IHJlbWVtYmVyaW5nIHRoYXQgdGhlIExBTiBzaWRlIGlzIGFsc28gaW1wb3J0YW50IChidXQgbm90 IGluIHRoZSBzY29wZSBvZiB0aGlzDQo+IGRvY3VtZW50KToNCj4gDQo+IDguICBTZWN1cml0eSBD b25zaWRlcmF0aW9ucw0KPiANCj4gICAgVGhlIElQdjYgVHJhbnNpdGlvbiBDRSBSb3V0ZXIgbXVz dCBjb21wbHkgd2l0aCB0aGUgU2VjdXJpdHkNCj4gICAgQ29uc2lkZXJhdGlvbnMgYXMgc3RhdGVk IGluIFtSRkM3MDg0XSwgYXMgd2VsbCBhcyB0aG9zZSBzdGF0ZWQgYnkNCj4gICAgZWFjaCB0cmFu c2l0aW9uIG1lY2hhbmlzbSBpbXBsZW1lbnRlZCBieSB0aGUgSVB2NiBUcmFuc2l0aW9uIENFDQo+ ICAgIFJvdXRlci4NCj4gDQo+ICAgIEFzIGRlc2NyaWJlZCBpbiBbUkZDODAyNl0gYW5kIFtSRkM4 NDE1XSBTZWN1cml0eSBDb25zaWRlcmF0aW9uDQo+ICAgIHNlY3Rpb25zLCB0aGVyZSBhcmUgZ2Vu ZXJpYyBESENQIHNlY3VyaXR5IGlzc3Vlcywgd2hpY2ggaW4gdGhlIGNhc2UNCj4gICAgb2YgdGhp cyBkb2N1bWVudCBtZWFucyB0aGF0IG1hbGljaW91cyBub2RlcyBtYXkgYWx0ZXIgdGhlIHByaW9y aXR5IG9mDQo+ICAgIHRoZSB0cmFuc2l0aW9uIG1lY2hhbmlzbXMuDQo+IA0KPiAgICBDb25zaWRl cmluZyB0aGF0LCBuZXR3b3JrcyB1c2luZyBESENQdjYgYXMgaW5kaWNhdGVkIGluIHRoaXMgZG9j dW1lbnQsDQo+ICAgIGRlcGVuZGluZyBvbiB0aGVpciBzcGVjaWZpYyB0b3BvbG9naWVzLCBzaG91 bGQgY29uc2lkZXIgdXNpbmcgYWNjZXNzDQo+ICAgIGNvbnRyb2wgbWVjaGFuaXNtcyBzdWNoIGFz IHRob3NlIGJhc2VkIG9uIElFRUUtODAyLjFYLCBhbmQNCj4gICAgREhDUHY2IGZpbHRlcmluZyBt ZWNoYW5pc21zIGRlc2lnbmVkIHRvIHByZXZlbnQgZm9yd2FyZGluZw0KPiAgICBvZiBzcG9vZmVk IERIQ1B2NiBwYWNrZXRzIHRvIHRoZSBJUHY2IFRyYW5zaXRpb24gQ0UsIG9mdGVuDQo+ICAgIHJl ZmVycmVkIHRvIGFzICJESENQIEd1YXJkIi4gVGhvc2UgY2FuIGJlIHVzZWQgYXMgd2VsbCwgaW4g dGhlDQo+ICAgIExBTiBzaWRlLCBidXQgdGhpcyBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoaXMg ZG9jdW1lbnQuDQo+DQo+ICAgIEFzIHN0YXRlZCBpbiB0aGUgaW50cm9kdWN0aW9uLCB0aGlzIGRv Y3VtZW50IGFkZHJlc3NlcyBkZXBsb3ltZW50IG9mDQo+ICAgIElQdjRhYVMgaW4gcmVzaWRlbnRp YWwgb3IgU09ITyBuZXR3b3Jrcy4gIERlcGxveW1lbnQgaW4gbW9yZQ0KPiAgICBjaGFsbGVuZ2lu ZyBlbnZpcm9ubWVudHMgd291bGQgcmVxdWlyZSBhZGRpdGlvbmFsIHNlY3VyaXR5IGFuYWx5c2lz Lg0KDQoNCkhvdyBhY2Nlc3MgbmV0d29ya3Mgc2VjdXJlIHRoZWlyIGluZnJhc3RydWN0dXJlIGlz IHNwZWNpZmljIHRvIHRoYXQgYWNjZXNzIG5ldHdvcmsncyBhcmNoaXRlY3R1cmUuIEFjY2VzcyBu ZXR3b3JrIGFyY2hpdGVjdHVyZXMgYXJlIHNwZWNpZmllZCBieSBvcmdzIHN1Y2ggYXMgM0dQUCwg Q2FibGVMYWJzLCBhbmQgQkJGLiBJbiB0aGUgY29udGV4dCBvZiBzb21lIGFjY2VzcyBuZXR3b3Jr IGFyY2hpdGVjdHVyZXMsIDgwMi4xWCBpcyBub3QgdGhlIHNvbHV0aW9uIHRoYXQgaXMgdXNlZCwg YW5kIElFVEYgc2hvdWxkbid0IGJlIHN1Z2dlc3RpbmcgdGhleSB1c2UgaXQuIEknbSBub3QgYXdh cmUgb2YgYW55IHRoYXQgdXNlICJESENQdjYgZmlsdGVyaW5nIG1lY2hhbmlzbXMiIG9yICJESENQ IEd1YXJkIi4gTW9zdCB0ZW5kIHRvIHVzZSBtdWNoIG1vcmUgZXh0cmVtZSBzZXBhcmF0aW9uIG9m IGN1c3RvbWVyIHRyYWZmaWMuIEFuZCBpZiBhbiBJU1AncyBvd24gbWFuYWdlZCBuZXR3b3JrIGVs ZW1lbnRzIGFyZSBjb21wcm9taXNlZCwgIkRIQ1AgR3VhcmQiIGlzIG5vdCB0aGUgYW5zd2VyIC0t IGlkZW50aWZ5aW5nIHRoZSBjb21wcm9taXNlZCBuZXR3b3JrIGVsZW1lbnQgYW5kIHJlbW92aW5n IGl0IGZyb20gdGhlIG5ldHdvcmsgaXMgdGhlIGFuc3dlci4gV2hpY2ggbWFrZXMgdGhpcyByZWNv bW1lbmRhdGlvbiBpbGxvZ2ljYWwgYW5kIGluYXBwcm9wcmlhdGUuIEFjY2VzcyBuZXR3b3JrIGFy Y2hpdGVjdHVyZSBpcyBub3QgaW4gc2NvcGUgb2YgdGhpcyBkcmFmdC4gSWYgeW91IHJlYWxseSB3 YW50IHRoZSBwYXJhZ3JhcGggYWJvdXQgZ2VuZXJpYyBESENQIHNlY3VyaXR5IGlzc3VlcywgSSB3 b3VsZCBzdWdnZXN0IGFkZGluZyBzb21ldGhpbmcgbGlrZSB0aGlzIGF0IHRoZSBlbmQ6ICJBY2Nl c3MgbmV0d29yayBhcmNoaXRlY3R1cmUgZm9yIHNlY3VyaW5nIERIQ1Agd2l0aGluIHRoZSBhY2Nl c3MgbmV0d29yayBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gU2VjdXJpbmcgREhD UCBpbiB0aGUgTEFOIGlzIGFsc28gbm90IGluIHNjb3BlLiBESENQIHBhY2tldHMgTVVTVCBOT1Qg YmUgZm9yd2FyZGVkIGJldHdlZW4gTEFOIGFuZCBXQU4gaW50ZXJmYWNlcyBvZiBhbiBJUHY2IFRy YW5zaXRpb24gQ0Ugcm91dGVyLiIgQW5kIGRlbGV0ZSB0aGUgbGFzdCAyIHBhcmFncmFwaHMuDQpC YXJiYXJhDQoNCj4gUmVnYXJkcywNCj4gSm9yZGkNCj4gDQo+IA0KPiANCj4g77u/LS0tLS1NZW5z YWplIG9yaWdpbmFsLS0tLS0NCj4gRGU6IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBl biBub21icmUgZGUgIlNUQVJLLCBCQVJCQVJBIEgiDQo+IDxiczc2NTJAYXR0LmNvbT4NCj4gRmVj aGE6IG1hcnRlcywgOCBkZSBlbmVybyBkZSAyMDE5LCAxODoxNg0KPiBQYXJhOiAnQ2hyaXN0aWFu IEh1aXRlbWEnIDxodWl0ZW1hQGh1aXRlbWEubmV0PiwgSk9SREkgUEFMRVQgTUFSVElORVoNCj4g PGpvcmRpLnBhbGV0PTQwY29uc3VsaW50ZWwuZXNAZG1hcmMuaWV0Zi5vcmc+DQo+IENDOiAidjZv cHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4sICJpZXRmQGlldGYub3JnIiA8aWV0ZkBpZXRm Lm9yZz4sDQo+ICJzZWNkaXJAaWV0Zi5vcmciIDxzZWNkaXJAaWV0Zi5vcmc+DQo+IEFzdW50bzog UmU6IFt2Nm9wc10gU2VjZGlyIHRlbGVjaGF0IHJldmlldyBvZiBkcmFmdC1pZXRmLXY2b3BzLXRy YW5zaXRpb24tDQo+IGlwdjRhYXMtMTINCj4gDQo+ICAgICA+IE1heWJlIEkgd2FzIG5vdCBjbGVh ci4gSSBhbSBub3Qgb3Zlcmx5IGNvbmNlcm5lZCB3aXRoIHdoYXQgaGFwcGVucyBvbg0KPiB0aGUN Cj4gICAgID4gV0FOIHNpZGUgLS0gSSBhc3N1bWUgdGhhdCB0aGUgSVNQIGRlcGxveWluZyBjdXN0 b21lciBwcmVtaXNlIGRldmljZXMNCj4gd2lsbA0KPiAgICAgPiBmaW5kIGEgd2F5IHRvIHByb3Zp c2lvbiB0aGVtIHNlY3VyZWx5LiBJIGFtIGNvbmNlcm5lZCB0aGF0IHVzaW5nDQo+ICAgICA+IERI Q1B2NiB0byBwcm92aXNpb24gbmV0d29ya2luZyBwYXJhbWV0ZXJzIG9uIHRoZSBsb2NhbCBob3N0 cyBleHBvc2VzDQo+ICAgICA+IHRoZXNlIGhvc3RzIHRvIGdlbmVyaWMgREhDUCBzcG9vZmluZyBh dHRhY2tzLiBUbyBtb3VudCB0aGUgREhDUA0KPiBzcG9vZmluZw0KPiAgICAgPiBhdHRhY2tzLCB0 aGUgYXR0YWNrZXIgd2lsbCBuZWVkIHRvIGVpdGhlciBnYWluIGNvbm5lY3Rpdml0eSB0byB0aGUg bG9jYWwNCj4gICAgID4gbmV0d29yaywgb3IgZ2FpbiBjb250cm9sbGVkIG9mIGEgbG9jYWwgZGV2 aWNlLiBBY2Nlc3MgY29udHJvbCBwcm90b2NvbHMgbGlrZQ0KPiAgICAgPiA4MDIuMXggd2lsbCBw cmV2ZW50IHVuYXV0aG9yaXplZCBkZXZpY2VzIGZyb20gY29ubmVjdGluZyB0byB0aGUgbG9jYWwN Cj4gICAgID4gbmV0d29yazsgdGhleSB3aWxsIG5vdCBjbG9zZSB0aGUgc2Vjb25kIGF2ZW51ZSBv ZiBhdHRhY2ssIHNvbWV0aGluZyB0aGF0DQo+ICAgICA+IHNvbHV0aW9ucyBsaWtlIERIQ1AgZ3Vh cmQgd291bGQgZG8uDQo+IA0KPiAgICAgSSBhZ3JlZSBjb21wbGV0ZWx5IHRoYXQgODAyLjFYIGlz IGlycmVsZXZhbnQgdG8gdGhlIHR5cGVzIG9mIExBTnMgdGhlIENFDQo+IHJvdXRlcnMgZGVzY3Jp YmVkIGJ5IHRoaXMgZHJhZnQgYXJlIHVzZWQgaW4sIGFuZCBzaG91bGRuJ3QgYmUgbWVudGlvbmVk IGluDQo+IHJlZmVyZW5jZSB0byB0aGUgTEFOIGludGVyZmFjZXMgb2YgdGhlc2UgQ0Ugcm91dGVy cy4NCj4gICAgIEhvd2V2ZXIsIElNTywgdGhlIHNlY3VyaXR5IHNlY3Rpb24gc2hvdWxkIGJlIGRp c2N1c3Npbmcgc2VjdXJpdHkgY29uY2VybnMNCj4gdGhhdCBhcmlzZSBzcGVjaWZpY2FsbHkgYXMg YSByZXN1bHQgb2YgdGhlIHJlcXVpcmVtZW50cyBpbiB0aGUgZHJhZnQuIENvbmNlcm5zDQo+IHRo YXQgYXJlIGluZGVwZW5kZW50IG9mIHRoZXNlIHJlcXVpcmVtZW50cyBhcmUgb3V0IG9mIHNjb3Bl LiBBRkFJQ1QsIG5vbmUNCj4gb2YgdGhlIHJlcXVpcmVtZW50cyBpbiB0aGlzIGRyYWZ0IGNyZWF0 ZS9lbmFibGUgbmV3IHRocmVhdHMgb3IgYXR0YWNrIHZlY3RvcnMNCj4gcmVsYXRlZCB0byBMQU4g REhDUCBzcG9vZmluZyBhdHRhY2tzOyB0aGVyZWZvcmUgTEFOIERIQ1Agc3Bvb2ZpbmcgYXR0YWNr cw0KPiAoZGlzY3Vzc2luZyB0aGVtIGFuZCBwcm9wb3NpbmcgaG93IHRvIGFkZHJlc3MgdGhlbSkg YXJlIG91dCBvZiBzY29wZS4NCj4gDQo+ICAgICA+IFRoZSBsb2NhbCByb3V0ZXIgY2FuIGZpbHRl ciB3aGljaCBwYWNrZXRzIGFyZSByZWxheWVkIGJldHdlZW4gV2ktRmkNCj4gZGV2aWNlcywNCj4g ICAgID4gYW5kIGNhbiBmaWx0ZXIgb3V0IHNwb29mZWQgREhDUCBwYWNrZXRzLiBUaGF0J3MgcmVh c29uYWJseSBlYXN5IHRvDQo+IGRlcGxveSBpbg0KPiAgICAgPiBzbWFsbCBuZXR3b3Jrcywgd2hl cmUgdGhlIG9ubHkgYXV0aG9yaXplZCBESENQIHNlcnZlciBpcyBsb2NhdGVkIG9uIHRoZQ0KPiAg ICAgPiByb3V0ZXIgaXRzZWxmLiBPZiBjb3Vyc2UsIHRoZSBjdXJyZW50IGRvY3VtZW50IGlzIG5v dCBtZWFudCBhcyBhIGdlbmVyYWwNCj4gICAgID4gaG9tZSByb3V0ZXIgcmVxdWlyZW1lbnQgZHJh ZnQgLS0gaXQganVzdCBzcGVjaWZpZXMgdGhlIG5hcnJvdyBwcm9ibGVtIG9mDQo+IGhvdw0KPiAg ICAgPiB0aGVzZSByb3V0ZXJzIHNob3VsZCBmYWNpbGl0YXRlIGRlcGxveW1lbnQgb2YNCj4gICAg ID4gSVB2NCBhcyBhIHNlcnZpY2UuIEkgZG8gbGlrZSBKb3JkaSdzIHN1Y2Nlc3Npb24gdG8gcmVm ZXIgdG8gREhDUCBHdWFyZCBhcyBhDQo+ICAgICA+IHBvdGVudGlhbCBtaXRpZ2F0aW9uIG9mIERI Q1B2NiBpc3N1ZXMsIGJlY2F1c2UgaXQgY2FuIGJlIGRlcGxveWVkIHNpbXBseQ0KPiBhbmQNCj4g ICAgID4gaXQgd291bGQgdGh3YXJ0IGEgc2VyaWVzIG9mIHBvdGVudGlhbCBhdHRhY2tzLg0KPiAN Cj4gICAgIEludHJhLUxBTiByb3V0aW5nL2JyaWRnaW5nL3N3aXRjaGluZy9maWx0ZXJpbmcvcmVs YXlpbmcgaXMgb3V0IG9mIHNjb3BlIG9mDQo+IHRoaXMgZHJhZnQuIEludHJhLUxBTiBiZWhhdmlv cnMgYXJlIG5vdCByZWxldmFudCB0byBJUHY0YWFTLiBUaGVyZSBpcyBubw0KPiBtZW50aW9uIG9m IExBTi1zaWRlIERIQ1B2NiAob3IgREhDUHY0KSBpbiB0aGUgZHJhZnQuIEFsbCBtZW50aW9uIG9m IERIQ1B2Ng0KPiBpcyBXQU4gaW50ZXJmYWNlIERIQ1B2NiBjbGllbnQgYmVoYXZpb3IuIERIQ1Ao djYpIGd1YXJkIGlzbid0IGEgY2xpZW50DQo+IGJlaGF2aW9yLiBJIGRvbid0IGxpa2UgSm9yZGkn cyBzdWdnZXN0ZWQgdGV4dCwgYmVjYXVzZSAoMSkgYXMgYSBXQU4gYmVoYXZpb3INCj4gKHdoaWNo IGlzIGhvdyBtb3N0IHBlb3BsZSB3aWxsIGludGVycHJldCBpdCkgREhDUCBndWFyZCBtYWtlcyBu byBzZW5zZSwgYW5kDQo+ICgyKSBhcyBhIExBTiBiZWhhdmlvciBpdCdzIG91dCBvZiBzY29wZS4N Cj4gDQo+ICAgICA+IEkgYW0gbGVzcyBlbnRodXNpYXN0aWMgYWJvdXQgODAyLjF4LCBiZWNhdXNl IGFzIEkgc2FpZCBhYm92ZSBpdCBhZGRyZXNzZXMgYQ0KPiAgICAgPiBmcmFjdGlvbiBvZiB0aGUg cHJvYmxlbSwgYnV0IG5vdCB0aGUgd2hvbGUgcHJvYmxlbS4gU3RhbmRhcmQNCj4gZGVwbG95bWVu dCBvZg0KPiAgICAgPiA4MDIuMXggcmVxdWlyZXMgYW4gYXV0aGVudGljYXRpb24gc2VydmVyLCB3 aGljaCBjdXJyZW50bHkgZG9lcyBub3QgY29tZQ0KPiB3aXRoDQo+ICAgICA+IHNtYWxsIHJvdXRl cnMuIEl0IGFsc28gcmVxdWlyZXMgbWFuYWdlbWVudCBvZiB0aGlzIGF1dGhlbnRpY2F0aW9uIHNl cnZlciwNCj4gICAgID4gd2hpY2ggaXMgYSB0YWxsIG9yZGVyIGluIHRoZXNlIHNtYWxsIG5ldHdv cmtzLg0KPiAgICAgPiBUaGVyZSBoYXZlIGJlZW4gYXR0ZW1wdHMgdG8gZGVmaW5lIGEgc2ltcGxl ciBwcm9maWxlIG9mIDgwMi4xeCwgaW4gd2hpY2gNCj4gYWxsDQo+ICAgICA+IHVzZXJzIGhhdmUg dGhlIHNhbWUgSUQgYW5kIHRoZSBzYW1lIHBhc3N3b3JkIC0tIHN1Y2ggYXMgd2hhdCBpcyB1c2Vk IGluDQo+IHRoZQ0KPiAgICAgPiBJRVRGIFdpLUZpIG5ldHdvcmtzLiBUaGlzIGRvZXMgaW1wcm92 ZSBzb21ld2hhdCBvdmVyIHRoZSByZXNpZGVudGlhbA0KPiAgICAgPiB2ZXJzaW9uIG9mIFdQQSwg aW4gd2hpY2ggYWxsIHVzZXJzIHNoYXJlIHRoZSBzYW1lICJXaS1GaSBwYXNzd29yZCIsDQo+IGJl Y2F1c2UNCj4gICAgID4gaXQgcHJvdmlkZXMgYmV0dGVyIGlzb2xhdGlvbiBiZXR3ZWVuIHVzZXJz LiBCdXQgSSB3b3VsZCBoYXZlIGEgaGFyZCB0aW1lDQo+ICAgICA+IHJlY29tbWVuZGluZyA4MDIu MXggZGVwbG95bWVudCBpbiByZXNpZGVudGlhbCBuZXR3b3JrcyAiYmVjYXVzZSBvZg0KPiAgICAg PiBESENQdjYgc2VjdXJpdHkiLg0KPiAgICAgPg0KPiAgICAgPiBXaGlsZSBJIGRvIGxpa2UgdGhl ICJESENQIEd1YXJkIiBjbGFzcyBvZiBzb2x1dGlvbnMsIEkgYW0gYWxzbyBjb25jZXJuZWQNCj4g dGhhdA0KPiAgICAgPiB0aGUgREhDUCBHdWFyZCBjb25jZXB0IGlzIG9ubHkgZGVmaW5lZCBieSB0 aGUgY29tbWVyY2lhbCBsaXRlcmF0dXJlIG9mDQo+ICAgICA+IHNvbWUgdmVuZG9ycyAtLSBhbmQg dGhlIHNhbWUgZ29lcyBmb3IgREhDUCBTbm9vcGluZywgd2hpY2ggY291bGQNCj4gaGF2ZSBhDQo+ ICAgICA+IHZhcmlldHkgb2YgbWVhbmluZ3MuIElmIHlvdSB3YW50IHRvIHVzZSB0aGF0IHRlcm0s IHRoZW4geW91IHNob3VsZCBhZGQgYQ0KPiAgICAgPiByZWZlcmVuY2UgdG8gdGhlIHBhcGVyIHdo ZXJlIHRoaXMgaXMgZGVmaW5lZC4gT3IgeW91IGNvdWxkIHVzZSBuZXV0cmFsDQo+ICAgICA+IGxh bmd1YWdlLCBsaWtlOg0KPiAgICAgPg0KPiAgICAgPiAgIENvbnNpZGVyaW5nIHRoYXQsIG5ldHdv cmtzIHVzaW5nIERIQ1B2NiwgZGVwZW5kaW5nIG9uIHRoZWlyIHNwZWNpZmljDQo+ICAgICA+ICAg dG9wb2xvZ2llcywgc2hvdWxkIGNvbnNpZGVyIHVzaW5nIGFjY2VzcyBjb250cm9sIG1lY2hhbmlz bXMgc3VjaCBhcw0KPiAgICAgPiAgIHRob3NlIGJhc2VkIG9uIElFRUUtODAyLjFYLCBhbmQgREhD UHY2IGZpbHRlcmluZyBtZWNoYW5pc21zIGRlc2lnbmVkDQo+IHRvDQo+ICAgICA+ICAgcHJldmVu dCBmb3J3YXJkaW5nIG9mIHNwb29mZWQgREhDUHY2IHBhY2tldHMgdGhyb3VnaCB0aGUgcm91dGVy LA0KPiBvZnRlbg0KPiAgICAgPiAgIHJlZmVycmVkIHRvIGFzICJESENQIEd1YXJkLiINCj4gDQo+ ICAgICBUaGVyZSBhcmUgbm8gZXhwZWN0YXRpb25zIGV4cHJlc3NlZCBlaXRoZXIgaW4gdGhpcyBk cmFmdCBvciBSRkMgNzA4NCAod2hpY2gNCj4gdGhpcyBkcmFmdCBidWlsZHMgdXBvbikgdGhhdCB0 aGUgQ0Ugcm91dGVyIG1pZ2h0IGJlIGZvcndhcmRpbmcgKG9yIHJlbGF5aW5nKQ0KPiBESENQdjYg cGFja2V0cyB0aHJvdWdoIHRoZSByb3V0ZXIuIFJGQyA3MDg0IHJlcXVpcmVzIHRoZSBDRSByb3V0 ZXIgdG8gaGF2ZQ0KPiBpdHMgb3duIFdBTi1mYWNpbmcgREhDUHY2IGNsaWVudC4gSWYgaXQgd2Fu dHMgdG8gc3VwcG9ydCBhbnkgc29ydCBvZiBMQU4tc2lkZQ0KPiBESENQdjYsIGl0IFNIT1VMRCBo YXZlIGEgREhDUHY2IHNlcnZlci4gTm90aGluZyBhYm91dCBmb3J3YXJkaW5nIG9yDQo+IHJlbGF5 aW5nLiBBZ2FpbiwgSSBjb250ZW5kIHRoYXQgZGlzY3Vzc2luZyBESENQIEd1YXJkIGluIHRoZSBT ZWN1cml0eSBzZWN0aW9uDQo+IGlzIG91dCBvZiBzY29wZS4NCj4gDQo+ICAgICBCYXJiYXJhDQo+ IA0KPiAgICAgPiBJIGFtIGFsc28gc2tlcHRpY2FsIG9mIHRoZSBtZW50aW9uIG9mICJTTUUiIGlu IHRoZSBsYXN0IHBhcmFncmFwaCwgaW4NCj4gICAgID4gImRlcGxveW1lbnQgb2YgSVB2NGFhUyBp biByZXNpZGVudGlhbCwgU09ITyBhbmQgU01FIG5ldHdvcmtzIi4gVGhlDQo+ICAgICA+IGRlZmlu aXRpb24gb2Ygd2hhdCBpcyBhIHNtYWxsIG9yIG1lZGl1bSBlbnRlcnByaXNlIHZhcmllcyBieSBj b3VudHJpZXMuDQo+ICAgICA+IEluIHRoZSBFdXJvcGVhbiBVbmlvbiwgaXQgaXMgdXAgdG8gMjUw IGVtcGxveWVlcy4gSW4gdGhlIFVTLCBpdCBpcyBkZWZpbmVkDQo+IGJ5DQo+ICAgICA+IHJldmVu dWVzIGFuZCBlbXBsb3llZXMgbGltaXQsIHR5cGljYWxseSBmZXdlciB0aGFuIDUwMCBlbXBsb3ll ZXMuIEluDQo+IG90aGVyDQo+ICAgICA+IHBhcnQgb2YgdGhlIHdvcmxkLCBpdCBjYW4gYmUgZmV3 ZXIgdGhhbiA1MCBlbXBsb3llZXMsIG9yIG1heWJlIGl0IGlzIGp1c3QNCj4gICAgID4gZGVmaW5l ZCBieSBhIGxpbWl0IG9uIHJldmVudWVzLiBJbiBhbnkgY2FzZSwgSSB3b3VsZCBwZXJzb25hbGx5 IGJlDQo+IHJlbHVjdGFudCB0bw0KPiAgICAgPiBkZXBsb3kgc2ltcGxlIGRldmljZXMgbGlrZSBk ZXNjcmliZWQgaW4gdGhlIGRyYWZ0IGluIGEgbmV0d29yayB3aXRoIDEwMCB0bw0KPiAyMDANCj4g ICAgID4gcGVvcGxlLCBsZXQgYWxvbmUgNTAwLiBUaGF0IHdvdWxkIGJlIHB1c2hpbmcgbHVjayBh IGJpdCB0b28gZmFyLg0KPiAgICAgPg0KPiAgICAgPiBUaGUgaW50cm9kdWN0aW9uIG9mIHRoZSBk cmFmdCBzYXlzICJUaGlzIGRvY3VtZW50IGRlZmluZXMgSVB2NCBzZXJ2aWNlDQo+ICAgICA+IGNv bnRpbnVpdHkgZmVhdHVyZXMgb3ZlciBhbiBJUHY2LW9ubHkgbmV0d29yaywgZm9yIGEgcmVzaWRl bnRpYWwgb3Igc21hbGwtDQo+ICAgICA+IG9mZmljZSByb3V0ZXIuLi4iIEkgd291bGQgc3VnZ2Vz dCB1c2luZyBleGFjdGx5IHRoZSBzYW1lIGxhbmd1YWdlLCBhcyBpbjoNCj4gICAgID4NCj4gICAg ID4gICBBcyBzdGF0ZWQgaW4gdGhlIGludHJvZHVjdGlvbiwgdGhpcyBkb2N1bWVudCBhZGRyZXNz ZXMgZGVwbG95bWVudCBvZg0KPiAgICAgPiAgIElQdjRhYVMgaW4gcmVzaWRlbnRpYWwgb3Igc21h bGwtb2ZmaWNlIG5ldHdvcmtzLiAgRGVwbG95bWVudCBpbiBtb3JlDQo+ICAgICA+ICAgY2hhbGxl bmdpbmcgZW52aXJvbm1lbnRzIHdvdWxkIHJlcXVpcmUgYWRkaXRpb25hbCBzZWN1cml0eSBhbmFs eXNpcy4NCj4gICAgID4NCj4gICAgID4gLS0gQ2hyaXN0aWFuIEh1aXRlbWENCj4gICAgID4NCj4g ICAgID4NCj4gDQo+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiAgICAgdjZvcHMgbWFpbGluZyBsaXN0DQo+ICAgICB2Nm9wc0BpZXRmLm9yZw0K PiAgICAgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0K PiAzQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdjZvcHMmZD1Ed0lGYVEmYz1MRlla LQ0KPiBvOV9IVU1lTVRTUWljdmpJZyZyPUxvR3poQy0NCj4gOHNjOFNZOFRxNHZyZm9nJm09Z0d3 dXNmU0NVamtRaWV1TlExSTc2eU56NTQzMjFMejhraVFwcUhCQnZ1MCZzDQo+ID02Mk5KajJueEhw N2xaeGY1aUVmdDRTRlo5LW1YUHZxU0F2WnZoRmJ1T3UwJmU9DQo+IA0KPiANCj4gDQo+IA0KPiAq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IElQdjQgaXMg b3Zlcg0KPiBBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCj4gaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtDQo+IDNBX193d3cudGhlaXB2 NmNvbXBhbnkuY29tJmQ9RHdJRmFRJmM9TEZZWi0NCj4gbzlfSFVNZU1UU1FpY3ZqSWcmcj1Mb0d6 aEMtDQo+IDhzYzhTWThUcTR2cmZvZyZtPWdHd3VzZlNDVWprUWlldU5RMUk3NnlOejU0MzIxTHo4 a2lRcHFIQkJ2dTAmcw0KPiA9eVJ3ZnpDMFVrZXlXd1dvQzVMdGhXa0dERGtBUFNvcXJOVzJNWnZG dk5fbyZlPQ0KPiBUaGUgSVB2NiBDb21wYW55DQo+IA0KPiBUaGlzIGVsZWN0cm9uaWMgbWVzc2Fn ZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvcg0KPiBjb25m aWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1 c2l2ZSB1c2Ugb2YgdGhlDQo+IGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIg bm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNjbG9zdXJlLA0KPiBjb3B5aW5nLCBkaXN0cmli dXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlm DQo+IHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9o aWJpdGVkIGFuZCB3aWxsIGJlIGNvbnNpZGVyZWQgYQ0KPiBjcmltaW5hbCBvZmZlbnNlLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55DQo+IGRp c2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9m IHRoaXMgaW5mb3JtYXRpb24sDQo+IGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNo ZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQsIHdpbGwgYmUNCj4gY29uc2lkZXJlZCBh IGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRvIHRoZSBvcmlnaW5hbCBzZW5k ZXIgdG8NCj4gaW5mb3JtIGFib3V0IHRoaXMgY29tbXVuaWNhdGlvbiBhbmQgZGVsZXRlIGl0Lg0K PiANCj4gDQoNCg== From nobody Tue Jan 8 17:59:36 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED98F12F1A5; Tue, 8 Jan 2019 17:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoVMKMOl7NDo; Tue, 8 Jan 2019 17:59:21 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7598512F1A2; Tue, 8 Jan 2019 17:59:21 -0800 (PST) Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:b4c1:b6ff:fe27:67bb]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id DDE04F99B; Tue, 8 Jan 2019 20:58:48 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 8FFAC202B4; Tue, 8 Jan 2019 13:55:32 -0500 (EST) From: Daniel Kahn Gillmor To: Russ Housley , Adam Montville Cc: spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF , IETF SecDir In-Reply-To: <38C4C1A8-42E9-4F50-B4F1-356909D81AC9@vigilsec.com> References: <154695697211.25494.5342366287090150478@ietfa.amsl.com> <38C4C1A8-42E9-4F50-B4F1-356909D81AC9@vigilsec.com> Date: Tue, 08 Jan 2019 13:55:28 -0500 Message-ID: <877effhtcv.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [secdir] [lamps] Secdir last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 01:59:23 -0000 --=-=-= Content-Type: text/plain On Tue 2019-01-08 12:33:45 -0500, Russ Housley wrote: > Guidance on the transition from one trust anchor to another is > available in Section 4.4 of [RFC4210]. In particular, the oldWithNew > and newWithOld advice ensures that relying parties are able to > validate certificates issued under the current Root CA certificate > and the next generation Root CA certificate throughout the > transition. Further, this advice avoids the need for all relying > parties to make the transition at the same time. I'm not convinced that this analysis is correct, as i tried to explain in more detail in Message-Id: <87k1jlnxnu.fsf@fifthhorseman.net>. I hope my analysis in that e-mail is wrong, but i've received no feedback on it yet. Maybe some additional guidance about which parties should ship which certificates in which contexts would clarify matters? Or maybe i'm just missing something obvious to other people -- i'd be happy to see a clarification. Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCXDTyIAAKCRBsHx7ezFD6 U7KEAP0VJvFgWeI58SxWFf02bqy+TDOLUCmdr3sBSLRJ9vimvgD/VUMWNinX3K27 AJFhtmUvlmYXU7C4hHZO+stZPHLnhwg= =iGZD -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 8 20:18:54 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A46712D4EB; Tue, 8 Jan 2019 20:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=0j1ExoO9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sKOu+l+l Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Im2O7NQ3bmV; Tue, 8 Jan 2019 20:18:38 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C9A129AB8; Tue, 8 Jan 2019 20:18:38 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3CA592538B; Tue, 8 Jan 2019 23:18:37 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 08 Jan 2019 23:18:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=BzscEGMa9ySZG8Co9mwBDQDL6 En1y+1sss3Y0auLZUs=; b=0j1ExoO99WprG6LoSkR+XmBIJJrraOPgIbXM4HgsH bRsWXNULZQhCporMKTbUXR9Y++kXImtwBnaIUY6cmu9Q+oORuaE0Y8VITuxS67nF DZX8MEpf6E0LplGdRLftpodfHnVtG3oinG/suxP6RzjZfIeuM/7ZcABxVJY9RJk+ TaJ2WdF07DFTcZq4C7WLHdWrhn8xym0BUc3Qz2c9gI6D9zuL1m3O2MxwwDRBN0eq ReyrXqOJA03Z3Pu5mQ9q5n9Jx2irQPb0BpPUbP8zvLirIh1EB1n2gkycQeP8ibmT Y6KJohhkTpu0lG8vrnln4scausonnze5h2GReatf9hCxA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=BzscEGMa9ySZG8Co9 mwBDQDL6En1y+1sss3Y0auLZUs=; b=sKOu+l+luaVOcY3qEEAYT4XSGjTvpN0yZ 9pt+HwbUMAArSo66Eb9tWtj5mVBKbxdICpyW0YTuu1SWAYo4Oc5Ob9EXV1cHI+FI WyqbwoRKSEbcTnnFUl+b/HoYiUDoYzyBLI3un+TUvoRBrYJet/EyODN3hCaC5aWp jbbxj2wYnECRw5EpvYzhgrDy1DKJ8TIpNwQgVryWEpP5398zqrJa/hGgsYyjzZ5X QDZSV43KYtrTCqcFVYxHm95+ByLLg+PHFYlVkMaw5QSgrcezbaPLlV2DlT2an+LF uZpli0Vg2EcHW/QU/1sI18nwno6PAofaz6xEB47N/ObLAHUNPJgaw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedtgdejudculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuffhomhgrihhnpehgihhthhhusgdrtghomhenucfrrghrrghmpehmrghilhhfrhhomhep nhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivg eptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 79A18203F1; Tue, 8 Jan 2019 23:18:36 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 64588216 Message-Id: In-Reply-To: <23604.45941.279266.464196@fireball.acr.fi> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> <23603.20862.976183.378013@fireball.acr.fi> <23604.45941.279266.464196@fireball.acr.fi> Date: Tue, 08 Jan 2019 23:18:36 -0500 From: "Neil Jenkins" To: "Tero Kivinen" Cc: secdir@ietf.org, "Bron Gondwana" , "IETF JMAP Mailing List" , draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=a589e271320c4d059cd84835353b537e Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 04:18:40 -0000 --a589e271320c4d059cd84835353b537e Content-Type: text/plain On Wed, 9 Jan 2019, at 1:28 AM, Tero Kivinen wrote: > When you are subscribing the push notifications your devices should be > running and not offline. Agreed. It's still possible for the initial message not to arrive, but in the vast majority of cases it will; if it doesn't, the client can destroy and recreate the subscription to try again. Weighing this up, I agree that adding a verification step is the best way forward here. > When something changes on the server, the server pushes a > *StateChange* object to the client. > > Actually that says "to the client" not to the "push service". Which > one should it be? Well, it's to the client, possibly via a push service, but possibly not because there are two "push" mechanisms defined here; the other is where the client can maintain a permanent TCP connection directly to the JMAP server in which case it can use an EventSource connection to receive push events directly without going via a 3rd party. > Hmm... and 7.2 then also uses term "push endpoint" which is not > defined anywhere? Is that the same as push service at given url Reading through it again, there was some confusion in the use of terminology. I have rewritten a few sections to attempt to clarify this and the other confusing points you pointed out. You can see the changes for this here . The addition of a verification step is added in this change here . Are you happy that this is sufficient to address your concerns? Regards, Neil. --a589e271320c4d059cd84835353b537e Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, 9 = Jan 2019, at 1:28 AM, Tero Kivinen wrote:
When you are subscribing the push notif= ications your devices should be
running and not offline.

Agreed. It's still possible for= the initial message not to arrive, but in the vast majority of cases it= will; if it doesn't, the client can destroy and recreate the subscripti= on to try again. Weighing this up, I agree that adding a verification st= ep is the best way forward here.

   When something chang= es on the server, the server pushes a
   *StateC= hange* object to the client.

Actually that = says "to the client" not to the "push service". Which
one = should it be?

Well, it's to th= e client, possibly via a push service, but possibly not because there ar= e two "push" mechanisms defined here; the other is where the client can = maintain a permanent TCP connection directly to the JMAP server in which= case it can use an EventSource connection to receive push events direct= ly without going via a 3rd party.

Hmm... and 7.2 then also uses te= rm "push endpoint" which is not
defined anywhere? Is that = the same as push service at given url

Reading through it again, there was some confusion in the use of= terminology. I have rewritten a few sections to attempt to clarify this= and the other confusing points you pointed out. You can see the changes= for this here. The addition of a verification st= ep is added in this change here.
Are you happy that this is sufficient to address your conce= rns?

Regards,
Neil.
= --a589e271320c4d059cd84835353b537e-- From nobody Tue Jan 8 20:29:09 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBC7129AB8 for ; Tue, 8 Jan 2019 20:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=RQ/JJz2J; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=P+mxVNDZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBpesocKDqnU for ; Tue, 8 Jan 2019 20:29:05 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0EFC12872C for ; Tue, 8 Jan 2019 20:29:05 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A1C57253F9; Tue, 8 Jan 2019 23:29:04 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 08 Jan 2019 23:29:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=4COrQRrySv0uE+flbbsOIHB/5 4nRpW6stTypyEQRUAE=; b=RQ/JJz2JUnKLKTweEowoG/iPWuXcPTu/1/GLF1I2M dVwldYs+JkxuO5iEhnZ/ez2h7zyWzh5PPlevL62kr9LXQxsWG3Jv31uce2cAIRUe y5EBAnzGOOt3GS7M5SHraOKq/WUwhy/yfJZbn92Js5L2IVISkI3EvW7+P9X3811e R1WPpLNQdT7gYaPfa8SqbCpEPavRqnOHMQ8EV9dI6kvgbcpqpxxciaULu/sOwR/y sLz455R5WPXZN/pBAXF9i90cLLLCsECUZa4S1Kk5vsN7FWR5a7v90uL8cAR/O9dJ GdpC9el1gXuz+Mt9GC74PBnxtnmNVFWP+YWdeTVNojI/g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=4COrQRrySv0uE+flb bsOIHB/54nRpW6stTypyEQRUAE=; b=P+mxVNDZJq3Doip5NTqtqa5Ly2KrYJtxw SK4TEamxk00C4sya0D6jlGSd0PJvRUdYObMaZJT1eLPJ5Cp8Bk08Qwka5sO9ZuEP Hp+TGATb3a0Ep6VCRV1Nv+MAdeLfXw0/dVDx0cJP31n4DJJqKGd05YOiZ4ieY6rA 9VuWGXd+O8CYYuE8uhfxr1+U6WXc5yFmYGEJ2YDYA8hWYZsXZ5Fyat3H2ffYmtZK 6ebGTGHEMdnVHBBkOGkLOZdqwRT4+sFrBHmepKk6xIrwcQhlmuN03P1i2UNWoNx3 2B53Q61sbC0V9QzSlOh8PgkmqjpCnFnuYqe/qt/XZVglJV4Hky5HA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedtgdejfeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne curfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdr tghomhenucevlhhushhtvghrufhiiigvpedu X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 20EAF203F1; Tue, 8 Jan 2019 23:29:04 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 64588216 Message-Id: <56087c0c-8cc4-4d86-b0d4-66281ee8ecee@beta.fastmail.com> In-Reply-To: <18ed534b-fca8-416e-a506-7397dcaac0a2@www.fastmail.com> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <20190105185050.GB28515@kduck.kaduk.org> <23603.21152.388621.403480@fireball.acr.fi> <23604.47198.503637.521152@fireball.acr.fi> <18ed534b-fca8-416e-a506-7397dcaac0a2@www.fastmail.com> Date: Tue, 08 Jan 2019 23:29:03 -0500 From: "Neil Jenkins" To: "Tero Kivinen" Cc: secdir@ietf.org Content-Type: multipart/alternative; boundary=1b94715f4b6f49dfbebb226935b19301 Archived-At: Subject: Re: [secdir] =?utf-8?q?=5BJmap=5D___Secdir_last_call_review_of_draft?= =?utf-8?q?-ietf-jmap-core-12?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 04:29:06 -0000 --1b94715f4b6f49dfbebb226935b19301 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, 9 Jan 2019, at 7:24 AM, Bron Gondwana wrote: > *Neil:* is this something which you feel strongly enough to insist on = keeping? I've gone back to the original email to try to see what the original com= ment was, before we digressed into arguing over whether people are able = to share individual mailboxes or not. As far as I can see the paragraph = that raised the issue was this in section 1.6.2: *A single set of credentials may provide access to multiple accounts, fo= r example if another user is sharing their mail with the logged in user,= or if there is a group account.* And Tero would like to see the word *mail* changed to *calendar*? I mean= , sure that can work equally well as an example. I don't really see the = need for the change, but if that resolves the issue I'm happy to change = it. *Tero* =E2=80=93 can you please let me know what change you are look= ing for if it's more than this. Neil. --1b94715f4b6f49dfbebb226935b19301 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Wed, 9 = Jan 2019, at 7:24 AM, Bron Gondwana wrote:
N= eil: is this something which you feel strongly enough to insist on k= eeping?

I've gone back t= o the original email to try to see what the original comment was, before= we digressed into arguing over whether people are able to share individ= ual mailboxes or not. As far as I can see the paragraph that raised the = issue was this in section 1.6.2:

A singl= e set of credentials may provide access to multiple accounts, for exampl= e if another user is sharing their mail with the logged in user, or if t= here is a group account.

And Tero would= like to see the word mail changed to calendar? I mean, su= re that can work equally well as an example. I don't really see the need= for the change, but if that resolves the issue I'm happy to change it. = Tero =E2=80=93 can you please let me know what change you are loo= king for if it's more than this.

Neil.
<= /div> --1b94715f4b6f49dfbebb226935b19301-- From nobody Tue Jan 8 22:38:27 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78E112D7EA for ; Tue, 8 Jan 2019 22:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS7HIUz4k9Ju for ; Tue, 8 Jan 2019 22:38:24 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 81EAE12D4E7 for ; Tue, 8 Jan 2019 22:38:24 -0800 (PST) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx66.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gh772-000CWs-W9 for secdir@ietf.org; Wed, 09 Jan 2019 07:13:13 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gh770-0000L3-8D for secdir@ietf.org; Wed, 09 Jan 2019 01:13:10 -0500 Received: (qmail 25413 invoked from network); 9 Jan 2019 06:13:06 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.39]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 9 Jan 2019 06:13:06 -0000 To: JORDI PALET MARTINEZ , "STARK, BARBARA H" Cc: "v6ops@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF88094@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <9674e692-41fd-1ef2-c4dc-9c01d4b49cc0@huitema.net> Date: Tue, 8 Jan 2019 22:13:02 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 168.144.250.231 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.09) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5jMfeynSaT0c7a12CP4J+WR602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzniiMFxnOFMHTZqw+apvQzTV/3OdXD2Xdo8CfrY5CQS2y4XPjVv1FkJPgbkBw/OCYyz NJVaeAWax4WOe4pTBX2DwIE7VKe+bqpcdCns72R1myoI6HG8RgZGnUdJnKT7IqXe0Of4jddu9xC8 8+iQ5nb7LoaTAX7mj3bIh4FDz/DsTWjvPyjQw0UjfF+Jrlh6iu5FWD3Fo0oXNNKNfWMJhMmBaQIi fdaGzMoXcgXnOXfsRAwX31WVY5lWjWxuGSRuxURW8UvT0kUDO7BO02wlaiMJNrZqjoiSWdcjcZLv /Am2ptBB9icD2fnZzw/HNF6wGm/P3Q658NtotfOVlwP9Y9difvX7GxYM34o1TppnqMQviUSfAdJk YJaAlfzQz6q7eKBmNlijRSWQzbBZx5Si4hrQHolQlVdf0A32Xtl5FAWD8PcNYjhf2jycpxDLnRQv ahqZR3KVQgqF/fPYYAfEfsjZunW7Kr2Ry7SfwNU0cVRE3ElSekOdZMuGg7NYIFnOUDJNDt97z3dg Xj0/mRPKWR2eMNnfXgg9myaSPB/HPOOqfJlbZZh01urflxdd2g4lVKNtykvTzwo4KsAf57LdPzrd Y4ZzPzG72tly1fyyBM2iMRsLUyPV5I9gDodoUEiziHU6PFg2lKttDfiiwYsEJ5JKZJ9YxIxnFPL7 Mk532j8tZT6pYh4rokCEVjmD/nrrE4R4k93mP4Eekr2+tRxjzzBc9aUV1oY4fX3W5eOCNA39O974 biSBdkAAz2bewJ5RaE5+njp0nEcGVrabE85kQ4vmxTjl47CRbKYwXAhuDhjdF38+1Ld/o5jGCpWO 7tD53U/zoT1m5J4PsFRO0LAQJoPE7IkBEvBnkx6O3ZGdJmC5VgW9/bktU41htiJ8fk7NkK+gHmCo 9pOAj2WXm6JD+gUbaII8msxPb2pTv/kRdZSBrflFxRDE6Obj7NyLtIl4Sg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [secdir] [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 06:38:26 -0000 On 1/8/2019 10:38 AM, JORDI PALET MARTINEZ wrote: > The security concerns raised *initially* by Christian were related to t= he use of DHCP for configuring the WAN. At least that was what I understo= od. Then we continued discussing about the LAN, which I agree with you, i= s not a requirement on this document. I may be very confused, because the way I read your draft I assumed that the DHCPv6 S46 option was meant to inform the LAN-side devices of the available and preferred transition services. From what you are telling me, the S46 option is actually provided by the WAN side DHCPv6 server, of which the CPE is a client. That would be the preferred way for an ISP to configure the customer premise device. If the DHCPv6 option is only used on the WAN side, then I agree with Barbara and you that solutions like DHCP Guard or 802.1x are not relevant. There is no need for the proposed paragraph starting with "considering that" and ending with "scope of this document". On the other hand, if I was that much confused, others will be too. I might be useful to drop a line in section 3.2 explain in layman terms how the S46 option is used. -- Christian Huitema From nobody Wed Jan 9 02:30:37 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500D312F1AC; Wed, 9 Jan 2019 02:30:28 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtr_gUOWMrtU; Wed, 9 Jan 2019 02:30:26 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14DD12F1A2; Wed, 9 Jan 2019 02:30:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547029824; x=1547634624; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=vT/XEAgZAZVb0i7qY5c5RVHoIgywp4H58PJGELx2mE8=; b=QHj5p8jFlG+ct AKyIPwvDX2RkZKxJXNm8Ff9r5uqmW2QfytlFAg1EDQrGElbSzyEZyZRtowIFORuB XRlRA6ptB6qcs+8oKMbooWbIwJhgKoOSzCFHQruPbvR4CcKrjoWoHSwnbfEJp0J9 WjkOkhkd5qSf3TzhLJAh4DQ9cntJ2Q= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 09 Jan 2019 11:30:24 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 09 Jan 2019 11:30:22 +0100 Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006103042.msg; Wed, 09 Jan 2019 11:30:20 +0100 X-MDRemoteIP: 2001:470:1f09:495:4069:342c:af81:26bf X-MDHelo: [10.10.10.140] X-MDArrival-Date: Wed, 09 Jan 2019 11:30:20 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=191216c492=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Wed, 09 Jan 2019 11:30:17 +0100 From: JORDI PALET MARTINEZ To: Christian Huitema , "STARK, BARBARA H" CC: "v6ops@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Message-ID: Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF88094@GAALPA1MSGUSRBF.ITServices.sbc.com> <9674e692-41fd-1ef2-c4dc-9c01d4b49cc0@huitema.net> In-Reply-To: <9674e692-41fd-1ef2-c4dc-9c01d4b49cc0@huitema.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 10:30:28 -0000 Hi Christian, No, it was not intended to configure the LANs, just the CE. I think that's clear in the document (abstract, intro), so if you feel that= something else need to be included to make sure that is not misunderstood,= please, let me know. In Section 3.2 I've added this, let me know if you think is now clearer: Note that this document is only configuring the IPv4aaS in the IPv6 Transition CE Router itself, and not forwarding such information to devices attached to the LANs, so the WAN configuration, availability of native IPv4 or IPv4aaS, is transparent for them. Regarding the Security Section, following your points and Barbara suggestio= ns I've this: The IPv6 Transition CE Router must comply with the Security Considerations as stated in [RFC7084], as well as those stated by each transition mechanism implemented by the IPv6 Transition CE Router. As described in [RFC8026] and [RFC8415] Security Consideration sections, there are generic DHCP security issues, which in the case of this document means that malicious nodes may alter the priority of the transition mechanisms. Access network architecture for securing DHCP within the access network is out of scope of this document. Securing DHCP in the LAN is also not in scope. DHCP packets MUST NOT be forwarded between LAN and WAN interfaces of an IPv6 Transition CE router. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: ietf en nombre de Christian Huitema Fecha: mi=C3=A9rcoles, 9 de enero de 2019, 7:14 Para: JORDI PALET MARTINEZ , "STARK, BARBARA H"= CC: "v6ops@ietf.org" , "ietf@ietf.org" , "se= cdir@ietf.org" Asunto: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-i= pv4aas-12 =20 On 1/8/2019 10:38 AM, JORDI PALET MARTINEZ wrote: > The security concerns raised *initially* by Christian were related to= the use of DHCP for configuring the WAN. At least that was what I understo= od. Then we continued discussing about the LAN, which I agree with you, is = not a requirement on this document. =20 I may be very confused, because the way I read your draft I assumed tha= t the DHCPv6 S46 option was meant to inform the LAN-side devices of the available and preferred transition services. From what you are telling me, the S46 option is actually provided by the WAN side DHCPv6 server, of which the CPE is a client. That would be the preferred way for an IS= P to configure the customer premise device. =20 If the DHCPv6 option is only used on the WAN side, then I agree with Barbara and you that solutions like DHCP Guard or 802.1x are not relevant. There is no need for the proposed paragraph starting with "considering that" and ending with "scope of this document". =20 On the other hand, if I was that much confused, others will be too. I might be useful to drop a line in section 3.2 explain in layman terms how the S46 option is used. =20 -- Christian Huitema =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Jan 10 05:10:23 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DF5130EB3 for ; Thu, 10 Jan 2019 05:10:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <154712582272.30788.17526337490127288731.idtracker@ietfa.amsl.com> Date: Thu, 10 Jan 2019 05:10:22 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 13:10:23 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-01-10 Reviewer LC end Draft Steve Hanna 2018-12-18 draft-ietf-extra-sieve-fcc-08 Last calls: Reviewer LC end Draft Daniel Gillmor 2018-03-19 draft-gutmann-scep-11 Leif Johansson 2018-12-24 draft-ietf-6lo-nfc-12 Daniel Migault 2019-01-16 draft-ietf-dmm-ondemand-mobility-15 Matthew Miller 2019-01-14 draft-ietf-mile-xmpp-grid-09 Kathleen Moriarty 2019-02-05 draft-nottingham-rfc5785bis-08 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Stefan Santesson R2018-11-20 draft-wilde-service-link-rel-09 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-09 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Sean Turner 2018-11-25 draft-ietf-babel-dtls-03 Next in the reviewer rotation: Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper Tim Polk Vincent Roca Kyle Rose From nobody Thu Jan 10 05:20:24 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE18130EB3 for ; Thu, 10 Jan 2019 05:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEQbEe31CVw6 for ; Thu, 10 Jan 2019 05:20:20 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 7BDF2130E13 for ; Thu, 10 Jan 2019 05:20:20 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x0ADKA0G018632 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 Jan 2019 15:20:10 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x0ADKAsV027695; Thu, 10 Jan 2019 15:20:10 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <23607.18058.82067.78692@fireball.acr.fi> Date: Thu, 10 Jan 2019 15:20:10 +0200 From: Tero Kivinen To: "Neil Jenkins" Cc: secdir@ietf.org In-Reply-To: <56087c0c-8cc4-4d86-b0d4-66281ee8ecee@beta.fastmail.com> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <20190105185050.GB28515@kduck.kaduk.org> <23603.21152.388621.403480@fireball.acr.fi> <23604.47198.503637.521152@fireball.acr.fi> <18ed534b-fca8-416e-a506-7397dcaac0a2@www.fastmail.com> <56087c0c-8cc4-4d86-b0d4-66281ee8ecee@beta.fastmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: Re: [secdir] [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 13:20:23 -0000 Neil Jenkins writes: > On Wed, 9 Jan 2019, at 7:24 AM, Bron Gondwana wrote: >=20 > Neil: is this something which you feel strongly enough to insist = on > keeping=3F >=20 > I've gone back to the original email to try to see what the original = comment > was, before we digressed into arguing over whether people are able to= share > individual mailboxes or not. As far as I can see the paragraph that r= aised the > issue was this in section 1.6.2: >=20 > A single set of credentials may provide access to multiple accounts, = for > example if another user is sharing their mail with the logged in user= , or if > there is a group account. >=20 > And Tero would like to see the word mail changed to calendar=3F I mea= n, sure > that can work equally well as an example. I don't really see the need= for the > change, but if that resolves the issue I'm happy to change it. Tero =E2= =80=93 can you > please let me know what change you are looking for if it's more than = this. That would be ok, or changing the text as I indicated in my previous email: A single set of credentials may provide access to multiple accounts, for example if another user is sharing their work calendar information with the logged in user. Another example of cases where access to multiple accounts can be useful is when logged in user can also access shared group account mailbox (for example it help desk inbox). --=20 kivinen@iki.fi From nobody Thu Jan 10 18:57:19 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F83E12950A for ; Thu, 10 Jan 2019 18:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=j7wJne6v; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ugmZgVOd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2V8eR-9oGk2a for ; Thu, 10 Jan 2019 18:57:16 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC5212785F for ; Thu, 10 Jan 2019 18:57:15 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C22E622197; Thu, 10 Jan 2019 21:57:13 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 10 Jan 2019 21:57:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=fEkzyv4nybFbdSI3ZE6qH6cXY zcWEGud5WY28xkcgog=; b=j7wJne6vonV9IeH1A5/s07HdxYHfW5DYfKGbkoE29 AtmmEKYWrj5dakfvU5BJ1o1juk2YSLY3blCzsnkX9N9CFtz35CB2COepB46llYgp ZTXeEjEaPDmv2wd92fpKo847eyHk8sqwrIRSORpfrQ1bwCDvzcFL0mmdc9/4M74R D6ycfkhcbp0CpgH7TcnD5OW+JzXg63DZigv2k7gULMI42/zZAxzIksRl2v/9fVJb hrXvBaw6GNGW/48mja8WJ9k3Ae692qMIUeVyAbJ6eHy+uZ02k+EXt8S03z6sQ77i P6Mp3hgdI7itFokElJl76vocvXfErzAqDH1xqJZsmVxFw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=fEkzyv4nybFbdSI3Z E6qH6cXYzcWEGud5WY28xkcgog=; b=ugmZgVOdA5N8WzroAigtUpVSonstI7uyJ ZHk3yML2jYxcdEMPM/67/NjID93JB8Nso668fX6JeaUKlpN8bbhloIxTdbEbxsCC YnaOxtvD8YfSqA6HYN4Y1yBLE0IIqpLKrLCcY6jkeY5ysVhVfN4gAiKZxOeX5oGd 40FWsYlUVASUFl+iyY5Vpe060VS+csBUPAqAXZizQEI98UQDRbwYDK5Tbwes3PVF vuiyP+az1yRoIXdzkmsHYCGNT4Hw63bVBSPRAKrcEbNYPWr+isugDMN4pOjGxs1S 30qj+GLlX4AHWQfMaQc0NKRYlaGHVKfq4bD6feXGi+4JXBJ9SI2PQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfeeggdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepofgfkfgjfhffhf fvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehn vghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfh hrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghr ufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 77152203F2; Thu, 10 Jan 2019 21:57:12 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 64588216 Message-Id: In-Reply-To: <23607.18058.82067.78692@fireball.acr.fi> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <20190105185050.GB28515@kduck.kaduk.org> <23603.21152.388621.403480@fireball.acr.fi> <23604.47198.503637.521152@fireball.acr.fi> <18ed534b-fca8-416e-a506-7397dcaac0a2@www.fastmail.com> <56087c0c-8cc4-4d86-b0d4-66281ee8ecee@beta.fastmail.com> <23607.18058.82067.78692@fireball.acr.fi> Date: Thu, 10 Jan 2019 21:57:11 -0500 From: "Neil Jenkins" To: "Tero Kivinen" Cc: secdir@ietf.org Content-Type: multipart/alternative; boundary=641100a7665f432397f5929a5f20929e Archived-At: Subject: Re: [secdir] =?utf-8?q?=5BJmap=5D___Secdir_last_call_review_of_draft?= =?utf-8?q?-ietf-jmap-core-12?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 02:57:17 -0000 --641100a7665f432397f5929a5f20929e Content-Type: text/plain OK, I've changed it to: *A single set of credentials may provide access to multiple accounts, for example if another user is sharing their work calendar with the logged in user, or if there is a group mailbox for a support-desk inbox.** * Neil. --641100a7665f432397f5929a5f20929e Content-Type: text/html
OK, I've changed it to:

A single set of credentials may provide access to multiple accounts, for example if another user is sharing their work calendar with the logged in user, or if there is a group mailbox for a support-desk inbox.

Neil.
--641100a7665f432397f5929a5f20929e-- From nobody Fri Jan 11 21:06:33 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2718130F6F; Fri, 11 Jan 2019 21:06:20 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkwNyYOqfIyg; Fri, 11 Jan 2019 21:06:19 -0800 (PST) Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) (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 0CEC7124408; Fri, 11 Jan 2019 21:06:19 -0800 (PST) Received: by mail-oi1-x243.google.com with SMTP id x202so13954663oif.13; Fri, 11 Jan 2019 21:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3LN2xAqI4hE9dnEWTLvelerNgc4E+W+sjfrxUqZmyb8=; b=s3783UWAZOrv+wMQ4PmPYm8hW33Mf8wzx31Y7P8JoOs9tRmBngXw8HdEIbVLBTypee yo8oYCWs0xpIUY9eaZZ/QXBYu7S5Xn+NJBLLwrDYEABo2woPsqYcKvOcri742iZv1nHK 8LOHRBeOfYy5yW43nMZpWXOryxcFU5a0c7Ri4rt1adaBFIRgi48WVrpCL6Wq8053fkzL nHk4rSK/b6PUqYcEMyw7cRjFa9EQR2Y1O079CZoxRi+bpscnzqGzr4pIXlt9PadnzFLG EhovADTVoV2EWT+Nai9XuCwEOXhn2UlU/59VBtzaSvZNFBow5S5jgW4yp6lRzOOIdJHH VH5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3LN2xAqI4hE9dnEWTLvelerNgc4E+W+sjfrxUqZmyb8=; b=Q78k/8ZGY8CWTw5vNh+EZwTSkeUefE6umEbLUEP6GdNeoR7g3u1hlr2ae8tnJUOipi ae+5kTJSxiFb/1hntWFjEIWeO+Ox7SmV22BgzCo/qPMO2PQMnnPmFF/fsyhUaQODWYbX rZzAVXNRNqwNvBpRgDq5lM5eEBAt4s/iod5f7KilMBJjwTYfYpn+9cACwxSj5xhP+b11 vfMcdrt3/UmAid65QrD9y5lEyaxgyQLCn6IarWxj+ESsYj8A39MY7g3noJqy66f04hxt lFOM25GUzqWHTvx0QNH6tGdGk9IBftsT22bOxsw/DbvlLE3Dit8RHCB8pAlCs4uSH0GN TzUw== X-Gm-Message-State: AJcUukcg9WrHdE2x8npylQh26J7CkeuGaU4oxlxyDPIsDGmN93GHf520 j72RaavrjBdKNEDI8szmup6csAWXgsdtYc88CC8= X-Google-Smtp-Source: ALg8bN63WgdUfNGAairC7witj67LSYQmg7qw4KVzhgo39KdD7QQT6+SohqJaI9Z/1R8rH1QkQTR9ZLwwOUC6j0onRQM= X-Received: by 2002:aca:1e08:: with SMTP id m8mr10419695oic.347.1547269578377; Fri, 11 Jan 2019 21:06:18 -0800 (PST) MIME-Version: 1.0 References: <154687749567.23321.13207113394828941966@ietfa.amsl.com> <62c9b5fb-5c03-0747-fa1e-a513118a35a8@gmail.com> In-Reply-To: <62c9b5fb-5c03-0747-fa1e-a513118a35a8@gmail.com> From: Phillip Hallam-Baker Date: Sat, 12 Jan 2019 00:06:06 -0500 Message-ID: To: Stewart Bryant Cc: secdir@ietf.org, draft-ietf-rtgwg-spf-uloop-pb-statement.all@ietf.org, IETF Discussion Mailing List , rtgwg@ietf.org Content-Type: multipart/alternative; boundary="000000000000974f15057f3bc5f7" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2019 05:06:21 -0000 --000000000000974f15057f3bc5f7 Content-Type: text/plain; charset="UTF-8" If the security considerations are addressed in a different document, this should be stated in the security considerations section. On Mon, Jan 7, 2019 at 12:05 PM Stewart Bryant wrote: > > On 07/01/2019 16:11, Phillip Hallam-Baker wrote: > > Reviewer: Phillip Hallam-Baker > Review result: Has Issues > > The document describes the problem and solution pretty clearly. Unfortunately, > there is no discussion of the security considerations which is not appropriate > for a document addressing an availability which is a security issue. > > While microloops can form by chance, some consideration should be given to the > possibility that an attacker could induce a loop to perform a DoS attack. > > In section 1 the text says: > > [RFC8405] defines a solution that satisfies this problem statement > and this document captures the reasoning of the provided solution. > > It is safe to assume that the reader of this text would have read > normative reference RFC8405 and thus would be fully aware of the security > issues related to the solution being analysed. > > An attacker that had access to a network such that they could induce > microloops would have the ability to do many worse things to the network. > > If they were able to attack in-band they could poison the routing system > to take it down in far more interesting ways. Operators use security at the > physical and network layer to prevent this. > > If they were operating at the physical layer then they could take circuits > down at will and cause microloops in the base protocol, traffic overloads > and application malfunction. > > Thus if the attacker could deploy either of those attacks in a network to > induce micro-loops, then any security considerations in this draft would > count for nothing. > > The draft is an analysis, and thus I think that it correctly states that > it introduces no additional matters for security consideration. > > - Stewart > > -- Website: http://hallambaker.com/ --000000000000974f15057f3bc5f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If the security considerations are addressed in a different d= ocument, this should be stated in the security considerations section.=C2= =A0

On Mon, Jan = 7, 2019 at 12:05 PM Stewart Bryant <stewart.bryant@gmail.com> wrote:
=20 =20 =20


On 07/01/2019= 16:11, Phillip Hallam-Baker wrote:
Reviewer: Phi=
llip Hallam-Baker
Review result: Has Issues

The document describes the problem and solution pretty clearly. Unfortunate=
ly,
there is no discussion of the security considerations which is not appropri=
ate
for a document addressing an availability which is a security issue.

While microloops can form by chance, some consideration should be given to =
the
possibility that an attacker could induce a loop to perform a DoS attack.

In section 1 the text says:

[RFC8405] defines a solution that satisfies this =
problem statement
   and this document captures the reasoning of the provided solution.

It is safe to assume that the reader of this text would have read normative reference RFC8405 and thus would be fully aware of the security issues related to the solution being analysed.

An attacker that had access to a network such that they could induce microloops would have the ability to do many worse things to the network.

If they were able to attack in-band they could poison the routing system to take it down in far more interesting ways. Operators use security at the physical and network layer to prevent this.

If they were operating at the physical layer then they could take circuits down at will and cause microloops in the base protocol, traffic overloads and application malfunction.

Thus if the attacker could deploy either of those attacks in a network to induce micro-loops, then any security considerations in this draft would count for nothing.

The draft is an analysis, and thus I think that it correctly states that it introduces no additional matters for security consideration.

- Stewart



--
Website: http://hallambaker.com/
--000000000000974f15057f3bc5f7-- From nobody Mon Jan 14 09:58:33 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651AC1311ED; Mon, 14 Jan 2019 09:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGTs8UcaShPn; Mon, 14 Jan 2019 09:58:28 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441791311E0; Mon, 14 Jan 2019 09:58:27 -0800 (PST) Received: from ians-mbp.fritz.box ([84.44.210.90]) by mail.gmx.com (mrgmx002 [212.227.17.184]) with ESMTPSA (Nemesis) id 0LtIZH-1hPXvH3M2l-012qRf; Mon, 14 Jan 2019 18:58:24 +0100 From: ianfarrer@gmx.com Message-Id: <306015DD-737D-4D27-B75C-6B7930948A7F@gmx.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_38C1EFF0-C7E5-4240-8418-90A2D23DB1D3" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 14 Jan 2019 18:58:23 +0100 In-Reply-To: <154687813459.23265.13403466946569558605@ietfa.amsl.com> Cc: secdir@ietf.org, softwires@ietf.org, draft-ietf-softwire-yang.all@ietf.org, ietf@ietf.org To: Phillip Hallam-Baker References: <154687813459.23265.13403466946569558605@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.102.3) X-Provags-ID: V03:K1:eiF4DUe+8yk0fcGRzFRPcMYyatS5ZNAR65RWtbQkIu0RxAaXHH1 Y4iIKyM1wRfL+uwXjSFe9SgrGqNPjRiTQgZcjoBKCOVYvmYYplSE2HVTtCZU1gFKI0XYU1b UOypMqb+3+G8FmDv3QXjpFPP5QWpyOeAeyF5XX3YGKGN2qg92V2ZjrPfF/q9b6uHyX0+hJ9 ynHdW5pLgqUJz6QJN1fxw== X-UI-Out-Filterresults: notjunk:1;V03:K0:6rg9b1Uu9CQ=:yMvTCbhaeDPmzKOYdrLJfL zhQxRl1i0HDqaNhwkaWO77q4msXWQqxK0UohyKiF/cv88pa+rdYmhfbFqpASMaaKdH/xdwfY0 PJCMcEYz9POH9ZiirADa/QbWvkfq5dzHiczAh3GGJOuDevuVd6MiotfakvqnKkkMHevq9Nq1g UqmwPE0u2g+ZdHdatcTarG99FH9qicJR1Gf1127zZTR7i5CtEHSsirfxLGhraBiadzgwrI/No Yj5F8IwnzdlUsn2J7c3ZD/hAFKlDZgcBv6lETocrzQ+bouh3tZ6zyhkUkW3jhDm1yprdn5yTz EJclHiGNY5jxJegTB81vy6AuzEWDTqD9uoxP3LZFU+JhmBwR6oCi/BRrB/WofsCPelmpegb0q MOH2IdtnI1cJqU3tiQ66l3tO4tuuwB5KWderRHjyqLhgwV4F9TPYMooUCGEr56/+1LwAG0k8x QMtA5HD2qI+iyYqCpNUIZBPvBPKrUfCFtLxVsagfvK+EMFiqjpmxdRPDfNvWC5RRNBaRWZTJz IHkt4Lbc+7BAVZjsJAY5gPftmfmToTC5tXcmtDZuAK4dAeKdTnN/dDwgg/YHOvvuoY1VXbfss 11krekieCMHlxi/NUXe+PyVnRfH8qQtHlo1JccMdPBJ+1/2XO23q5G7UMCO2Ns08vRrwxuhFx /blKiInWrUibg61rXy0YqeznRtlpSs1Er8AVvUWbBblLBEoowTbYCWDfXriNu7lpwBfu1A7yb 0LB8l+XRnK1dVS7oVytSez3bDfguVXLmbYeuMfnSLgIsq8HgPHlC1PpzYyBxVYIBd9/Ofb958 GVy6MeQN5Mu5QPPCSmG5auNxD5K5qL3NuRHboxa0zmRX72zKqeFwN3LjlrHMShwtVwh5CDN2A 22oyKm6heP5iC0YnXksu5XLK9D0motGYHYDR3+KfmNiDnfxJDOAZ5QlpeGTcJk Archived-At: Subject: Re: [secdir] [Softwires] Secdir last call review of draft-ietf-softwire-yang-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 17:58:31 -0000 --Apple-Mail=_38C1EFF0-C7E5-4240-8418-90A2D23DB1D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Phillip, Thank you for your review and comment. We=E2=80=99ve re-written the Security Guidelines section following the = guidance here: = https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines = and = Section 3.7.1 of RFC8407. The proposed text is below. However, your comment is not really covered by those guidelines, = assuming that it is applicable to YANG processing generally, rather than = the modules in this draft specifically. The focus of the security = section is more related to configuration and state nodes which the = module exposes and threats associated with them rather than how those = nodes are accessed. In existing YANG documents the closest I=E2=80=99ve found is from = RFC6020 (and RFC7950) Sec. Considerations: "YANG parsers need to be robust with respect to malformed documents. Reading malformed documents from unknown or untrusted sources could result in an attacker gaining the privileges of the user running the YANG parser. In an extreme situation, the entire machine could be compromised." Do you think that this text addresses your comment? If so, I will = include a pointer to it. Thanks, Ian 9. Security Considerations The YANG modules defined in this document is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The NETCONF access control model [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. All data nodes defined in the YANG modules which can be created, modified, and deleted (i.e., config true, which is the default) are considered sensitive. Write operations (e.g., edit-config) applied to these data nodes without proper protection can negatively affect network operations. An attacker who is able to access the BR can undertake various attacks, such as: o Setting the value of 'br-ipv6-addr' on the CE to point to an illegitimate BR so that it can intercept all the traffic sent by a CE. Illegitimately intercepting users' traffic is an attack with severe implications on privacy. o Setting the MTU to a low value, which may increase the number of fragments ('softwire-payload-mtu'). o Disabling hairpinning (i.e., setting 'enable-hairpinning' to 'false') to prevent communications between CEs. o Setting 'softwire-num-max' to an arbitrary high value, which may be exploited by a misbehaving user to perform a DoS on the binding BR by mounting a massive number of softwires. o Setting 'icmpv4-rate' or 'icmpv6-rate' to a low value, which may lead to the deactivation of ICMP messages handling. o Accessing to privacy data maintained by the BR (e.g., the binding table or the algorithm configuration). Such data can be misused to track the activity of a host. o Instructing the BR to install entries which in turn will induce a DDoS attack by means of the notifications generated by the BR. This DDoS can be softened by defining a notification interval, but given that this interval parameter can be disabled or set to a low value by the misbehaving entity, the same problem will be observed. Security considerations related to lw4o6, MAP-T, and MAP-E are discussed in [RFC7596], [RFC7597], and [RFC7599] respectively. > On 7. Jan 2019, at 17:22, Phillip Hallam-Baker = wrote: >=20 > Reviewer: Phillip Hallam-Baker > Review result: Has Nits >=20 > The document describes a schema and has appropriately identified the = read/write > security concerns arising from it. >=20 > One issue that I thing could be usefully spelled out is that the use = of > automated tools to decode structures of this type is not merely a = programming > convenience. Attempts to parse length delimited objects nested in = length > delimited structures using handwritten code is error prone and has led = to > introduction of numerous buffer overrun vulnerabilities. >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail=_38C1EFF0-C7E5-4240-8418-90A2D23DB1D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Phillip,

Thank you = for your review and comment.

We=E2=80=99ve re-written the Security = Guidelines section following the guidance here: https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines and Section 3.7.1 of RFC8407. The proposed text is = below.

However, = your comment is not really covered by those guidelines, assuming that it = is applicable to YANG processing generally, rather than the modules in = this draft specifically.  The focus of the security section is more = related to configuration and state nodes which the module exposes and = threats associated with them rather than how those nodes are = accessed.

In = existing YANG documents the closest I=E2=80=99ve found is from RFC6020 = (and RFC7950) Sec. Considerations:

"YANG parsers need to = be robust with respect to malformed documents.
 =  Reading malformed documents from unknown or untrusted sources = could
   result in an attacker gaining = the privileges of the user running the
  =  YANG parser.  In an extreme situation, the entire machine = could be
   compromised."

Do you think that this = text addresses your comment? If so, I will include a pointer to = it.

Thanks,
Ian


9.  Security Considerations

   The YANG modules defined = in this document is designed to be accessed
  =  via network management protocols such as NETCONF [RFC6241] = or
   RESTCONF [RFC8040].  The = lowest NETCONF layer is the secure transport
  =  layer, and the mandatory-to-implement secure transport is = Secure
   Shell (SSH) [RFC6242]. =  The lowest RESTCONF layer is HTTPS, and the
   mandatory-to-implement secure transport is TLS = [RFC8446].

   The NETCONF access control model [RFC8341] = provides the means to
   restrict access = for particular NETCONF or RESTCONF users to a
  =  preconfigured subset of all available NETCONF or RESTCONF = protocol
   operations and = content.

  =  All data nodes defined in the YANG modules which can be = created,
   modified, and deleted (i.e., = config true, which is the default) are
  =  considered sensitive.  Write operations (e.g., edit-config) = applied
   to these data nodes without = proper protection can negatively affect
  =  network operations.  An attacker who is able to access the BR = can
   undertake various attacks, such = as:

  =  o  Setting the value of 'br-ipv6-addr' on the CE to point to = an
      illegitimate BR so that it = can intercept all the traffic sent by a
  =     CE.  Illegitimately intercepting users' traffic is an = attack with
      severe = implications on privacy.

   o  Setting the MTU to a low value, which = may increase the number of
      = fragments ('softwire-payload-mtu').

   o  Disabling = hairpinning (i.e., setting 'enable-hairpinning' to
      'false') to prevent communications = between CEs.

   o  Setting 'softwire-num-max' to an = arbitrary high value, which may
    =   be exploited by a misbehaving user to perform a DoS on the = binding
      BR by mounting a = massive number of softwires.

   o  Setting = 'icmpv4-rate' or 'icmpv6-rate' to a low value, which may
      lead to the deactivation of ICMP = messages handling.

   o  Accessing to privacy data maintained by = the BR (e.g., the binding
      = table or the algorithm configuration).  Such data can be = misused
      to track the activity = of a host.

   o  Instructing the BR to install entries = which in turn will induce a
      = DDoS attack by means of the notifications generated by the BR.
      This DDoS can be softened by defining a = notification interval, but
      = given that this interval parameter can be disabled or set to a = low
      value by the misbehaving = entity, the same problem will be
    =   observed.

   Security considerations related to lw4o6, MAP-T, = and MAP-E are
   discussed in [RFC7596], = [RFC7597], and [RFC7599] respectively.

On 7. = Jan 2019, at 17:22, Phillip Hallam-Baker <hallam@gmail.com> = wrote:

Reviewer: Phillip Hallam-Baker
Review result: = Has Nits

The document describes a schema = and has appropriately identified the read/write
security = concerns arising from it.

One issue that I = thing could be usefully spelled out is that the use of
automated tools to decode structures of this type is not = merely a programming
convenience. Attempts to parse length = delimited objects nested in length
delimited structures = using handwritten code is error prone and has led to
introduction of numerous buffer overrun vulnerabilities.

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

= --Apple-Mail=_38C1EFF0-C7E5-4240-8418-90A2D23DB1D3-- From nobody Tue Jan 15 13:43:15 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937B61294FA for ; Tue, 15 Jan 2019 13:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.642 X-Spam-Level: X-Spam-Status: No, score=-17.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asvVBgtMDAEu for ; Tue, 15 Jan 2019 13:43:02 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 2FC08129AA0 for ; Tue, 15 Jan 2019 13:43:02 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id c2so3266418iom.12 for ; Tue, 15 Jan 2019 13:43:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bbs5kQmNHzG7ta3gZdf0zkxNgGdVe1ay5IFGJ1jdhrw=; b=HFePYzAlR2zVGuKsrzimevfedcs733KkCdHCbQmlSBSb68IrwbUOhaxx82zqwtsYbx S7jgjiMii+REgaWx1Cses8RIMlUbOpdo8HfK7cqE3/q0ff22HkxQSTfGOJRKhq4PeSUv PMl3c1cy4vIZmNutMg29fx3fQxSZLhnA0VpqVEHypH2Zcuyz1nYnwEInmAYHOx2KdWCe 6ZoNkFXmXfA5vPNdY30modm/jjSPcPxqfSoydBlhMY4eB2hZZmq5vpT+9a0r6UonP3HF q2QvRz1Le+jSXsMXQEJIKYfZpO9AY0D+guAUg1l6uBPkPps6rVXDNw0bni32LsourqXO Iy9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bbs5kQmNHzG7ta3gZdf0zkxNgGdVe1ay5IFGJ1jdhrw=; b=dEXnIKO8+inZvusrZy5C5fT2rlFLXgrxY51rmvVXRqky+hNK/Z8Bt542h2suZTRnsc 3a15C/2xaEBFfwTWFWJHP+OCeuRo7o6/c/U7DbL0yI39guMFnjpiwqochjAs0n8iovg2 uZqfL/2zPh+RFwkebueetp9lUPu+BY7Ch4d3gp5Fw+y4eb/3/BjgYpqdIgteG188+TSe ZM9rX70QV2Lb0q0CIFNNdgweDBL1yB+DC38n+J5fEKkvDpeJD9NRR2cZVq9hbImZOVz/ 8QlLsdbTmezDSIpJvEpOKtSw25okvE9xLWABxNZJT/tyjI45BnRms48T0K/7IuNjk5B6 tnWA== X-Gm-Message-State: AJcUukcb8o7r6hIoRYvssU38V9iTTlmYcHw5jJuJ58SDBSVciydfuiM2 hCeMf/qjoTKSP9RNc2tSzruBAXHbIaVTjnfiV2jl7OvzfNB6MQ== X-Google-Smtp-Source: ALg8bN7sHghmIgIS9B09JSdmD2jbSTlylMKbjdc7H6LJUlzpP/Itfqu/TabQ+wghd3c2eYfHxT7q5WWFEQJsqO5Xo9s= X-Received: by 2002:a5e:8306:: with SMTP id x6mr2838341iom.229.1547588581034; Tue, 15 Jan 2019 13:43:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: William Denniss Date: Tue, 15 Jan 2019 13:42:49 -0800 Message-ID: To: Christopher Wood Cc: The IESG , draft-ietf-oauth-device-flow.all@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="000000000000a21f0f057f860b4f" Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-oauth-device-flow X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 21:43:06 -0000 --000000000000a21f0f057f860b4f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Aug 26, 2018 at 7:30 PM Christopher Wood < christopherwood07@gmail.com> wrote: > Hi William, > > Please see inline below. > > On Wed, Aug 1, 2018 at 5:03 PM William Denniss > wrote: > >> >> On Tue, Jun 12, 2018 at 5:55 PM, Christopher Wood < >> christopherwood07@gmail.com> wrote: >> >>> Hello, >>> >>> I have reviewed this document as part of the security directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. These comments were written primarily for the benefit of the >>> security area directors. Document editors and WG chairs should treat >>> these comments just like any other last call comments. >>> >>> The summary of my review is: Ready with nits. >>> >>> Overall, the document is in fine shape. I have a few general comments >>> (not quite nits, >>> though not quite issues either), listed below: >>> >>> - Section 3.5, fifth paragraph: Requiring clients to poll at a >>> =E2=80=9Creasonable=E2=80=9D polling interval >>> without a suggestion of what is reasonable seems strange. Could you >>> suggest a value that=E2=80=99s >>> within reason, e.g., every second? >>> >> >> We documented a default of 5s in version 12. >> >> >>> - Section 5.1, first paragraph: It might be useful to point to Section >>> 6.1 wherein User Code >>> generation is discussed. Right now minimum entropy =E2=80=9Crequirement= s=E2=80=9D are >>> listed without further >>> details regarding viable mechanisms. >>> >> >> The authors are still considering this feedback, along with Benjamin >> Kaduk's DISCUSS. >> >> >>> - Section 5.2, second paragraph: The text claims that an end user would >>> end up =E2=80=9Con the >>> authorization page of the wrong service.=E2=80=9D Can you provide more = details >>> here? What stops >>> the malicious MITM from serving an authorization page that=E2=80=99s >>> indistinguishable from the >>> legitimate service page? >> >> >> >>> - Section 5.3, first paragraph: How specifically does the authorization >>> service prevent >>> devices from lying when providing =E2=80=9Cinformation about the device= =E2=80=9D? Or, >>> alternatively, how >>> does the authorization service learn this information? >>> >> >> These 2 also pending. >> >> >>> - Section 5.4: Would it be useful to suggest that clients SHOULD use a >>> secure (encrypted >>> and authenticated) channel when communicating to the user device? >>> >> >> This section is actually referring to real-world spying, i.e. someone in >> the same room as you who can see the TV. Perhaps we need to make that mo= re >> clear? >> > > That might help. It seems to be only a matter of clarity, not correctness= . > Thank you for the suggestion, a clarification has been added and will be published in -14. As currently drafted it now reads: While the device is pending authorization, it may be possible for a malicious user to physically spy on the device user interface (by viewing the screen on which it's displayed, for example) and hijack the session by completing the authorization faster than the user that initiated it. > >> >>> >>> The remainder of my comments, listed below, are editorial in nature, >>> aimed towards improving >>> readability of the document. >>> >>> - Section 1, step (E): This is the first time client polling is >>> mentioned without >>> discussion of timeouts or server-generated errors. The draft provides >>> such details later >>> on, so it would be helpful to allude or point to them here. >>> >> >> I believe this is covered in detail in the document, this section is >> intending to just be a high-level overview. >> >> >>> - Section 3.3, second paragraph: Please cite TLS upon use (=E2=80=9C=E2= =80=A6 in a >>> secure TLS-protected >>> session.=E2=80=9D). >>> >> >> Done, thanks! >> >> >>> - Section 3.3, second paragraph: The text suggests that the server >>> informs the user to >>> =E2=80=9Creturn to their device.=E2=80=9D Perhaps this should be prefac= ed with a MAY, as >>> the client will >>> eventually learn that authorization is complete upon polling. >>> >> >> MAY was added, thanks! >> >> >>> - Section 3.3.1, first paragraph: Should it be required that >>> =E2=80=9Cverification_uri_complete=E2=80=9D >>> is constructed in part from the =E2=80=9Cverification_uri=E2=80=9D and = =E2=80=9Cuser_code=E2=80=9D? I=E2=80=99m >>> not sure this is >>> necessary, though the example given is constructed this way. If not >>> required, this might be >>> worth noting. >>> >> >> The working group considered this, in fact originally we were not going >> to have verification_uri_complete and it would just be defined as a >> composition of those two values. In the end, the work group decided to m= ake >> it separate. The authorization server can combine them to create the >> complete verification URI, or may use something else. >> >> The text currently states the following which I believe covers this: >> >> "A verification URI that includes the "user_code" (or >> other information with the same function as the "user_code"), >> designed for non-textual transmission." >> >> - Section 3.5, first paragraph: s/token endpoint/authentication server? >>> >> >> This section does actually relate to the token endpoint. >> > > Ah, okay. I misunderstood. Thanks! > > >> >>> - Section 5.1, third paragraph: This text is mostly redundant with the >>> preceding paragraphs. >>> I would remove or merge it with the paragraphs above. >>> >> >> I don't agree that it's redundant. Willing to review text if you have a >> concrete proposal. >> > > My only recommendation is to remove the paragraph. I think it=E2=80=99s a= lready > covered by the preceding paragraphs. That said, I don=E2=80=99t think thi= s is > necessary. It=E2=80=99s merely a suggestion. > > Note that this paragraph was significantly reworked in -13 and has a longer discussion on entropy now. > >> >> Please let me know if you=E2=80=99ve further questions, comments, or con= cerns. I >>> hope this helps. >> >> > It does indeed. Thanks for your changes! > > Best, > Chris > Thanks again for your review! William --000000000000a21f0f057f860b4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Aug 26, 2018 at 7:30 PM Christoph= er Wood <christopherwood07@gmail.com> wrote:
Hi William,
=

Please see inline below.

On Wed, Aug 1, 2018 a= t 5:03 PM William Denniss <wdenniss@google.com> wrote:

On Tue, Jun 12, 2018 at 5:55 PM, Chri= stopher Wood <christopherwood07@gmail.com> wrote:<= br>
Hello,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.=C2=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and WG chairs should treat<= br> these comments just like any other last call comments.

=C2=A0 The summary of my review is: Ready with nits.

Overall, the document is in fine shape. I have a few general comments (not = quite nits,
though not quite issues either), listed below:

- Section 3.5, fifth paragraph: Requiring clients to poll at a =E2=80=9Crea= sonable=E2=80=9D polling interval
without a suggestion of what is reasonable seems strange. Could you suggest= a value that=E2=80=99s
within reason, e.g., every second?

We d= ocumented a default of 5s in version 12.
=C2=A0
- Section 5.1, first paragraph: It might be useful to point to Section 6.1 = wherein User Code
generation is discussed. Right now minimum entropy =E2=80=9Crequirements=E2= =80=9D are listed without further
details regarding viable mechanisms.

Th= e authors are still considering this feedback, along with Benjamin Kaduk= 9;s DISCUSS.
=C2=A0
- Section 5.2, second paragraph: The text claims that an end user would end= up =E2=80=9Con the
authorization page of the wrong service.=E2=80=9D Can you provide more deta= ils here? What stops
the malicious MITM from serving an authorization page that=E2=80=99s indist= inguishable from the
legitimate service page?
=C2=A0
- Section 5.3, first paragraph: How specifically does the authorization ser= vice prevent
devices from lying when providing =E2=80=9Cinformation about the device=E2= =80=9D? Or, alternatively, how
does the authorization service learn this information?

These 2 also pending.
=C2=A0
- Section 5.4: Would it be useful to suggest that clients SHOULD use a secu= re (encrypted
and authenticated) channel when communicating to the user device?

This section is actually referring to real-world= spying, i.e. someone in the same room as you who can see the TV. Perhaps w= e need to make that more clear?

That might help. It seems to be only= a matter of clarity, not correctness.
= =C2=A0
Thank you for the suggestion, a clarification has been add= ed and will be published in -14.

As currently draf= ted it now reads:

=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 While the device is pending authorization, it may be possibl= e for a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 malicious user = to physically spy on the device user interface
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 (by viewing the screen on which it's displayed= , for example) and hijack the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 session by completing the authorization faster than the user that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 initiated it.
=
=C2=A0
=C2=A0

The remainder of my comments, listed below, are editorial in nature, aimed = towards improving
readability of the document.

- Section 1, step (E): This is the first time client polling is mentioned w= ithout
discussion of timeouts or server-generated errors. The draft provides such = details later
on, so it would be helpful to allude or point to them here.

I believe this is covered in detail in the document, t= his section is intending to just be a high-level overview.
=C2=A0=
- Section 3.3, second paragraph: Please cite TLS upon use (=E2=80=9C=E2=80= =A6 in a secure TLS-protected
session.=E2=80=9D).

Done, thanks!
=
=C2=A0
- Section 3.3, second paragraph: The text suggests that the server informs = the user to
=E2=80=9Creturn to their device.=E2=80=9D Perhaps this should be prefaced w= ith a MAY, as the client will
eventually learn that authorization is complete upon polling.

MAY was added, thanks!
=C2=A0
- Section 3.3.1, first paragraph: Should it be required that =E2=80=9Cverif= ication_uri_complete=E2=80=9D
is constructed in part from the =E2=80=9Cverification_uri=E2=80=9D and =E2= =80=9Cuser_code=E2=80=9D? I=E2=80=99m not sure this is
necessary, though the example given is constructed this way. If not require= d, this might be
worth noting.

The working group conside= red this, in fact originally we were not going to have verification_uri_com= plete and it would just be defined as a composition of those two values. In= the end, the work group decided to make it separate. The authorization ser= ver can combine them to create the complete verification URI, or may use so= mething else.
=C2=A0
The text currently states the foll= owing which I believe covers this:

"A verification URI that incl= udes the "user_code" (or
other information with th= e same function as the "user_code"),
designed for = non-textual transmission."

- Section 3.5, first paragraph: s/token endpoint/authentication server?
=

This section does actually relate to the t= oken endpoint.

Ah, okay. I misunderstood. Thanks!

<= div>=C2=A0
- Section 5.1, third paragraph: This text is mostly redundant with the prec= eding paragraphs.
I would remove or merge it with the paragraphs above.
=
I don't agree that it's redundant. Willing to review= text if you have a concrete proposal.
=

My only recommendation is to = remove the paragraph. I think it=E2=80=99s already covered by the preceding= paragraphs. That said, I don=E2=80=99t think this is necessary. It=E2=80= =99s merely a suggestion.


Note that this paragraph was significantly rew= orked in -13 and has a longer discussion on entropy now.=C2=A0
= =C2=A0
=C2=A0

Please let me know if you=E2=80=99ve further questions, comments, or concer= ns. I hope this helps.

It does indeed. Thanks for your chang= es!

Best,
Chris

Thanks ag= ain for your review!

William=C2=A0
--000000000000a21f0f057f860b4f-- From nobody Tue Jan 15 18:57:09 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C0513103B; Tue, 15 Jan 2019 18:56:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Migault To: Cc: draft-ietf-dmm-ondemand-mobility.all@ietf.org, ietf@ietf.org, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154760741387.10854.10303591799017138670@ietfa.amsl.com> Date: Tue, 15 Jan 2019 18:56:53 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dmm-ondemand-mobility-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 02:56:55 -0000 Reviewer: Daniel Migault Review result: Not Ready Hi, I am the assigned Secdir reviewer for this draft. The Security Directorate (Secdir) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. Yours, Daniel On Demand Mobility Management draft-ietf-dmm-ondemand-mobility-15 Abstract Applications differ with respect to whether they need session continuity and/or IP address reachability. The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies. "inefficiencies" seems too vague to me and it could be clarified. Reading the abstract, it is unclear (to me) if the issue is on the application side or the network operator side. I guess this is the network side. It is also unclear the nature of the inefficiency. This document describes a solution for taking the application needs into account by selectively providing session continuity and IP address reachability on a per- socket basis. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 27, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Yegin, et al. Expires January 27, 2019 [Page 1] Internet-Draft On Demand Mobility July 2018 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Types of IP Addresses . . . . . . . . . . . . . . . . . . 4 3.2. Granularity of Selection . . . . . . . . . . . . . . . . 6 3.3. On Demand Nature . . . . . . . . . . . . . . . . . . . . 6 3.4. Conveying the Desired Address Type . . . . . . . . . . . 7 4. Usage example . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Pseudo-code example . . . . . . . . . . . . . . . . . . . 8 4.2. Message Flow example . . . . . . . . . . . . . . . . . . 10 5. Backwards Compatibility Considerations . . . . . . . . . . . 11 5.1. Applications . . . . . . . . . . . . . . . . . . . . . . 11 5.2. IP Stack in the Mobile Host . . . . . . . . . . . . . . . 12 5.3. Network Infrastructure . . . . . . . . . . . . . . . . . 12 5.4. Merging this work with RFC5014 . . . . . . . . . . . . . 12 6. Summary of New Definitions . . . . . . . . . . . . . . . . . 13 6.1. New APIs . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. New Flags . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944], the following two attributes are defined for IP service provided to mobile hosts: Session continuity: The ability to maintain an ongoing transport interaction by keeping the same local end-point IP address throughout the life-time of the IP socket despite the mobile host changing its Yegin, et al. Expires January 27, 2019 [Page 2] Internet-Draft On Demand Mobility July 2018 point of attachment within the IP network topology. The IP address of the host may change after closing the IP socket and before opening a new one, but that does not jeopardize the ability of applications using these IP sockets to work flawlessly. Session continuity is essential for mobile hosts to maintain ongoing flows without any interruption. Session continuity can be provided at multiple layers thus I would recommend for clarity to change session continuity to IP session continuity and insists that this is being provided at the IP layer. Not that IP is sessionless, so here session seems similar to reachability but 'orchestrated' by a higher session protocol. The difference I see is that reachability is a commitment (by the ISP) for not changing the IP address while with session continuity the commitment is related to the use of the IP address. In other words, with a limited period of time. IP address reachability: The ability to maintain the same IP address for an extended period of time. The IP address stays the same across independent sessions, and even in the absence of any session. The IP address may be published in a long-term registry (e.g., DNS), and is made available for serving incoming (e.g., TCP) connections. IP address reachability is essential for mobile hosts to use specific/ published IP addresses. Mobile IP is designed to provide both session continuity and IP address reachability to mobile hosts. Architectures utilizing these protocols (e.g., 3GPP, 3GPP2, WIMAX) ensure that any mobile host attached to the compliant networks can enjoy these benefits. Any application running on these mobile hosts is subjected to the same treatment with respect to session continuity and IP address reachability. My understanding of the text is that Mobile IP is expensive to deploy and I believe it would be easier for the reader to state it here before developing all mechanisms that have been designed to overcome session continuity in a different way. Thus I would put the following text right here: Achieving session continuity and IP address reachability with Mobile IP incurs some cost. Mobile IP protocol forces the mobile host's IP traffic to traverse a centrally-located router (Home Agent, HA), which incurs additional transmission latency and use of additional network resources, adds to the network CAPEX and OPEX, and decreases the reliability of the network due to the introduction of a single point of failure [RFC7333]. Therefore, session continuity and IP address reachability SHOULD be provided only when necessary. It should be noted that in reality not every application may need these benefits. IP address reachability is required for applications running as servers (e.g., a web server running on the mobile host). But, a typical client application (e.g., web browser) does not necessarily require IP address reachability. Similarly, session continuity is not required for all types of applications either. Applications performing brief communication (e.g., ping) can survive without having session continuity support. I believe that session continuity is the main motivation of the draft. Mentioning ping as an example is counter productive as I doubt this is the target application of the draft. Thus citing an application no one really wants could mean that we have not found any other application that do not need session continuity, which could be interpreted as every application needs session continuity at the IP layer. This is not the intention of the text, so we should find another example. Well I think reachability and session continuity are two different features. Applications may only need one of these features not both. In addition, application can provide these features at the IP layer layer or using other mechanisms. As a reason the use of Mobile IP is limited to applications that needs both features being performed at the IP layer which only concern a small fraction of applications. Reading the text above seems to take for granted that reachability is performed only at the IP layer. Splitting the feature versus its implementation should be done in a similar manner for both session continuity and reachability to ease the reading. Achieving session continuity and IP address reachability with Mobile IP incurs some cost. Mobile IP protocol forces the mobile host's IP traffic to traverse a centrally-located router (Home Agent, HA), which incurs additional transmission latency and use of additional network resources, adds to the network CAPEX and OPEX, and decreases the reliability of the network due to the introduction of a single point of failure [RFC7333]. Therefore, session continuity and IP address reachability SHOULD be provided only when necessary. This section should be moved up. Here it is splitting the discussion on session continuity and reachability, which is confusing. Furthermore, when an application needs session continuity, it may be able to satisfy that need by using a solution above the IP layer, such as MPTCP [RFC6824], SIP mobility [RFC3261], or an application- layer mobility solution. These higher-layer solutions are not subject to the same issues that arise with the use of Mobile IP since they can utilize the most direct data path between the end-points. But, if Mobile IP is being applied to the mobile host, the higher- Yegin, et al. Expires January 27, 2019 [Page 3] Internet-Draft On Demand Mobility July 2018 layer protocols are rendered useless because their operation is inhibited by Mobile IP. Since Mobile IP ensures that the IP address of the mobile host remains fixed (despite the location and movement of the mobile host), the higher-layer protocols never detect the IP- layer change and never engage in mobility management. The same paragraph should say the reachability can be performed by application using other means than IP reachability. This document proposes a solution for applications running on mobile hosts to indicate whether they need session continuity or IP address reachability. The network protocol stack on the mobile host, in conjunction with the network infrastructure, provides the required type of service. I assume that session continuity is only understood as IP session continuity and not the transport layer. It is for the benefit of both the users and the network operators not to engage an extra level of service unless it is absolutely necessary. It is expected that applications and networks compliant with this specification will utilize this solution to use network resources more efficiently. The introduction should also position it work regarding 5014. At the point it is not clear why the recommendations could not be such as: * when IP session reachability only is requires the application indicates a preference for Public IP addresses * when IP session continuity is needed the application sends a preference for home of address. * when none is required the application sends a preference for Care of Address. While on demand is mentioned in the title, it does not appear in the introduction. I believe the introduction should expose why there is a need to have this feature. 2. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Solution 3.1. Types of IP Addresses Four types of IP addresses are defined with respect to mobility management. - Fixed IP Address A Fixed IP address is an address with a guarantee to be valid for a very long time, regardless of whether it is being used in any packet to/from the mobile host, or whether or not the mobile host is connected to the network, or whether it moves from one point-of- attachment to another (with a different IP prefix) while it is connected. Thought english is not my first language, "guarantee" sounds a bit inappropriate. I might be wrong but the following text seems clearer to me: OLD: A Fixed IP address is an address with a guarantee to be valid for a very long time NEW: A Fixed IP address is an address that remains valid for a very long time Fixed IP addresses are required by applications that need both session continuity and IP address reachability. I think the document should clarify how this is different from a public address 5014. - Session-lasting IP Address A session-lasting IP address is an address with a guarantee to be valid throughout the life-time of the socket(s) for which it was requested. It is guaranteed to be valid even after the mobile host had moved from one point-of-attachment to another (with a different IP prefix). Similarly I would propose the following text: OLD: A session-lasting IP address is an address with a guarantee to be valid throughout the life-time of the socket(s) NEW: A session-lasting IP address is an address valid throughout the life-time of the socket(s) OLD: It is guaranteed to be valid even after NEW: It remains valid even after Yegin, et al. Expires January 27, 2019 [Page 4] Internet-Draft On Demand Mobility July 2018 Session-lasting IP addresses are required by applications that need session continuity but do not need IP address reachability. Home of Address provides IP reachability, but it is unclear if IP session continuity can be provided by other mechanisms that Mobile IP. If that were the case, it would be good to specify how this coudl be provided without IP reachability. - Non-persistent IP Address This type of IP address has no guarantee to exist after a mobile host moves from one point-of-attachment to another, and therefore, no session continuity nor IP address reachability are provided. The IP address is created from an IP prefix that is obtained from the serving IP gateway and is not maintained across gateway changes. In other words, the IP prefix may be released and replaced by a new one when the IP gateway changes due to the movement of the mobile host forcing the creation of a new source IP address with the updated allocated IP prefix. It woudl be good to position this toward the care of address. - Graceful Replacement IP Address In some cases, the network cannot guarantee the validity of the provided IP prefix throughout the duration of the opened socket, but can provide a limited graceful period of time in which both the original IP prefix and a new one are valid. This enables the application some flexibility in the transition from the existing source IP address to the new one. This gracefulness is still better than the non-persistence type of address for applications that can handle a change in their source IP address but require that extra flexibility. The classes defined above have overlaps. I believe that we have: Fixed IP Address \in Session-lasting IP Address \in Graceful Replacement IP Address \in Non-persistent IP Address I think that should be stated in the section. Applications running as servers at a published IP address require a Fixed IP Address. Long-standing applications (e.g., an SSH session) may also require this type of address. Enterprise applications that connect to an enterprise network via virtual LAN require a Fixed IP Address. Applications with short-lived transient sessions can use Session- lasting IP Addresses. For example: Web browsers. Applications with very short sessions, such as DNS clients and instant messengers, can utilize Non-persistent IP Addresses. Even though they could very well use Fixed or Session-lasting IP Addresses, the transmission latency would be minimized when a Non- persistent IP Addresses are used. Applications that can tolerate a short interruption in connectivity can use the Graceful-replacement IP addresses. For example, a streaming client that has buffering capabilities. Yegin, et al. Expires January 27, 2019 [Page 5] Internet-Draft On Demand Mobility July 2018 3.2. Granularity of Selection IP address type selection is made on a per-socket granularity. Different parts of the same application may have different needs. For example, the control-plane of an application may require a Fixed IP Address in order to stay reachable, whereas the data-plane of the same application may be satisfied with a Session-lasting IP Address. 3.3. On Demand Nature At any point in time, a mobile host may have a combination of IP addresses configured. Zero or more Non-persistent, zero or more Session-lasting, zero or more Fixed and zero or more Graceful- Replacement IP addresses may be configured by the IP stack of the host. The combination may be as a result of the host policy, application demand, or a mix of the two. Listing the different classes in the same order as the one of the definitions may ease the reading. When an application requires a specific type of IP address and such an address is not already configured on the host, the IP stack SHALL attempt to configure one. For example, a host may not always have a Session-lasting IP address available. When an application requests one, the IP stack SHALL make an attempt to configure one by issuing a request to the network (see Section 3.4 below for more details). If the operation fails, the IP stack SHALL fail the associated socket request and return an error. If successful, a Session-lasting IP Address gets configured on the mobile host. If another socket requests a Session-lasting IP address at a later time, the same IP address may be served to that socket as well. When the last socket using the same configured IP address is closed, the IP address may be released or kept for future applications that may be launched and require a Session-lasting IP address. I suspect the application is expected to request the type of IP with minimal capabilities. In some cases the OS may not have the requested type of address bu may have another type of addresses that could fulfill the application requirements. I believe the text should specify what should be done in this situation. I suppose the text will say that the host sends a request to the network. However, I suspect that allowing the OS to return higher capabilities would encourage the applications to send a minimal level of expectation so to maximize the probability of avoiding a interaction between the host and the network to request the specific type of IP address. In some cases it might be preferable for the mobile host to request a new Session-lasting IP address for a new opening of an IP socket (even though one was already assigned to the mobile host by the network and might be in use in a different, already active IP sockets). It is outside the scope of this specification to define criteria for choosing to use available addresses or choosing to request new ones. It supports both alternatives (and any combination). It is outside the scope of this specification to define how the host requests a specific type of prefix and how the network indicates the type of prefix in its advertisement or in its reply to a request). The following are matters of policy, which may be dictated by the host itself, the network operator, or the system architecture standard: Yegin, et al. Expires January 27, 2019 [Page 6] Internet-Draft On Demand Mobility July 2018 - The initial set of IP addresses configured on the host at boot time. - Permission to grant various types of IP addresses to a requesting application. - Determination of a default address type when an application does not make any explicit indication, whether it already supports the required API or it is just a legacy application. 3.4. Conveying the Desired Address Type [RFC5014] introduced the ability of applications to influence the source address selection with the IPV6_ADDR_PREFERENCE option at the IPPROTO_IPV6 level. This option is used with setsockopt() and getsockopt() calls to set/get address selection preferences. Extending this further by adding more flags does not work when a request for an address of a certain type results in requiring the IP stack to wait for the network to provide the desired source IP prefix and hence causing the setsockopt() call to block until the prefix is allocated (or an error indication from the network is received). One thing is the value of the flags, another thing is the behaviour of the API. So I understand that the new API provides more flexibility in the sense that a requirement that cannot be fulfilled does not necessarily end up in an error. Instead it can lead in an IP address that does not fulfill the application requirement. If that is correct, this is still something the application will have to deal with. IN one case, it will need to deal with an error, in the other case, with something that does not fulfill the requirements. If that is correct, I believe the benefit of it should be highlighted. Alternatively a new socket API is defined - getsc() which allows applications to express their desired type of session continuity service. The new getsc() API will return an IPv6 address that is associated with the desired session continuity service and with status information indicating whether or not the desired service was provided. An application that wishes to secure a desired service will call getsc() with the service type definition and a place to contain the provided IP address, and call bind() to associate that IP address with the socket (See pseudo-code example in Section 4 below). When the IP stack is required to use a source IP address of a specified type, it can use an existing address, or request a new IP prefix (of the same type) from the network and create a new one. If the host does not already have an IPv6 prefix of that specific type, it MUST request one from the network. Using an existing address from an existing prefix is faster but might yield a less optimal route (if a hand-off event occurred after its configuration). On the other hand, acquiring a new IP prefix from the network may be slower due to signaling exchange with the network. Applications can control the stack's operation by setting a new flag - ON_NET flag - which directs the IP stack whether to use a Yegin, et al. Expires January 27, 2019 [Page 7] Internet-Draft On Demand Mobility July 2018 preconfigured source IP address (if exists) or to request a new IPv6 prefix from the current serving network and configure a new IP address. This new flag is added to the set of flags in the IPV6_ADDR_PREFERENCES option at the IPPROTO_IPV6 level. It is used in setsockopt() to set the desired behavior. My understanding of the flag is that it forces the OS to request the network. This means that even if it already has teh desired IP address the ON_NET flag set will force the OS to re-ask. When unset, the decision to re-ask or not is let to the OS. IS that correct ? 4. Usage example 4.1. Pseudo-code example It would be good the example also shows the ON_NET flag. The following example shows pseudo-code for creating a Stream socket (TCP) with a Session-Lasting source IP address: #include #include // Socket information int s ; // socket id // Source information (for secsc() and bind()) sockaddr_in6 sourceInfo // my address and port for bind() in6_addr sourceAddress // will contain the provisioned // source IP address uint8_t sc_type = IPV6_REQUIRE_SESSION_LASTING_IP ; // For requesting a Session-Lasting // source IP address // Destination information (for connect()) sockaddr_in6 serverInfo ; // server info for connect() // Create an IPv6 TCP socket s = socket(AF_INET6, SOCK_STREAM, 0) ; if (s!=0) { // Handle socket creation error // ... } // if socket creation failed else { // Socket creation is successful // The application cannot connect yet, since it wants to use // a Session-Lasting source IP address It needs to request // the Session-Lasting source IP before connecting if (setsc(s, &sourceAddress, &sc_type)) == 0){ // setting session continuity to Session Lasting is // Successful. sourceAddress now contains the Session- // LAsting source IP address s/LAsting/Lasting/gc Yegin, et al. Expires January 27, 2019 [Page 8] Internet-Draft On Demand Mobility July 2018 // Bind to that source IP address sourceInfo.sin6_family = AF_INET6 ; sourceInfo.sin6_port = 0 // let the stack choose the port sourceInfo.sin6_address = sourceAddress ; // Use the source address that was // generated by the setsc() call if (bind(s, &sourceInfo, sizeof(sourceInfo))==0){ // Set the desired server's information for connect() serverInfo.sin6_family = AF_INET6 ; serverInfo.sin6_port = SERVER_PORT_NUM ; serverAddress.sin6_addr = SERVER_IPV6_ADDRESS ; // Connect to the server if (connect(s, &serverInfo, sizeof(serverInfo))==0) { // connect successful (3-way handshake has been // completed with Session-Lasting source address. // Continue application functionality // ... } // if connect() is successful else { // connect failed // ... // Application code that handles connect failure and // closes the socket // ... } // if connect() failed } // if bind() successful else { // bind() failed // ... // Application code that handles bind failure and // closes the socket // ... } // if bind() failed } // if setsc() was successful and of a Session-Lasting // source IP address was provided else { // application code that does not use Session-lasting IP // address. The application may either connect without // the desired Session-lasting service, or close the // socket... } // if setsc() failed } // if socket was created successfully // The rest of the application's code // ... Yegin, et al. Expires January 27, 2019 [Page 9] Internet-Draft On Demand Mobility July 2018 4.2. Message Flow example The following message flow illustrates a possible interaction for achieving OnDemand functionality. It is an example of one scenario and should not be regarded as the only scenario or the preferred one. OnDemand versus On Demand versus On-Demand. The text should be consistent. This flow describes the interaction between the following entities: - Applications requiring different types of OnDemand service. - The mobile host's IP stack. - The network infrastructure providing the services. In this example, the network infrastructure provides 2 IPv6 prefixes upon attachment of the mobile host to the network: A Session-lasting IPv6 prefix and a Non-persistent IPv6 prefix. Whenever the mobile host moves to a different point-of-attachment, the network infrastructure provides a new Non-persistent IPv6 address. In this example, the network infrastructure does not support Fixed IP addresses nor Graceful-replacement IP addresses. Whenever an application opens an IP socket and requests a specific IPv6 address type, the IP stack will provide one from its available IPv6 prefixes or return an error message if the request cannot be fulfilled. Message Flow: - The mobile device attaches to the network. - The Network provides two IPv6 prefixes: PREFsl1 - a Session-lasting IPv6 prefix and PREFnp1 - a Non-persistent IP v6 prefix. IP v6/IPv6/gc It would ease the reading if the mechanism used to specify the Type of the address by the operator to the host being described - at least an example. - An application on the mobile host is launched. It opens an IP socket and requests a Non-persistent IPv6 address. - The IP stack provides IPnp1 which is generated from PREFnp1. - Another application is launched, requesting a Non-persistent IPv6 address. - The IP stack provides IPnp1 again. - A third application is launched. This time, it requires a Session- lasting IPv6 address. second ? Yegin, et al. Expires January 27, 2019 [Page 10] Internet-Draft On Demand Mobility July 2018 - The IP stack provides IPsl1 which is generated from PREFsl1. - The mobile hosts moves to a new point-of-attachment. - The network provides a new Non-persistent IPv6 prefix - PREFnp2. PREFnp1 is no longer valid. - The applications that were given IPnp1 re-establish the socket and receive a new IPv6 address - IPnp2 which is generated from PREFnp2 - The application that is using IPsl1 can still use it since the network guaranteed that PREFsl1 will be valid even after moving to a new point-of-attachment. - A new application is launched, this time requiring a Graceful- replacement IPv6 address. - The IP stack returns setsc() with an error since the network does not support this service. - The application re-attempts to open a socket, this time requesting a Session-lasting IPv6 address. - The IP stack provides IPsl1. 5. Backwards Compatibility Considerations Backwards compatibility support is REQUIRED by the following 3 types of entities: - The Applications on the mobile host - The IP stack in the mobile host - The network infrastructure 5.1. Applications Legacy applications that do not support the OnDemand functionality will use the legacy API and will not be able to take advantage of the On-Demand Mobility feature. Applications using the new OnDemand functionality MUST be aware that they may be executed in legacy environments that do not support it. Such environments may include a legacy IP stack on the mobile host, legacy network infrastructure, or both. In either case, the API will return an error code and the invoking applications may just give up and use legacy calls. Yegin, et al. Expires January 27, 2019 [Page 11] Internet-Draft On Demand Mobility July 2018 5.2. IP Stack in the Mobile Host New IP stacks MUST continue to support all legacy operations. If an application does not use On-Demand functionality, the IP stack MUST respond in a legacy manner. The legacy manner does not seems to be a standard way of behavior. It seems to me as the way the OS used to behave. I believe the draft shoudl be a bit more specific here. If the network infrastructure supports On-Demand functionality, the IP stack SHOULD follow the application request: If the application requests a specific address type, the stack SHOULD forward this request to the network. If the application does not request an address type, the IP stack MUST NOT request an address type and leave it to the network's default behavior to choose the type of the allocated IP prefix. If an IP prefix was already allocated to the host, the IP stack uses it and may not request a new one from the network. 5.3. Network Infrastructure The network infrastructure may or may not support the On-Demand functionality. How the IP stack on the host and the network infrastructure behave in case of a compatibility issue is outside the scope of this API specification. I believe that such statement should be made in the introduction with the addition of a list of potential mechanism to provide the type of IP addresses by the network. There is a need to have such mechanisms since the OS cannot derive the properties from the IP address itself. Which was teh case with Home of address, care of address, cga.... 5.4. Merging this work with RFC5014 [RFC5014] defines new flags that may be used with setsockopt() to influence source IP address selection for a socket. The list of flags include: source home address, care-of address, temporary address, public address CGA (Cryptographically Created Address) and non-CGA. When applications require session continuity service and use setsc() and bind(), they SHOULD NOT set the flags specified in [RFC5014]. However, if an application sets a specific option using setsockopt() with one of the flags specified in [RFC5014] and also selects a source IP address using setsc() and bind() the IP address that was generated by setsc() and bound using bind() will be the one used by traffic generated using that socket and options set by setsockopt() will be ignored. The sentence above is hard to read - at least to me. I suspect "the" is missing after "by". What the text says is that after bind setsockopt will be ignored. Correct ? If bind() was not invoked after setsc() by the application, the IP address generated by setsc() will not be used and traffic generated by the socket will use a source IP address that complies with the options selected by setsockopt(). Yegin, et al. Expires January 27, 2019 [Page 12] Internet-Draft On Demand Mobility July 2018 6. Summary of New Definitions Flags and address types should in my opinion be placed in evidence. (.h) 6.1. New APIs setsc() enables applications to request a specific type of source IP address in terms of session continuity. Its definition is: int setsc(int sockfd, in6_addr *sourceAddress, sc_type addressType); Where: - sockfd - is the socket descriptor of the socket with which a specific address type is associated - sourceAddress - is a pointer to an area allocated for setsc() to place the generated source IP address of the desired session continuity type - addressType - Is the desired type of session continuity service. It is a 3-bit field containing one of the following values: 0 - Reserved 1 - FIXED_IPV6_ADDRESS 2 - SESSION_LASTING_IPV6_ADDRESS 3 - NON_PERSISTENT_IPV6_ADDRESS 4 - GRACEFUL_REPLACEMENT_IPV6_ADDRESS 5-7 - Reserved setsc() returns the status of the operation: - 0 - Address was successfully generated - EAI_REQUIREDIPNOTSUPPORTED - the required service type is not supported - EAI_REQUIREDIPFAILED - the network could not fulfill the desired request setsc() MAY block the invoking thread if it triggers the TCP/IP stack to request a new IP prefix from the network to construct the desired source IP address. If an IP prefix with the desired session continuity features already exists (was previously allocated to the mobile host) and the stack is not required to request a new one as a result of setting the IPV6_REQUIRE_SRC_ON_NET flag (defined below), setsc() MAY return immediately with the constructed IP address and will not block the thread. 6.2. New Flags The following flag is added to the list of flags in the IPV6_ADDR_PREFERENCE option at the IPPROTO6 level: IPV6_REQUIRE_SRC_ON_NET - set IP stack address allocation behavior Yegin, et al. Expires January 27, 2019 [Page 13] Internet-Draft On Demand Mobility July 2018 If set, the IP stack will request a new IPv6 prefix of the desired type from the current serving network and configure a new source IP address. If reset, the IP stack will use a preconfigured one if it exists. If there is no preconfigured IP address of the desired type, a new prefix will be requested and used for creating the IP address. 7. Security Considerations The setting of certain IP address type on a given socket may be restricted to privileged applications. For example, a Fixed IP Address may be provided as a premium service and only certain applications may be allowed to use them. Setting and enforcement of such privileges are outside the scope of this document. I believe the text could describe the threat such recommendation is addressing. The document describes how applications provides the OS their requirements in order to select the appropriated IP address. The resource are associated to different costs. While the cost is primarily on the operator side, it is likely that usage by the mobile node comes with some restrictions, limitation or direct cost. Typically, some type of IP address may be provided by the operator for a limited number of bytes upon which the IP address type will not be available to the mobile node or may be charged. A malicious application may use these limitations to generate extra billing of the mobile node or to prevent the usage of some applications by exhausting the expected type of IP address. In order to prevent such scenario, the mobile node SHOULD be able to authorize specific PI address types to privilege application. With these new types of IP addresses, the IP address leaks some connectivity requirements of the application. This also means that additional information is provided to the destination which could reveal to a passive monitoring attacker some information such as the type of application and the application itself even though the packet is protected by IPsec or TLS. To avoid profiling an application according to the type of IP addresses, it is expected that prefixes provided by the operator are associated to various type of addresses over time. As a result, the type of address could not be associated to the prefix, making application profiling based on the type of address harder. Application using multiple type of IP addresses to avoid being profiled is likely to create some patterns. So that remains a hard problem to solve by the application. The usage of a fixed IP address, enables tracking the mobile node, or its application over time. This is a similar problem as the one encountered with Public IP addresses. The usage of the Fixed IP addresses should be limited. To limit the effect of IP tracking, the application or the OS should ensure that IP addresses regularly change to limit IP tracking by a passive observer. The application should regularly set the On Demand flag. The application should be able to ensure that session lasting IP address are regularly changed by setting a lifetime for example handled by the application. In addition, the application should consider the use of graceful replacement IP addresses. Similarly, the OS may also associated IP addresses with a lifetime. Upon receiving a request for a given type of IP address, after some time, the OS should request a new address to the network even if it already has one IP address available with the requested type. This includes any type of IP address. Addresses of type graceful replacement or non persistent IP addresses should be regularly renewed by the OS. The lifetime of an IP address may be expressed in number of seconds or in umber of bytes sent through this IP address. Session lasting IP address could be used to avoid tracking and should be preferred. However, there should be a way to specify between one session lasting or if the IP address can last multiple sessions. 8. IANA Considerations This document has no IANA considerations. 9. Contributors This document was merged with [I-D.sijeon-dmm-use-cases-api-source]. We would like to acknowledge the contribution of the following people to that document as well: Sergio Figueiredo Altran Research, France Email: sergio.figueiredo@altran.com Younghan Kim Soongsil University, Korea Email: younghak@ssu.ac.kr John Kaippallimalil Huawei, USA Email: john.kaippallimalil@huawei.com 10. Acknowledgements We would like to thank Wu-chi Feng, Alexandru Petrescu, Jouni Korhonen, Sri Gundavelli, Dave Dolson and Lorenzo Colitti for their valuable comments and suggestions on this work. 11. References Yegin, et al. Expires January 27, 2019 [Page 14] Internet-Draft On Demand Mobility July 2018 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, DOI 10.17487/RFC5014, September 2007, . 11.2. Informative References [I-D.sijeon-dmm-use-cases-api-source] Jeon, S., Figueiredo, S., Kim, Y., and J. Kaippallimalil, "Use Cases and API Extension for Source IP Address Selection", draft-sijeon-dmm-use-cases-api-source-07 (work in progress), September 2017. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, . [RFC5563] Leung, K., Dommety, G., Yegani, P., and K. Chowdhury, "WiMAX Forum / 3GPP2 Proxy Mobile IPv4", RFC 5563, DOI 10.17487/RFC5563, February 2010, . [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, DOI 10.17487/RFC5944, November 2010, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, . Yegin, et al. Expires January 27, 2019 [Page 15] Internet-Draft On Demand Mobility July 2018 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, . Authors' Addresses Alper Yegin Actility Istanbul Turkey Email: alper.yegin@actility.com Danny Moses Intel Corporation Petah Tikva Israel Email: danny.moses@intel.com Kisuk Kweon Samsung Suwon South Korea Email: kisuk.kweon@samsung.com Jinsung Lee Samsung Suwon South Korea Email: js81.lee@samsung.com Jungshin Park Samsung Suwon South Korea Email: shin02.park@samsung.com Yegin, et al. Expires January 27, 2019 [Page 16] Internet-Draft On Demand Mobility July 2018 Seil Jeon Sungkyunkwan University Suwon South Korea Email: seiljeon@skku.edu Yegin, et al. Expires January 27, 2019 [Page 17] From nobody Tue Jan 15 20:56:03 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDBC1310D7 for ; Tue, 15 Jan 2019 20:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYtBljfmmx7w for ; Tue, 15 Jan 2019 20:55:58 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 066F11310CD for ; Tue, 15 Jan 2019 20:55:57 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id p6so4418752eds.0 for ; Tue, 15 Jan 2019 20:55:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=ZqcQx95Ud6AWhwgtIplPXbp8stH2CleHyQc2s8Q14s0=; b=gEVpOWQnMsf7EP4lDwro3eHgrad3Ot/MfyfZXTFBqlQY4H7Veyq54gc4jeEFRBK1/B U/mKVqgzPMA7UqqbJU5eW7BANGmOOn89ObWQmB1fWTQ5R2JtSlsscoOWpWrdwMTihVhg Z3scvpc2wiFICDy2NVHZjmhSu9VOcJs+TK1Ao= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=ZqcQx95Ud6AWhwgtIplPXbp8stH2CleHyQc2s8Q14s0=; b=OoPFZ+NR5jIPDCCU9ZhH5AIMapCWo5QVvrO5vK6CZOmBpi13GpAs6r65fxDTmmaxKT h+YNE8FEa5ZKJ9mVqy2jpSqd/vZ5uOU5OqcVYV8KBWEGac1pPULcoClBSFKSWbSELXua Q2ikKGcuPOg+hEv3mSXZ/G2xayTkCEMvy8gz92oz0pKHfmsyA6di/PMRN/361Ur0I+Fs N1PvGL9yXDMOqMVzSliq2+DWfdTR/YAnPRKt54j4MFfHdvy8LamnuFCOdwhpid/FbUgv AqJbXbyAliPPvWv3kYvm/2S+UZR2DoQwSuNFOeYvE2RyJeZLcSAFBt/gl+CfxX+XEJq+ g26w== X-Gm-Message-State: AJcUukd+ACHGb/ewydILQVyA+6G1MUjRWhfWco8HaC48xDGMOSO8XZYN oxe3oTjZIaHfkr04J/UVRKJiyA== X-Google-Smtp-Source: ALg8bN539DHOIn2FpCAh5mXA7YBVy7D0mZcEW8TURrPW+/BurqZ+vwnVzx3DIT9INsD2Wlg1wcOn+A== X-Received: by 2002:a50:ad84:: with SMTP id a4mr4476600edd.253.1547614556241; Tue, 15 Jan 2019 20:55:56 -0800 (PST) Received: from [5.5.33.23] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id k26-v6sm3011536ejv.59.2019.01.15.20.55.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Jan 2019 20:55:55 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: Date: Tue, 15 Jan 2019 20:55:51 -0800 Cc: The IESG , secdir@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org To: "Franke, Daniel" , Warren Kumari X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] sector review of draft-ietf-sidrops-rtr-keying-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 04:56:01 -0000 Daniel, Hi and thanks for the review! My comments are prefaced with [spt]. ---------- I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. The summary of the review is Ready with Issues. This document is well-written and generally sensible. I have just one major substantive concern, which is with this remark: = "[W]hen an operator wants to support hot-swappable routers, the same = private key needs to be installed in the soon-to-be online router that = was used by the the soon-to-be offline router. This motivated the = operator-driven model.=E2=80=9D This justification doesn't make sense to me. Surely it's possible for = the two routers to have two different, concurrently-valid certificates, = with the same Subject Name but different keys, each of them generated on = the respective device? It must be, because this is explicitly described = in the case of certificate rollover, and the two cases oughtn't look any = different from the outside other than the "staging period" being = much-prolonged. I'm not going to advocate for complete elimination of the = operator-generated method, but only because I know people are going to = do it no matter what we tell them, whether it's a good idea or not. But = we shouldn't be rationalizing copying private key material around when = it isn't really necessary to do so. [spt] So, you got me. I totally agree that we do not want to be = advocating manually copying around the private keys. It is just bad = practice and fraught with problems. But, this is is the process I=E2=80=99= ve been told some implementations need to follow to get them to work. = Until we actually get better tooling and something that looks more like = what=E2=80=99s described in s8 (Advanced Deployment Scenarios) I am = afraid that we=E2=80=99re probably stuck with the operator-driven model. Moving to meta-level concerns, this document reads much more like a BCP = than a Proposed Standard. I note that it actually started that way, but = was changed in November 2015. I can't find any record in the mailing = list archives or meeting minutes of what motivated the change. I can = venture a guess that at the time, the authors didn't feel that the = "current" part of "best current practice" was truthful advertising. But = if that's the case then this seems like a good time to reconsider in the = light of the past three years of RPKI and BGPsec adoption. This document contains 18 instance of SHOULD/RECOMMENDED and just two = instances of MUST, and one of those two is a requirement on the behavior = of the operator(!). I find this ratio troubling for a standards-track = document and think it may be a symptom of inappropriate classification. [spt] the RTGDIR and OPSDIR had the same comment. In the RTGDIR = response, we agreed to have the IESG just tell us what it ought to be, = but it looks like now we=E2=80=99re going to BCP now that all of the = reviews have questions the intended status. Here=E2=80=99s what I said = in response to the OPSDIR review: [spt] I seem to remember a discussion about whether this should be BCP = or ST. We discussed BCP addressing both what the IETF wanted to be the = best practice as well as what is the actual current practice. Since = BGPsec was/is new it was hard to say it fell in the latter bucket and = there was at least one person who felt that the router and operator = driven methods weren=E2=80=99t te way to go in the future (hence why = there is s8 the "advanced deployment scenarios=E2=80=9D section). So = the WG said go ST and because this draft has exhausted me we just = changed it to ST. I will note that the SECDIR and RTGDIR both had this = same comment it seems like we=E2=80=99re back to BCP. I think there was = another message somewhere about changing this to BCP so I will do that = in -03 unless I hear otherwise. Editorial nits: > There are two sub-methods, router-driven and operator-driven. These = two sub-methods differ=E2=80=A6=20 Why are these called "sub-methods" here when in the rest of the document = they're just "methods"? In various other places the document also uses = "model" in place of "method" with no clear distinction. [spt] The RTG Directorate wondered the same thing so I changed it to: = There are two methods, router-driven and operator-driven. > Though other configuration mechanisms might be used, e.g. NetConf (see = [RFC6470]); for simplicity, in this document, the protected channel = between the management platform and the router is assumed to be an = SSH-protected CLI. The semicolon is ungrammatical. The sentence might scan better as = "Though other configuration mechanisms might be used, e.g. NetConf = [RFC6470], the protected channel between the management platform and the = router is assumed in this document to be an SSH-protected CLI.=E2=80=9D=20= [spt] Fully agree will incorporate in -03. > A number of options exist for the operator management station to = exchange PKI-related information with routers and with the RPKI = including =E2=80=A6=20 The subsequent occurrences of "use" should be "using" or "to use" in = order to complement the subject "a number of options=E2=80=9D. [spt] Agreed will be incorporated in -03. > Once generated, the PKCS#10 certification request is returned to the = operator over the protected channel. Unnecessary passive voice. Rewrite as "Once the router has generated the = PKCS #10 certification request, it returns it to the operator over the = protected channel=E2=80=9D. [spt] Agreed will be incorporated in -03. > Beware that experience has shown that copy and paste from a management = station to a router can be unreliable for long texts. "copy-and-paste" should be hyphenated. [spt] Agreed will be incorporated in -03. > The router SHOULD extract the certificate from the PKCS#7 certs-ony = message and verify that the public key corresponds to the stored private = key Typo: "certs-ony=E2=80=9D. [spt] RTG Directorate noticed this too and it was changed in -02. > Signing the PKCS#8, permits more advanced configurations where the = entity that generates the keys is not the direct CA. Inappropriate comma. [spt] Agreed will be incorporated in -03. > The operator burden shifts here to include: Should be "operator's burden=E2=80=9D. [spt] Agreed will be incorporated in -03. > It is critical that a BGPsec speaking router is signing with a valid = private key at all times. Hyphenate "BGPsec-speaking=E2=80=9D. [spt] Agreed will be incorporated in -03. > Ensuring this is not terribly difficult but requires that either The = subsequent "has", "notes", "warns", "uses" should be the subjunctive = "have", "note", "warn", "use=E2=80=9D. [spt] Agreed will be incorporated in -03. Thank you Danny Cooper, who knows much more than I do about RPKI, for = sanity-checking my thoughts. [spt] thanks to you and Danny!= From nobody Thu Jan 17 12:12:16 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8459C130E63; Thu, 17 Jan 2019 12:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKoNB_nyObdt; Thu, 17 Jan 2019 12:11:52 -0800 (PST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (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 A0CF1128CF2; Thu, 17 Jan 2019 12:11:51 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2019 12:11:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,489,1539673200"; d="scan'208,217";a="267958719" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga004.jf.intel.com with ESMTP; 17 Jan 2019 12:11:50 -0800 Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 17 Jan 2019 12:11:49 -0800 Received: from lcsmsx154.ger.corp.intel.com (10.186.165.229) by FMSMSX157.amr.corp.intel.com (10.18.116.73) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 17 Jan 2019 12:11:48 -0800 Received: from hasmsx106.ger.corp.intel.com ([169.254.10.88]) by LCSMSX154.ger.corp.intel.com ([169.254.7.125]) with mapi id 14.03.0415.000; Thu, 17 Jan 2019 22:11:05 +0200 From: "Moses, Danny" To: Daniel Migault , "secdir@ietf.org" CC: "draft-ietf-dmm-ondemand-mobility.all@ietf.org" , "ietf@ietf.org" , "dmm@ietf.org" Thread-Topic: [DMM] Secdir last call review of draft-ietf-dmm-ondemand-mobility-15 Thread-Index: AQHUrUcsbqyzACp9uU2p16FppKffBKWz5VHA Date: Thu, 17 Jan 2019 20:11:04 +0000 Message-ID: References: <154760741387.10854.10303591799017138670@ietfa.amsl.com> In-Reply-To: <154760741387.10854.10303591799017138670@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzcxMDI5NDAtYTIzNC00OGIwLWEwOTYtYTkxMGI4Y2QxZTcwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiYkxna25GRlVZWStWd3BBVW1oV2dpVzZ0dVBwQ3BJN1UxczhKbjJsQ1hGXC9RamJLQ3ZLdzAwNWZHWGh6TVwvZEs3In0= dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.254.151.94] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC281441C1044HASMSX106gercor_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [DMM] Secdir last call review of draft-ietf-dmm-ondemand-mobility-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 20:12:02 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC281441C1044HASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Daniel, Thanks for a very thorough review and the detailed comments. I appreciate y= our invested time. There were one or two comments I did not fully understand. I have used many of them to improve the document. There were some which I t= hought differently and provided by reasoning. Please see my detailed response below. Thanks and regards, Danny 1. "inefficiencies" seem too vague... I am adding a reference to RFC 7333 that describe these inefficiencies in s= ection 4. 2. Use "IP session continuity" rather than "session continuity" The original definition was "IP session continuity". However, Brian Haberma= n in the early review commented that this term is confusing since the IP la= yer is not a session layer and thus, "IP Session" is not defined. To resolv= e this, we agreed to change "IP session continuity" to "session continuity"= in version 15 of this draft. I feel comfortable with any of these definiti= ons, so if the reviewers can agree on a term, I will adopt it. In any case,= I believe the text clearly describe the behavior of the network. 3. Recommended reordering of the text in section 1. I did not understand the recommended order, that is, which paragraph needs = to be moved to which place. Please help clarify this comment. 4. Replace 'ping' with a more useful application as an example. Use text messaging instead. 5. Split the feature versus its implementation should be done in a sim= ilar manner for both session continuity and reachability to ease reading. After giving it some thought, I tend to think differently. This is the Intr= oduction section and as such should be short. I do not think the splitting = is needed to understand the rest of the document. I prefer to keep this sec= tion short. 6. Add a paragraph that indicates the address reachability can be perf= ormed by applications using other means than IP reachability. I do not think this is required. The motivation of this Introduction is to = convince the reader that there is a benefit from enabling applications to i= ndicate their requirements from the mobile network, rather than getting the= full service support. I think the message is clear as it is. 7. Add a reference to RFC 5014 and the usage of home and care-of addre= sses. Actually, for mobile IP, this document is not required. If the mobile host = supports mobile IP, it can enable applications to select either a home addr= ess or a care-of address to use for the IP connection and by that, use or c= hoose not to use mobility services prided by the mobile network. This document addresses the case where the network provide these services b= y proxy and thus, provides the full mobility service regardless of whether = or not they are needed. For proxy services, we need a way for applications to express their true ne= eds and for the network stack to convey these needs to the network. 8. Indicate 'on demand' in the Introduction. I thought this is clear from the fact that each application indicates it mo= bility service requirements. As applications could be launched separately f= rom each other with possible large time gaps, on-demand is deducted. But to= be on the safe side, I will add 'on demand'. 9. In the several definitions of types IP address in section 3 replace= 'guarantee' with 'remains' I prefer 'guarantee' because it better indicates the commitment of the netw= ork to preserve the address. 10. A suggestion regarding the definition of Non-persistent IP address. I did not quite understand this suggestion. Something to do with Home Addre= ss and mobile IP. However, I believe the definition of Non-persistent IP ad= dress in this section is good as it is. 11. There are additional comments regarding mobile IP. As I indicated before, this document is not about mobile IP where the mobil= e host has control over the selection of care-of versus Home addresses. It = is about proxy solutions, in which the mobile host does not have any contro= l over the mobility service because it is done by-proxy by the network. 12. Need to mention the overlaps of the address types. Yes, there are overlaps but I do not see why mentioning them helps. 13. List the different address types in the same order in all sections to= ease the reading. I agree. Changing the order in section 3.3. 14. A comment about having the application request the minimal capability= and the network automatically providing the next level if it cannot fulfil= l this minimal level. This is a point we considered along with enabling applications to request s= everal levels in parallel and letting the network select the most preferabl= e one. After some evaluation, we decided that this flexibility is counter-p= roductive and it is best to specify a specific service type, and expect it = to either be fulfilled or have the request fail. This way, no 'smart' decis= ions are made automatically by the network. Remember however, that the appl= ication requests the service from the network stack, and the network stack = requests it from the network. We do not provide any restrictions on the imp= lementations of network stacks. Some could perform caching of network capab= ilities, and select to respond to applications without interacting with the= network. 15. Another comment about the behavior of the API, assuming a request mig= ht not be fulfilled without resulting in an error response. So as I described previously, API requests that cannot be fulfilled exactly= as specified, result with an error response. 16. A question about the ON_NET flag. Yes, your understanding is correct. 17. Request an example with the ON_NET flag. There could be other examples as well. There are all kinds of cases that co= uld be presented. There is a trade-off between the size of an RFC and a tex= t book. We thought it would be useful to provide an example of a non-trivia= l case and leave other cases to future text books and tutorials. 18. OnDeman versus On Demand versus On-Demand. Be consistent. I agree. Will be fixed. 19. IP v6 versus IPv6. Be consistent. I agree. Will be fixed. 20. Describe the mechanism in which the address type is indicated by the = network to the host. Unfortunately I cannot. Such a mechanism does not exist at the moment. We a= re working on that as well. 21. In section 5.2, need to describe how the new IP stack needs to behave= when an application that does not support On-Demand opens initiates a netw= ork connection. 'legacy manner' is not a good description. The next paragraph in this section does exactly that. Describes how the IP = stack should interact with the network. 22. Place the statement about networks supporting or not supporting On-De= mand functionality in the introduction. I prefer not to do that. I am trying to keep the Introduction short and cri= sp. Listing all use-cases, backwards compatibility and other details - for = that we have the rest of the document. The 'Introdcution' in my opinion sho= uld only provide information to help the reader decide it it should continu= e reading the document or not. 23. The description regarding the use-case of using both setsockopt() and= setsc()/bind() is hard to read. Clarify. OK. I will try to simplify it. By the way, your understanding is correct. 24. A comment about the placement of the flags and address types. I did not quite get this comment. I would like to clarify that we are provi= ding the Socket API as an example to clarify the concept. We expect other s= tandard bodies to use this document to specify the exact implementation in = different programming languages. 25. Security threats. I would like some clarification about these threats. My understanding is th= at these threats are relevant to the protocol use by the mobile host (or sp= ecifically its IP stack) to interact with the network to convey the desired= mobility service, and receive the granted service. But this document does not define these protocols. It defines the On-Demand= concept and the features needed by the API between applications and the ne= twork stack. Shouldn't these threats be described in the specification of t= he protocol between the mobile host and network? -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Daniel Migault Sent: Wednesday, January 16, 2019 04:57 To: secdir@ietf.org Cc: draft-ietf-dmm-ondemand-mobility.all@ietf.org; ietf@ietf.org; dmm@ietf.= org Subject: [DMM] Secdir last call review of draft-ietf-dmm-ondemand-mobility-= 15 Reviewer: Daniel Migault Review result: Not Ready Hi, I am the assigned Secdir reviewer for this draft. The Security Directorate (Secdir) reviews all IETF documents being processed by the IESG for the IET= F Chair. Please treat these comments just like any other last call commen= ts. Yours, Daniel On Demand Mobility Management draft-ietf-dmm-ondemand-mobility-15 Abstract Applications differ with respect to whether they need session continuity and/or IP address reachability. The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies. "inefficiencies" seems too vague to me and it could be clarified. Reading the abstract, it is unclear (to me) if the issue is on the applicat= ion side or the network operator side. I guess this is the network side. It= is also unclear the nature of the inefficiency. This document describes a solution for taking the application needs into account by selectively providing session continuity and IP address reachability on a per- socket basis. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 27, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Yegin, et al. Expires January 27, 2019 [Page 1] Internet-Draft On Demand Mobility July 2018 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Types of IP Addresses . . . . . . . . . . . . . . . . . . 4 3.2. Granularity of Selection . . . . . . . . . . . . . . . . 6 3.3. On Demand Nature . . . . . . . . . . . . . . . . . . . . 6 3.4. Conveying the Desired Address Type . . . . . . . . . . . 7 4. Usage example . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Pseudo-code example . . . . . . . . . . . . . . . . . . . 8 4.2. Message Flow example . . . . . . . . . . . . . . . . . . 10 5. Backwards Compatibility Considerations . . . . . . . . . . . 11 5.1. Applications . . . . . . . . . . . . . . . . . . . . . . 11 5.2. IP Stack in the Mobile Host . . . . . . . . . . . . . . . 12 5.3. Network Infrastructure . . . . . . . . . . . . . . . . . 12 5.4. Merging this work with RFC5014 . . . . . . . . . . . . . 12 6. Summary of New Definitions . . . . . . . . . . . . . . . . . 13 6.1. New APIs . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. New Flags . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944], the following two attributes are defined for IP service provided to mobile hosts: Session continuity: The ability to maintain an ongoing transport interaction by keeping the same local end-point IP address throughout the life-time of the IP socket despite the mobile host changing its Yegin, et al. Expires January 27, 2019 [Page 2] Internet-Draft On Demand Mobility July 2018 point of attachment within the IP network topology. The IP address of the host may change after closing the IP socket and before opening a new one, but that does not jeopardize the ability of applications using these IP sockets to work flawlessly. Session continuity is essential for mobile hosts to maintain ongoing flows without any interruption. Session continuity can be provided at multiple layers thus I would recommen= d for clarity to change session continuity to IP session continuity and ins= ists that this is being provided at the IP layer. Not that IP is sessionless, so here session seems similar to reachability b= ut 'orchestrated' by a higher session protocol. The difference I see is that reachability is a commitment (by the ISP) for = not changing the IP address while with session continuity the commitment is= related to the use of the IP address. In other words, with a limited perio= d of time. IP address reachability: The ability to maintain the same IP address for an extended period of time. The IP address stays the same across independent sessions, and even in the absence of any session. The IP address may be published in a long-term registry (e.g., DNS), and is made available for serving incoming (e.g., TCP) connections. IP address reachability is essential for mobile hosts to use specific/ published IP addresses. Mobile IP is designed to provide both session continuity and IP address reachability to mobile hosts. Architectures utilizing these protocols (e.g., 3GPP, 3GPP2, WIMAX) ensure that any mobile host attached to the compliant networks can enjoy these benefits. Any application running on these mobile hosts is subjected to the same treatment with respect to session continuity and IP address reachability. My understanding of the text is that Mobile IP is expensive to deploy and I= believe it would be easier for the reader to state it here before developi= ng all mechanisms that have been designed to overcome session continuity in= a different way. Thus I would put the following text right here: Achieving session continuity and IP address reachability with Mobile IP incurs some cost. Mobile IP protocol forces the mobile host's IP traffic to traverse a centrally-located router (Home Agent, HA), which incurs additional transmission latency and use of additional network resources, adds to the network CAPEX and OPEX, and decreases the reliability of the network due to the introduction of a single point of failure [RFC7333]. Therefore, session continuity and IP address reachability SHOULD be provided only when necessary. It should be noted that in reality not every application may need these benefits. IP address reachability is required for applications running as servers (e.g., a web server running on the mobile host). But, a typical client application (e.g., web browser) does not necessarily require IP address reachability. Similarly, session continuity is not required for all types of applications either. Applications performing brief communication (e.g., ping) can survive without having session continuity support. I believe that session continuity is the main motivation of the draft. Mentioning ping as an example is counter productive as I doubt this is the = target application of the draft. Thus citing an application no one really w= ants could mean that we have not found any other application that do not ne= ed session continuity, which could be interpreted as every application need= s session continuity at the IP layer. This is not the intention of the text= , so we should find another example. Well I think reachability and session continuity are two different features= . Applications may only need one of these features not both. In addition, a= pplication can provide these features at the IP layer layer or using other = mechanisms. As a reason the use of Mobile IP is limited to applications tha= t needs both features being performed at the IP layer which only concern a = small fraction of applications. Reading the text above seems to take for granted that reachability is perfo= rmed only at the IP layer. Splitting the feature versus its implementation = should be done in a similar manner for both session continuity and reachabi= lity to ease the reading. Achieving session continuity and IP address reachability with Mobile IP incurs some cost. Mobile IP protocol forces the mobile host's IP traffic to traverse a centrally-located router (Home Agent, HA), which incurs additional transmission latency and use of additional network resources, adds to the network CAPEX and OPEX, and decreases the reliability of the network due to the introduction of a single point of failure [RFC7333]. Therefore, session continuity and IP address reachability SHOULD be provided only when necessary. This section should be moved up. Here it is splitting the discussion on ses= sion continuity and reachability, which is confusing. Furthermore, when an application needs session continuity, it may be able to satisfy that need by using a solution above the IP layer, such as MPTCP [RFC6824], SIP mobility [RFC3261], or an application- layer mobility solution. These higher-layer solutions are not subject to the same issues that arise with the use of Mobile IP since they can utilize the most direct data path between the end-points. But, if Mobile IP is being applied to the mobile host, the higher- Yegin, et al. Expires January 27, 2019 [Page 3] Internet-Draft On Demand Mobility July 2018 layer protocols are rendered useless because their operation is inhibited by Mobile IP. Since Mobile IP ensures that the IP address of the mobile host remains fixed (despite the location and movement of the mobile host), the higher-layer protocols never detect the IP- layer change and never engage in mobility management. The same paragraph should say the reachability can be performed by applicat= ion using other means than IP reachability. This document proposes a solution for applications running on mobile hosts to indicate whether they need session continuity or IP address reachability. The network protocol stack on the mobile host, in conjunction with the network infrastructure, provides the required type of service. I assume that session continuity is only understood as IP session continuit= y and not the transport layer. It is for the benefit of both the users and the network operators not to engage an extra level of service unless it is absolutely necessary. It is expected that applications and networks compliant with this specification will utilize this solution to use network resources more efficiently. The introduction should also position it work regarding 5014. At the point = it is not clear why the recommendations could not be such as: * when IP session reachability only is requires the application indicates a= preference for Public IP addresses * when IP session continuity is needed the application sends a preference f= or home of address. * when none is required the application sends a preference for Care of Addr= ess. While on demand is mentioned in the title, it does not appear in the introd= uction. I believe the introduction should expose why there is a need to hav= e this feature. 2. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Solution 3.1. Types of IP Addresses Four types of IP addresses are defined with respect to mobility management. - Fixed IP Address A Fixed IP address is an address with a guarantee to be valid for a very long time, regardless of whether it is being used in any packet to/from the mobile host, or whether or not the mobile host is connected to the network, or whether it moves from one point-of- attachment to another (with a different IP prefix) while it is connected. Thought english is not my first language, "guarantee" sounds a bit inapprop= riate. I might be wrong but the following text seems clearer to me: OLD: A Fixed IP address is an address with a guarantee to be valid for a very long time NEW: A Fixed IP address is an address that remains valid for a very long time Fixed IP addresses are required by applications that need both session continuity and IP address reachability. I think the document should clarify how this is different from a public add= ress 5014. - Session-lasting IP Address A session-lasting IP address is an address with a guarantee to be valid throughout the life-time of the socket(s) for which it was requested. It is guaranteed to be valid even after the mobile host had moved from one point-of-attachment to another (with a different IP prefix). Similarly I would propose the following text: OLD: A session-lasting IP address is an address with a guarantee to be valid throughout the life-time of the socket(s) NEW: A session-lasting IP address is an address valid throughout the life-time of the socket(s) OLD: It is guaranteed to be valid even after NEW: It remains valid even after Yegin, et al. Expires January 27, 2019 [Page 4] Internet-Draft On Demand Mobility July 2018 Session-lasting IP addresses are required by applications that need session continuity but do not need IP address reachability. Home of Address provides IP reachability, but it is unclear if IP session c= ontinuity can be provided by other mechanisms that Mobile IP. If that were the case, it would be good to specify how this coudl be provid= ed without IP reachability. - Non-persistent IP Address This type of IP address has no guarantee to exist after a mobile host moves from one point-of-attachment to another, and therefore, no session continuity nor IP address reachability are provided. The IP address is created from an IP prefix that is obtained from the serving IP gateway and is not maintained across gateway changes. In other words, the IP prefix may be released and replaced by a new one when the IP gateway changes due to the movement of the mobile host forcing the creation of a new source IP address with the updated allocated IP prefix. It woudl be good to position this toward the care of address. - Graceful Replacement IP Address In some cases, the network cannot guarantee the validity of the provided IP prefix throughout the duration of the opened socket, but can provide a limited graceful period of time in which both the original IP prefix and a new one are valid. This enables the application some flexibility in the transition from the existing source IP address to the new one. This gracefulness is still better than the non-persistence type of address for applications that can handle a change in their source IP address but require that extra flexibility. The classes defined above have overlaps. I believe that we have: Fixed IP Address \in Session-lasting IP Address \in Graceful Replacement IP= Address \in Non-persistent IP Address I think that should be stated in the section. Applications running as servers at a published IP address require a Fixed IP Address. Long-standing applications (e.g., an SSH session) may also require this type of address. Enterprise applications that connect to an enterprise network via virtual LAN require a Fixed IP Address. Applications with short-lived transient sessions can use Session- lasting IP Addresses. For example: Web browsers. Applications with very short sessions, such as DNS clients and instant messengers, can utilize Non-persistent IP Addresses. Even though they could very well use Fixed or Session-lasting IP Addresses, the transmission latency would be minimized when a Non- persistent IP Addresses are used. Applications that can tolerate a short interruption in connectivity can use the Graceful-replacement IP addresses. For example, a streaming client that has buffering capabilities. Yegin, et al. Expires January 27, 2019 [Page 5] Internet-Draft On Demand Mobility July 2018 3.2. Granularity of Selection IP address type selection is made on a per-socket granularity. Different parts of the same application may have different needs. For example, the control-plane of an application may require a Fixed IP Address in order to stay reachable, whereas the data-plane of the same application may be satisfied with a Session-lasting IP Address. 3.3. On Demand Nature At any point in time, a mobile host may have a combination of IP addresses configured. Zero or more Non-persistent, zero or more Session-lasting, zero or more Fixed and zero or more Graceful- Replacement IP addresses may be configured by the IP stack of the host. The combination may be as a result of the host policy, application demand, or a mix of the two. Listing the different classes in the same order as the one of the definitio= ns may ease the reading. When an application requires a specific type of IP address and such an address is not already configured on the host, the IP stack SHALL attempt to configure one. For example, a host may not always have a Session-lasting IP address available. When an application requests one, the IP stack SHALL make an attempt to configure one by issuing a request to the network (see Section 3.4 below for more details). If the operation fails, the IP stack SHALL fail the associated socket request and return an error. If successful, a Session-lasting IP Address gets configured on the mobile host. If another socket requests a Session-lasting IP address at a later time, the same IP address may be served to that socket as well. When the last socket using the same configured IP address is closed, the IP address may be released or kept for future applications that may be launched and require a Session-lasting IP address. I suspect the application is expected to request the type of IP with minima= l capabilities. In some cases the OS may not have the requested type of add= ress bu may have another type of addresses that could fulfill the applicati= on requirements. I believe the text should specify what should be done in t= his situation. I suppose the text will say that the host sends a request to= the network. However, I suspect that allowing the OS to return higher capabilities would= encourage the applications to send a minimal level of expectation so to ma= ximize the probability of avoiding a interaction between the host and the n= etwork to request the specific type of IP address. In some cases it might be preferable for the mobile host to request a new Session-lasting IP address for a new opening of an IP socket (even though one was already assigned to the mobile host by the network and might be in use in a different, already active IP sockets). It is outside the scope of this specification to define criteria for choosing to use available addresses or choosing to request new ones. It supports both alternatives (and any combination). It is outside the scope of this specification to define how the host requests a specific type of prefix and how the network indicates the type of prefix in its advertisement or in its reply to a request). The following are matters of policy, which may be dictated by the host itself, the network operator, or the system architecture standard: Yegin, et al. Expires January 27, 2019 [Page 6] Internet-Draft On Demand Mobility July 2018 - The initial set of IP addresses configured on the host at boot time. - Permission to grant various types of IP addresses to a requesting application. - Determination of a default address type when an application does not make any explicit indication, whether it already supports the required API or it is just a legacy application. 3.4. Conveying the Desired Address Type [RFC5014] introduced the ability of applications to influence the source address selection with the IPV6_ADDR_PREFERENCE option at the IPPROTO_IPV6 level. This option is used with setsockopt() and getsockopt() calls to set/get address selection preferences. Extending this further by adding more flags does not work when a request for an address of a certain type results in requiring the IP stack to wait for the network to provide the desired source IP prefix and hence causing the setsockopt() call to block until the prefix is allocated (or an error indication from the network is received). One thing is the value of the flags, another thing is the behaviour of the = API. So I understand that the new API provides more flexibility in the sens= e that a requirement that cannot be fulfilled does not necessarily end up i= n an error. Instead it can lead in an IP address that does not fulfill the = application requirement. If that is correct, this is still something the ap= plication will have to deal with. IN one case, it will need to deal with an= error, in the other case, with something that does not fulfill the require= ments. If that is correct, I believe the benefit of it should be highlighte= d. Alternatively a new socket API is defined - getsc() which allows applications to express their desired type of session continuity service. The new getsc() API will return an IPv6 address that is associated with the desired session continuity service and with status information indicating whether or not the desired service was provided. An application that wishes to secure a desired service will call getsc() with the service type definition and a place to contain the provided IP address, and call bind() to associate that IP address with the socket (See pseudo-code example in Section 4 below). When the IP stack is required to use a source IP address of a specified type, it can use an existing address, or request a new IP prefix (of the same type) from the network and create a new one. If the host does not already have an IPv6 prefix of that specific type, it MUST request one from the network. Using an existing address from an existing prefix is faster but might yield a less optimal route (if a hand-off event occurred after its configuration). On the other hand, acquiring a new IP prefix from the network may be slower due to signaling exchange with the network. Applications can control the stack's operation by setting a new flag - ON_NET flag - which directs the IP stack whether to use a Yegin, et al. Expires January 27, 2019 [Page 7] Internet-Draft On Demand Mobility July 2018 preconfigured source IP address (if exists) or to request a new IPv6 prefix from the current serving network and configure a new IP address. This new flag is added to the set of flags in the IPV6_ADDR_PREFERENCES option at the IPPROTO_IPV6 level. It is used in setsockopt() to set the desired behavior. My understanding of the flag is that it forces the OS to request the networ= k. This means that even if it already has teh desired IP address the ON_NET= flag set will force the OS to re-ask. When unset, the decision to re-ask o= r not is let to the OS. IS that correct ? 4. Usage example 4.1. Pseudo-code example It would be good the example also shows the ON_NET flag. The following example shows pseudo-code for creating a Stream socket (TCP) with a Session-Lasting source IP address: #include #include // Socket information int s ; // socket id // Source information (for secsc() and bind()) sockaddr_in6 sourceInfo // my address and port for bind() in6_addr sourceAddress // will contain the provisioned // source IP address uint8_t sc_type =3D IPV6_REQUIRE_SESSION_LASTING_IP ; // For requesting a Session-Lasting // source IP address // Destination information (for connect()) sockaddr_in6 serverInfo ; // server info for connect() // Create an IPv6 TCP socket s =3D socket(AF_INET6, SOCK_STREAM, 0) ; if (s!=3D0) { // Handle socket creation error // ... } // if socket creation failed else { // Socket creation is successful // The application cannot connect yet, since it wants to use // a Session-Lasting source IP address It needs to request // the Session-Lasting source IP before connecting if (setsc(s, &sourceAddress, &sc_type)) =3D=3D 0){ // setting session continuity to Session Lasting is // Successful. sourceAddress now contains the Session- // LAsting source IP address s/LAsting/Lasting/gc Yegin, et al. Expires January 27, 2019 [Page 8] Internet-Draft On Demand Mobility July 2018 // Bind to that source IP address sourceInfo.sin6_family =3D AF_INET6 ; sourceInfo.sin6_port =3D 0 // let the stack choose the port sourceInfo.sin6_address =3D sourceAddress ; // Use the source address that was // generated by the setsc() call if (bind(s, &sourceInfo, sizeof(sourceInfo))=3D=3D0){ // Set the desired server's information for connect() serverInfo.sin6_family =3D AF_INET6 ; serverInfo.sin6_port =3D SERVER_PORT_NUM ; serverAddress.sin6_addr =3D SERVER_IPV6_ADDRESS ; // Connect to the server if (connect(s, &serverInfo, sizeof(serverInfo))=3D=3D0) { // connect successful (3-way handshake has been // completed with Session-Lasting source address. // Continue application functionality // ... } // if connect() is successful else { // connect failed // ... // Application code that handles connect failure and // closes the socket // ... } // if connect() failed } // if bind() successful else { // bind() failed // ... // Application code that handles bind failure and // closes the socket // ... } // if bind() failed } // if setsc() was successful and of a Session-Lasting // source IP address was provided else { // application code that does not use Session-lasting IP // address. The application may either connect without // the desired Session-lasting service, or close the // socket... } // if setsc() failed } // if socket was created successfully // The rest of the application's code // ... Yegin, et al. Expires January 27, 2019 [Page 9] Internet-Draft On Demand Mobility July 2018 4.2. Message Flow example The following message flow illustrates a possible interaction for achieving OnDemand functionality. It is an example of one scenario and should not be regarded as the only scenario or the preferred one. OnDemand versus On Demand versus On-Demand. The text should be consis= tent. This flow describes the interaction between the following entities: - Applications requiring different types of OnDemand service. - The mobile host's IP stack. - The network infrastructure providing the services. In this example, the network infrastructure provides 2 IPv6 prefixes upon attachment of the mobile host to the network: A Session-lasting IPv6 prefix and a Non-persistent IPv6 prefix. Whenever the mobile host moves to a different point-of-attachment, the network infrastructure provides a new Non-persistent IPv6 address. In this example, the network infrastructure does not support Fixed IP addresses nor Graceful-replacement IP addresses. Whenever an application opens an IP socket and requests a specific IPv6 address type, the IP stack will provide one from its available IPv6 prefixes or return an error message if the request cannot be fulfilled. Message Flow: - The mobile device attaches to the network. - The Network provides two IPv6 prefixes: PREFsl1 - a Session-lasting IPv6 prefix and PREFnp1 - a Non-persistent IP v6 prefix. IP v6/IPv6/gc It would ease the reading if the mechanism used to specify the Type o= f the address by the operator to the host being described - at least an exa= mple. - An application on the mobile host is launched. It opens an IP socket and requests a Non-persistent IPv6 address. - The IP stack provides IPnp1 which is generated from PREFnp1. - Another application is launched, requesting a Non-persistent IPv6 address. - The IP stack provides IPnp1 again. - A third application is launched. This time, it requires a Session- lasting IPv6 address. second ? Yegin, et al. Expires January 27, 2019 [Page 10] Internet-Draft On Demand Mobility July 2018 - The IP stack provides IPsl1 which is generated from PREFsl1. - The mobile hosts moves to a new point-of-attachment. - The network provides a new Non-persistent IPv6 prefix - PREFnp2. PREFnp1 is no longer valid. - The applications that were given IPnp1 re-establish the socket and receive a new IPv6 address - IPnp2 which is generated from PREFnp2 - The application that is using IPsl1 can still use it since the network guaranteed that PREFsl1 will be valid even after moving to a new point-of-attachment. - A new application is launched, this time requiring a Graceful- replacement IPv6 address. - The IP stack returns setsc() with an error since the network does not support this service. - The application re-attempts to open a socket, this time requesting a Session-lasting IPv6 address. - The IP stack provides IPsl1. 5. Backwards Compatibility Considerations Backwards compatibility support is REQUIRED by the following 3 types of entities: - The Applications on the mobile host - The IP stack in the mobile host - The network infrastructure 5.1. Applications Legacy applications that do not support the OnDemand functionality will use the legacy API and will not be able to take advantage of the On-Demand Mobility feature. Applications using the new OnDemand functionality MUST be aware that they may be executed in legacy environments that do not support it. Such environments may include a legacy IP stack on the mobile host, legacy network infrastructure, or both. In either case, the API will return an error code and the invoking applications may just give up and use legacy calls. Yegin, et al. Expires January 27, 2019 [Page 11] Internet-Draft On Demand Mobility July 2018 5.2. IP Stack in the Mobile Host New IP stacks MUST continue to support all legacy operations. If an application does not use On-Demand functionality, the IP stack MUST respond in a legacy manner. The legacy manner does not seems to be a standard way of behavior. It seems= to me as the way the OS used to behave. I believe the draft shoudl be a bi= t more specific here. If the network infrastructure supports On-Demand functionality, the IP stack SHOULD follow the application request: If the application requests a specific address type, the stack SHOULD forward this request to the network. If the application does not request an address type, the IP stack MUST NOT request an address type and leave it to the network's default behavior to choose the type of the allocated IP prefix. If an IP prefix was already allocated to the host, the IP stack uses it and may not request a new one from the network. 5.3. Network Infrastructure The network infrastructure may or may not support the On-Demand functionality. How the IP stack on the host and the network infrastructure behave in case of a compatibility issue is outside the scope of this API specification. I believe that such statement should be made in the introduction with the a= ddition of a list of potential mechanism to provide the type of IP addresse= s by the network. There is a need to have such mechanisms since the OS cann= ot derive the properties from the IP address itself. Which was teh case wit= h Home of address, care of address, cga.... 5.4. Merging this work with RFC5014 [RFC5014] defines new flags that may be used with setsockopt() to influence source IP address selection for a socket. The list of flags include: source home address, care-of address, temporary address, public address CGA (Cryptographically Created Address) and non-CGA. When applications require session continuity service and use setsc() and bind(), they SHOULD NOT set the flags specified in [RFC5014]. However, if an application sets a specific option using setsockopt() with one of the flags specified in [RFC5014] and also selects a source IP address using setsc() and bind() the IP address that was generated by setsc() and bound using bind() will be the one used by traffic generated using that socket and options set by setsockopt() will be ignored. The sentence above is hard to read - at least to me. I suspect "the" = is missing after "by". What the text says is that after bind setsockopt wil= l be ignored. Correct ? If bind() was not invoked after setsc() by the application, the IP address generated by setsc() will not be used and traffic generated by the socket will use a source IP address that complies with the options selected by setsockopt(). Yegin, et al. Expires January 27, 2019 [Page 12] Internet-Draft On Demand Mobility July 2018 6. Summary of New Definitions Flags and address types should in my opinion be placed in evidence. (.h) 6.1. New APIs setsc() enables applications to request a specific type of source IP address in terms of session continuity. Its definition is: int setsc(int sockfd, in6_addr *sourceAddress, sc_type addressType); Where: - sockfd - is the socket descriptor of the socket with which a specific address type is associated - sourceAddress - is a pointer to an area allocated for setsc() to place the generated source IP address of the desired session continuity type - addressType - Is the desired type of session continuity service. It is a 3-bit field containing one of the following values: 0 - Reserved 1 - FIXED_IPV6_ADDRESS 2 - SESSION_LASTING_IPV6_ADDRESS 3 - NON_PERSISTENT_IPV6_ADDRESS 4 - GRACEFUL_REPLACEMENT_IPV6_ADDRESS 5-7 - Reserved setsc() returns the status of the operation: - 0 - Address was successfully generated - EAI_REQUIREDIPNOTSUPPORTED - the required service type is not supported - EAI_REQUIREDIPFAILED - the network could not fulfill the desired request setsc() MAY block the invoking thread if it triggers the TCP/IP stack to request a new IP prefix from the network to construct the desired source IP address. If an IP prefix with the desired session continuity features already exists (was previously allocated to the mobile host) and the stack is not required to request a new one as a result of setting the IPV6_REQUIRE_SRC_ON_NET flag (defined below), setsc() MAY return immediately with the constructed IP address and will not block the thread. 6.2. New Flags The following flag is added to the list of flags in the IPV6_ADDR_PREFERENCE option at the IPPROTO6 level: IPV6_REQUIRE_SRC_ON_NET - set IP stack address allocation behavior Yegin, et al. Expires January 27, 2019 [Page 13] Internet-Draft On Demand Mobility July 2018 If set, the IP stack will request a new IPv6 prefix of the desired type from the current serving network and configure a new source IP address. If reset, the IP stack will use a preconfigured one if it exists. If there is no preconfigured IP address of the desired type, a new prefix will be requested and used for creating the IP address. 7. Security Considerations The setting of certain IP address type on a given socket may be restricted to privileged applications. For example, a Fixed IP Address may be provided as a premium service and only certain applications may be allowed to use them. Setting and enforcement of such privileges are outside the scope of this document. I believe the text could describe the threat such recommendation is address= ing. The document describes how applications provides the OS their requirements = in order to select the appropriated IP address. The resource are associated= to different costs. While the cost is primarily on the operator side, it i= s likely that usage by the mobile node comes with some restrictions, limita= tion or direct cost. Typically, some type of IP address may be provided by = the operator for a limited number of bytes upon which the IP address type w= ill not be available to the mobile node or may be charged. A malicious appl= ication may use these limitations to generate extra billing of the mobile n= ode or to prevent the usage of some applications by exhausting the expected= type of IP address. In order to prevent such scenario, the mobile node SHOULD be able to author= ize specific PI address types to privilege application. With these new types of IP addresses, the IP address leaks some connectivit= y requirements of the application. This also means that additional informat= ion is provided to the destination which could reveal to a passive monitori= ng attacker some information such as the type of application and the applic= ation itself even though the packet is protected by IPsec or TLS. To avoid profiling an application according to the type of IP addresses, it= is expected that prefixes provided by the operator are associated to vario= us type of addresses over time. As a result, the type of address could not = be associated to the prefix, making application profiling based on the type= of address harder. Application using multiple type of IP addresses to avoid being profiled is = likely to create some patterns. So that remains a hard problem to solve by = the application. The usage of a fixed IP address, enables tracking the mobile node, or its a= pplication over time. This is a similar problem as the one encountered with= Public IP addresses. The usage of the Fixed IP addresses should be limited. To limit the effect of IP tracking, the application or the OS should ensure= that IP addresses regularly change to limit IP tracking by a passive obser= ver. The application should regularly set the On Demand flag. The applicat= ion should be able to ensure that session lasting IP address are regularly = changed by setting a lifetime for example handled by the application. In ad= dition, the application should consider the use of graceful replacement IP = addresses. Similarly, the OS may also associated IP addresses with a lifetime. Upon re= ceiving a request for a given type of IP address, after some time, the OS s= hould request a new address to the network even if it already has one IP ad= dress available with the requested type. This includes any type of IP addre= ss. Addresses of type graceful replacement or non persistent IP addresses s= hould be regularly renewed by the OS. The lifetime of an IP address may be expressed in number of seconds or in u= mber of bytes sent through this IP address. Session lasting IP address could be used to avoid tracking and should be pr= eferred. However, there should be a way to specify between one session last= ing or if the IP address can last multiple sessions. 8. IANA Considerations This document has no IANA considerations. 9. Contributors This document was merged with [I-D.sijeon-dmm-use-cases-api-source]. We would like to acknowledge the contribution of the following people to that document as well: Sergio Figueiredo Altran Research, France Email: sergio.figueiredo@altran.com Younghan Kim Soongsil University, Korea Email: younghak@ssu.ac.kr John Kaippallimalil Huawei, USA Email: john.kaippallimalil@huawei.com 10. Acknowledgements We would like to thank Wu-chi Feng, Alexandru Petrescu, Jouni Korhonen, Sri Gundavelli, Dave Dolson and Lorenzo Colitti for their valuable comments and suggestions on this work. 11. References Yegin, et al. Expires January 27, 2019 [Page 14] Internet-Draft On Demand Mobility July 2018 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, DOI 10.17487/RFC5014, September 2007, . 11.2. Informative References [I-D.sijeon-dmm-use-cases-api-source] Jeon, S., Figueiredo, S., Kim, Y., and J. Kaippallimalil, "Use Cases and API Extension for Source IP Address Selection", draft-sijeon-dmm-use-cases-api-source-07 (work in progress), September 2017. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, . [RFC5563] Leung, K., Dommety, G., Yegani, P., and K. Chowdhury, "WiMAX Forum / 3GPP2 Proxy Mobile IPv4", RFC 5563, DOI 10.17487/RFC5563, February 2010, . [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, DOI 10.17487/RFC5944, November 2010, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, . Yegin, et al. Expires January 27, 2019 [Page 15] Internet-Draft On Demand Mobility July 2018 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, . Authors' Addresses Alper Yegin Actility Istanbul Turkey Email: alper.yegin@actility.com Danny Moses Intel Corporation Petah Tikva Israel Email: danny.moses@intel.com Kisuk Kweon Samsung Suwon South Korea Email: kisuk.kweon@samsung.com Jinsung Lee Samsung Suwon South Korea Email: js81.lee@samsung.com Jungshin Park Samsung Suwon South Korea Email: shin02.park@samsung.com Yegin, et al. Expires January 27, 2019 [Page 16] Internet-Draft On Demand Mobility July 2018 Seil Jeon Sungkyunkwan University Suwon South Korea Email: seiljeon@skku.edu Yegin, et al. Expires January 27, 2019 [Page 17] _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC281441C1044HASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Daniel,

 

Thanks for a very thorough review and the detaile= d comments. I appreciate your invested time.

 

There were one or two comments I did not fully un= derstand.

I have used many of them to improve the document.= There were some which I thought differently and provided by reasoning.

 

Please see my detailed response below.=

Thanks and regards,

Danny

 

1.      “inefficiencies̶= 1; seem too vague…

I am adding a reference to RFC 7333= that describe these inefficiencies in section 4.

2.      Use “IP session cont= inuity” rather than “session continuity”

The original definition was “= IP session continuity”. However, Brian Haberman in the early review c= ommented that this term is confusing since the IP layer is not a session la= yer and thus, “IP Session” is not defined. To resolve this, we agreed to change “IP session continuity” to &= #8220;session continuity” in version 15 of this draft. I feel comfort= able with any of these definitions, so if the reviewers can agree on a term= , I will adopt it. In any case, I believe the text clearly describe the behavior of the network.

3.      Recommended reordering of = the text in section 1.

I did not understand the recommende= d order, that is, which paragraph needs to be moved to which place. Please = help clarify this comment.

4.      Replace ‘ping’= with a more useful application as an example.

Use text messaging instead.

5.      Split the feature versus i= ts implementation should be done in a similar manner for both session conti= nuity and reachability to ease reading.

After giving it some thought, I ten= d to think differently. This is the Introduction section and as such should= be short. I do not think the splitting is needed to understand the rest of= the document. I prefer to keep this section short.

6.      Add a paragraph that indic= ates the address reachability can be performed by applications using other = means than IP reachability.

I do not think this is required. Th= e motivation of this Introduction is to convince the reader that there is a= benefit from enabling applications to indicate their requirements from the= mobile network, rather than getting the full service support. I think the message is clear as it is.

7.      Add a reference to RFC 501= 4 and the usage of home and care-of addresses.

Actually, for mobile IP, this docum= ent is not required. If the mobile host supports mobile IP, it can enable a= pplications to select either a home address or a care-of address to use for= the IP connection and by that, use or choose not to use mobility services prided by the mobile network.<= /o:p>

This document addresses the case wh= ere the network provide these services by proxy and thus, provides the full= mobility service regardless of whether or not they are needed.<= /p>

For proxy services, we need a way f= or applications to express their true needs and for the network stack to co= nvey these needs to the network. 

8.      Indicate ‘on demand&= #8217; in the Introduction.

I thought this is clear from the fa= ct that each application indicates it mobility service requirements. As app= lications could be launched separately from each other with possible large = time gaps, on-demand is deducted. But to be on the safe side, I will add ‘on demand’.=

9.      In the several definitions= of types IP address in section 3 replace ‘guarantee’ with R= 16;remains’

I prefer ‘guarantee’ be= cause it better indicates the commitment of the network to preserve the add= ress.

10.   A suggestion regarding the= definition of Non-persistent IP address.

I did not quite understand this sug= gestion. Something to do with Home Address and mobile IP. However, I believ= e the definition of Non-persistent IP address in this section is good as it= is.

11.   There are additional comme= nts regarding mobile IP.

As I indicated before, this documen= t is not about mobile IP where the mobile host has control over the selecti= on of care-of versus Home addresses. It is about proxy solutions, in which = the mobile host does not have any control over the mobility service because it is done by-proxy by the netwo= rk.

12.   Need to mention the overla= ps of the address types.

Yes, there are overlaps but I do no= t see why mentioning them helps.

13.   List the different address= types in the same order in all sections to ease the reading.

I agree. Changing the order in sect= ion 3.3.

14.   A comment about having the= application request the minimal capability and the network automatically p= roviding the next level if it cannot fulfill this minimal level.=

This is a point we considered along= with enabling applications to request several levels in parallel and letti= ng the network select the most preferable one. After some evaluation, we de= cided that this flexibility is counter-productive and it is best to specify a specific service type, and expect it to either= be fulfilled or have the request fail. This way, no ‘smart’ de= cisions are made automatically by the network. Remember however, that the a= pplication requests the service from the network stack, and the network stack requests it from the network. We do not provi= de any restrictions on the implementations of network stacks. Some could pe= rform caching of network capabilities, and select to respond to application= s without interacting with the network. 

15.   Another comment about the = behavior of the API, assuming a request might not be fulfilled without resu= lting in an error response.

So as I described previously, API r= equests that cannot be fulfilled exactly as specified, result with an error= response.

16.   A question about the ON_NE= T flag.

Yes, your understanding is correct.=

17.   Request an example with th= e ON_NET flag.

There could be other examples as we= ll. There are all kinds of cases that could be presented. There is a trade-= off between the size of an RFC and a text book. We thought it would be usef= ul to provide an example of a non-trivial case and leave other cases to future text books and tutorials.  =

18.   OnDeman versus On Demand v= ersus On-Demand. Be consistent.

I agree. Will be fixed.<= /p>

19.   IP v6 versus IPv6. Be cons= istent.

I agree. Will be fixed.<= /p>

20.   Describe the mechanism in = which the address type is indicated by the network to the host.<= /p>

Unfortunately I cannot. Such a mech= anism does not exist at the moment. We are working on that as well.

21.   In section 5.2, need to de= scribe how the new IP stack needs to behave when an application that does n= ot support On-Demand opens initiates a network connection. ‘legacy ma= nner’ is not a good description.

The next paragraph in this section = does exactly that. Describes how the IP stack should interact with the netw= ork.

22.   Place the statement about = networks supporting or not supporting On-Demand functionality in the introd= uction.

I prefer not to do that. I am tryin= g to keep the Introduction short and crisp. Listing all use-cases, backward= s compatibility and other details – for that we have the rest of the = document. The ‘Introdcution’ in my opinion should only provide information to help the reader decide it it should con= tinue reading the document or not.

23.   The description regarding = the use-case of using both setsockopt() and setsc()/bind() is hard to read.= Clarify.

OK. I will try to simplify it. By t= he way, your understanding is correct.

24.   A comment about the placem= ent of the flags and address types.

I did not quite get this comment. I= would like to clarify that we are providing the Socket API as an example t= o clarify the concept. We expect other standard bodies to use this document= to specify the exact implementation in different programming languages.

25.   Security threats.

I would like some clarification abo= ut these threats. My understanding is that these threats are relevant to th= e protocol use by the mobile host (or specifically its IP stack) to interac= t with the network to convey the desired mobility service, and receive the granted service.

But this document does not define the= se protocols. It defines the On-Demand concept and the features needed by t= he API between applications and the network stack. Shouldn’t these th= reats be described in the specification of the protocol between the mobile host and network?

 

 

 

 

 =

-----Original= Message-----
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Daniel Migault
Sent: Wednesday, January 16, 2019 04:57
To: secdir@ietf.org
Cc: draft-ietf-dmm-ondemand-mobility.all@ietf.org; ietf@ietf.org; dmm@ietf.= org
Subject: [DMM] Secdir last call review of draft-ietf-dmm-ondemand-mobility-= 15

 

Reviewer: Daniel Migault

Review result: Not Ready

 

Hi,

 

I am the assigned Secdir reviewer for this draft.= The Security Directorate

(Secdir) reviews all IETF documents being process= ed by the IESG for the IETF  Chair.  Please treat these comments = just like any other last call comments.

 

Yours,

Daniel

 

        &= nbsp;            On = Demand Mobility Management

        &= nbsp;         draft-ietf-dmm-ondema= nd-mobility-15

 

Abstract

 

   Applications differ with respect to = whether they need session

   continuity and/or IP address reachab= ility.  The network providing the

   same type of service to any mobile h= ost and any application running

   on the host yields inefficiencies.

<mglt>

"inefficiencies" seems too vague to me = and it could be clarified.

Reading the abstract, it is unclear (to me) if th= e issue is on the application side or the network operator side. I guess th= is is the network side. It is also unclear the nature of the inefficiency.<= o:p>

</mglt>

 

   This document describes a=

   solution for taking the application = needs into account by selectively

   providing session continuity and IP = address reachability on a per-

   socket basis.

 

Status of This Memo

 

   This Internet-Draft is submitted in = full conformance with the

   provisions of BCP 78 and BCP 79.

 

   Internet-Drafts are working document= s of the Internet Engineering

   Task Force (IETF).  Note that o= ther groups may also distribute

   working documents as Internet-Drafts= .  The list of current Internet-

   Drafts is at https://datatracker.i= etf.org/drafts/current/.

 

   Internet-Drafts are draft documents = valid for a maximum of six months

   and may be updated, replaced, or obs= oleted by other documents at any

   time.  It is inappropriate to u= se Internet-Drafts as reference

   material or to cite them other than = as "work in progress."

 

   This Internet-Draft will expire on J= anuary 27, 2019.

 

Copyright Notice

 

   Copyright (c) 2018 IETF Trust and th= e persons identified as the

   document authors.  All rights r= eserved.

 

Yegin, et al.      =      Expires January 27, 2019    &n= bsp;           [Page 1]

 

Internet-Draft      = ;       On Demand Mobility   &= nbsp;           &nbs= p;  July 2018

 

   This document is subject to BCP 78 a= nd the IETF Trust's Legal

   Provisions Relating to IETF Document= s

   (https:= //trustee.ietf.org/license-info) in effect on the date of

   publication of this document.  = Please review these documents

   carefully, as they describe your rig= hts and restrictions with respect

   to this document.  Code Compone= nts extracted from this document must

   include Simplified BSD License text = as described in Section 4.e of

   the Trust Legal Provisions and are p= rovided without warranty as

   described in the Simplified BSD Lice= nse.

 

Table of Contents

 

   1.  Introduction  . . . . = . . . . . . . . . . . . . . . . . . . .   2

   2.  Notational Conventions = ; . . . . . . . . . . . . . . . . . . .   4

   3.  Solution  . . . . . . = . . . . . . . . . . . . . . . . . . . .   4

     3.1.  Types of IP A= ddresses . . . . . . . . . . . . . . . . . .   4

     3.2.  Granularity o= f Selection  . . . . . . . . . . . . . . . .   6<= /p>

     3.3.  On Demand Nat= ure  . . . . . . . . . . . . . . . . . . . .   6<= /p>

     3.4.  Conveying the= Desired Address Type  . . . . . . . . . . .   7<= /p>

   4.  Usage example . . . . . . .= . . . . . . . . . . . . . . . . .   8

     4.1.  Pseudo-code e= xample . . . . . . . . . . . . . . . . . . .   8

     4.2.  Message Flow = example  . . . . . . . . . . . . . . . . . .  10

   5.  Backwards Compatibility Con= siderations  . . . . . . . . . . .  11

     5.1.  Applications&= nbsp; . . . . . . . . . . . . . . . . . . . . . .  11

     5.2.  IP Stack in t= he Mobile Host . . . . . . . . . . . . . . .  12

     5.3.  Network Infra= structure  . . . . . . . . . . . . . . . . .  12

     5.4.  Merging this = work with RFC5014  . . . . . . . . . . . . .  12

   6.  Summary of New Definitions&= nbsp; . . . . . . . . . . . . . . . . .  13

     6.1.  New APIs = ; . . . . . . . . . . . . . . . . . . . . . . . .  13

     6.2.  New Flags . .= . . . . . . . . . . . . . . . . . . . . . .  13

   7.  Security Considerations . .= . . . . . . . . . . . . . . . . .  14

   8.  IANA Considerations . . . .= . . . . . . . . . . . . . . . . .  14

   9.  Contributors  . . . . = . . . . . . . . . . . . . . . . . . . .  14

   10. Acknowledgements  . . . . .= . . . . . . . . . . . . . . . . .  14

   11. References  . . . . . . . .= . . . . . . . . . . . . . . . . .  14

     11.1.  Normative Re= ferences . . . . . . . . . . . . . . . . . .  15

     11.2.  Informative = References . . . . . . . . . . . . . . . . .  15

   Authors' Addresses  . . . . . .= . . . . . . . . . . . . . . . . .  16

 

1.  Introduction

 

   In the context of Mobile IP [RFC5563= ][RFC6275][RFC5213][RFC5944], the

   following two attributes are defined= for IP service provided to

   mobile hosts:

 

   Session continuity: The ability to m= aintain an ongoing transport

   interaction by keeping the same loca= l end-point IP address throughout

   the life-time of the IP socket despi= te the mobile host changing its

 

Yegin, et al.      =      Expires January 27, 2019    &n= bsp;           [Page 2]

 

Internet-Draft      = ;       On Demand Mobility   &= nbsp;           &nbs= p;  July 2018

 

   point of attachment within the IP ne= twork topology.  The IP address

   of the host may change after closing= the IP socket and before opening

   a new one, but that does not jeopard= ize the ability of applications

   using these IP sockets to work flawl= essly.  Session continuity is

   essential for mobile hosts to mainta= in ongoing flows without any

   interruption.

 

<mglt>

Session continuity can be provided at multiple la= yers thus I would recommend for clarity to change session continuity to IP = session continuity and insists that this is being provided at the IP layer.=

 

Not that IP is sessionless, so here session seems= similar to reachability but 'orchestrated' by a higher session protocol.

The difference I see is that reachability is a co= mmitment (by the ISP) for not changing the IP address while with session co= ntinuity the commitment is related to the use of the IP address. In other w= ords, with a limited period of time.

</mglt>

 

   IP address reachability: The ability= to maintain the same IP address

   for an extended period of time. = ; The IP address stays the same across

   independent sessions, and even in th= e absence of any session.  The IP

   address may be published in a long-t= erm registry (e.g., DNS), and is

   made available for serving incoming = (e.g., TCP) connections.  IP

   address reachability is essential fo= r mobile hosts to use specific/

   published IP addresses.

 

   Mobile IP is designed to provide bot= h session continuity and IP

   address reachability to mobile hosts= .  Architectures utilizing these

   protocols (e.g., 3GPP, 3GPP2, WIMAX)= ensure that any mobile host

   attached to the compliant networks c= an enjoy these benefits.  Any

   application running on these mobile = hosts is subjected to the same

   treatment with respect to session co= ntinuity and IP address

   reachability.

 

<mglt>

My understanding of the text is that Mobile IP is= expensive to deploy and I believe it would be easier for the reader to sta= te it here before developing all mechanisms that have been designed to over= come session continuity in a different way. Thus I would put the following text right

here:

   Achieving session continuity and IP = address reachability with Mobile

   IP incurs some cost.  Mobile IP= protocol forces the mobile host's IP

   traffic to traverse a centrally-loca= ted router (Home Agent, HA),

   which incurs additional transmission= latency and use of additional

   network resources, adds to the netwo= rk CAPEX and OPEX, and decreases

   the reliability of the network due t= o the introduction of a single

   point of failure [RFC7333].  Th= erefore, session continuity and IP

   address reachability SHOULD be provi= ded only when necessary.

</mglt>

 

   It should be noted that in reality n= ot every application may need

   these benefits.  IP address rea= chability is required for applications

   running as servers (e.g., a web serv= er running on the mobile host).

   But, a typical client application (e= .g., web browser) does not

   necessarily require IP address reach= ability.  Similarly, session

   continuity is not required for all t= ypes of applications either.

   Applications performing brief commun= ication (e.g., ping) can survive

   without having session continuity su= pport.

 

<mglt>

I believe that session continuity is the main mot= ivation of the draft.

Mentioning ping as an example is counter producti= ve as I doubt this is the target application of the draft. Thus citing an a= pplication no one really wants could mean that we have not found any other = application that do not need session continuity, which could be interpreted as every application needs session = continuity at the IP layer. This is not the intention of the text, so we sh= ould find another example.

 

Well I think reachability and session continuity = are two different features. Applications may only need one of these feature= s not both. In addition, application can provide these features at the IP l= ayer layer or using other mechanisms. As a reason the use of Mobile IP is limited to applications that needs bot= h features being performed at the IP layer which only concern a small fract= ion of applications.

 

Reading the text above seems to take for granted = that reachability is performed only at the IP layer. Splitting the feature = versus its implementation should be done in a similar manner for both sessi= on continuity and reachability to ease the reading.

</mglt>

 

   Achieving session continuity and IP = address reachability with Mobile

   IP incurs some cost.  Mobile IP= protocol forces the mobile host's IP

   traffic to traverse a centrally-loca= ted router (Home Agent, HA),

   which incurs additional transmission= latency and use of additional

   network resources, adds to the netwo= rk CAPEX and OPEX, and decreases

   the reliability of the network due t= o the introduction of a single

   point of failure [RFC7333].  Th= erefore, session continuity and IP

   address reachability SHOULD be provi= ded only when necessary.

 

<mglt>

This section should be moved up. Here it is split= ting the discussion on session continuity and reachability, which is confus= ing.

</mglt>

 

   Furthermore, when an application nee= ds session continuity, it may be

   able to satisfy that need by using a= solution above the IP layer,

   such as MPTCP [RFC6824], SIP mobilit= y [RFC3261], or an application-

   layer mobility solution.  These= higher-layer solutions are not

   subject to the same issues that aris= e with the use of Mobile IP since

   they can utilize the most direct dat= a path between the end-points.

   But, if Mobile IP is being applied t= o the mobile host, the higher-

 

Yegin, et al.      =      Expires January 27, 2019    &n= bsp;           [Page 3]

 

Internet-Draft      = ;       On Demand Mobility   &= nbsp;           &nbs= p;  July 2018

 

   layer protocols are rendered useless= because their operation is

   inhibited by Mobile IP.  Since = Mobile IP ensures that the IP address

   of the mobile host remains fixed (de= spite the location and movement

   of the mobile host), the higher-laye= r protocols never detect the IP-

   layer change and never engage in mob= ility management.

 

<mglt>

The same paragraph should say the reachability ca= n be performed by application using other means than IP reachability.<= /o:p>

</mglt>

 

   This document proposes a solution fo= r applications running on mobile

   hosts to indicate whether they need = session continuity or IP address

   reachability.  The network prot= ocol stack on the mobile host, in

   conjunction with the network infrast= ructure, provides the required

   type of service.

 

<mglt>

I assume that session continuity is only understo= od as IP session continuity and not the transport layer.

</mglt>

 

   It is for the benefit of both the us= ers and the

   network operators not to engage an e= xtra level of service unless it

   is absolutely necessary.  It is= expected that applications and

   networks compliant with this specifi= cation will utilize this solution

   to use network resources more effici= ently.

 

<mglt>

The introduction should also position it work reg= arding 5014. At the point it is not clear why the recommendations could not= be such as:

* when IP session reachability only is requires t= he application indicates a preference for Public IP addresses

* when IP session continuity is needed the applic= ation sends a preference for home of address.

* when none is required the application sends a p= reference for Care of Address.

</mglt>

 

<mglt>

While on demand is mentioned in the title, it doe= s not appear in the introduction. I believe the introduction should expose = why there is a need to have this feature.

</mglt>

 

2.  Notational Conventions

 

   The key words "MUST", &quo= t;MUST NOT", "REQUIRED", "SHALL", "SHALL NOT&= quot;,

   "SHOULD", "SHOULD NOT= ", "RECOMMENDED", "MAY", and "OPTIONAL" = in this

   document are to be interpreted as de= scribed in [RFC2119].

 

3.  Solution

 

3.1.  Types of IP Addresses

 

   Four types of IP addresses are defin= ed with respect to mobility

   management.

 

   - Fixed IP Address

 

   A Fixed IP address is an address wit= h a guarantee to be valid for a

   very long time, regardless of whethe= r it is being used in any packet

   to/from the mobile host, or whether = or not the mobile host is

   connected to the network, or whether= it moves from one point-of-

   attachment to another (with a differ= ent IP prefix) while it is

   connected.

 

<mglt>

Thought english is not my first language, "g= uarantee" sounds a bit inappropriate. I might be wrong but the followi= ng text seems clearer to

me:

 

OLD:

A Fixed IP address is an address with a guarantee= to be valid for a

   very long time

 

NEW:

A Fixed IP address is an address that remains val= id for a

   very long time

 

</mglt>

 

   Fixed IP addresses are required by a= pplications that need both

   session continuity and IP address re= achability.

 

<mglt>

I think the document should clarify how this is d= ifferent from a public address 5014.

</mglt>

 

   - Session-lasting IP Address

 

   A session-lasting IP address is an a= ddress with a guarantee to be

   valid throughout the life-time of th= e socket(s) for which it was

   requested.  It is guaranteed to= be valid even after the mobile host

   had moved from one point-of-attachme= nt to another (with a different

   IP prefix).

 

<mglt>

Similarly I would propose the following text:

 

OLD:

  A session-lasting IP address is an address= with a guarantee to be

   valid throughout the life-time of th= e socket(s)

 

NEW:

  A session-lasting IP address is an address=

   valid throughout the life-time of th= e socket(s)

 

OLD:

It is guaranteed to be valid even after

 

NEW:

It remains valid even after

</mglt>

 

Yegin, et al.      =      Expires January 27, 2019    &n= bsp;           [Page 4]

 

Internet-Draft      = ;       On Demand Mobility   &= nbsp;           &nbs= p;  July 2018

 

   Session-lasting IP addresses are req= uired by applications that need

   session continuity but do not need I= P address reachability.

 

<mglt>

Home of Address provides IP reachability, but it = is unclear if IP session continuity can be provided by other mechanisms tha= t Mobile IP.

If that were the case, it would be good to specif= y how this coudl be provided without IP reachability.

</mglt>

 

   - Non-persistent IP Address

 

   This type of IP address has no guara= ntee to exist after a mobile host

   moves from one point-of-attachment t= o another, and therefore, no

   session continuity nor IP address re= achability are provided.  The IP

   address is created from an IP prefix= that is obtained from the

   serving IP gateway and is not mainta= ined across gateway changes.  In

   other words, the IP prefix may be re= leased and replaced by a new one

   when the IP gateway changes due to t= he movement of the mobile host

   forcing the creation of a new source= IP address with the updated

   allocated IP prefix.

 

<mglt>

It woudl be good to position this toward the care= of address.

</mglt>

 

   - Graceful Replacement IP Address

 

   In some cases, the network cannot gu= arantee the validity of the

   provided IP prefix throughout the du= ration of the opened socket, but

   can provide a limited graceful perio= d of time in which both the

   original IP prefix and a new one are= valid.  This enables the

   application some flexibility in the = transition from the existing

   source IP address to the new one.

 

   This gracefulness is still better th= an the non-persistence type of

   address for applications that can ha= ndle a change in their source IP

   address but require that extra flexi= bility.

 

<mglt>

The classes defined above have overlaps. I believ= e that we have:

Fixed IP Address \in Session-lasting IP Address \= in Graceful Replacement IP Address \in Non-persistent IP Address=

 

I think that should be stated in the section.

 

</mglt>

 

   Applications running as servers at a= published IP address require a

   Fixed IP Address.  Long-standin= g applications (e.g., an SSH session)

   may also require this type of addres= s.  Enterprise applications that

   connect to an enterprise network via= virtual LAN require a Fixed IP

   Address.

 

   Applications with short-lived transi= ent sessions can use Session-

   lasting IP Addresses.  For exam= ple: Web browsers.

 

   Applications with very short session= s, such as DNS clients and

   instant messengers, can utilize Non-= persistent IP Addresses.  Even

   though they could very well use Fixe= d or Session-lasting IP

   Addresses, the transmission latency = would be minimized when a Non-

   persistent IP Addresses are used.

 

   Applications that can tolerate a sho= rt interruption in connectivity

   can use the Graceful-replacement IP = addresses.  For example, a

   streaming client that has buffering = capabilities.

 

Yegin, et al.      =      Expires January 27, 2019    &n= bsp;           [Page 5]

 

Internet-Draft      = ;       On Demand Mobility   &= nbsp;           &nbs= p;  July 2018

 

3.2.  Granularity of Selection

 

   IP address type selection is made on= a per-socket granularity.

   Different parts of the same applicat= ion may have different needs.

   For example, the control-plane of an= application may require a Fixed

   IP Address in order to stay reachabl= e, whereas the data-plane of the

   same application may be satisfied wi= th a Session-lasting IP Address.

 

3.3.  On Demand Nature

 

   At any point in time, a mobile host = may have a combination of IP

   addresses configured.  Zero or = more Non-persistent, zero or more

   Session-lasting, zero or more Fixed = and zero or more Graceful-

   Replacement IP addresses may be conf= igured by the IP stack of the

   host.  The combination may be a= s a result of the host policy,

   application demand, or a mix of the = two.

 

<mglt>

Listing the different classes in the same order a= s the one of the definitions may ease the reading.

</mglt>

 

   When an application requires a speci= fic type of IP address and such

   an address is not already configured= on the host, the IP stack SHALL

   attempt to configure one.  For = example, a host may not always have a

   Session-lasting IP address available= .  When an application requests

   one, the IP stack SHALL make an atte= mpt to configure one by issuing a

   request to the network (see Section = 3.4 below for more details).  If

   the operation fails, the IP stack SH= ALL fail the associated socket

   request and return an error.  I= f successful, a Session-lasting IP

   Address gets configured on the mobil= e host.  If another socket

   requests a Session-lasting IP addres= s at a later time, the same IP

   address may be served to that socket= as well.  When the last socket

   using the same configured IP address= is closed, the IP address may be

   released or kept for future applicat= ions that may be launched and

   require a Session-lasting IP address= .

 

<mglt>

I suspect the application is expected to request = the type of IP with minimal capabilities. In some cases the OS may not have= the requested type of address bu may have another type of addresses that c= ould fulfill the application requirements. I believe the text should specify what should be done in this situation. I= suppose the text will say that the host sends a request to the network.

 

However, I suspect that allowing the OS to return= higher capabilities would encourage the applications to send a minimal lev= el of expectation so to maximize the probability of avoiding a interaction = between the host and the network to request the specific type of IP address.

</mglt>

 

   In some cases it might be preferable= for the mobile host to request a

   new Session-lasting IP address for a= new opening of an IP socket

   (even though one was already assigne= d to the mobile host by the

   network and might be in use in a dif= ferent, already active IP

   sockets).  It is outside the sc= ope of this specification to define

   criteria for choosing to use availab= le addresses or choosing to

   request new ones.  It supports = both alternatives (and any

   combination).

 

   It is outside the scope of this spec= ification to define how the host

   requests a specific type of prefix a= nd how the network indicates the

   type of prefix in its advertisement = or in its reply to a request).

 

   The following are matters of policy,= which may be dictated by the

   host itself, the network operator, o= r the system architecture

   standard:

 

Yegin, et al.      =      Expires January 27, 2019    &n= bsp;           [Page 6]

 

Internet-Draft      = ;       On Demand Mobility   &= nbsp;           &nbs= p;  July 2018

 

   - The initial set of IP addresses co= nfigured on the host at boot

   time.

 

   - Permission to grant various types = of IP addresses to a requesting

   application.

 

   - Determination of a default address= type when an application does

   not make any explicit indication, wh= ether it already supports the

   required API or it is just a legacy = application.

 

3.4.  Conveying the Desired Address Type

 

   [RFC5014] introduced the ability of = applications to influence the

   source address selection with the IP= V6_ADDR_PREFERENCE option at the

   IPPROTO_IPV6 level.  This optio= n is used with setsockopt() and

   getsockopt() calls to set/get addres= s selection preferences.

 

   Extending this further by adding mor= e flags does not work when a

   request for an address of a certain = type results in requiring the IP

   stack to wait for the network to pro= vide the desired source IP prefix

   and hence causing the setsockopt() c= all to block until the prefix is

   allocated (or an error indication fr= om the network is received).

 

<mglt>

One thing is the value of the flags, another thin= g is the behaviour of the API. So I understand that the new API provides mo= re flexibility in the sense that a requirement that cannot be fulfilled doe= s not necessarily end up in an error. Instead it can lead in an IP address that does not fulfill the application= requirement. If that is correct, this is still something the application w= ill have to deal with. IN one case, it will need to deal with an error, in = the other case, with something that does not fulfill the requirements. If that is correct, I believe the benef= it of it should be highlighted.

</mglt>

 

   Alternatively a new socket API is de= fined - getsc() which allows

   applications to express their desire= d type of session continuity

   service.  The new getsc() API w= ill return an IPv6 address that is

   associated with the desired session = continuity service and with

   status information indicating whethe= r or not the desired service was

   provided.

 

   An application that wishes to secure= a desired service will call

   getsc() with the service type defini= tion and a place to contain the

   provided IP address, and call bind()= to associate that IP address

   with the socket (See pseudo-code exa= mple in Section 4 below).

 

   When the IP stack is required to use= a source IP address of a

   specified type, it can use an existi= ng address, or request a new IP

   prefix (of the same type) from the n= etwork and create a new one.  If

   the host does not already have an IP= v6 prefix of that specific type,

   it MUST request one from the network= .

 

   Using an existing address from an ex= isting prefix is faster but might

   yield a less optimal route (if a han= d-off event occurred after its

   configuration).  On the other h= and, acquiring a new IP prefix from

   the network may be slower due to sig= naling exchange with the network.

 

   Applications can control the stack's= operation by setting a new flag

   - ON_NET flag - which directs the IP= stack whether to use a

 

Yegin, et al.      =      Expires January 27, 2019    &n= bsp;           [Page 7]

 

Internet-Draft      = ;       On Demand Mobility   &= nbsp;           &nbs= p;  July 2018

 

   preconfigured source IP address (if = exists) or to request a new IPv6

   prefix from the current serving netw= ork and configure a new IP

   address.

 

   This new flag is added to the set of= flags in the

   IPV6_ADDR_PREFERENCES option at the = IPPROTO_IPV6 level.  It is used

   in setsockopt() to set the desired b= ehavior.

 

<mglt>

My understanding of the flag is that it forces th= e OS to request the network. This means that even if it already has teh des= ired IP address the ON_NET flag set will force the OS to re-ask. When unset= , the decision to re-ask or not is let to the OS. IS that correct ?

</mglt>

 

4.  Usage example

 

4.1.  Pseudo-code example

 

<mglt>

It would be good the example also shows the ON_NE= T flag.

</mglt>

 

   The following example shows pseudo-c= ode for creating a Stream socket

   (TCP) with a Session-Lasting source = IP address:

 

   #include <sys/socket.h>

   #include <netinnet/in.h><= /o:p>

 

     // Socket information

   int     &nb= sp;        s ;    &n= bsp;       // socket id

 

     // Source information (f= or secsc() and bind())

   sockaddr_in6    = sourceInfo     // my address and port for bind()<= /o:p>

   in6_addr    &nbs= p;    sourceAddress  // will contain the provisioned

        &= nbsp;           &nbs= p;            &= nbsp; // source IP address

   uint8_t     = ;     sc_type =3D IPV6_REQUIRE_SESSION_LASTING_IP ;

        &= nbsp;           &nbs= p;            &= nbsp; // For requesting a Session-Lasting

        &= nbsp;           &nbs= p;            &= nbsp; // source IP address

 

     // Destination informati= on (for connect())

   sockaddr_in6    = serverInfo ;   // server info for connect()

 

     // Create an IPv6 TCP so= cket

   s =3D socket(AF_INET6, SOCK_STREAM, = 0) ;

   if (s!=3D0) {

         = // Handle socket creation error

         = // ...

   } // if socket creation failed<= /o:p>

   else {

        &= nbsp; // Socket creation is successful

        &= nbsp; // The application cannot connect yet, since it wants to use

        &= nbsp; // a Session-Lasting source IP address It needs to request=

        &= nbsp; // the Session-Lasting source IP before connecting

        if (se= tsc(s, &sourceAddress, &sc_type)) =3D=3D 0){

        &= nbsp;    // setting session continuity to Session Lasting is=

        &= nbsp;    // Successful. sourceAddress now contains the Sessi= on-

        &= nbsp;    // LAsting source IP address <mglt>s/LAsting/= Lasting/gc</mglt>

 

Yegin, et al.      =      Expires January 27, 2019    &n= bsp;           [Page 8]

 

Internet-Draft      = ;       On Demand Mobility   &= nbsp;           &nbs= p;  July 2018

 

        &= nbsp;    // Bind to that source IP address

        &= nbsp;  sourceInfo.sin6_family =3D AF_INET6 ;

        &= nbsp;  sourceInfo.sin6_port =3D 0  // let the stack choose the po= rt

        &= nbsp;  sourceInfo.sin6_address =3D sourceAddress ;

        &= nbsp;           &nbs= p;            &= nbsp; // Use the source address that was

        &= nbsp;           &nbs= p;            &= nbsp; // generated by the setsc() call

        &= nbsp;  if (bind(s, &sourceInfo, sizeof(sourceInfo))=3D=3D0){<= /o:p>

        &= nbsp;       // Set the desired server's infor= mation for connect()

        &= nbsp;     serverInfo.sin6_family =3D AF_INET6 ;

        &= nbsp;     serverInfo.sin6_port =3D SERVER_PORT_NUM ;

        &= nbsp;     serverAddress.sin6_addr =3D SERVER_IPV6_ADDRE= SS ;

 

        &= nbsp;       // Connect to the server

        &= nbsp;     if (connect(s, &serverInfo, sizeof(server= Info))=3D=3D0) {

         =          // connect successful= (3-way handshake has been

        &= nbsp;         // completed with Ses= sion-Lasting source address.

        &= nbsp;         // Continue applicati= on functionality

        &= nbsp;         // ...

        &= nbsp;     }  // if connect() is successful

        &= nbsp;     else {

        &= nbsp;         // connect failed

        &= nbsp;         // ...

        &= nbsp;         // Application code t= hat handles connect failure and

        &= nbsp;         // closes the socket<= o:p>

        &= nbsp;         // ...

        &= nbsp;     } // if connect() failed

        &= nbsp;  } // if bind() successful

        &= nbsp;  else {

        &= nbsp;         // bind() failed=

        &= nbsp;         // ...

        &= nbsp;         // Application code t= hat handles bind failure and

        &= nbsp;         // closes the socket<= o:p>

        &= nbsp;         // ...

        &= nbsp;  } // if bind() failed

        } = ; // if setsc() was successful and of a Session-Lasting

        &= nbsp;  // source IP address was provided

        else {=

        &= nbsp;    // application code that does not use Session-lasti= ng IP

        &= nbsp;    // address. The application may either connect with= out

        &= nbsp;    // the desired Session-lasting service, or close th= e

        &= nbsp;    // socket...

        } // i= f setsc() failed

   }  // if socket was created suc= cessfully

 

     // The rest of the appli= cation's code

     // ...

 

Yegin, et al.      =      Expires January 27, 2019    &n= bsp;           [Page 9]

 

Internet-Draft      = ;       On Demand Mobility   &= nbsp;           &nbs= p;  July 2018

 

4.2.  Message Flow example

 

   The following message flow illustrat= es a possible interaction for

   achieving OnDemand functionality.&nb= sp; It is an example of one scenario

   and should not be regarded as the on= ly scenario or the preferred one.

 

<mglt>OnDemand versus On Demand versus On-D= emand. The text should be consistent. </mglt>

   This flow describes the interaction = between the following entities:

 

   - Applications requiring different t= ypes of OnDemand service.

 

   - The mobile host's IP stack.

 

   - The network infrastructure providi= ng the services.

 

   In this example, the network infrast= ructure provides 2 IPv6 prefixes

   upon attachment of the mobile host t= o the network: A Session-lasting

   IPv6 prefix and a Non-persistent IPv= 6 prefix.  Whenever the mobile

   host moves to a different point-of-a= ttachment, the network

   infrastructure provides a new Non-pe= rsistent IPv6 address.

 

   In this example, the network infrast= ructure does not support Fixed IP

   addresses nor Graceful-replacement I= P addresses.

 

   Whenever an application opens an IP = socket and requests a specific

   IPv6 address type, the IP stack will= provide one from its available

   IPv6 prefixes or return an error mes= sage if the request cannot be

   fulfilled.

 

   Message Flow:

 

   - The mobile device attaches to the = network.

 

   - The Network provides two IPv6 pref= ixes: PREFsl1 - a Session-lasting

   IPv6 prefix and PREFnp1 - a Non-pers= istent IP v6 prefix.

 

<mglt>IP v6/IPv6/gc</mglt>=

<mglt>It would ease the reading if the mech= anism used to specify the Type of the address by the operator to the host b= eing described - at least an example.

</mglt>

 

   - An application on the mobile host = is launched.  It opens an IP

   socket and requests a Non-persistent= IPv6 address.

 

   - The IP stack provides IPnp1 which = is generated from PREFnp1.

 

   - Another application is launched, r= equesting a Non-persistent IPv6

   address.

 

   - The IP stack provides IPnp1 again.=

 

   - A third application is launched.&n= bsp; This time, it requires a Session-

   lasting IPv6 address.

 

<mglt>second ?</mglt>

 

Yegin, et al.      =      Expires January 27, 2019    &n= bsp;          [Page 10]

 

Internet-Draft      = ;       On Demand Mobility   &= nbsp;           &nbs= p;  July 2018

 

   - The IP stack provides IPsl1 which = is generated from PREFsl1.

 

   - The mobile hosts moves to a new po= int-of-attachment.

 

   - The network provides a new Non-per= sistent IPv6 prefix - PREFnp2.

   PREFnp1 is no longer valid.

 

   - The applications that were given I= Pnp1 re-establish the socket and

   receive a new IPv6 address - IPnp2 w= hich is generated from PREFnp2

 

   - The application that is using IPsl= 1 can still use it since the

   network guaranteed that PREFsl1 will= be valid even after moving to a

   new point-of-attachment.<= /p>

 

   - A new application is launched, thi= s time requiring a Graceful-

   replacement IPv6 address.=

 

   - The IP stack returns setsc() with = an error since the network does

   not support this service.=

 

  - The application re-attempts to open= a socket, this time requesting

   a Session-lasting IPv6 address.=

 

   - The IP stack provides IPsl1.<= /o:p>

 

5.  Backwards Compatibility Considerations

 

   Backwards compatibility support is R= EQUIRED by the following 3 types

   of entities:

 

   - The Applications on the mobile hos= t

 

   - The IP stack in the mobile host

 

   - The network infrastructure

 

5.1.  Applications

 

   Legacy applications that do not supp= ort the OnDemand functionality

   will use the legacy API and will not= be able to take advantage of the

   On-Demand Mobility feature.

 

   Applications using the new OnDemand = functionality MUST be aware that

   they may be executed in legacy envir= onments that do not support it.

   Such environments may include a lega= cy IP stack on the mobile host,

   legacy network infrastructure, or bo= th.  In either case, the API will

   return an error code and the invokin= g applications may just give up

   and use legacy calls.

 

Yegin, et al.      =      Expires January 27, 2019    &n= bsp;          [Page 11]

 

Internet-Draft      = ;       On Demand Mobility   &= nbsp;           &nbs= p;  July 2018

 

5.2.  IP Stack in the Mobile Host=

 

   New IP stacks MUST continue to suppo= rt all legacy operations.  If an

   application does not use On-Demand f= unctionality, the IP stack MUST

   respond in a legacy manner.

 

<mglt>

The legacy manner does not seems to be a standard= way of behavior. It seems to me as the way the OS used to behave. I believ= e the draft shoudl be a bit more specific here.

</mglt>

 

   If the network infrastructure suppor= ts On-Demand functionality, the

   IP stack SHOULD follow the applicati= on request: If the application

   requests a specific address type, th= e stack SHOULD forward this

   request to the network.  If the= application does not request an

   address type, the IP stack MUST NOT = request an address type and leave

   it to the network's default behavior= to choose the type of the

   allocated IP prefix.  If an IP = prefix was already allocated to the

   host, the IP stack uses it and may n= ot request a new one from the

   network.

 

5.3.  Network Infrastructure

 

   The network infrastructure may or ma= y not support the On-Demand

   functionality.  How the IP stac= k on the host and the network

   infrastructure behave in case of a c= ompatibility issue is outside the

   scope of this API specification.

 

<mglt>

I believe that such statement should be made in t= he introduction with the addition of a list of potential mechanism to provi= de the type of IP addresses by the network. There is a need to have such me= chanisms since the OS cannot derive the properties from the IP address itself. Which was teh case with Home of= address, care of address, cga....

</mglt>

 

5.4.  Merging this work with RFC5014

 

   [RFC5014] defines new flags that may= be used with setsockopt() to

   influence source IP address selectio= n for a socket.  The list of

   flags include: source home address, = care-of address, temporary

   address, public address CGA (Cryptog= raphically Created Address) and

   non-CGA.  When applications req= uire session continuity service and

   use setsc() and bind(), they SHOULD = NOT set the flags specified in

   [RFC5014].

 

   However, if an application sets a sp= ecific option using setsockopt()

   with one of the flags specified in [= RFC5014] and also selects a

   source IP address using setsc() and = bind() the IP address that was

   generated by setsc() and bound using= bind() will be the one used by

   traffic generated using that socket = and options set by setsockopt()

   will be ignored.

 

<mglt>The sentence above is hard to read - = at least to me. I suspect "the" is missing after "by". = What the text says is that after bind setsockopt will be ignored. Correct ?=

</mglt>

 

   If bind() was not invoked after sets= c() by the application, the IP

   address generated by setsc() will no= t be used and traffic generated

   by the socket will use a source IP a= ddress that complies with the

   options selected by setsockopt().

 

Yegin, et al.      =      Expires January 27, 2019    &n= bsp;          [Page 12]

 

Internet-Draft      = ;       On Demand Mobility   &= nbsp;           &nbs= p;  July 2018

 

6.  Summary of New Definitions

 

<mglt>

Flags and address types should in my opinion be p= laced in evidence. (.h) </mglt>

 

6.1.  New APIs

 

   setsc() enables applications to requ= est a specific type of source IP

   address in terms of session continui= ty.  Its definition is:

 

   int setsc(int sockfd, in6_addr *sour= ceAddress, sc_type addressType);

 

   Where:

    - sockfd -   &n= bsp;    is the socket descriptor of the socket with which

        &= nbsp;           &nbs= p; a specific address type is associated

    - sourceAddress - is a pointer= to an area allocated for setsc() to

        &= nbsp;           &nbs= p; place the generated source IP address of the

        &= nbsp;           &nbs= p; desired session continuity type

    - addressType -   Is= the desired type of session continuity service.

        &= nbsp;           &nbs= p; It is a 3-bit field containing one of the

        &= nbsp;           &nbs= p; following values:

        &= nbsp;           &nbs= p; 0 - Reserved

        &= nbsp;           &nbs= p; 1 - FIXED_IPV6_ADDRESS

        &= nbsp;           &nbs= p; 2 - SESSION_LASTING_IPV6_ADDRESS

        &= nbsp;           &nbs= p; 3 - NON_PERSISTENT_IPV6_ADDRESS

        &= nbsp;           &nbs= p; 4 - GRACEFUL_REPLACEMENT_IPV6_ADDRESS

        &= nbsp;           &nbs= p; 5-7 - Reserved

 

   setsc() returns the status of the op= eration:

    - 0 - Address was successfully= generated

    - EAI_REQUIREDIPNOTSUPPORTED -= the required service type is not

      supported

    - EAI_REQUIREDIPFAILED - the n= etwork could not fulfill the desired

      request=

 

   setsc() MAY block the invoking threa= d if it triggers the TCP/IP stack

   to request a new IP prefix from the = network to construct the desired

   source IP address.  If an IP pr= efix with the desired session

   continuity features already exists (= was previously allocated to the

   mobile host) and the stack is not re= quired to request a new one as a

   result of setting the IPV6_REQUIRE_S= RC_ON_NET flag (defined below),

   setsc() MAY return immediately with = the constructed IP address and

   will not block the thread.

 

6.2.  New Flags

 

   The following flag is added to the l= ist of flags in the

   IPV6_ADDR_PREFERENCE option at the I= PPROTO6 level:

 

   IPV6_REQUIRE_SRC_ON_NET - set IP sta= ck address allocation behavior

 

Yegin, et al.      =      Expires January 27, 2019    &n= bsp;          [Page 13]

 

Internet-Draft      = ;       On Demand Mobility   &= nbsp;           &nbs= p;  July 2018

 

   If set, the IP stack will request a = new IPv6 prefix of the desired

   type from the current serving networ= k and configure a new source IP

   address.  If reset, the IP stac= k will use a preconfigured one if it

   exists.  If there is no preconf= igured IP address of the desired type,

   a new prefix will be requested and u= sed for creating the IP address.

 

7.  Security Considerations

 

   The setting of certain IP address ty= pe on a given socket may be

   restricted to privileged application= s.  For example, a Fixed IP

   Address may be provided as a premium= service and only certain

   applications may be allowed to use t= hem.  Setting and enforcement of

   such privileges are outside the scop= e of this document.

 

<mglt>

I believe the text could describe the threat such= recommendation is addressing.

 

The document describes how applications provides = the OS their requirements in order to select the appropriated IP address. T= he resource are associated to different costs. While the cost is primarily = on the operator side, it is likely that usage by the mobile node comes with some restrictions, limitation or = direct cost. Typically, some type of IP address may be provided by the oper= ator for a limited number of bytes upon which the IP address type will not = be available to the mobile node or may be charged. A malicious application may use these limitations to ge= nerate extra billing of the mobile node or to prevent the usage of some app= lications by exhausting the expected type of IP address.

 

In order to prevent such scenario, the mobile nod= e SHOULD be able to authorize specific PI address types to privilege applic= ation.

 

With these new types of IP addresses, the IP addr= ess leaks some connectivity requirements of the application. This also mean= s that additional information is provided to the destination which could re= veal to a passive monitoring attacker some information such as the type of application and the application itsel= f even though the packet is protected by IPsec or TLS.

 

To avoid profiling an application according to th= e type of IP addresses, it is expected that prefixes provided by the operat= or are associated to various type of addresses over time. As a result, the = type of address could not be associated to the prefix, making application profiling based on the type of address h= arder.

Application using multiple type of IP addresses t= o avoid being profiled is likely to create some patterns. So that remains a= hard problem to solve by the application.

 

The usage of a fixed IP address, enables tracking= the mobile node, or its application over time. This is a similar problem a= s the one encountered with Public IP addresses. The usage of the Fixed IP a= ddresses should be limited.

 

To limit the effect of IP tracking, the applicati= on or the OS should ensure that IP addresses regularly change to limit IP t= racking by a passive observer.  The application should regularly set t= he On Demand flag. The application should be able to ensure that session lasting IP address are regularly changed by= setting a lifetime for example handled by the application. In addition, th= e application should consider the use of graceful replacement IP addresses.=

 

Similarly, the OS may also associated IP addresse= s with a lifetime. Upon receiving a request for a given type of IP address,= after some time, the OS should request a new address to the network even i= f it already has one IP address available with the requested type. This includes any type of IP address. Addresses o= f type graceful replacement or non persistent IP addresses should be regula= rly renewed by the OS.

 

The lifetime of an IP address may be expressed in= number of seconds or in umber of bytes sent through this IP address.<= /o:p>

</mglt>

 

Session lasting IP address could be used to avoid= tracking and should be preferred. However, there should be a way to specif= y between one session lasting or if the IP address can last multiple sessio= ns.

 

</mglt>

 

8.  IANA Considerations

 

   This document has no IANA considerat= ions.

 

9.  Contributors

 

   This document was merged with [I-D.s= ijeon-dmm-use-cases-api-source].

   We would like to acknowledge the con= tribution of the following people

   to that document as well:=

 

   Sergio Figueiredo

   Altran Research, France

   Email: se= rgio.figueiredo@altran.com

 

   Younghan Kim

   Soongsil University, Korea

   Email: younghak@ssu= .ac.kr

 

   John Kaippallimalil

   Huawei, USA

   Email: john.kaippallimalil@h= uawei.com

 

10.  Acknowledgements

 

   We would like to thank Wu-chi Feng, = Alexandru Petrescu, Jouni

   Korhonen, Sri Gundavelli, Dave Dolso= n and Lorenzo Colitti for their

   valuable comments and suggestions on= this work.

 

11.  References

 

Yegin, et al.      =      Expires January 27, 2019    &n= bsp;          [Page 14]

 

Internet-Draft      = ;       On Demand Mobility   &= nbsp;           &nbs= p;  July 2018

 

11.1.  Normative References

 

   [RFC2119]  Bradner, S., "K= ey words for use in RFCs to Indicate

        &= nbsp;     Requirement Levels", BCP 14, RFC 2119,

        &= nbsp;     DOI 10.17487/RFC2119, March 1997,<= /p>

        &= nbsp;     <https://ww= w.rfc-editor.org/info/rfc2119>.

 

   [RFC5014]  Nordmark, E., Chakra= barti, S., and J. Laganier, "IPv6

        &= nbsp;     Socket API for Source Address Selection"= , RFC 5014,

        &= nbsp;     DOI 10.17487/RFC5014, September 2007,

        &= nbsp;     <https://ww= w.rfc-editor.org/info/rfc5014>.

 

11.2.  Informative References

 

   [I-D.sijeon-dmm-use-cases-api-source= ]

        &= nbsp;     Jeon, S., Figueiredo, S., Kim, Y., and J. Kai= ppallimalil,

        &= nbsp;     "Use Cases and API Extension for Source = IP Address

        &= nbsp;     Selection", draft-sijeon-dmm-use-cases-a= pi-source-07 (work

        &= nbsp;     in progress), September 2017.

 

   [RFC3261]  Rosenberg, J., Schul= zrinne, H., Camarillo, G., Johnston,

        &= nbsp;     A., Peterson, J., Sparks, R., Handley, M., an= d E.

        &= nbsp;     Schooler, "SIP: Session Initiation Proto= col", RFC 3261,

        &= nbsp;     DOI 10.17487/RFC3261, June 2002,

        &= nbsp;     <https://ww= w.rfc-editor.org/info/rfc3261>.

 

   [RFC5213]  Gundavelli, S., Ed.,= Leung, K., Devarapalli, V.,

        &= nbsp;     Chowdhury, K., and B. Patil, "Proxy Mobi= le IPv6",

        &= nbsp;     RFC 5213, DOI 10.17487/RFC5213, August 2008,<= o:p>

        &= nbsp;     <https://ww= w.rfc-editor.org/info/rfc5213>.

 

   [RFC5563]  Leung, K., Dommety, = G., Yegani, P., and K. Chowdhury,

         =      "WiMAX Forum / 3GPP2 Proxy Mobile IPv4&q= uot;, RFC 5563,

        &= nbsp;     DOI 10.17487/RFC5563, February 2010,

        &= nbsp;     <https://ww= w.rfc-editor.org/info/rfc5563>.

 

   [RFC5944]  Perkins, C., Ed., &q= uot;IP Mobility Support for IPv4, Revised",

        &= nbsp;     RFC 5944, DOI 10.17487/RFC5944, November 2010= ,

        &= nbsp;     <https://ww= w.rfc-editor.org/info/rfc5944>.

 

   [RFC6275]  Perkins, C., Ed., Jo= hnson, D., and J. Arkko, "Mobility

        &= nbsp;     Support in IPv6", RFC 6275, DOI 10.17487= /RFC6275, July

        &= nbsp;     2011, <http= s://www.rfc-editor.org/info/rfc6275>.

 

   [RFC6824]  Ford, A., Raiciu, C.= , Handley, M., and O. Bonaventure,

        &= nbsp;     "TCP Extensions for Multipath Operation = with Multiple

        &= nbsp;     Addresses", RFC 6824, DOI 10.17487/RFC68= 24, January 2013,

        &= nbsp;     <https://ww= w.rfc-editor.org/info/rfc6824>.

 

Yegin, et al.      =      Expires January 27, 2019    &n= bsp;          [Page 15]

 

Internet-Draft      = ;       On Demand Mobility   &= nbsp;           &nbs= p;  July 2018

 

   [RFC7333]  Chan, H., Ed., Liu, = D., Seite, P., Yokota, H., and J.

        &= nbsp;     Korhonen, "Requirements for Distributed = Mobility

        &= nbsp;     Management", RFC 7333, DOI 10.17487/RFC7= 333, August 2014,

        &= nbsp;     <https://ww= w.rfc-editor.org/info/rfc7333>.

 

Authors' Addresses

 

   Alper Yegin

   Actility

   Istanbul

   Turkey

 

   Email: alper.= yegin@actility.com

 

   Danny Moses

   Intel Corporation

   Petah Tikva

   Israel

 

   Email: danny.mos= es@intel.com

 

   Kisuk Kweon

   Samsung

   Suwon

   South Korea

 

   Email: kisuk.k= weon@samsung.com

 

   Jinsung Lee

   Samsung

   Suwon

   South Korea

 

   Email: js81.lee@s= amsung.com

 

   Jungshin Park

   Samsung

   Suwon

   South Korea

 

   Email: shin02.= park@samsung.com

 

Yegin, et al.      =      Expires January 27, 2019    &n= bsp;          [Page 16]

 

Internet-Draft      = ;       On Demand Mobility   &= nbsp;           &nbs= p;  July 2018

 

   Seil Jeon

   Sungkyunkwan University

   Suwon

   South Korea

 

   Email: seiljeon@skku= .edu

 

Yegin, et al.       = ;    Expires January 27, 2019    &n= bsp;          [Page 17]

 

 

_______________________________________________

dmm mailing list

dmm@ietf.org

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

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC281441C1044HASMSX106gercor_-- From nobody Thu Jan 17 12:50:21 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2BA1271FF for ; Thu, 17 Jan 2019 12:50:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <154775821932.10445.15340117858290282481.idtracker@ietfa.amsl.com> Date: Thu, 17 Jan 2019 12:50:19 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 20:50:19 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-01-24 Reviewer LC end Draft Matthew Miller 2019-01-14 draft-ietf-mile-xmpp-grid-09 Last calls: Reviewer LC end Draft Daniel Gillmor 2018-03-19 draft-gutmann-scep-11 Steve Hanna 2018-12-18 draft-ietf-extra-sieve-fcc-09 Leif Johansson 2018-12-24 draft-ietf-6lo-nfc-12 Kathleen Moriarty 2019-02-05 draft-nottingham-rfc5785bis-08 Russ Mundy 2019-01-31 draft-ietf-mpls-sfc-04 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2019-01-31 draft-ietf-ccamp-rsvp-te-bandwidth-availability-13 Yoav Nir 2019-01-28 draft-ietf-rmcat-video-traffic-model-06 Stefan Santesson R2018-11-20 draft-wilde-service-link-rel-10 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-09 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Sean Turner 2018-11-25 draft-ietf-babel-dtls-03 Next in the reviewer rotation: Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper Tim Polk Vincent Roca Kyle Rose Joseph Salowey Rich Salz Stefan Santesson From nobody Sun Jan 20 03:13:06 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925EA131069 for ; Sun, 20 Jan 2019 03:13:03 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=op3ft.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVAiQmZe69IY for ; Sun, 20 Jan 2019 03:13:00 -0800 (PST) Received: from beige.cedar.relay.mailchannels.net (beige.cedar.relay.mailchannels.net [23.83.210.16]) (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 54AA0130EF1 for ; Sun, 20 Jan 2019 03:12:59 -0800 (PST) X-Sender-Id: 5ei546bipu|env-sender|benjamin.phister@op3ft.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2BDF0682467 for ; Sun, 20 Jan 2019 11:12:59 +0000 (UTC) Received: from mail0.stg-interactive.net (unknown [100.96.26.166]) (Authenticated sender: 5ei546bipu) by relay.mailchannels.net (Postfix) with ESMTPA id 6EEC168259E for ; Sun, 20 Jan 2019 11:12:58 +0000 (UTC) X-Sender-Id: 5ei546bipu|env-sender|benjamin.phister@op3ft.org Received: from mail0.stg-interactive.net (mx1.fr.stgi.io [164.132.65.8]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Sun, 20 Jan 2019 11:12:59 +0000 X-MC-Relay: Junk X-MailChannels-SenderId: 5ei546bipu|env-sender|benjamin.phister@op3ft.org X-MailChannels-Auth-Id: 5ei546bipu X-Interest-Trouble: 3ddf27d760b6469c_1547982779054_4011264590 X-MC-Loop-Signature: 1547982779054:4145817758 X-MC-Ingress-Time: 1547982779053 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=op3ft.org; s=mail; t=1547982774; bh=xZdT3DIw+nmwu+CGMrs+AwzOj59E37zUzknfJF2SeJI=; h=Subject:References:From:To:Cc:Date:In-Reply-To; b=Vjt1WVgFg4o32PMAtwyZsbWptSDsakh137P1WOdG/pySmSLPaHWyic6XmWIgPPNyp LwWkrnykgfyzzV4OYf10kpEQZeF2sAQIFSAOHfflmvomGs23EfjqaoMHd89xbH0YZq Ddn6qImmi+ELKk/7dkYuY3DmceqMkEeQLzd3vw3I= References: From: Benjamin PHISTER To: =?UTF-8?Q?Magnus_Nystr=c3=b6m?= , secdir@ietf.org Cc: Alexey Melnikov , draft-op3ft-leaptofrogans-uri-scheme@ietf.org Message-ID: <70a588e6-c939-526b-2a84-9a40444ca3a7@op3ft.org> Date: Sun, 20 Jan 2019 12:12:53 +0100 User-Agent: Evolution 2.22.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F1627D018D83E217785B22E4" X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun Jan 20 12:12:56 2019 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 6800,5c4457b841301815517186 X-DSPAM-Factors: 27, not+#+#+URLs, 0.40000, not+#+#+URLs, 0.40000, instead+#+#+a, 0.40000, instead+#+#+a, 0.40000, D+only, 0.40000, D+only, 0.40000, top+#+#+Content, 0.40000, top+#+#+Content, 0.40000, I+#+#+#+document, 0.40000, I+#+#+#+document, 0.40000, security+#+#+that, 0.40000, security+#+#+that, 0.40000, comments+#+document, 0.40000, comments+#+document, 0.40000, your+#+#+in, 0.40000, your+#+#+in, 0.40000, and+#+#+their, 0.40000, and+#+#+their, 0.40000, section+#+#+discussion, 0.40000, section+#+#+discussion, 0.40000, reply+#+#+responded, 0.40000, reply+#+#+responded, 0.40000, name+seems, 0.40000, name+seems, 0.40000, Concerning+#+#+used, 0.40000, Concerning+#+#+used, 0.40000, frogans+#+#+do, 0.40000 X-Virus-Scanned: ClamAV using ClamSMTP Archived-At: Subject: Re: [secdir] Secdir review of draft-op3ft-leaptofrogans-uri-scheme-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2019 11:13:04 -0000 This is a multi-part message in MIME format. --------------F1627D018D83E217785B22E4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Magnus, Thank you for your review, and please excuse my late reply. I have responded to your questions directly in your message below. Best regards, Ben -- Benjamin Phister Head of Technical Specifications benjamin.phister@op3ft.org OP3FT 6 square Mozart 75016 Paris - France Tel: +33 1 5392 0040 https://www.op3ft.org/ frogans*op3ft ------------------------------------------------------------------------ *From:* Magnus Nyström *Subject:* Secdir review of draft-op3ft-leaptofrogans-uri-scheme-03 *Date:* Friday, Nov 16, 2018 9:47 AM CET *To:* secdir@ietf.org, draft-op3ft-leaptofrogans-uri-scheme@ietf.org > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document specifies the "leaptofrogans" URI scheme. Its security > considerations section provides a discussion of common URI risks and > how they apply to the frogans URIs. I do wonder a bit about the > statement that "[the] risk of confusion i[due to the true address > being hidden in the link text visible to the user] is mitigated > because Frogans Player must always display the real Frogans address > contained in the URI" - does this necessarily also apply to "inbound" > direction cases - i.e., when a regular browser displays a link which > allows the user to launch a frogans site? The way that end-user applications (such as a Web browser or an E-mail client) choose to display links is outside the scope of this I-D. The I-D only says what Frogans Player must do when dealing with a 'leaptofrogans' URI. It does not say what other end-user applications must display when dealing with a 'leaptofrogans' URI. Furthermore, the way end-user applications display links varies considerably. The real Frogans address contained in the URI may not be displayed at all. For instance, on a Web page, a link can be presented using an image instead of using a hypertext link. In any case, as discussed in the I-D, the risk of confusion is mitigated by Frogans Player that always displays the real Frogans address contained in the URI. > > (Unrelated, the "leaptofrogans" name seems long. The scheme part of > URIs is typically the name of a protocol or similar. In the frogans > case, "fsdl" comes to mind as iI understand it to be the language used > to create frogans sites (I do not know what protocol is used to > commuicate with such sites).) The choice of the scheme name is discussed in Section 3 ("The Choice of the Scheme Name") of the I-D. Choosing 'fsdl' as the scheme name would not work because FSDL, the Frogans Slide Description Language, relates to the format of the documents representing the slides of a Frogans site and does not relate to its Frogans address (just like HTML relates to the format of documents representing the pages of a Web site and not to their URLs). Concerning the protocols used by Frogans Player for requesting and receiving data from the server hosting the Frogans site: As of version 3.0 of the FSDL technical specification (https://www.frogans.org/en/resources/fsdl/access.html -- see Section 1.2 "Purpose"), FSDL works on top of Uniform Content Server Request (UCSR), a new framework designed and developed by the OP3FT to make the Frogans technology independent from data-transport protocols. The UCSR framework provides a client application with an abstraction layer for uniformly requesting and receiving data from a content server, while ensuring a predetermined security level. Note that UCSR does not propose new networking protocols. It utilizes existing protocols widely used on the Internet such as IP, DNS, TCP, TLS, and HTTP. For more information on UCSR (and also to get an overall understanding of the Frogans technology), see Frogans Technology Overview on the official Web site of the Frogans technology (https://www.frogans.org/en/resources/overview/access.html). Choosing 'ucsr' as a scheme name would not work either because UCSR can be used in contexts outside Frogans technology. > Thanks, > -- Magnus --------------F1627D018D83E217785B22E4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear Magnus,

Thank you for your review, and please excuse my late reply.

I have responded to your questions directly in your message below.

Best regards,

Ben

-- 
Benjamin Phister
Head of Technical Specifications
benjamin.phister@op3ft.org

OP3FT
6 square Mozart
75016 Paris - France
Tel: +33 1 5392 0040
https://www.op3ft.org/
frogans*op3ft

From: Magnus Nyström <magnusn@gmail.com>
Subject: Secdir review of draft-op3ft-leaptofrogans-uri-scheme-03
Date: Friday, Nov 16, 2018 9:47 AM CET
To: secdir@ietf.org, draft-op3ft-leaptofrogans-uri-scheme@ietf.org

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the  security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document specifies the "leaptofrogans" URI scheme. Its security considerations section provides a discussion of common URI risks and how they apply to the frogans URIs. I do wonder a bit about the statement that "[the] risk of confusion i[due to the true address being hidden in the link text visible to the user] is mitigated because Frogans Player must always display the real Frogans address contained in the URI" - does this necessarily also apply to "inbound" direction cases - i.e., when a regular browser displays a link which allows the user to launch a frogans site?

The way that end-user applications (such as a Web browser or an E-mail client) choose to display links is outside the scope of this I-D. The I-D only says what Frogans Player must do when dealing with a 'leaptofrogans' URI. It does not say what other end-user applications must display when dealing with a 'leaptofrogans' URI.

Furthermore, the way end-user applications display links varies considerably. The real Frogans address contained in the URI may not be displayed at all. For instance, on a Web page, a link can be presented using an image instead of using a hypertext link.

In any case, as discussed in the I-D, the risk of confusion is mitigated by Frogans Player that always displays the real Frogans address contained in the URI.


(Unrelated, the "leaptofrogans" name seems long. The scheme part of URIs is typically the name of a protocol or similar. In the frogans case, "fsdl" comes to mind as iI understand it to be the language used to create frogans sites (I do not know what protocol is used to commuicate with such sites).)

The choice of the scheme name is discussed in Section 3 ("The Choice of the Scheme Name") of the I-D.

Choosing 'fsdl' as the scheme name would not work because FSDL, the Frogans Slide Description Language, relates to the format of the documents representing the slides of a Frogans site and does not relate to its Frogans address (just like HTML relates to the format of documents representing the pages of a Web site and not to their URLs).

Concerning the protocols used by Frogans Player for requesting and receiving data from the server hosting the Frogans site: As of version 3.0 of the FSDL technical specification (https://www.frogans.org/en/resources/fsdl/access.html -- see Section 1.2 "Purpose"), FSDL works on top of Uniform Content Server Request (UCSR), a new framework designed and developed by the OP3FT to make the Frogans technology independent from data-transport protocols. The UCSR framework provides a client application with an abstraction layer for uniformly requesting and receiving data from a content server, while ensuring a predetermined security level. Note that UCSR does not propose new networking protocols. It utilizes existing protocols widely used on the  Internet such as IP, DNS, TCP, TLS, and HTTP. For more information on UCSR (and also to get an overall understanding of the Frogans technology), see Frogans Technology Overview on the official Web site of the Frogans technology (https://www.frogans.org/en/resources/overview/access.html).

Choosing 'ucsr' as a scheme name would not work either because UCSR can be used in contexts outside Frogans  technology.

Thanks,
-- Magnus

--------------F1627D018D83E217785B22E4-- From nobody Mon Jan 21 12:16:20 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5CC126BED; Mon, 21 Jan 2019 12:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2LK65BOuloV; Mon, 21 Jan 2019 12:16:16 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 F417E124408; Mon, 21 Jan 2019 12:16:15 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DEDF0D3BC1E958F94207; Mon, 21 Jan 2019 20:16:13 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 21 Jan 2019 20:16:13 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.96]) by SJCEML703-CHM.china.huawei.com ([169.254.5.115]) with mapi id 14.03.0415.000; Mon, 21 Jan 2019 12:16:08 -0800 From: Leeyoung To: Watson Ladd , "secdir@ietf.org" CC: "draft-ietf-pce-wson-rwa-ext.all@ietf.org" , "pce@ietf.org" , "ietf@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-pce-wson-rwa-ext-10 Thread-Index: AQHUnAPv3/fqZQlb10mkTsVxPoH3HqW6Ue8w Date: Mon, 21 Jan 2019 20:16:07 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E173D0C5201@sjceml521-mbx.china.huawei.com> References: <154570936991.12911.1627288364179668736@ietfa.amsl.com> In-Reply-To: <154570936991.12911.1627288364179668736@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.123] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-pce-wson-rwa-ext-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2019 20:16:18 -0000 SGkgV2F0c29uLA0KDQpTb3JyeSBmb3IgdGhlIGxhdGUgcmVzcG9uc2UgdG8geW91ciByZXZpZXcu ICBJIHRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcgb2YgdGhpcyBkcmFmdCBhbmQgdGhlIHJlc3Vs dC4gDQoNCkluIHJlZ2FyZHMgdG8geW91ciBxdWVzdGlvbiwgcGxlYXNlIHNlZSBiZWxvdyBpbmxp bmUuIA0KDQpUaGFua3MgJiBCZXN0IHJlZ2FyZHMsDQpZb3VuZw0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogV2F0c29uIExhZGQgW21haWx0bzp3YXRzb25ibGFkZEBnbWFpbC5j b21dIA0KU2VudDogTW9uZGF5LCBEZWNlbWJlciAyNCwgMjAxOCA5OjQzIFBNDQpUbzogc2VjZGly QGlldGYub3JnDQpDYzogZHJhZnQtaWV0Zi1wY2Utd3Nvbi1yd2EtZXh0LmFsbEBpZXRmLm9yZzsg cGNlQGlldGYub3JnOyBpZXRmQGlldGYub3JnDQpTdWJqZWN0OiBTZWNkaXIgbGFzdCBjYWxsIHJl dmlldyBvZiBkcmFmdC1pZXRmLXBjZS13c29uLXJ3YS1leHQtMTANCg0KUmV2aWV3ZXI6IFdhdHNv biBMYWRkDQpSZXZpZXcgcmVzdWx0OiBSZWFkeQ0KDQpEZWFyIGFsbCwNCg0KSSBoYXZlIHJldmll d2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBv bmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3Nl ZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9y IHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVk aXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtl IGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNClRoZSBzdW1tYXJ5IG9mIHRoZSByZXZp ZXcgaXMgUkVBRFkuDQoNClRoaXMgaXMgYSBkb2N1bWVudCBpbiBhbiBhcmVhIEkga25vdyBhbG1v c3Qgbm90aGluZyBhYm91dC4gSXQgYXBwZWFycyB0byBiZSBhYm91dCBhbiBpbnRlcm5hbCBtZWNo YW5pc20gZm9yIGNvbmZpZ3VyaW5nIGxhYmVsIGJhc2VkIHJvdXRpbmcgaW4gYW4gb3B0aWNhbCBu ZXR3b3JrIHRvIG1pbmltaXplIHRoZSBudW1iZXIgb2Ygb3B0aWNhbCB0byBlbGVjdHJpY2FsIHRy YW5zaXRpb25zIGFsb25nIHRoZSByb3V0ZS4gSSBhbSBwZXJoYXBzIGEgYml0IGNvbmZ1c2VkIGFz IHRvIHdoeSB0aGUgUENDIHdvdWxkIHNwZWNpZnkgdGhlIGNvbnN0cmFpbnRzIG9uIHdhdmVsZW5n dGhzIG9uIGhvcHMgdGhhdCBhcmUgbm90IHRoZSBlbmQgb25lczogaWYgdGhlIHBhY2tldHMgbXVz dCBmbG93IGZyb20gQSB0byBCLCBzaG91bGRuJ3QgdGhlIFBDRSBiZSB0aGUgb25lIHRvIGRlY2lk ZSBob3cgdG8gZG8gdGhhdCB1c2luZyBhbGwgdGhlIHJlc291cmNlcyBhdmFpbGFibGU/IA0KDQpZ TD4+IFBDQyBpcyBhIGNsaWVudCB0aGF0IHdvdWxkIGFzayBzb21lIGNvbnN0cmFpbnRzIHRvIHRo ZSBQQ0Ugc28gdGhhdCBQQ0Ugd291bGQgZmlsdGVyIHN1Y2ggY29uc3RyYWludHMgaW4gaXRzIHBh dGggY29tcHV0YXRpb24uIFRoZSBmaW5hbCBkZWNpc2lvbiBvbiB0aGUgcGF0aCBhbmQgd2F2ZWxl bmd0aCBhc3NpZ25tZW50IGlzIGRvbmUgYnkgdGhlIFBDRSBpbiBnZW5lcmFsIGNhc2UuIEhvcGUg dGhpcyBhbnN3ZXJzIHRvIHlvdXIgcXVlc3Rpb24uIA0KDQpNZXJyeSBDaHJpc3RtYXMhDQoNClNp bmNlcmVseSwNCldhdHNvbiBMYWRkDQoNCg== From nobody Wed Jan 23 10:01:46 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFDC1311CE; Wed, 23 Jan 2019 10:01:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: Cc: mile@ietf.org, draft-ietf-mile-xmpp-grid.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154826649938.7505.11018194912932133243@ietfa.amsl.com> Date: Wed, 23 Jan 2019 10:01:39 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-mile-xmpp-grid-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 18:01:39 -0000 Reviewer: Matthew Miller Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Document: draft-ietf-mile-xmpp-grid-09 Reviewer: Matthew A. Miller Review Date: 2018-01-23 IETF LC End Date: 2019-01-14 IESG Telechat date: 2019-01-24 Summary: This document defines an architecture for distributing security information using publish-subscribe semantics over XMPP. It is well written and addressed many (but not all) known concerns of a publish-subscribe This document has issues that should be addressed before it is ready to be published as a Proposed Standard. Major Issues: The document does not explicitly discuss the implications of the Controller and Broker having plaintext access and control of the published data. It seems to be implied in the section 8.2.3 for the Controller (and, for those proficient with XMPP, the Broker). I am not strongly recommending any sort of end-to-end protections be proscribed (since existing protections are likely unsuitable for this architecture). The document does not have any real discussion around persistence of node items. if they are expected or desired to be persisted, then there should be some discussion about retention policies (meaning: deployments ought to have one), and behaviors when a Platform subscribes to the Topic (e.g., should or may automatically send the last published item to the recent subscriber). If not, then some discussion on the implications of existing/historic data being unavailable through this mechanism. Minor Issues: XMPP pubsub is complex, and node configuration reflects that. Relying on XEP-0060 is something of a disservice to implementers, in my opinion. I suggest that an addition Topic creation example be added that demonstrates the recommended configuration: * pubsub#access-authorize or access-whitelist * pubsub#persist_items = ?? (1 or 0) * pubsub#send_last_published_item = ?? (on_sub? never?) Nits: N/A From nobody Thu Jan 24 11:23:49 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF12613120F; Thu, 24 Jan 2019 11:23:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir To: Cc: rmcat@ietf.org, draft-ietf-rmcat-video-traffic-model.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154835782178.29376.11315332570255821000@ietfa.amsl.com> Date: Thu, 24 Jan 2019 11:23:41 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-rmcat-video-traffic-model-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 19:23:42 -0000 Reviewer: Yoav Nir Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. To quote from the abstract, the document "describes two reference video traffic models for evaluating RTP congestion control algorithms". Indeed it does not describe any protocol or algorithm that is going to get deployed on the Internet, but rather a model for evaluating congestion control algorithm before they are standardized or deployed. As such, I would not expect it to have much to say on security, either good or bad. It is conceivable that a congestion control algorithm would be exploitable by an attacker. For example, some pattern of traffic might trigger such an algorithm to block or slow down traffic for a victim. It may be a good idea to evaluate whether such algorithms are conducive to such attacks. But speculation such as this are not related to the draft. This draft is about evaluating congestion control algorithms for their effect on video quality and frame rates. So what is my nit with this? Why does the Security Considerations section contains what it does? It is important to evaluate RTP-based congestion control schemes using realistic traffic patterns, so as to ensure stable operations of the network. Therefore, it is RECOMMENDED that candidate RTP- based congestion control algorithms be tested using the video traffic models presented in this draft before wide deployment over the Internet. This is interesting, but I don't think it has much to do with security. IMO it would be enough to say that this document introduces models for evaluation and doesn't have any security implications. The existing text should go somewhere else. From nobody Thu Jan 24 11:40:06 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D74F1277BB; Thu, 24 Jan 2019 11:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ipCnsSkUvYo; Thu, 24 Jan 2019 11:39:56 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 838C1130F06; Thu, 24 Jan 2019 11:39:56 -0800 (PST) Received: from [81.187.2.149] (port=33107 helo=[192.168.0.68]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gmkqs-0002Qw-KT; Thu, 24 Jan 2019 19:39:55 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Colin Perkins In-Reply-To: <154835782178.29376.11315332570255821000@ietfa.amsl.com> Date: Thu, 24 Jan 2019 19:39:45 +0000 Cc: secdir@ietf.org, rmcat@ietf.org, draft-ietf-rmcat-video-traffic-model.all@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4474F01B-D594-485D-BAC5-E64703406A34@csperkins.org> References: <154835782178.29376.11315332570255821000@ietfa.amsl.com> To: Yoav Nir X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-rmcat-video-traffic-model-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 19:39:59 -0000 > On 24 Jan 2019, at 19:23, Yoav Nir wrote: >=20 > Reviewer: Yoav Nir > Review result: Has Nits >=20 > I have reviewed this document as part of the security directorate's = ongoing > effort to review all IETF documents being processed by the IESG. = Document > editors and WG chairs should treat these comments just like any other = last call > comments. >=20 > To quote from the abstract, the document "describes two reference = video traffic > models for evaluating RTP congestion control algorithms". Indeed it = does not > describe any protocol or algorithm that is going to get deployed on = the > Internet, but rather a model for evaluating congestion control = algorithm before > they are standardized or deployed. As such, I would not expect it to = have much > to say on security, either good or bad. >=20 > It is conceivable that a congestion control algorithm would be = exploitable by > an attacker. For example, some pattern of traffic might trigger such = an > algorithm to block or slow down traffic for a victim. It may be a good = idea to > evaluate whether such algorithms are conducive to such attacks. But = speculation > such as this are not related to the draft. This draft is about = evaluating > congestion control algorithms for their effect on video quality and = frame rates. >=20 > So what is my nit with this? Why does the Security Considerations = section > contains what it does? >=20 > It is important to evaluate RTP-based congestion control schemes > using realistic traffic patterns, so as to ensure stable operations > of the network. Therefore, it is RECOMMENDED that candidate RTP- > based congestion control algorithms be tested using the video = traffic > models presented in this draft before wide deployment over the > Internet. >=20 > This is interesting, but I don't think it has much to do with = security. IMO it > would be enough to say that this document introduces models for = evaluation and > doesn't have any security implications. The existing text should go = somewhere > else. To my mind, the security implication is that the algorithm be tested to = demonstrate that it doesn=E2=80=99t cause denial-of-service when = operating with realistic traffic. This could be, as you note above, that = it disrupts the video application by forcing the sending rate to zero; = but it=E2=80=99s also important to check that it doesn=E2=80=99t send = overly quickly and congest the network, so denying service to other = flows.=20 --=20 Colin Perkins https://csperkins.org/ From nobody Thu Jan 24 13:31:11 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAE3127B4C; Thu, 24 Jan 2019 13:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxIr6MfshuKM; Thu, 24 Jan 2019 13:30:57 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 163ED131182; Thu, 24 Jan 2019 13:30:55 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x0OLUi83023861 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Jan 2019 23:30:44 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x0OLUhXv006091; Thu, 24 Jan 2019 23:30:43 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23626.11907.681078.321687@fireball.acr.fi> Date: Thu, 24 Jan 2019 23:30:43 +0200 From: Tero Kivinen To: "Neil Jenkins" Cc: secdir@ietf.org, "Bron Gondwana" , "IETF JMAP Mailing List" , draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org In-Reply-To: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> <23603.20862.976183.378013@fireball.acr.fi> <23604.45941.279266.464196@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 21:31:00 -0000 Neil Jenkins writes: > On Wed, 9 Jan 2019, at 1:28 AM, Tero Kivinen wrote: > > When you are subscribing the push notifications your devices should be > running and not offline. > > Agreed. It's still possible for the initial message not to arrive, but in the > vast majority of cases it will; if it doesn't, the client can destroy and > recreate the subscription to try again. Weighing this up, I agree that adding > a verification step is the best way forward here. > > When something changes on the server, the server pushes a > *StateChange* object to the client. > > Actually that says "to the client" not to the "push service". Which > one should it be? > > Well, it's to the client, possibly via a push service, but possibly not > because there are two "push" mechanisms defined here; the other is where the > client can maintain a permanent TCP connection directly to the JMAP server in > which case it can use an EventSource connection to receive push events > directly without going via a 3rd party. > > Hmm... and 7.2 then also uses term "push endpoint" which is not > defined anywhere? Is that the same as push service at given url > > Reading through it again, there was some confusion in the use of terminology. > I have rewritten a few sections to attempt to clarify this and the other > confusing points you pointed out. You can see the changes for this here. The > addition of a verification step is added in this change here. > > Are you happy that this is sufficient to address your concerns? Yes, I think this addresses my concerns about the denial of service issues. The text also seems to make little bit more clear about the terminology, and perhaps the Terminology section should refer to the terms defined in the RFC8030, so it would be clear which terms comes from there. Sorry that it took so long to reply, but last week I was in the IEEE meeting, thus I was not able to check these during that time. -- kivinen@iki.fi From nobody Thu Jan 24 13:44:08 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D2B130EFA for ; Thu, 24 Jan 2019 13:44:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <154836624727.29312.841138971518323188.idtracker@ietfa.amsl.com> Date: Thu, 24 Jan 2019 13:44:07 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 21:44:07 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-02-07 Reviewer LC end Draft Kyle Rose R2018-08-29 draft-ietf-lisp-rfc6830bis-26 Takeshi Takahashi R2018-08-31 draft-ietf-lisp-rfc6833bis-23 Last calls: Reviewer LC end Draft Daniel Gillmor 2018-03-19 draft-gutmann-scep-11 Steve Hanna 2018-12-18 draft-ietf-extra-sieve-fcc-09 Leif Johansson 2018-12-24 draft-ietf-6lo-nfc-12 Kathleen Moriarty 2019-02-05 draft-nottingham-rfc5785bis-08 Russ Mundy 2019-01-31 draft-ietf-mpls-sfc-04 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2019-01-31 draft-ietf-ccamp-rsvp-te-bandwidth-availability-13 Magnus Nystrom 2019-02-04 draft-ietf-jmap-mail-14 Hilarie Orman 2019-02-01 draft-ietf-rtcweb-fec-08 Radia Perlman 2019-02-01 draft-ietf-payload-flexible-fec-scheme-16 Stefan Santesson R2018-11-20 draft-wilde-service-link-rel-10 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-09 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Sean Turner 2018-11-25 draft-ietf-babel-dtls-03 Next in the reviewer rotation: Derrell Piper Tim Polk Vincent Roca Kyle Rose Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore From nobody Thu Jan 24 21:08:35 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F40129508 for ; Thu, 24 Jan 2019 21:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE3kqkySz11R for ; Thu, 24 Jan 2019 21:08:32 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B2B128D09 for ; Thu, 24 Jan 2019 21:08:32 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 24 Jan 2019 21:08:26 -0800 From: Jim Schaad To: Date: Thu, 24 Jan 2019 21:08:23 -0800 Message-ID: <00ac01d4b46c$00f9de30$02ed9a90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdS0aYd+IIiEJdHOSfGMDJ3y6un6LA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [secdir] EDHOC and Transports X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 05:08:34 -0000 Someplace over the set of messages which I recently scanned one of the questions was what were the constrained restrictions that we were looking at as part of the evaluation process. There are three that I will highlight even though I am only able to provide any type of quantification for two of them: 1. Low-power devices that either are battery based or scavenge power, these devices pay a power penalty for every byte of data sent and thus have a desire for the smallest messages possible. 2. CoAP over SMS: SMS has a 140 byte packet size. There are two approaches for dealing with packets of larger than 140 bytes: 1) There is a method of appending multiple packets together to form a single larger packet. 2) You can use CoAP blockwise transfer. Using CoAP blockwise would result in 128 byte packets for the underlying transfer assuming that only 12 bytes are needed for the CoAP header itself. 3. 6LoPan over IEEE 802.15.4: This has a packet size of 127 bytes. The maximum frame overhead size is 25 bytes allowing for 102 bytes of message space. If one assumes 20 bytes of overhead for CoAP then this means a protocol packet size of 82 bytes. If one needs to break the message across multiple packets then the maximum data size is going to be 64 bytes using CoAP blockwise options. There are of course two additional transports which are to be considered IPV4 UDP and IPV6 UDP. Both of these transports have a packet size which is sufficiently large to hold a any given message using TLS or EDHOC. Jim From nobody Fri Jan 25 05:51:52 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CA1130FA0 for ; Fri, 25 Jan 2019 05:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZksbPg5JPUsu for ; Fri, 25 Jan 2019 05:51:43 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70080.outbound.protection.outlook.com [40.107.7.80]) (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 E3222130E6D for ; Fri, 25 Jan 2019 05:51:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i3DThNexXalEKrGcMGX8uUY5DJCm0PQGr4T87YTzOpc=; b=SM7pUg5xkpTRNTaxaEiVOfmz3ymX9cwfJIwQ7ikJb5duFFcq1p5GNdnNfuHQzGF9SVMM6lgIyrjqifp9hWIQ+o53TEluxnNIRG4N9uv8zAraBkq0ZSXmv21o/MObWNRzQOLzHaBSFBaunhbBZxz9jwWkCST4aTNIdTOsEntgHSE= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1645.eurprd08.prod.outlook.com (10.168.66.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.18; Fri, 25 Jan 2019 13:51:40 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019%7]) with mapi id 15.20.1558.016; Fri, 25 Jan 2019 13:51:39 +0000 From: Hannes Tschofenig To: Jim Schaad , "secdir@ietf.org" Thread-Topic: [secdir] EDHOC and Transports Thread-Index: AdS0aYd+IIiEJdHOSfGMDJ3y6un6LAAOu51g Date: Fri, 25 Jan 2019 13:51:39 +0000 Message-ID: References: <00ac01d4b46c$00f9de30$02ed9a90$@augustcellars.com> In-Reply-To: <00ac01d4b46c$00f9de30$02ed9a90$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.119.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1645; 6:v7efscUc4s338xwXT2joGy6nZc/SXVbt6/zc7Hq31Wwmw2aHclnCYJ3qRXfizJ2OaIc2D38jhB/ZylVjGtWGluX79GaSq9lY9QG/QFQapftwOL1uGFk+aBtKk7lNG0IdccQDZSPv6euOOvqERoOuvM1jwLeTNnIn4yBP0uA/4QG9zB0jYq0liBIq76q/Gy9QwSVNBPxwh0XHXAQHlJ866+gduXkpcg+UiJVBre/nRpEqNTdY5Y7Dd/Ur2ZJvIFQUJEMV0DxcRo1vL/v9XQtimQC8Xg5BVg7T27B3FHJjj2yRd1OmS9fOs+zZ4wQqNnTp6M9h2tUWM93UnYKYhxLPkZXC8Y4vR67DeNtt9K++CrcDTJIIAzNvRl0N7aRuiwqA44MGkIo2JRh1AgSEQBvYPzapXM2JA3u/bGPRYYlKmgEzSdtucV41Ik0BH7RN3cIQKj4Y1c5qowTN1497gtwLtA==; 5:yus+Jgzgwuw69Brmf3vmcR8wBZYfTDcBsjoj+GGMtK9qpCIR0dnYIxzWFXMMA6TJijAF5LXYTfdSgRszLIWnR7TY9nKiVAF8Bs8lTXiYaLaReaGAICQAMaljkK8YuGNgPGKoIJdrQQOJaUAZoWZHuVdVoay+c3gTmdjX2E06m/mZL1Ob1IWiSrQLZb96f1QF/F6cPNnFX59zwRB1sF/AWQ==; 7:MGjECWRJWnJWJqSuahDC2gz6z4iGYz3k+JKdiEPj05bt+lS/S7T3flVJlP1nE9xJCCtXOcoubw1XaBRJg/YrZoq1Cd53NCxHXLcMZu5SeCRbwM/N7m9Jjq4na90pYA9UawCuY4u1CHYv2/cFerdfMA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: cc4c6d71-ece8-46fc-926e-08d682cc3b51 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1645; x-ms-traffictypediagnostic: VI1PR0801MB1645: x-microsoft-antispam-prvs: x-forefront-prvs: 0928072091 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(136003)(346002)(39860400002)(366004)(199004)(189003)(40434004)(6246003)(97736004)(26005)(66574012)(6506007)(8936002)(476003)(3846002)(6116002)(446003)(68736007)(6436002)(86362001)(71190400001)(71200400001)(74316002)(486006)(11346002)(66066001)(8676002)(81166006)(102836004)(53936002)(81156014)(14454004)(186003)(99286004)(106356001)(305945005)(72206003)(966005)(2501003)(7736002)(478600001)(6306002)(33656002)(2906002)(25786009)(229853002)(316002)(7696005)(110136005)(76176011)(9686003)(14444005)(256004)(5024004)(105586002)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1645; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 10J6wWYfq0BNGrxSQNVn8FrtswfzAzxMn0OckqxggNFZ4m4sw88DTfIbdB5GwUJeNSFMpH7b+mnX5ngHJx2nSYlAtodQqoGz6GgP5Nn+VclKZ5a40Dq3MIAiHsEFXIgA6DqPglbtmzy3v61Ea58Ez2bZ9ipputCDMWGwQEPYWApECo6x2Y93JOwjRXRVQYm5OGaOCVzBEKB60ZT/dyQz0a870M12yFGAtyc3U+9FrnJTEOlLvcb/FbpXr4+vzPrcHd0/Ox2nJPf1nd4YJqdl7P5Hdw0kCfXsoboX2hyKlz67Ssw2NA5RzYXESSVp7oUemQXKP89SAj1nkIWjlFUuVrOwPttEVJYY4wWhbXCBuXNAwcCCfYLuqRvi2tiBNhErWcJyMW/SV7qXf57Yb2d4WDo0xrThXbYJqmzQqLDAKQw= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: cc4c6d71-ece8-46fc-926e-08d682cc3b51 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2019 13:51:39.8394 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1645 Archived-At: Subject: Re: [secdir] EDHOC and Transports X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 13:51:52 -0000 Hi Jim, what we are doing here is making an optimization. For some (unknown reason)= we have focused our attention to the over-the-wire transmission overhead (= not code size, RAM utilization, or developer usability*). We are doing this= optimization mostly based on information about what other people tell us r= ather than based on our experience. The problem is that we have too few peo= ple with hands-on knowledge and/or deployment experience and if they have t= hat experience they may not like to talk about it. So, we are stepping arou= nd in the dark and mostly perceived problems. Having said that I would like to provide a few remarks to your list below: 1. Low-power devices that either are battery based or scavenge power, thes= e devices pay a power penalty for every byte of data sent and thus have a d= esire for the smallest messages possible. [Hannes] Low power is a very complex topic since it is a system issue and b= oiling it down to the transmission overhead of every byte is an oversimplif= ication. You are making certain assumptions of how power consumption of rad= io technologies work, which will be hard to verify. I have been working on = power measurements recently (but only focused on power measurements of cryp= to, see https://community.arm.com/arm-research/b/articles/posts/testing-cry= pto-performance-and-power-consumption). I doubt that many people on this li= st nor in the IETF have a lot of experience in this field to use this as a = basic for an optimization. My co-workers, who are active in this space, tell me that there is nothing = like a "per byte" linear relationship (for small quantities of data) in ter= ms of energy cost. Obviously if you trigger "an additional transmission", w= hich requires you to ramp up a PLL, turn on radio amplifiers, send lengthy = preambles etc then the incremental cost of sending 64 bytes in that packet = vs 16 bytes might be immeasurable small. The critical thing appears to be = how long the RF amplifiers are powered on. Hence, you will often see public= ations that tell you that waiting for incoming packets is actually the most= expensive task (in terms of power consumption). When it comes to energy scavenging devices then it becomes even more challe= nging since this is a more rarely used case. I know about one company doing= this and I have spoken with a researchers at last year's Arm research summ= it who show-cased one device. The device shown by the researcher was a prot= otype and didn't use any Internet protocol nor a security mechanism. I woul= dn't call myself knowledgeable enough to optimize a system based on this ex= perience but maybe you have more expertise in this field. I am happy to lea= rn more. 2. CoAP over SMS: SMS has a 140 byte packet size. There are two approache= s for dealing with packets of larger than 140 bytes: 1) There is a method = of appending multiple packets together to form a single larger packet. 2) = You can use CoAP blockwise transfer. Using CoAP blockwise would result in = 128 byte packets for the underlying transfer assuming that only 12 bytes ar= e needed for the CoAP header itself. [Hannes] It turns out that CoAP over SMS is rarely used for delivering data= of IP-based devices since SMS is a pretty expensive transport. From my wor= k in the OMA I know that people use SMS to trigger the wake-up of devices a= nd then switch to regular data transmission over IP. IMHO optimizing for us= e cases that barely anyone uses appears to be a waste of time. 3. 6LoPan over IEEE 802.15.4: This has a packet size of 127 bytes. The ma= ximum frame overhead size is 25 bytes allowing for 102 bytes of message space. If one assumes 20 bytes of overhead for CoAP then this means a protocol packet size of 82 bytes. If one needs to break the message across= multiple packets then the maximum data size is going to be 64 bytes using = CoAP blockwise options. [Hannes] For some reason there seems to be the worry that a small MTU size = at the link layer will cause a lot of problems. There are some radios that = have this small MTU size, IEEE 802.15.4 and Bluetooth Low Energy belong to = them. It turns out, however, that higher layers then offer fragmentation an= d reassembly support so that higher layers just don't get to see any of thi= s. In IEEE 802.15.4 this fragmentation & reassembly support is offered by 6= lowpan and in case of Bluetooth Low Energy the link layer actually consists= of various sub-protocols. One of them offers fragmentation & reassembly. A= s such, the problem you describe is actually not a problem. There is no rea= son why you always have to put a single application layer payload into a si= ngle link layer frame. We have been using LwM2M (which uses DTLS and CoAP) over IEEE 802.15.4 netw= orks successfully for big commercial deployments. We have not run into prob= lems with the smaller MTU size at the lower layers. The handshake itself is= just a very small part of the overall size of data that gets transmitted d= uring the lifetime of the device since the handshake obviously happens extr= emely rarely. There are much better ways to optimize traffic and you obviou= sly have to look at all the data you are transmitting for the device. Ciao Hannes *: In my experience the ability for developers to easily use any of the per= formance optimization techniques is the biggest barrier for gaining perform= ance. Of course, this does not fit nicely in any of the standardization eff= orts in the IETF so the focus has to be somewhere else. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Fri Jan 25 06:06:44 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AC4129AA0 for ; Fri, 25 Jan 2019 06:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9a5oiVT9LkZ for ; Fri, 25 Jan 2019 06:06:40 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0608.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::608]) (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 98C7A129A87 for ; Fri, 25 Jan 2019 06:06:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bvKOtBlyB6a2NQPha8qHO7DHH/uofIAl4mT++3qQHXc=; b=W1+r2D3n7H9liX1Si4X9+9xn8zR7ZG+bqeWc+GzMEwgUVyBR1+mAEqtqhdZ1XFKpgq2ejGZZcaiPkQZ1qzR/z6viq63NxI2lowhpyWiJ7RkKMa4FmXUD+IvTMw6lDULKyoXeBU8RDmFuopSxYNmm2KBwdlHOoYKqd7uY/2AulNQ= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1262.eurprd08.prod.outlook.com (10.167.197.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.18; Fri, 25 Jan 2019 14:06:36 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019%7]) with mapi id 15.20.1558.016; Fri, 25 Jan 2019 14:06:36 +0000 From: Hannes Tschofenig To: Hannes Tschofenig , Jim Schaad , "secdir@ietf.org" Thread-Topic: [secdir] EDHOC and Transports Thread-Index: AdS0aYd+IIiEJdHOSfGMDJ3y6un6LAAOu51gAASLwYA= Date: Fri, 25 Jan 2019 14:06:36 +0000 Message-ID: References: <00ac01d4b46c$00f9de30$02ed9a90$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.119.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1262; 6:5ffFN69O2dWklqpSuI1TOCThUm4x7Q0qxQmcVZWzEWk4QqUOO4OdjXX5reCl4fOO5V6TUdbIsYIfLgWyZFx+CnKy92tizOJdZq6JeSDGiNmOsgHxbZgSu3jqkGoeQVlq3Ewa/Hy5VdEffMkSRuv59d5oRJVk8xivt/t/pLz9eQHK9pFSnAXy8K5O5UuQgZYT0Q68QUoVwiSBsN+O4kxMmX6a6+/09/RGrVzoP8JOQ6OepXZWlbBty5nXbM0EW1FDGwRB3UxowmeL9LYOxHDLCgV4siuJO9OU5DFu0fwKGT1LHpu5BUgEh5fQp42Ay9vUmE8tIUFM9Moud9JHzJZVQRmHBl1gRIcdxeGFE8i8AAskA+5x8YVxrw+dlma5Xs2OH8Y5rUZcemWTKjJusrY5fhbnSGlq04YbTFpDhVXupUanSRYDhG1gFCt0sk2LvVDwwQMB7mrh64lorib5JN11BA==; 5:9noy5amkOqiGb7CSQQCD4uCgc0C1kZh3CR6wMMeDPmumyRJ11gkehUQAVrTxWO/8dRVIS7Fis5HkyIR6S3yjfxi6Gxk4gdXQwy2Fi2ttvYzTgPHf6A99BX1+TJnt1h+4ZLntRvJj3VjpY2MTbs1hZn26L1ZVdg1wLT4PRfkyAmXNWs+NDlXoQ02IA/aY8F5UwZhEOWXCJ2iW4F0yjTGkCA==; 7:+2gggmji7TJohRiK8fgQYi7lbuvkCseyNXdgmo02NfkwlbNvBPsFi5U1eAtxSM3YT40a24HAM6L0pvc8J/xrcYv1VlvlaTR2xdaL+nKAbSj8w/ZsOFGAIbleP2XbCqYugSg8uRuQAo47ZX4McC19kg== x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-ms-office365-filtering-correlation-id: 641645aa-bc6d-4e4b-4e61-08d682ce5188 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1262; x-ms-traffictypediagnostic: VI1PR0801MB1262: x-microsoft-antispam-prvs: x-forefront-prvs: 0928072091 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(396003)(366004)(346002)(136003)(189003)(199004)(13464003)(40434004)(25786009)(71190400001)(71200400001)(110136005)(66574012)(99286004)(14444005)(97736004)(2940100002)(316002)(256004)(8936002)(5024004)(2906002)(81166006)(11346002)(81156014)(6436002)(446003)(8676002)(3846002)(6116002)(476003)(105586002)(106356001)(486006)(229853002)(66066001)(53546011)(93156006)(6506007)(74316002)(53936002)(102836004)(86362001)(305945005)(76176011)(7696005)(7736002)(186003)(6306002)(2501003)(9686003)(68736007)(33656002)(55016002)(6246003)(72206003)(14454004)(966005)(478600001)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1262; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: MIRyIFnEszTfaEJKukemRrwSvp48IxIFsxDhjv0tdGumxGTZfBjM0ePXB15yJN9dfFIjFr5yK0tG2mXdk7a4e/SiEfyjXpQeIM+9r7ubonNyfryrN61wrHWj95VG+JuBTsUgJ3OGiSc3ptpmhG51IbelPu3e0D9iZbYrXrb+Cqtx8Bz5HeW30OCXeOYQZmf6c8cC5dOWhqN0gLKEnw6YqMvoFyVJ1mwrsNshIn/57dnOltkg/heeSjsOlar5hx35/vE6YMKcN487JL09lxZ+j8B0/pDvTXtcZygY5JN1yfWcVE3udHcXMOlHN+xlniA11ZHPJ3HbrZTqwrYNBjisDQF/GPA1AQKv4cU4XYA2SONUcHZRtqM4fDBVFh8WIlR2geaaiSPQdimh/LR4XC51bGXXEj0HcGINQ6AknpC1OH0= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 641645aa-bc6d-4e4b-4e61-08d682ce5188 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2019 14:06:36.1483 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1262 Archived-At: Subject: Re: [secdir] EDHOC and Transports X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 14:06:43 -0000 A minor follow-up: I mentioned that I am aware of a company using the energ= y scavenging devices and it turns out that this information is actually pub= lic and there is even a short video on YouTube. The company we worked with = is called Alphatronics and here is the video: https://www.youtube.com/watch= ?v=3DJHpJV_CPYb4 As you can hear in the video we have been using our Mbed OS together with o= ur device management solution (LwM2M with DTLS and CoAP) for these types of= devices. Ciao Hannes -----Original Message----- From: secdir On Behalf Of Hannes Tschofenig Sent: Freitag, 25. Januar 2019 13:52 To: Jim Schaad ; secdir@ietf.org Subject: Re: [secdir] EDHOC and Transports Hi Jim, what we are doing here is making an optimization. For some (unknown reason)= we have focused our attention to the over-the-wire transmission overhead (= not code size, RAM utilization, or developer usability*). We are doing this= optimization mostly based on information about what other people tell us r= ather than based on our experience. The problem is that we have too few peo= ple with hands-on knowledge and/or deployment experience and if they have t= hat experience they may not like to talk about it. So, we are stepping arou= nd in the dark and mostly perceived problems. Having said that I would like to provide a few remarks to your list below: 1. Low-power devices that either are battery based or scavenge power, thes= e devices pay a power penalty for every byte of data sent and thus have a d= esire for the smallest messages possible. [Hannes] Low power is a very complex topic since it is a system issue and b= oiling it down to the transmission overhead of every byte is an oversimplif= ication. You are making certain assumptions of how power consumption of rad= io technologies work, which will be hard to verify. I have been working on = power measurements recently (but only focused on power measurements of cryp= to, see https://community.arm.com/arm-research/b/articles/posts/testing-cry= pto-performance-and-power-consumption). I doubt that many people on this li= st nor in the IETF have a lot of experience in this field to use this as a = basic for an optimization. My co-workers, who are active in this space, tell me that there is nothing = like a "per byte" linear relationship (for small quantities of data) in ter= ms of energy cost. Obviously if you trigger "an additional transmission", w= hich requires you to ramp up a PLL, turn on radio amplifiers, send lengthy = preambles etc then the incremental cost of sending 64 bytes in that packet = vs 16 bytes might be immeasurable small. The critical thing appears to be = how long the RF amplifiers are powered on. Hence, you will often see public= ations that tell you that waiting for incoming packets is actually the most= expensive task (in terms of power consumption). When it comes to energy scavenging devices then it becomes even more challe= nging since this is a more rarely used case. I know about one company doing= this and I have spoken with a researchers at last year's Arm research summ= it who show-cased one device. The device shown by the researcher was a prot= otype and didn't use any Internet protocol nor a security mechanism. I woul= dn't call myself knowledgeable enough to optimize a system based on this ex= perience but maybe you have more expertise in this field. I am happy to lea= rn more. 2. CoAP over SMS: SMS has a 140 byte packet size. There are two approache= s for dealing with packets of larger than 140 bytes: 1) There is a method = of appending multiple packets together to form a single larger packet. 2) = You can use CoAP blockwise transfer. Using CoAP blockwise would result in = 128 byte packets for the underlying transfer assuming that only 12 bytes ar= e needed for the CoAP header itself. [Hannes] It turns out that CoAP over SMS is rarely used for delivering data= of IP-based devices since SMS is a pretty expensive transport. From my wor= k in the OMA I know that people use SMS to trigger the wake-up of devices a= nd then switch to regular data transmission over IP. IMHO optimizing for us= e cases that barely anyone uses appears to be a waste of time. 3. 6LoPan over IEEE 802.15.4: This has a packet size of 127 bytes. The ma= ximum frame overhead size is 25 bytes allowing for 102 bytes of message space. If one assumes 20 bytes of overhead for CoAP then this means a protocol packet size of 82 bytes. If one needs to break the message across= multiple packets then the maximum data size is going to be 64 bytes using = CoAP blockwise options. [Hannes] For some reason there seems to be the worry that a small MTU size = at the link layer will cause a lot of problems. There are some radios that = have this small MTU size, IEEE 802.15.4 and Bluetooth Low Energy belong to = them. It turns out, however, that higher layers then offer fragmentation an= d reassembly support so that higher layers just don't get to see any of thi= s. In IEEE 802.15.4 this fragmentation & reassembly support is offered by 6= lowpan and in case of Bluetooth Low Energy the link layer actually consists= of various sub-protocols. One of them offers fragmentation & reassembly. A= s such, the problem you describe is actually not a problem. There is no rea= son why you always have to put a single application layer payload into a si= ngle link layer frame. We have been using LwM2M (which uses DTLS and CoAP) over IEEE 802.15.4 netw= orks successfully for big commercial deployments. We have not run into prob= lems with the smaller MTU size at the lower layers. The handshake itself is= just a very small part of the overall size of data that gets transmitted d= uring the lifetime of the device since the handshake obviously happens extr= emely rarely. There are much better ways to optimize traffic and you obviou= sly have to look at all the data you are transmitting for the device. Ciao Hannes *: In my experience the ability for developers to easily use any of the per= formance optimization techniques is the biggest barrier for gaining perform= ance. Of course, this does not fit nicely in any of the standardization eff= orts in the IETF so the focus has to be somewhere else. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Fri Jan 25 06:35:49 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81D4128BCC for ; Fri, 25 Jan 2019 06:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRBm2G_5w7W3 for ; Fri, 25 Jan 2019 06:35:45 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 69B6F128B01 for ; Fri, 25 Jan 2019 06:35:45 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x0PEZcAa006976 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Jan 2019 16:35:38 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x0PEZbpe016415; Fri, 25 Jan 2019 16:35:37 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23627.7865.796955.746573@fireball.acr.fi> Date: Fri, 25 Jan 2019 16:35:37 +0200 From: Tero Kivinen To: Jim Schaad Cc: In-Reply-To: <00ac01d4b46c$00f9de30$02ed9a90$@augustcellars.com> References: <00ac01d4b46c$00f9de30$02ed9a90$@augustcellars.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 10 min Archived-At: Subject: [secdir] EDHOC and Transports X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 14:35:48 -0000 Jim Schaad writes: > 3. 6LoPan over IEEE 802.15.4: This has a packet size of 127 bytes. The > maximum frame overhead size is 25 bytes allowing for 102 bytes of message > space. If one assumes 20 bytes of overhead for CoAP then this means a > protocol packet size of 82 bytes. If one needs to break the message across > multiple packets then the maximum data size is going to be 64 bytes using > CoAP blockwise options. IEEE 802.15.9 which provides framework for providing key management for IEEE 802.15.4 do provide its own fragmentation and reassembly service, thus allows bigger packets to delivered between devices. When 802.15.9 was being specified we saw that support for larger packets in KMP is needed than what 802.15.4 provides (note, that in some cases the phy layer limits the packet size even more), and thats why we did define a fragmentation and reassembly protocol there too. Currently specified key management protocols for 802.15.9 include 802.1X/MKA, HIP, IKEv2, PANA, Dragonfly, 802.11/4WH, 802.11/GKH, ETSI TS 102 887-2. Someone would need to write specification how to use EDHOC over 802.15.9 to make it usable there too. Another omission in the KMPs provided by the 802.15.9 is the TLS, as nobody wanted to write that specification. In the IEEE there is some plans of doing amendment to the 802.15.9 which could include some new key management protocols, depending who would be interesting to write the text... -- kivinen@iki.fi From nobody Fri Jan 25 08:07:26 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD074130F81; Fri, 25 Jan 2019 08:06:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1548432376; bh=6wfpo/zRR+gH9ORM+gPeoU/EmAD4lrQRj5oLGilKiKE=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=LiH4lvCfIMGV1Si1Qw0BPsG3UTjvMW0dKW2IHjxTHDfiZOJNasOOlRSxyns0+Pnzt xC19kASG36xuc0Cu24MW2I4NQY+0sCdtZKWo0nU/CwMWpeJzJjdNJQAVa0pxxza5H4 nPpJ17AzubGUX8gBABqG7Nk1dd3wBJ1sBYZu13Cg= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Jan 25 08:06:12 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 127D6130F62; Fri, 25 Jan 2019 08:06:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1548432365; bh=6wfpo/zRR+gH9ORM+gPeoU/EmAD4lrQRj5oLGilKiKE=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=gsw6mbDTWSZvWcnljlGdL3HY628MzAGQ5aV8XMBjXIbmOMVSrXFm9yEcOTmPzWVeP tgBXvkLEOSDKKjhBsCsWN51QI117cpfI0ZgdVvUSeESJMrWliqKFJ5jw57EzsG63p2 CWre9XViznn9DOk78s12cOQjYtRnU/QB1WYHGIFY= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B54130EB1 for ; Fri, 25 Jan 2019 08:05:55 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <154843235559.29038.811400056729094465.idtracker@ietfa.amsl.com> Date: Fri, 25 Jan 2019 08:05:55 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 25 Jan 2019 08:07:25 -0800 Subject: [secdir] [new-work] WG Review: GitHub Integration and Tooling (git) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 16:06:21 -0000 A new IETF WG has been proposed in the General Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2019-02-04. GitHub Integration and Tooling (git) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Alissa Cooper General Area Directors: Alissa Cooper Mailing list: Address: ietf-and-github@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/ietf-and-github Archive: https://mailarchive.ietf.org/arch/browse/ietf-and-github/ Group page: https://datatracker.ietf.org/group/git/ Charter: https://datatracker.ietf.org/doc/charter-ietf-git/ Many IETF working groups use external code repository services, primarily GitHub, in managing their work. Individual working groups, while continuing to operate within IETF guidelines for working group activity, have developed their own policies and practices for how they use these services. These policies and practices cover aspects such as: managing discussion between working group mailing lists and GitHub issues and pull requests; how text contributions are expected to be made; labeling and naming conventions; maintaining readable draft snapshots; using tooling and automation; informing participants about IETF policies; and others. The GitHub Integration and Tooling (GIT) working group will select a set of such practices and document policies that support those practices. The policies will each detail how work is conducted by working groups that opt to follow the work practice. The goal is to provide both process and tooling support for working groups that choose to adopt the practices. The documents will not alter the Internet Standards Process (BCP 9), they will describe how to work within it. Whether working groups choose to use GitHub or the documented policies to support their work will remain entirely at their discretion. The working group may also discuss tooling requirements in support of GitHub use. Decisions about implementing specific tooling needs will be undertaken by the IETF Tools Team in consultation with working group participants and other interested contributors. Milestones: Aug 2019 - Work practice description and policy document(s) sent to IESG for publication as BCP _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Sat Jan 26 13:17:50 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2163131000; Sat, 26 Jan 2019 13:17:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjJLbmp8R7E9; Sat, 26 Jan 2019 13:17:40 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760119.outbound.protection.outlook.com [40.107.76.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3341E130FFA; Sat, 26 Jan 2019 13:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2I71B2sxtbbS5NPaIYzzlyytToVQdG16CDPBZK6YOjk=; b=cplmLC75/4F/dqY+qWvGcVvKEajeb/vDYhVvOZs2M+GVci5d+ozPZx950YJI1P8olzLd+2Aue+B0uSt2DqqO5N979LdGaPgJyMtI6vtUcjwRqJ0q0hBMCbHKqn6FOT8jTddQCGoUa4IivTtctJBJvYlDYVJAtFuBSgZw7DbJOSc= Received: from DM5PR0102CA0001.prod.exchangelabs.com (2603:10b6:4:9c::14) by BL0PR01MB4483.prod.exchangelabs.com (2603:10b6:208:81::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.18; Sat, 26 Jan 2019 21:17:34 +0000 Received: from DM3NAM03FT065.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::204) by DM5PR0102CA0001.outlook.office365.com (2603:10b6:4:9c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.16 via Frontend Transport; Sat, 26 Jan 2019 21:17:34 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT065.mail.protection.outlook.com (10.152.82.254) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.10 via Frontend Transport; Sat, 26 Jan 2019 21:17:33 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0QLHUqH005987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 26 Jan 2019 16:17:32 -0500 Date: Sat, 26 Jan 2019 15:17:29 -0600 From: Benjamin Kaduk To: Mach Chen CC: Linda Dunbar , "secdir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org" , "ietf@ietf.org" Message-ID: <20190126211729.GJ49072@kduck.mit.edu> References: <154455986336.13151.8483284555885294015@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(136003)(39860400002)(346002)(376002)(2980300002)(51914003)(13464003)(199004)(189003)(54906003)(76176011)(47776003)(7696005)(14444005)(4326008)(229853002)(55016002)(305945005)(97756001)(1076003)(6246003)(6666004)(246002)(356004)(106002)(58126008)(6916009)(53546011)(426003)(486006)(336012)(104016004)(186003)(26005)(8676002)(53416004)(75432002)(8936002)(126002)(476003)(446003)(11346002)(956004)(33656002)(23726003)(26826003)(86362001)(2906002)(478600001)(46406003)(88552002)(50466002)(316002)(36906005)(106466001)(16586007)(786003)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR01MB4483; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT065; 1:5klBDNEVGQg5sobp+q0lTuA6VKPbVARiP4B7QQH5ZDW+MTsA9hdMkMDTN6PvfRMlfzlyBK7IWROREpGF/6ylQbBGlD8/KOuRPUc3HLXo2ZlFDV7NvehMElKVCvD8l0jMglC3oUpIVEn9DJEsNHXMHg== X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 122caf7c-2370-4f67-24e4-08d683d3b0a4 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060); SRVR:BL0PR01MB4483; X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4483; 3:D+pPg+ndZ8DCmErMiOblxd05iAIluLANS0q2zLkYVvXCpM/g7Ry7qZJYxStX65TxUrLejXyn1MlSrCP+1Lhd6O7tK83fuft4pG8XL6MafU4R6TMW9Z3VU4LQqoN5vnceYsaI2m3ncrlvZ9aYB145lvVHEQLVBcfDtUTFDuRmG0t/a0OhkQi8AlhRPJ0ofuCrqyUHZgBsd9lqhctRhLU8YTHTUTON8EPuaI1HqQfvsfnaw6pWy+CoMjeXvoAzFG1bUbG/1kHzissJUhESGJqqJctTtqFC3kuuJowe/qU6WP60gYTmBR6Y8R6LNFQcOf/vbQKyBH/Vbuxakksg1+SHbpcN/oyOYoyJl8GRDMd45dML94yfIZbI1RDt2NuxCKab; 25:jX6jZM9IU/GgsW2cZzrqcM/rozORPxHDcLHXl5vwynl1JFQBdjmS70dPC7pT0kpTMpQldADLxmCtEgND6yDK0gcBdx6xcUz697vr3OetcuHx9Y0wh6RmdzFfRUfQwikYRjkJlx1D/aD0ylYWUvGxgkyS3oyod673U5vJt3MeSy9C8T8NizRgy3394MLjxMInbj+LvU3V7eAvsG2qh78lNhiRFeSKzTXWsaFCB7kQ88kR51H+E38XQDXO3cg5y8qVPy4DXeRme2T3qA+TM9ZmBz74SCJOIeomlJ21AE6ABJP624E5y57XFsitZ6/s0CEkP98xjCrohDY13q2VRQ341w== X-MS-TrafficTypeDiagnostic: BL0PR01MB4483: X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4483; 31:NaW1g+EjOYHuB6TjXKQYj49fr5Nschofyj6lTjEyl05ba0xeWaeBQws9FJAJYYoJHEYH/nYN2sxLdgXR6RsDUAEVLTlS+YDthKum/R0JZxgcGmoHTfGSB6rluxO+jVtoMcssEMm6O0ArHW8E+LdqN0ylhibeiiytWQO7vvYYU9p9G8qq55CmJx9WlpGHnaGeQ9DSyTvkqy4vv/mR4mTsjdin2NarGQViiYNAKlya1V0=; 20:YPPq9C/uEXXMypoKyWiW1tzBKyNbqEOl5c38cqZBQH73A/DdpaadyPYy0P1uH8A4KobRIfrkieNgdFTly7TPnOrppF6OPuZKLPiVRvU5aBAL6nm5h9pEih6igTEM+FJDsqMAVrW37e8lBtzEX4wRgJyB/norlz/CgrMZ1N80vR++VDc/A9ka1j4sGsGSY4+lebuSnUfOLika0mc3cpXqoM4Rr2IT5pALCHsJquxHNwW/Pl7binxwr+cM8QWBq7GlM6QwNVgCdJ1Ceb+lfQ5DhjK1Zk/sFWEZ6Pv5nLzgGsLDHA2OkwdlELQdTo05l/kiRcuM7zFziQYjIJbMFM8G0doi4bwHznDTRImBKUCn7Eobl8hWdASXCmawo6mlnOEOnv7acdKfLuEQdQ0d7b79DW1D87mKQm8aC55cCuA1oGvX6u2/bRisvpudBiqki+jjvzU/3LUvEDfrF8gc6Mj/A8/1Q+XWzrTd/FDhjkfCxioKypZKIqFhhH+2u3G95PwQ4xYozZhZ87EAlAdOLDce8QVRa8zenay6PmcA8YwNhbCdHkBxoIWjTGwgR5+KnUKBTgFUMI7lEzmr24Q0SYl9w0LtA2Q6rSxTrNEi1FFozqI= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4483; 4:Ei19V+kL7VA/kJOhybc/QVcf6Xcgy2cmtbpFNuzfonEZX3ma9rsGNGmk0GuvnZD/LxWJf+1y5skxGq08eb6vesNPgtt2Ra6ssNgy64RnWHP683QtjXw19UYMA6k17o+IPHcVckkbAk+LYHUhYa+HlyAMaM5MjeaBQMOerXwMiltDGWOreGWmUpuFoc5upJwGlzWnfoACTakWZIuuN0rM6+DXn5ez/qta39vsYjFU+nkGL942N72bf6JIBRBRc09JFmqoSiBZWITE2I6SQAB1MPtXbpG7BQ/Z+gHGC0tBIcw+JKmMIdgnqya34kRaNNwW X-Forefront-PRVS: 0929F1BAED X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL0PR01MB4483; 23:iFo3/nuJ6udS1iQwOb02Z+EbHsqitGYQb/oqqS882?= =?us-ascii?Q?q/jc4EK7fOnEcxrilZTQkRNAXgd76j4o3DcC0CLSGXIBAIoouy25/0CwZf0h?= =?us-ascii?Q?B/+w1dX1C7o0EeiKsL/v/Tx831aBVBOqUpWiyZewp8Qrn+fZZDWrrioz8omT?= =?us-ascii?Q?r6IvBok3vSXxUH2fVtseLF6x5DdrcOOE6p5ew38jUCWHL4Or+f3iU+gs8NLO?= =?us-ascii?Q?fg5kP4mP6bLimxmhYXiOTpM9/KjNKEW/mY4VbP0c6HrZb980ja8eCle6+mYA?= =?us-ascii?Q?iNC6LE2cuxZzXCCSma2eT3zLiCwQ9oKUAAwwrlXnYcrxqGXNu1p4E/9+ks91?= =?us-ascii?Q?wwLVszdZ+4FwOESjfPOjtz9DALSv9DeBbChQA6S4gkxFTLAwBEM96oVpKftL?= =?us-ascii?Q?0K7Gb/gnnqJXl91scCoRseKSrF24+3kbWlGHfC90G0SJOI8QHrJnxgCTpSoT?= =?us-ascii?Q?Ul73tWbyv7zkLGn/NQleS4uyB/rj1OClyk+5yiArBRrI+zgDwBMhdRBTTE7x?= =?us-ascii?Q?Uw8uWstSLbLSuMcBw9o25IizX0yB9G/LBNEb03kaa+IbcCbZQRVlSuizsuqQ?= =?us-ascii?Q?XhoWbYee6SFPMsUMIAjAO2Ab89lvitnfqdIeGdZb/uAqdDliMnVFbs2szkPk?= =?us-ascii?Q?N6zbf9ixg5aYUvEckZJ4YamlqgtUz3fZJ+Mq8lirYuUXgeq+U41wWOq1zfnb?= =?us-ascii?Q?JNnb6VTXNhOX15HHfeaZ8sjd+CX6cBJH8HMwBTCCRxKFXEMlSWsPs0s16R3/?= =?us-ascii?Q?RSRSqCQ6E6vxSvYschF+WivjnR/Y/7hRbXGFs1BeCQ7Ab/K69OfOJEhnnkO6?= =?us-ascii?Q?+RDNXE+ZkyD2Qoad7Bk+bHFxmoEOBIrow6Lp/no8Pj3Bt7mMv9Cs0bS1s0by?= =?us-ascii?Q?PZg6OVLJt7/XN1qNf5K5SSzYlSZ8JuDIQKR8jjuvr4mG4eq58N8uWWBYT8c9?= =?us-ascii?Q?t1vpuGUI2OJy+rSzFSUVsnckfOIxh6ZAWme0x4QhI6VP2lMOH5eWMvNPBXYt?= =?us-ascii?Q?ZhWV3f+HPIpEzVRAThTwk4j9+V0rtTKBRSCRx9SyzNU5mLQKCinCyjrpOZyA?= =?us-ascii?Q?ix8e0W4xSOk2vpNgoWBGXO95Cr2B2B59SumsWM+Z27A8MEWLGqZgu22quRx/?= =?us-ascii?Q?RyA4YLqh1g5mkGtw0FSfZaePbmW62HrMueLRVDkc6iFUOBvY9dw1wt8vzJZP?= =?us-ascii?Q?2Dmu2OYpOI17WunH+4c4IazIXhcijMoEAAQ3RzfGgzwS++1e2bTt70KV79I9?= =?us-ascii?Q?wqxjvBLMzIZQv3UFp5r6mys9HyRq0PfOd2jYQTc?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: MZRrcHEfXE7dkVnGYfKzyDDYzV1dvQ65c6QpvY3xlxioDzSPN3JduwEE5FNvr5AJEXCW1crNqIuielxth3uW3apsJ8b5b1GOR4MOOAZuFiHipNHT6yIGtnZk9j+sjSl5GwdPcRgzIC4V+Z0nQhpg3tkGMTV56FdM6pflEuEsaY6eLGORGACrkJk1iorsYvvbXHogXm9s1hlAp2LxWZ5GX7LuObB3eQvKQtCH7euDGwxir5+BVqWkaP4KxNm/COPERMBAqHLVwPLe5XGaiQJkh+1EL08A6vOgZBIfxssbf+nr5XmVaRBAdWTJW7SG3X2AK41e1xkmbEUfZYzUTDSaF/ECNLoGyDIe74zzoqm05yyzkLbFNV+gDYtFnZz4AWaOTuhyll6GyxBPjkH97CwuUlXdl5JTbsYpHvWUcOUH0L0= X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4483; 6:3VYialgj7LqHYCrVvtZvZxc24Z72VQSOX0L+JNEWsZTToEXY/VDwRiatF4S3P20hsS3LGY6HpECjkJ3+yOD8I6Oi0l0caOBfs6AN7L3llDH5/1P8Kl9wdbsqg0mq8AsbgIfaOqM8Ptu0+Vx5pcAeHk/FLtdn2N6U5FUR5XS9K2Q6no7fF/fsJiaPrIa9JBl/8IAVju7PJWxUO80/u4jBGN/RxGCrBI+aS7/tNLf3l5DwBYk8ctPqGNwQ6ZQe/VAhYq/iGe9uNYFIA+6037fvl2MvPHBXapQ07pit/UaQBpC5t5F1EGoSowI1jntU9lklzbNgTQhDPsW97dsNiwz3aeKTUvZ7rlhNQNP73YexRoFZmTGkiHb5kUEvixstA5Ufl4PdLxIFDSXO0cQxeTO5TKSLCzvBUkbl6XAoef2NUnSzs9XH/3m4a0hmxye04hwBQ3tdJnhQNWufCvFNmtmN2A==; 5:T2nCYOtfPF+jgBQrDenGHP5dgrMi0ckLE94eOPUmbZr42rPLRuJashhcaJhDum0MsdDMfRC5ZMUxkloBesyWaX2IxIJVX8xWhUNd5pq5tHRaNRirB0iU/akLaGhiF/AKtgbmIRZy7UcbtByCC1oZk6F00FYUHzaQBXpCaEOgW9KTCAWx8zANu1SYESghtSyvTudw84oIpDwe6aM4ul6SEA==; 7:zjW8eFF/kCXLTqJDHRR1clhNbW2xyJ0P88y1PZGfFp3cI/IWDTHnoL/4SRMSD4BHCjIEuK63T4ckglQ7h6a7xGa2faTj+IGuNCr73GVN1BTC7apD/+jHf62KBaOzRNT1pBGxVrvhIrsi193oMgOwpg== X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2019 21:17:33.9565 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 122caf7c-2370-4f67-24e4-08d683d3b0a4 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR01MB4483 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2019 21:17:43 -0000 On Fri, Dec 14, 2018 at 02:11:21AM +0000, Mach Chen wrote: > Hi Linda, > > Thanks for the review! > > Some responses inline... > > > -----Original Message----- > > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Linda Dunbar > > Sent: Wednesday, December 12, 2018 4:24 AM > > To: secdir@ietf.org > > Cc: mpls@ietf.org; draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org; > > ietf@ietf.org > > Subject: Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05 > > > > Reviewer: Linda Dunbar > > Review result: Ready > > > > I have reviewed this document as part of the security directorate's ongoing > > effort to review all IETF documents being processed by the IESG. These > > comments were written primarily for the benefit of the security area > > directors. Document editors and WG chairs should treat these comments > > just like any other last call comments. > > > > The summary of the review is Ready with comment > > > > The described mechanism for LSP Multipath Ping is very clear. The Security > > Consideration re-uses the description of RFC8029, which is very > > comprehensive. > > It would be better if the draft describes how to prevent intermediate LSRs in > > between the Initiating LSR and Responding LSR from mis-using the detailed > > link information (e.g. forwarding to somewhere else). > > The Echo Request and Reply messages are directly exchanged between the Initiating LSR and the Responding LSR, those intermediate LSRs just forward the messages as normal packets, they will not see the detailed link information unless if they inspect and do DPI on every packet forwarded by them. > > The detailed link information is supplied to the Initiating LSR for using, the intermediate LSRs will not try to use it even if they received the information, because there is no corresponding Echo Request to the received Echo Reply. The intermediate LSRs still will have access to the plaintext information, even if in normal operation they do not need to act upon that information. Generally in this sort of situation we will either explicitly state that the intermediate nodes must be trusted to not abuse the information in question, or provide some mechanism for end-to-end confidentiality protection. Also (noting that I only skimmed the document so this may not make sense), the security considerations seem to suggest using an IP ACL for determining which messages are trusted; IP ACLs are generally not recommended in favor of cryptographic mechanisms at this point. -Benjamin From nobody Tue Jan 29 18:03:27 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FF71310D4; Tue, 29 Jan 2019 18:03:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner To: Cc: draft-ietf-babel-dtls.all@ietf.org, ietf@ietf.org, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154881379920.7794.15439486195773911279@ietfa.amsl.com> Date: Tue, 29 Jan 2019 18:03:19 -0800 Archived-At: Subject: [secdir] Secdir early review of draft-ietf-babel-dtls-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 02:03:19 -0000 Reviewer: Sean Turner Review result: Has Nits Hi, David wanted to make it really easy on me and get as much early input as he could get by sending a msg to the TLS list asking for comments [0]. Version -02 addressed those comments. I'm no babel expert, but I did take the time to read/skim the base protocol document to get more familiar with it as well as re-read the babel-tls draft. The tl;dr here is that babel is multicast but DTLS is not so changes to babel are needed. Here are my comments in no particular order. No show stoppers here. 0) Since DTLS is in the RFC Editor's Abbreviations List - I think you can get away with: Babel Routing Protocol over DTLS But, that's up to you. 1) (IEGS food fight alert) I see that the updates header updates 6126bis. Not sure how this will fly in the face of the draft IESG Statement [1]. 2) (This might just be document organization) The applicability section kind of jumped out at me because there's also an applicability draft. Further, it and 6126bis says the HMAC mechanism is preferred. I'd just drop the entire section ;) 3) s2.1 - maybe add a pointer to the IANA considerations section. 4) s2.1 - Because you're doing client authentication do you need say anything about the type of cert, whether certificate_authorities, signature_algorithms_cert, signature_algorithms should be sent (for 1.3 connections)? 5) s4 - add that IANA is requested to point to this specification for the reference. 6) AppA - I think you might need to tweak the last sentence in light 1.3? Cheers, spt [0] https://mailarchive.ietf.org/arch/msg/tls/tIaK0rgm5zCVuYmLm5qsCIvKXKw [1] https://mailarchive.ietf.org/arch/msg/ietf/-1u_1-peHKAmUDuLyGAJYu0fPCE From nobody Wed Jan 30 08:28:14 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E681131228; Wed, 30 Jan 2019 08:28:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: Cc: draft-nottingham-rfc5785bis.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154886569351.10484.4703007670359734409@ietfa.amsl.com> Date: Wed, 30 Jan 2019 08:28:13 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 16:28:14 -0000 Reviewer: Kathleen Moriarty Review result: Has Nits Thank you, Mark and others for your work on this document to update the specification. My comments are mainly requests for clarity in the document and text suggestions are provided to hopefully make this as easy as possible. 1. Section 3: Nit: In my opinion, the flow would be improved if the third paragraph came before the current second paragraph. 2. Could you provide a transitional sentence between the current second paragraph and the instructions that follow since the current second paragraph points to following section 5.1 for instructions, but paragraph 4+ include instructions or guidance followed by additional helpful information. I think a slight adjustment as follows to accomplish this would be quite helpful to the reader: Applications that wish to mint new well-known URIs MUST register them, following the procedures in Section 5.1 and the following requirements. 3. Section 3.1 says: The "Well-Known URIs" registry is located at "https://www.iana.org/assignments/well-known-uris/". Registration requests can be made by following the instructions located there or by sending an email to the "wellknown-uri-review@ietf.org" mailing list. I'm not clear on the instructions as I follow the link to the registry and there's a pointer to the RFC that this document will obsolete. I'm assuming that the reference will be replaced with this document. Is that the case or are there additional instructions than what will be included directly in the registry? If they are repeated (I don't see an IANA request for that action), that is fine, but I think it's a little confusing to send someone to that link if they are already reading this document. This document is also going through a review process to update that registry, so if instructions were maintained at the registry URL, what would be the review process to alter the instructions? I'm assuming that this sentence just should be removed, but if not, I'd like to understand the update process for that registry (instructions for registering values not adding them). If the sentence should be changed, I suggest something like: The "Well-Known URIs" registry is located at "https://www.iana.org/assignments/well-known-uris/". Registration requests can be made by following the instructions in this document and sending the email to the "wellknown-uri-review@ietf.org" mailing list. 4. Question on Change controller: Is it possible to successfully make a request through an experimental track RFC or standards track only? If experimental is allowed, can it only be provisional? 5. Section 3 has the following sentence: General requirements for registered relation types are described in Section 3. Did the document in a previous revision contain something in section 3 about registered relation types or am I missing something when reading section 3 (which is entirely possible)? If it were there (or maybe was in a previous revision), I'd expect to see it in the following paragraph, but could see the above text being dropped as an answer to this question as well (unless I am missing something): It MAY also contain additional information, such as the syntax of additional path components, query strings and/or fragment identifiers to be appended to the well-known URI, or protocol-specific details (e.g., HTTP [RFC7231] method handling). 6. Section 3.1: Is the following referring to IETF standards-track documents or could other standards from other SDOs (or some other constraint) be included? Standards-defined values have a status of "permanent". Other values can also be registered as permanent, if the Experts find that they are in use, in consultation with the community. Other values should be registered as "provisional". I'm guessing a standards track RFC is not necessary for standards track because of the next paragraph in this section, but maybe some added text would help to clarify the above paragraph? Provisional entries can be removed by the Experts if - in consultation with the community - the Experts find that they are not in use. The Experts can change a provisional entry's status to permanent at any time. 7. Section 5.1 second paragraph has the following text: Well-known URIs are registered on the advice of one or more experts (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC8126]). This should read as follows according to RFC8126 section 5.2.1: https://tools.ietf.org/html/rfc8126#section-5.2.1 Well-known URIs are registered on the advice of one or more experts (appointed by the IESG), with a Specification Required (using terminology from [RFC8126]). There's no provision for the IESG to delegate assignment of an expert. IESG member often consult working group chairs and experts, but the assignment is currently performed by the IESG unless RFC8126 gets updated. 8. Section 5.1: (additional context for #5) Text adjustments in section 3 similar to what was proposed above may help avoid confusion when someone reaches this text on requirements in section 3 so that they are grouped and called out specifically as requirements. (No change suggested here, but rather just expanding on the desire for clarification above). The Experts' primary considerations in evaluating registration requests are: o Conformance to the requirements in Section 3 o The availability and stability of the specifying document o The considerations outlined in Section 4 9. Section 5.1: There may be additional information I am not aware of, hence the following clarifying questions. Is there a hold on the registry from now until this document is published? Could an expert receive a request prior to publication where they feel the right status is "provisional" and is timely (cannot wait until after actions for this document are complete)? I'm asking because of the following text and the answer may be yes, there is a hold, but I am not seeing where one is listed. Since the expert can update the registry at any time, is the second bullet necessary (could it cause problems)? Upon publication, IANA should: o Replace all references to RFC 5988 in that registry have been replaced with references to this document. o Update the status of all existing registrations to "permanent". ------- 10. For the IESG: Are there plans to name a second expert in case Mark isn't available? ----- I hope you find these comments helpful to further clarify the text of this document. Thank you, Kathleen From nobody Wed Jan 30 14:10:43 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B02130EB2; Wed, 30 Jan 2019 14:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Y1eT2X6_V-D; Wed, 30 Jan 2019 14:10:41 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8FB1130EBD; Wed, 30 Jan 2019 14:10:40 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id AAF6F28B0043; Wed, 30 Jan 2019 17:10:39 -0500 (EST) Received: from [127.0.0.1] (nova.tislabs.com [10.66.1.77]) by nova.tislabs.com (Postfix) with ESMTP id 740FA1F804E; Wed, 30 Jan 2019 17:10:39 -0500 (EST) From: Russ Mundy Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 570579038.0771509-849baa518c5707c2f5c8c95ed554aaa0 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <5920C065-DDDB-4C1A-83FB-E0436C467D3B@tislabs.com> Date: Wed, 30 Jan 2019 17:10:39 -0500 Cc: Russ Mundy , draft-ietf-mpls-sfc.all@ietf.org, ietf@ietf.org To: secdir@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [secdir] secdir last call review of draft-ietf-mpls-sfc-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 22:10:42 -0000 Reviewer: Russ Mundy Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Document: draft-ietf-mpls-sfc-04 Reviewer: Russ Mundy Review Date: 2019-01-30 IETF LC End Date: 2019-01-31 Summary: This document defines defines a methods to achieve Service Function = Chaining (SFC) using Network Service Header (NSH) in Multiprotocol Label = Switching (MPLS) networks. An architecture for SFC is defined in = RFC7665 and NSH is defined in RFC8300. This document has issues that should be addressed before it is ready to = be published as a Proposed Standard. Issues: First, the document and in particular the Security Considerations = section points to published RFCs for discussions of the security = properties. In particular, RFC7665 and RFC8300 are referenced however = each of these documents left some significant security descriptions & = definitions to be addressed by implementation documents such as this = one. Additionally, the SECDIR reviews of the IDs prior to publication = of these RFCs point out several security related issues that, as far as = I could tell, were primarily addressed by saying that future = implementation specifications will address them. Since this ID is such = an implementation specification, referring to the earlier RFCs for the = security properties results in essentially no security properties = provided in either the earlier RFCs or this implementation document - = security properties need to be identified avoided via circular = referendes. Next, the Security Considerations section identifies that the certain = elements of the design must be a =E2=80=98trusted resource=E2=80=99 and = that some functions must also be trusted. The term =E2=80=9Ctrusted=E2=80= =9D in relationship to computing and software has a wide range of = different meanings (as shown by many years of research in the CS field). = In the context of this document, my guess is that it means that some = unidentified (but not defined) entity believes (=E2=80=9Ctrusts=E2=80=9D) = that the software will do the =E2=80=9Cright thing=E2=80=9D - to me = (from a security perspective) it also means trusting that the software = will not do the wrong thing. All of this is very abstract (both the = Security Considerations text & this critique) which in my view is why = the 'trust' section is very inadequate for an implementation document. Additionally, the last paragraph of the Security Considerations section = asserts: Thus the security vulnerabilities are addressed (or should be addressed) in all the underlying technologies used by this design, which itself does not introduce any new security vulnerabilities. As far as I could see, the assertion is not supported anywhere in the = document itself or other referenced documents, i.e., what = vulnerabilities should the implementation be concerned with (e.g. = passive monitoring, active attacks on metadata, etc??) that result from = this implementation. Since the document does not provide a clear = identification of it's security requirement, any security services it = does (or might) provide nor require from underlying technologies, the = assertion should be clarified, supported by additional information or = removed from the section. From nobody Wed Jan 30 15:08:22 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEE7130ED7; Wed, 30 Jan 2019 15:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.263 X-Spam-Level: X-Spam-Status: No, score=-3.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frakqgAUX9BZ; Wed, 30 Jan 2019 15:08:16 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 C8F48130F05; Wed, 30 Jan 2019 15:08:13 -0800 (PST) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0UN2jdv014817; Wed, 30 Jan 2019 15:08:13 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=0tPqQ5dmiIaDhH0osU/+bX4f8bBpj4EtNFr4ENOm+Cg=; b=x98JoPqnaLP+xEfXlN+3Q8744bRsSgEG9+945hOU8ngevGX4I4aFYOQCxJkVIbmkqMax A4HM6ZhEYFlWykgETVR4nMcG82fK79FBVDc5C4WlQMDtIkiZM4fzDLvraGrQj5K8gCWv fuEUtu371B6fpAotD1/MXVt+AFg6kAnigF9VUo/z6lB7X3n0/X/mmAqcREj0WgrsfB5z kwQBs/epJlrg+Z1M7kYU2ijDnqkdv5hobwCfaug3VHQANDKSAoGXwvbUyEdVnSB52iLk q3iGkpjZLpKi+L3wYI4948vKkUQQFIq1/UzZ4NSrpJROOcS3TIwn66AeJhnHqIuMDun2 MA== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp2057.outbound.protection.outlook.com [104.47.34.57]) by mx0a-00273201.pphosted.com with ESMTP id 2qbdm80uwq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Jan 2019 15:08:13 -0800 Received: from CY4PR0501MB3698.namprd05.prod.outlook.com (52.132.97.154) by CY4PR0501MB3843.namprd05.prod.outlook.com (52.132.100.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.11; Wed, 30 Jan 2019 23:08:11 +0000 Received: from CY4PR0501MB3698.namprd05.prod.outlook.com ([fe80::4e9:c3bf:1c78:68d6]) by CY4PR0501MB3698.namprd05.prod.outlook.com ([fe80::4e9:c3bf:1c78:68d6%5]) with mapi id 15.20.1580.017; Wed, 30 Jan 2019 23:08:11 +0000 From: Cyril Margaria To: Vincent Roca , The IESG , "secdir@ietf.org" , "draft-ietf-pce-gmpls-pcep-extensions.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-pce-gmpls-pcep-extensions-12 Thread-Index: AQHUgwvDphDSiahwmUOqL/DqfyKS4aXI2la7 Date: Wed, 30 Jan 2019 23:08:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0501MB3843; 6:GGxSp2fU8XwnSRas0Wg+u8luayd/+1KYYDgu4zuIasajqX1m2DV1J1mHVtAQmYHWzEL4stcXIGKZIt2RX1pInZ8Y6lCW7uYr/Wkuk1hyv8zCIMVfSBm9buaSI9KDDZ7W/GuyY10NoLObdJbVYBo9XhKAI8QH/DNoJgEjk/nDtFaR+UIdOJOoUjDEp/aGLOTE+KRZlEJySlUTWIUuI5UzmL8qfVN6HFmtlHPDZT9tvGZvzKMXrCDFsvZvXr+jno0hdIsTVp2Zf3EGKf/vWryEWNUxGu2Dr8DHo/Nl0nUZ8aPwyLt6FqzWKe82p7qnfdJAPhvTSvRhfMa7r7WiqQt8CqTVAHpAb83y3JWUf5ke4AiFKA4GG9ApP/oF+/TANU27xs8ctf5ub8b/+LSFJeRWT+/apVRSUTJlojYb+Eb8OUNiO+d2+xo1yTeTDGoXhS0hRg1S0nSAPniEO0sA4ApE5Q==; 5:ghEzmpqHQua06O9GZZKAOdN4igRsDoZEXXzAlRHohE2DDJ2Sso1VCQoE+2IyvT19WbZZKRvo515KTDqIaEitRbBJtlJmD4L88+Z3mAooOOxsftivSpzmtAVR5I0GU/DjU3mxk6+1rF8gfyeVRh+AnAU43KhrMUtg5m+mpzcio2HhPTphY9w6Tl+bbgJRPWCUHmMy3++PRbF5/grDWBRDaQ==; 7:nwrhSuln2/v1qzJH41wrTanO08V92jGHrlA17GHLUkK0ljZQcMo96xU1Tp1/MK3VAEWqcgB2Vyxs3p8XVc9NE4toijsPczsegZ+zwobDN3pdlwkAGPaQzFSy5sT0mliGFKQTjb/YgSAQJAT7Mx2vLg== x-ms-office365-filtering-correlation-id: 2abae5c9-4045-4e08-d819-08d68707ce50 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:CY4PR0501MB3843; x-ms-traffictypediagnostic: CY4PR0501MB3843: x-microsoft-antispam-prvs: x-forefront-prvs: 0933E9FD8D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(39860400002)(366004)(396003)(376002)(199004)(189003)(6506007)(81166006)(8676002)(606006)(81156014)(256004)(71200400001)(102836004)(14444005)(53546011)(71190400001)(2906002)(86362001)(74316002)(186003)(446003)(486006)(66066001)(11346002)(2201001)(476003)(26005)(68736007)(7696005)(8936002)(76176011)(105004)(25786009)(33656002)(54896002)(6116002)(97736004)(9686003)(6246003)(106356001)(6306002)(55016002)(236005)(7736002)(3846002)(229853002)(53936002)(316002)(110136005)(2501003)(14454004)(99286004)(478600001)(105586002)(19627405001)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0501MB3843; H:CY4PR0501MB3698.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Y/1xQxt/p49XfLheY/c8abkBd9UKude6fAU1tWMm2A/KLiBmpkwbgVsb1UIFgAldroFMVNLR+g1w3fvgjVrQIfI6lwAVVEPafFsz9UXTbXeY5HtJawVZUrxihVpROPWQf9CARB/KgfVfnFE+coRZvKawKa1zKaKbtmEbUZZUov5H5tf1xDOEj0EcETfLo07Vyll6x2DQVQzVJXE3zdfwZHRZl5+wG3O83qITCFOJVXD7K/zAeVu3uBfnaO2UQUQo4yhq4JCAKWDsu+FXBXlwE4HtclWGTc4A6wZKMdsYXvhoTUw9sT2OBXNeM3I6mUKMbH9LuRsBp5VtbNNBHc+2xO6dh/NE+u6fQxcaW+E50XprajubWxmMwfvKPE+90rch6UDJk81At/lGWnGZe38Tfkoxwp32c0dot0Cj3LyHq+s= Content-Type: multipart/alternative; boundary="_000_CY4PR0501MB36985EA23D8870C52322CD26B5900CY4PR0501MB3698_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 2abae5c9-4045-4e08-d819-08d68707ce50 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2019 23:08:11.4608 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0501MB3843 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-30_17:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901300166 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-pce-gmpls-pcep-extensions-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 23:08:20 -0000 --_000_CY4PR0501MB36985EA23D8870C52322CD26B5900CY4PR0501MB3698_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks a lot for the review, please see inline for answers, a revised I.D will be posted shortly ________________________________ From: Vincent Roca Sent: Friday, November 23, 2018 01:05 To: The IESG; secdir@ietf.org; draft-ietf-pce-gmpls-pcep-extensions.all@iet= f.org Cc: Vincent Roca Subject: Secdir review of draft-ietf-pce-gmpls-pcep-extensions-12 Hello, I have reviewed this document as part of the security directorate=92s ongoi= ng effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready with issues The Security Considerations section provides a good introduction to the ris= ks. However my main concern is the lack of discussion around security policies. After reading this section, we have the feeling that TLS alone is sufficien= t to secure the GMPLS PCE WRT the three attacks described. With scenario 1, a fundamental part of the solution consists in setting up security policies: what is acceptable or not in terms of path? It may be discussed in the two references mentioned in the last paragraph, but even in that case, the way the current section is written is misleading= . [MC] Would the following change clarify the section? OLD: The security mechanisms can provide authentication and confidentiality for those scenarios where the PCC-PCE communication cannot be completely trusted. Authentication can provide origin verification, message integrity and replay protection, while confidentiality ensures that a third party cannot decipher the contents of a message. NEW: The security mechanisms can provide authentication and confidentiality for those scenarios where the PCC-PCE communication cannot be completely trusted. [RFC8253] provides origin verification, message integrity and replay protection, and ensures that a third party cannot decipher the contents of a message. In order to protect against against the malicious PCE case the PCC SHOULD have policies in place to accept or not the path provided by the PCE. Those policies can verify if the path follows the provided constraints. In addition Technology specific data plane mechanism can be used (following [RFC5920] Section 5.8) to verify the data plane connectivity and deviation from constraints END I have two additional comments: ** Ambiguous text: it is said o Message deciphering: As in the previous case, knowledge of an infrastructure can be obtained by sniffing PCEP messages. Message deciphering suggests the message is encrypted but the attacker has enough knowledge to decrypt it. I'm not sure it's what the authors mean= . I think there's a confusion in the use of "deciphering" which in security explicitely refers to encryption (https://en.wikipedia.org/wiki/Cipher). [MC] It should be replaced by message inspection ** Ambiguous text: it is said "Authentication can provide origin verification, message integrity = and replay protection,..." [MC] Will be replaced by RFC8253 provides.. =C0uthentication of the two peers on the one hand, and integrity/replay protection on the other hand, are different services. There's probably a package where these three services are bundled together, but that's a design choice. I suggest changing a little bit the sentence to avoid this confusion. Typo: ** Section 6: "A legitimate PCC could requests" : s/requests/request/ [MC] OK Cheers, Vincent --_000_CY4PR0501MB36985EA23D8870C52322CD26B5900CY4PR0501MB3698_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thanks a lot for the review, 

please see inline for answers, a revised I.D will be posted shortly


From: Vincent Roca <vinc= ent.roca@inria.fr>
Sent: Friday, November 23, 2018 01:05
To: The IESG; secdir@ietf.org; draft-ietf-pce-gmpls-pcep-extensions.= all@ietf.org
Cc: Vincent Roca
Subject: Secdir review of draft-ietf-pce-gmpls-pcep-extensions-12
 
Hello,

I have reviewed this document as part of the security directorate=92s ongoi= ng
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments= just
like any other last call comments.

Summary: Ready with issues

The Security Considerations section provides a good introdu= ction to the risks.
However my main concern is the lack of discussion around se= curity policies.
After reading this section, we have the feeling that TLS al= one is sufficient to
secure the GMPLS PCE WRT the three attacks described.
With scenario 1, a fundamental  part of the solution c= onsists in setting
up security policies: what is acceptable or not in terms of= path?
It may be discussed in the two references mentioned in the = last paragraph,
but even in that case, the way the current section is writt= en is misleading.
[MC] Would the fol= lowing change clarify the section?
OLD:

   The security mec= hanisms can provide authentication and
   confidentiality = for those scenarios where the PCC-PCE communication
   cannot be comple= tely trusted.  Authentication can provide origin
   verification, me= ssage integrity and replay protection, while
   confidentiality = ensures that a third party cannot decipher the
   contents of a me= ssage.

NEW:
 The security mechanisms= can provide authentication and
   confidentiality = for those scenarios where the PCC-PCE communication
   cannot be comple= tely trusted.  [RFC8253] provides origin
   verification, me= ssage integrity and replay protection, and ensures
   that a third par= ty cannot decipher the contents of a message.

   In order to prot= ect against against the malicious PCE case the PCC
   SHOULD have poli= cies in place to accept or not the path provided by
   the PCE.  T= hose policies can verify if the path follows the provided
   constraints. &nb= sp;In addition Technology specific data plane mechanism can
   be used (followi= ng [RFC5920] Section 5.8) to verify the data plane
   connectivity and= deviation from constraints
END


I have two additional  comments:

** Ambiguous text: it is said

        o  Message deciphering: As= in the previous case, knowledge of an
              infrastruc= ture can be obtained by sniffing PCEP messages.

Message deciphering suggests the message is encrypted but t= he attacker
has enough knowledge to decrypt it. I'm not sure it's what = the authors mean.
I think there's a confusion in the use of "deciphering= " which in security
explicitely refers to encryption (https://en.wikipedia.org/wiki/Cipher).

[MC] It should be = replaced by message inspection


** Ambiguous text: it is said

        "Authentication can provid= e origin verification, message integrity and replay protection,..."


[MC] Will be repla= ced by RFC8253 provides..

=C0uthentication of the two peers on the one hand, and inte= grity/replay
protection on the other hand, are different services.
There's probably a package where these three services are b= undled together,
but that's a design choice. I suggest changing a little bit= the sentence
to avoid this confusion.


Typo:
** Section 6: "A legitimate PCC could requests" &= nbsp;: s/requests/request/
[MC] OK

Cheers,

  Vincent




--_000_CY4PR0501MB36985EA23D8870C52322CD26B5900CY4PR0501MB3698_-- From nobody Thu Jan 31 02:52:07 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993A0130EBA; Thu, 31 Jan 2019 02:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhvB8kE2SL7b; Thu, 31 Jan 2019 02:52:05 -0800 (PST) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 B0C4C128CE4; Thu, 31 Jan 2019 02:52:04 -0800 (PST) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id x0VAq2cR002415; Thu, 31 Jan 2019 10:52:02 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3EFFB22044; Thu, 31 Jan 2019 10:52:02 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id 28F7B22042; Thu, 31 Jan 2019 10:52:02 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.189.92]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x0VAq0wP032293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 31 Jan 2019 10:52:01 GMT Reply-To: From: "Adrian Farrel" To: "'Russ Mundy'" , Cc: , References: <5920C065-DDDB-4C1A-83FB-E0436C467D3B@tislabs.com> In-Reply-To: <5920C065-DDDB-4C1A-83FB-E0436C467D3B@tislabs.com> Date: Thu, 31 Jan 2019 10:52:02 -0000 Organization: Old Dog Consulting Message-ID: <055301d4b953$0044f3d0$00cedb70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKncW31kBUGQFOHrs80y4/8+kj9a6QjqWkA Content-Language: en-gb X-Originating-IP: 87.112.189.92 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24400.006 X-TM-AS-Result: No--18.325-10.0-31-10 X-imss-scan-details: No--18.325-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24400.006 X-TMASE-Result: 10--18.324600-10.000000 X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbOYAh37ZsBDCVBDQSDMig9GqvcIF1TcLYGaz bvK3eijuQAvTIQMxZJ9ERAG5H09G8aNmd7pYp+mtTVa+L3Zgqc7Thmt8qRASYJJWUogu623F7kO MrBz6LkmT5dDfN8Tpsa8XLD5qB/Bi8FFFRqZ+F4xu+yxbbkYIFhlgDfyCPcHEFRlN8zTSzj7FQN PEve+5IITQBkTtwk+z3ENKbj/2xt/kQ45DXVbLaBVXx+49zfW3YfCcFySxIqU/17THutn2g0AC5 xm4Bei1M6TEcC5a4IANYIDF+TyWAVqgUVEApa8m84dsinZ5e1gfXzVgO0hVqj9QzIS5KoGBD8FP ruvrBUvDWuH4B0t8VYmrwhubYlODWehFCA8qX0OTeuX4xo2DEM0ENs5LdCH5V6KWY8jugmW8ISQ WFLhHcBnGRpIgNrtwzgEXO60X3oyTsChfABLrkhXbvUeivEs0D8tT5eIcvW2vloAnGr4qhpivGt cLct3uskr7LbqmDOAKeN7VuhdCKynbeaPf0/tqNVRz+HwqL4KCEWSnl/5g9hER5MrEGoh5flSnl 2q/EVO7K1/gwGs4IoAKncS/Ew4TJ97zn9JejhaC7jU7gemo7sMdI0UcXEHzS7VteKmx1/NHSGrl tJ8EhqY82ZOhSgpjhxj+c9KPeTC1DfGM6db7X0NTnAhL0/m3+IfriO3cV8QUnhXZChKvF+k4Q+v wx+h09uF4SmMWdeG7+TULEz66tyaHj+XQ22lLSDkh6bW+bcd5c60gxbJmRTHskkJQ4S5FTe9gr7 g3DKuN3w7wTjCclazIXzN3JNhp516w/ps6lCmeAiCmPx4NwFkMvWAuahr8m5N2YHMD0b8MyrfP9 j+C1SAHAopEd76vq9FgTE9NW8Xe0R7nq7xHrr/LsrUwl3GtF5MdSUA5zQbVhPuECPYLAQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [secdir] secdir last call review of draft-ietf-mpls-sfc-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 10:52:07 -0000 Hi Russ, Thanks for reviewing. A few responses ... > Summary: > > This document defines defines a methods to achieve Service Function = Chaining (SFC)=20 > using Network Service Header (NSH) in Multiprotocol Label Switching = (MPLS) networks. No, it absolutely does not. To quote from the Abstract... This document describes how Service Function Chaining can be achieved in an MPLS network by means of a logical representation of the NSH in an MPLS label stack. The point of this document is exactly that it does not use the NSH. = Instead it encodes the fields of the NSH in MPLS headers. This is = crucially important because if one wanted to use the NSH in an MPLS = network one would apply RFC 8300 and draft-ietf-mpls-sfc-encapsulation. > Issues: > > First, the document and in particular the Security Considerations = section points to published RFCs > for discussions of the security properties. In particular, RFC7665 and = RFC8300 are referenced=20 > however each of these documents left some significant security = descriptions & definitions to be > addressed by implementation documents such as this one. Additionally, = the SECDIR reviews of > the IDs prior to publication of these RFCs point out several security = related issues that, as far as > I could tell, were primarily addressed by saying that future = implementation specifications will > address them. Since this ID is such an implementation specification, = referring to the earlier RFCs > for the security properties results in essentially no security = properties provided in either the=20 > earlier RFCs or this implementation document - security properties = need to be identified avoided > via circular references. I think you have a good point here that, although the aspects of = security related to SFC are inherited from whatever documents the SFC WG = produces (complete with whatever flaws exist in that set of documents = that need to be patched by that WG), *this* document needs to talk about = the security of the mechanisms that it defines. That means some discussion of the security of the MPLS forwarding plane = (with references) and some discussion about what would happen if someone = was able to tamper with a packet (noting that if someone can = successfully tamper with an MPLS packet in flight then they can do a lot = of other bad things as well). > Next, the Security Considerations section identifies that the certain = elements of the design must > be a =E2=80=98trusted resource=E2=80=99 and that some functions must = also be trusted. The term =E2=80=9Ctrusted=E2=80=9D in=20 > relationship to computing and software has a wide range of different = meanings (as shown by > many years of research in the CS field). In the context of this = document, my guess is that it > means that some unidentified (but not defined) entity believes = (=E2=80=9Ctrusts=E2=80=9D) that the software > will do the =E2=80=9Cright thing=E2=80=9D - to me (from a security = perspective) it also means trusting that the > software will not do the wrong thing. All of this is very abstract = (both the Security=20 > Considerations text & this critique) which in my view is why the = 'trust' section is very > inadequate for an implementation document. If there is an IETF security definition of "trust" that we could look = at, that would help. "Do the right thing" is probably not quite what we mean.=20 I think we mean "Not act maliciously so as to wilfully break the network = or send traffic to/via the wrong places." But this is all a little like how we "trust" a router.=20 A malign router could drop or redirect packets contrary to the routing = information it has received. We typically test for that in the lab, and = maybe watch for it in the field, but other procedures (such as checking = software images) are generally out of scope for protocol documents. > Additionally, the last paragraph of the Security Considerations = section asserts: > > Thus the security vulnerabilities are addressed (or should be > addressed) in all the underlying technologies used by this design, > which itself does not introduce any new security vulnerabilities. > > As far as I could see, the assertion is not supported anywhere in the = document > itself or other referenced documents, i.e., what vulnerabilities = should the=20 > implementation be concerned with (e.g. passive monitoring, active = attacks > on metadata, etc??) that result from this implementation. Since the=20 > document does not provide a clear identification of it's security = requirement, > any security services it does (or might) provide nor require from = underlying > technologies, the assertion should be clarified, supported by = additional=20 > information or removed from the section. I *do* understand where you are coming from on this, but I'm not sure = where we go with it. Let's consider for a moment the case of email being carried over an MPLS = network. There is a security vulnerability that passive monitoring of = MPLS packets would allow inspection of the contents of the email. There = are a number of ways to protect against this including encryption at the = application layer (i.e. of the email) and encryption at the transport = layer, and encryption at the IP layer. There is also the possibility to = encrypt the underlying transport (such as MACsec).=20 Now, you are asking about whether this document should discuss the = security of any metadata carried in the MPLS encoding of an SFC system = (I realise this is just one example of the concerns you are raising). = And I would say that it should not. It should observe that metadata is = an SFC concept (SFC is the application using MPLS) and encryption of = that data is a function of the "SFC layer". So maybe a bolder statement could be added to the document... "The MPLS forwarding plane does not include any security mechanisms. = That means that procedures described in this document rely on three = basic principles: - The MPLS network is often considered to be a closed network such that = insertion, Modification, or inspection of packets by an outside party is not = possible. - The underlying transport mechanisms (such as Ethernet) between = adjacent MPLS Nodes may offer security mechanisms that can be used to defend = packets "on the Wire" - The SFC-capable devices participating in the network are responsible = for verifying And protecting packets and their contents. Deployments of any SFC system will need to consider these issues, = especially the last point. It is expected that a deployment of the = techniques defined in this document would benefit from the more general = security mechanisms defined for SFC." Thanks, Adrian From nobody Thu Jan 31 05:15:19 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC57128CB7 for ; Thu, 31 Jan 2019 05:15:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <154894051824.9974.6644534925524661077.idtracker@ietfa.amsl.com> Date: Thu, 31 Jan 2019 05:15:18 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 13:15:18 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-02-07 Reviewer LC end Draft Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Kyle Rose R2018-08-29 draft-ietf-lisp-rfc6830bis-26 Takeshi Takahashi R2018-08-31 draft-ietf-lisp-rfc6833bis-23 Last calls: Reviewer LC end Draft Leif Johansson 2018-12-24 draft-ietf-6lo-nfc-12 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2019-01-31 draft-ietf-ccamp-rsvp-te-bandwidth-availability-13 Magnus Nystrom 2019-02-04 draft-ietf-jmap-mail-14 Hilarie Orman 2019-02-01 draft-ietf-rtcweb-fec-08 Radia Perlman 2019-02-01 draft-ietf-payload-flexible-fec-scheme-16 Derrell Piper 2019-02-27 draft-hollenbeck-vcarddav-icann-rdap-extensions-00 Tim Polk 2019-02-13 draft-ietf-sipcore-reason-q850-loc-05 Vincent Roca 2019-02-13 draft-ietf-perc-private-media-framework-08 Kyle Rose 2019-02-12 draft-ietf-tsvwg-le-phb-08 Joseph Salowey 2019-02-11 draft-ietf-rmcat-eval-test-08 Stefan Santesson 2019-02-11 draft-ietf-extra-imap-fetch-preview-01 Stefan Santesson R2018-11-20 draft-wilde-service-link-rel-10 Yaron Sheffer 2019-02-08 draft-ietf-uta-smtp-require-tls-07 Rifaat Shekh-Yusef 2019-02-08 draft-ietf-pim-igmp-mld-yang-10 Valery Smyslov None draft-ietf-cellar-ebml-09 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-09 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Next in the reviewer rotation: Robert Sparks Takeshi Takahashi Tina Tsou Sean Turner Carl Wallace David Waltermire Samuel Weiler Brian Weis Klaas Wierenga Christopher Wood From nobody Thu Jan 31 23:43:03 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6270131106; Thu, 31 Jan 2019 23:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_XSOoxhR_X4; Thu, 31 Jan 2019 23:42:54 -0800 (PST) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.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 3EE2612875B; Thu, 31 Jan 2019 23:42:54 -0800 (PST) Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1gpTTQ-0006U7-Cm; Fri, 01 Feb 2019 00:42:52 -0700 Received: from [72.250.219.84] (helo=rumpleteazer.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1gpTTP-0006CW-NE; Fri, 01 Feb 2019 00:42:52 -0700 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x117gdIx030847; Fri, 1 Feb 2019 00:42:39 -0700 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id x117gdGm030846; Fri, 1 Feb 2019 00:42:39 -0700 Date: Fri, 1 Feb 2019 00:42:39 -0700 Message-Id: <201902010742.x117gdGm030846@rumpleteazer.rhmr.com> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-rtcweb-fec.all@tools.ietf.org X-XM-SPF: eid=1gpTTP-0006CW-NE; ; ; mid=<201902010742.x117gdGm030846@rumpleteazer.rhmr.com>; ; ; hst=in02.mta.xmission.com; ; ; ip=72.250.219.84; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX1+3xh4LPwWxBL4RJts0k7kv X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *********;iesg@ietf.org, secdir@ietf.org, draft-ietf-rtcweb-fec.all@tools.ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 378 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.3 (0.9%), b_tie_ro: 2.2 (0.6%), parse: 0.64 (0.2%), extract_message_metadata: 3.0 (0.8%), get_uri_detail_list: 0.89 (0.2%), tests_pri_-1000: 2.6 (0.7%), tests_pri_-950: 1.25 (0.3%), tests_pri_-900: 1.05 (0.3%), tests_pri_-90: 17 (4.5%), check_bayes: 15 (4.0%), b_tokenize: 4.4 (1.2%), b_tok_get_all: 5.0 (1.3%), b_comp_prob: 1.83 (0.5%), b_tok_touch_all: 2.4 (0.6%), b_finish: 0.54 (0.1%), tests_pri_0: 341 (90.0%), check_dkim_signature: 0.46 (0.1%), check_dkim_adsp: 52 (13.7%), poll_dns_idle: 46 (12.2%), tests_pri_10: 2.1 (0.6%), tests_pri_500: 4.9 (1.3%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Archived-At: Subject: [secdir] Security review of draft-ietf-perc-srtp-ekt-diet-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 07:42:56 -0000 Security Review of WebRTC Forward Error Correction Requirements draft-ietf-rtcweb-fec-08 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document describes the appropriate uses of FEC for web content when using WebRTC. It also describes how to indicate that FEC is being used. The Security Considerations mention the possibility of additional network congestion when using FEC. Although this can be a problem, I do not think it is a security issue, thus it does not belong in this section. There is a security-related issue wrt to FEC and encryption. If the error model is that message blocks may be lost but not altered in transit, then FEC with encryption is fine. But if FEC is added for the purpose of correcting corrupted bits in a message block, then it is important that FEC is done after encryption. The draft seems to ignore the issue, and it also seems to recommend a processing scheme that would result in encryption of the FEC data. If there is a body of practice for other IETF FEC protocols that explains these issues, an explicit reference to it in the Security Considerations would be very helpful. Hilarie