From nobody Wed Apr 1 05:29:36 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8761A8A23 for ; Wed, 1 Apr 2015 05:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5ZFL-9Iv5W8 for ; Wed, 1 Apr 2015 05:29:32 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42BDC1A8AB2 for ; Wed, 1 Apr 2015 05:29:32 -0700 (PDT) Received: by qcbii10 with SMTP id ii10so16291332qcb.2 for ; Wed, 01 Apr 2015 05:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=iWLcEORnTgNzhhM+wIqPy+syI9smdhMl5WdGufEb/7M=; b=mhzLR4eMFiak3KyQVndy+9IbW6QRqphzxZp5F0rj/hHGhGgimCNGwm7gULqgnOCr1s svuhT6pQVrZ8xlHHB+Pxl/N6D0V1johm9Lajk1jOEGgWGDWF7GubEL5ziSgbIVBX66O0 3YjlgJ38fP82vmFPXSf/SEh1XJMztXQNPIfQun3kSXvWGmv2A/ssPtaFE6voY1Fs8FVb CgP+GOUDO0o2eRsAmTt+DyO8wfu2unqqe2ZuUTZW7+/Qkxgu0jcO2sBS2SN3OIi/qf3n 8j1SGNeWNpWHoyXdnOUluUm9du8UlCO3daZPADdo7FDAEyjIyDkfZangqYh3QsYNRvpF ggbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=iWLcEORnTgNzhhM+wIqPy+syI9smdhMl5WdGufEb/7M=; b=GP/s7obobDwpgqdO+q8N5lZCirFLSqNZkzfxJENEPsKA/JUtWEov+F6nFu7SZPCBsK zVXteMGYovxP9MU9V/YpUqbyJH7mlveDklQmOBLY0/JFn0kyNTYktAQzymLX8kLHtxIy YfolqfplcR/JDyneU9EuLm+xacd/ogymrgePKfZa3xzIQa3Npvh6dvb37IlDvVQY8sKw sG1izjQdy0ES3mCKlzSQHAu8lEa3AVPw1kknj+Pb6seBUAKE99+hYB6sxRIj5BRakH4f xLgdafXaSXRmosKAsu4Wcd9Qe2YlpF5gXdfb4hi8t7evHZHMX0hcldNIA3WzPvjwOCLw 0PdQ== X-Gm-Message-State: ALoCoQnrIOR/aLdYm4Fx8xkbnE5Yr1SbjW0fC5YixMMNqnkcbBYu1cnAgj1e+pL3kNsgwA9x4EF/ MIME-Version: 1.0 X-Received: by 10.55.49.138 with SMTP id x132mr47416846qkx.19.1427891371455; Wed, 01 Apr 2015 05:29:31 -0700 (PDT) Received: by 10.229.178.135 with HTTP; Wed, 1 Apr 2015 05:29:31 -0700 (PDT) Date: Wed, 1 Apr 2015 13:29:31 +0100 Message-ID: From: Ben Laurie To: "secdir@ietf.org" , The IESG , draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] Security review of draft-ietf-oauth-dyn-reg-management-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 12:29:34 -0000 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. Summary: ready with issues. Nit: the Security Consideration section contains normative requirements. I don't know if this is strictly wrong, but it is unusual. The style I am used to has the normative requirements in the main body of the I-D, with Security Considerations confining itself to explaining what is going on security-wise. Issue: "Note that the authorization server decides the frequency of the credential rotation and not the client. Methods by which the client can request credential rotation are outside the scope of this document." Clients are presumably as likely as servers to cause credential compromise, hence a mechanism by which a client can request a new credential seems wise. Of course, this could be used by an attacker to lock a client out, so more thought required. Issue: size limits. There don't appear to be any limits (minimum server must accept, max client must send) for client data. Not necessarily a security issue, but seems likely to cause interop problems. Issue: "Configuration Endpoint" (not a security issue) It looks like the definition of this is deferred to draft-ietf-oauth-dyn-reg, but I couldn't find it there either. Issue: "The server MUST support TLS 1.2" - it seems unwise to mandate a particular version of TLS - work on TLS 1.3 is already under way, and TLS 1.2 is not (it seems) that far off deprecation! Issue: " Since the client configuration endpoint is an OAuth 2.0 protected resource, it SHOULD have some rate limiting on failures to prevent the registration access token from being disclosed though repeated access attempts." I am not sure what this is getting at. Limits on key re-use? Some kind of BEAST defence? Something else? Without some quantification of the threat, it seems hard to act on this requirement. From nobody Wed Apr 1 06:29:08 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6591A910E; Wed, 1 Apr 2015 06:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10gAYeloCF2q; Wed, 1 Apr 2015 06:29:03 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E43C1A8ADB; Wed, 1 Apr 2015 06:28:55 -0700 (PDT) Received: by obvd1 with SMTP id d1so79214419obv.0; Wed, 01 Apr 2015 06:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=9ATDWIS43z5RFWiJLu0p8dINyZfe6jRe4gvr6zzJCWo=; b=UyvpfAw5L8ms2dWbh85gnlVUCptWKSsu6pB1uyj6Sj1wiQUjKWT/lqEQ37Exk2o1uk uI2wEaBFv8k7EggfjROgXg+sp3m99uoww/3fCKBFUUQ76PyyjT+hLewU0JODsWKxhfuu +j/1GAAP5s65vCMb0bth1zarIYc5W6TiFoLmpeEYiTpc3+ItUgGQRXAegYbieT+kRscy SBfMzOX+OxcV1qw/spIClSPNglg8EvQ27TbA8XbZ0fEFf49ppkhJ5bHqMr0tni1fgLe2 ofAczLwgK4fCBBQL8a6r6PZOYMZGoHAiTeGQxVc6/2WIMuDuC0lExdUeS3qo7GFmWx2N O2HQ== X-Received: by 10.60.45.244 with SMTP id q20mr17611959oem.1.1427894926865; Wed, 01 Apr 2015 06:28:46 -0700 (PDT) Received: from ?IPv6:2602:306:3406:4f00:2d74:e5c1:6b77:ba0e? ([2602:306:3406:4f00:2d74:e5c1:6b77:ba0e]) by mx.google.com with ESMTPSA id x8sm1722414oey.12.2015.04.01.06.28.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Apr 2015 06:28:45 -0700 (PDT) From: "Adam W. Montville" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <718D753F-E377-4197-9F01-C34C12EC5CA0@gmail.com> Date: Wed, 1 Apr 2015 08:28:43 -0500 To: The IESG , secdir@ietf.org, draft-ietf-isis-extended-sequence-no-tlv.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [secdir] Security review of draft-ietf-isis-extended-sequence-no-tlv-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 13:29:05 -0000 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. This draft is ready with issues. There are two circumstances within IS-IS that are subject to replay = attacks. One can happen when adjacencies are brought up and an IS sends = an IIH (hello). The other circumstance pertains to replaying CSNP, = which may cause replay of PSNP and thus cause LSP flooding. =20 This draft proposes a sequence to mitigate replay attacks in both = circumstances. The structure of the sequence is defined as a new TLV = called "ESN TLV". It constists of the three fields, Type, Length, and = Value, where Value is to be interpreted as two separate fields. These = two fields are known as Extended Session Sequence Number (ESSN; a 64-bit = value, which is non-zero and unsigned), and Packet Sequence Number (PSN; = a 32-bit value). A given ESN is associated with a particular Protocol = Data Unit (PDU). A PDU, therefore, "has" an ESSN, which is associated = with a monotonically increasing PSN. If the PSN wraps or if the device = needs to be restarted, then the next ESSN must be larger than the = previous ESSN. This is where I see a potential issue, but maybe I'm missing a limit of = practicality. What happens when the ESSN is at 2^64-1 and needs to = increment? Granted that's a large number, so it might be the case that = under no practical circumstance would the ESSN ever become that large; = but, if that's the case, then it might be best to state so in the draft. In the Appendix, the draft also goes into how timestamps may be = leveraged (which are potentially more effective at mitigating replay = attacks than are sequences), but does not clearly indicate how neighbors = would negotiate the use of timestamps or how exactly the timestamps = would be used or which format then must be used (a suggestion to look at = RFC5905 is made). =20 There may be valid operational reasons to favor a sequence over = timestamps for replay mitigation, but such considerations appear absent = in this draft. Is there a reason timestamps are being avoided as the = replay mitigation solution? Nits: There was at least one area of the text that could probably be clarified = for the sake of non-security-familiar folks. The paragraph in section = 2.1 could be changed as follows, to make clear that the authenticated = case of IIH is where mitigation can be made. OLD At the time of adjacency bring up an IS sends IIH packet with empty = neighbor list (TLV 6) and with or without the authentication information = as per provisioned authentication mechanism. If this packet is replayed = later on the broadcast network all ISes in the broadcast network can = bounce the adjacency to create a huge churn in the network. NEW When an adjacency is brought up an IS sends an IIH packet with an empty = neighbor list (TLV 6), which can be sent with or without authentication = information. Packets can be replayed later on the broadcast network = which may cause all ISes to bounce the adjacency, thus churning the = network. Note that mitigating replay is only possible when = authentication information is present. In general, I recommend reviewing the draft for clarity. Kind regards, Adam= From nobody Wed Apr 1 07:26:48 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB111AC3CD; Wed, 1 Apr 2015 07:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzfouW69qHsj; Wed, 1 Apr 2015 07:26:41 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C041AC3D4; Wed, 1 Apr 2015 07:26:32 -0700 (PDT) Received: from [192.168.131.146] ([80.92.114.249]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MRoyH-1Z1txr1zlR-00SwFR; Wed, 01 Apr 2015 16:26:18 +0200 Message-ID: <551C0005.2000309@gmx.net> Date: Wed, 01 Apr 2015 16:26:13 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ben Laurie , "secdir@ietf.org" , The IESG , draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org References: In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rCBg1fUnkvfi2P446NeSGWEmr8ctBoutR" X-Provags-ID: V03:K0:YnlNJqNMmpBRCCgL6WPvF3ZuDLL+hDrgrLGHOHGGU+9IQskkbDU 6cBhY3iaHG1ctUlcGMPLI4iwWOb4BhuxN5CH/hgg1PiyT+d/W79xOpfnT8cx+4z4G5HYLn2 IIkdUcR3H91ivNCFYL0F/55N2897moOeMxz18ITTOW7WSsRThxfO0bQvzLWT3T9ZDex/e7P LeWASNEEHQbHTFhCk++Rg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [secdir] MTI ... Re: Security review of draft-ietf-oauth-dyn-reg-management-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 14:26:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rCBg1fUnkvfi2P446NeSGWEmr8ctBoutR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ben, I would like to respond to this issue: On 04/01/2015 02:29 PM, Ben Laurie wrote: > Issue: "The server MUST support TLS 1.2" - it seems unwise to mandate > a particular version of TLS - work on TLS 1.3 is already under way, > and TLS 1.2 is not (it seems) that far off deprecation! We had a lengthy debate in OAuth around the issue of mandatory-to-implement security functionality. Earlier we just pointed to the use of TLS but then the question arises what version of TLS and what ciphersuites to use. Then, we came up with this text for all of our documents but it creates the problem you outlined. In essence, all our documents will point to an old TLS version in approx. 1 year from now when TLS 1.3 is finalized. I believe this is a broader issue that needs to be solved in the security area and not just with OAuth, namely should specifications contain MTI security functionality when we know already at the time of writing that they will be outdated within a reasonable amount of time? In some sense, I see a bit of overlap with the crypto agility debate and the attempt to reduce the overhead for standardization in introducing new cryptographic algorithms. I personally would like to replace these types of recommendations with references to a page on the IETF website that talks about the most recent TLS & ciphersuite recommendations. I am aware that this might create problems with claiming interoperability with a specific RFC... Help appreciated. Ciao Hannes --rCBg1fUnkvfi2P446NeSGWEmr8ctBoutR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVHAAFAAoJEGhJURNOOiAt+DEH+QGEx/qTWvOoDxgJieRbYxiH 3NCmh20pt1s5oRVB00tiJqjZ1f4L36fx2BrWTzte3k/YcSLtYynaeHOJzZi9M572 OX8oULJpQalP3Xyrs6QKxnqKexr473gH9/wrQWTLH80pw7uiWPNNl63r2BNo2tGU ghifSyXYTshKC2tCAeaEMA/hEwTGYqmeFs1bi0WpUS64k5xIhkAxjr3qeUFnnQsU 6oGk8ogfFh+YQmHoINOW93qBidWGmTOjEg/HrnmmK+pn2BUIaSTnFHnguaL9fAr2 m9vD9p6Tb+iRjz1eehNJQQeibdWAkh0ybWb+MYSWGohXW0Fm5/cPZcMvIb1RII0= =nkYl -----END PGP SIGNATURE----- --rCBg1fUnkvfi2P446NeSGWEmr8ctBoutR-- From nobody Wed Apr 1 09:04:45 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52AAC1A9151; Wed, 1 Apr 2015 07:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_CmUvgEgeqe; Wed, 1 Apr 2015 07:20:04 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D1581A916D; Wed, 1 Apr 2015 07:19:59 -0700 (PDT) Received: by obvd1 with SMTP id d1so81675730obv.0; Wed, 01 Apr 2015 07:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0dg89tURZ4MZ4d7ax4Ml5dlJQ7SWYTfp78W0TWhbEFk=; b=jmY5C4pVtdNVrwKzu5gwTbp0Yg5Z/xauwFXkQPlD7LzM6ooq399FbT+D0QnZrx8I0m ZefwSGIDeJDpZtoWgTEeZYtY9d5X62cLpuqqAVbJXPNrENnWlBipu124m9x9Vd+H9+Y7 CtPlgcW7THfSgPlNkvO8p2FUuoQX1kn1g3cWS/hPomOuU+GMpta6miiuE/QlL3ZeuVZB R1g7K4NxgM0s6Qq5gln8qbin66ZR8+NhsgrVjop33xZNqRkalNzKU5vM79i5HaH7xwgX gM3hhkQTiomrtXRj3yhEFybs5Bot7K/KAzxCO1871+O+etWnd1yWkMr5JJ78Ut2LrWPF pvuA== X-Received: by 10.183.24.168 with SMTP id ij8mr41188113obd.15.1427897984976; Wed, 01 Apr 2015 07:19:44 -0700 (PDT) Received: from [198.18.97.107] ([12.190.128.2]) by mx.google.com with ESMTPSA id u9sm1856079obx.13.2015.04.01.07.19.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Apr 2015 07:19:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Jounikor X-Mailer: iPhone Mail (12D508) In-Reply-To: <779642F1-4094-4524-A6B8-EE4E40B1CF8A@cisco.com> Date: Wed, 1 Apr 2015 08:19:43 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <780CC07C-5873-47FC-8002-5C8B3BE13F7C@gmail.com> References: <779642F1-4094-4524-A6B8-EE4E40B1CF8A@cisco.com> To: "Brian Weis (bew)" Archived-At: X-Mailman-Approved-At: Wed, 01 Apr 2015 09:04:44 -0700 Cc: The IESG , "draft-ietf-radext-dynamic-discovery.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-radext-dynamic-discovery-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 14:20:06 -0000 Thanks Brian! - jouni Sent from a smart phone.. Mind the typos.. > Brian Weis (bew) kirjoitti 31.3.2015 kello 22.54: >=20 > I have reviewed this document as part of the security directorate's ongoin= g 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.= =20 >=20 > Previously I reviewed draft-ietf-radext-dynamic-discovery-12, and while I d= idn=E2=80=99t have any particular issues with it there were some questions a= nd suggestions for clarifying trust model. The current draft added some real= ly valuable text and figures. I believe it is ready to be published. >=20 > Brian >=20 >=20 From nobody Wed Apr 1 09:12:00 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B391ACF5D; Wed, 1 Apr 2015 09:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy242ZXcyfdh; Wed, 1 Apr 2015 09:11:52 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCF141ACF18; Wed, 1 Apr 2015 09:11:50 -0700 (PDT) X-AuditID: 1209190d-f79676d000000da0-78-551c18c542d6 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 22.6C.03488.5C81C155; Wed, 1 Apr 2015 12:11:49 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t31GBmeN017218; Wed, 1 Apr 2015 12:11:48 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t31GBjUl002880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Apr 2015 12:11:46 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t31GBiqR029563; Wed, 1 Apr 2015 12:11:44 -0400 (EDT) Date: Wed, 1 Apr 2015 12:11:44 -0400 (EDT) From: Benjamin Kaduk To: Hannes Tschofenig In-Reply-To: <551C0005.2000309@gmx.net> Message-ID: References: <551C0005.2000309@gmx.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixCmqrXtUQibUYMF0FYsNn6+xWZzr62K2 WLrzHqvFjD8TmS0+LHzI4sDqsXjTfjaPBZtKPZYs+cnk8eXyZ7YAligum5TUnMyy1CJ9uwSu jIZjR5kK9jBXTN52jbmB8QFTFyMnh4SAicSes99YIWwxiQv31rN1MXJxCAksZpKYM2seK4Sz gVHi4fs5LCBVQgIHmSTWrDCDsOsljj4/BdTBwcEioCXxtMsOJMwmoCIx881GNhBbRMBQ4vrM 6WBzmAVWMkr8frCOESQhLBAr0f5gC9hMTgF1ic/zJ4BdxCvgKLF+fT8zxPxsiV3v94LFRQV0 JFbvn8ICUSMocXLmEzCbGWjv8unbWCYwCs5CkpqFJLWAkWkVo2xKbpVubmJmTnFqsm5xcmJe XmqRrpFebmaJXmpK6SZGcGBL8u5gfHdQ6RCjAAejEg9vQ5R0qBBrYllxZe4hRkkOJiVRXg1R mVAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrySIkA53pTEyqrUonyYlDQHi5I476YffCFCAumJ JanZqakFqUUwWRkODiUJ3qfiQI2CRanpqRVpmTklCGkmDk6Q4TxAwxkkQIYXFyTmFmemQ+RP Mepy3JnyfxGTEEtefl6qlDjvNZBBAiBFGaV5cHNgCekVozjQW8K8x0CqeIDJDG7SK6AlTEBL HOZJgywpSURISTUwSvgE/t+0nPdinlr3XSnlNdWCk58nuUZNimW/4Bz6/265Qs/Jtg8tied1 bf/Fr9357frMv+2MOqu418x4Ob1vve+fMqPYYu4zsgLdVhZZdU08T+aJ6NlndxVoTDv3wLz9 amSrbpbi0UcNppNu6gYdf3O6ST588v/v+r+3CnyefGJ/60mJrKV6SizFGYmGWsxFxYkAhWXv yyMDAAA= Archived-At: Cc: draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] MTI ... Re: Security review of draft-ietf-oauth-dyn-reg-management-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 16:11:55 -0000 On Wed, 1 Apr 2015, Hannes Tschofenig wrote: > I personally would like to replace these types of recommendations with > references to a page on the IETF website that talks about the most > recent TLS & ciphersuite recommendations. I am aware that this might > create problems with claiming interoperability with a specific RFC... Why not a BCP document for TLS usage? It seems to be a charter item for the uta WG already... -Ben From nobody Wed Apr 1 09:14:47 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A9B1A92DC; Wed, 1 Apr 2015 09:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3r3cYMSujFDT; Wed, 1 Apr 2015 09:14:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48871A88C5; Wed, 1 Apr 2015 09:14:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8AC98BEE8; Wed, 1 Apr 2015 17:14:40 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm8Vu3Rs0SkR; Wed, 1 Apr 2015 17:14:40 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5BFAABE79; Wed, 1 Apr 2015 17:14:40 +0100 (IST) Message-ID: <551C1970.4050600@cs.tcd.ie> Date: Wed, 01 Apr 2015 17:14:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Benjamin Kaduk , Hannes Tschofenig References: <551C0005.2000309@gmx.net> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] MTI ... Re: Security review of draft-ietf-oauth-dyn-reg-management-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 16:14:43 -0000 On 01/04/15 17:11, Benjamin Kaduk wrote: > On Wed, 1 Apr 2015, Hannes Tschofenig wrote: > >> I personally would like to replace these types of recommendations with >> references to a page on the IETF website that talks about the most >> recent TLS & ciphersuite recommendations. I am aware that this might >> create problems with claiming interoperability with a specific RFC... > > Why not a BCP document for TLS usage? It seems to be a charter item for > the uta WG already... Well, initially OAuth wanted some specifics that matched the deployments then seen, but yeah, I think the world may have moved on sufficiently that a simple reference to the UTA BCP (which is in the RFC editor queue) [1] might be fine. I'd say it's defo worth asking the wg if they'd have a problem with that now. S. [1] https://www.rfc-editor.org/queue2.html#draft-ietf-uta-tls-bcp > > -Ben > From nobody Wed Apr 1 10:06:07 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CAB1A0039; Wed, 1 Apr 2015 10:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mR3S5UbFOto7; Wed, 1 Apr 2015 10:06:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0871F1A002D; Wed, 1 Apr 2015 10:06:01 -0700 (PDT) Received: from [192.168.131.146] ([80.92.114.249]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MaIPo-1YspbI0xgm-00JuPa; Wed, 01 Apr 2015 19:05:48 +0200 Message-ID: <551C2568.3050301@gmx.net> Date: Wed, 01 Apr 2015 19:05:44 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Stephen Farrell , Benjamin Kaduk References: <551C0005.2000309@gmx.net> <551C1970.4050600@cs.tcd.ie> In-Reply-To: <551C1970.4050600@cs.tcd.ie> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cI4XwhMkwI0pVdHhoCu0IwEIONfxV7jOG" X-Provags-ID: V03:K0:2vMA18tEbpNlabWWXxhmSdlH7AdNJW+1vz5kn0zXkAnFgTT0nyj gwztADCqazs7dljNCatrqO/uYoujPIKW9JSB/7FwiGUCEB7Zd8XdlkceSVlIwVJUH3dVFN3 fa2xYqL+GCRUqELsfazdOJ8q94L3ufFMyITek4nRpcgqvCktmx0oF05mdwBQjdrHDXs0jgS 3VfMUDFie8Mkavvjpyirw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] MTI ... Re: Security review of draft-ietf-oauth-dyn-reg-management-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 17:06:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cI4XwhMkwI0pVdHhoCu0IwEIONfxV7jOG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ben, Stephen, I believe that this would be a good idea although it does not really solve the underlying problem. Why? If we put a reference to the UTA BCP in there then we end up in the need to update our documents in the not too distance future to point to a new UTA BCP that talks about TLS 1.3. Ciao Hannes On 04/01/2015 06:14 PM, Stephen Farrell wrote: >=20 >=20 > On 01/04/15 17:11, Benjamin Kaduk wrote: >> On Wed, 1 Apr 2015, Hannes Tschofenig wrote: >> >>> I personally would like to replace these types of recommendations wit= h >>> references to a page on the IETF website that talks about the most >>> recent TLS & ciphersuite recommendations. I am aware that this might >>> create problems with claiming interoperability with a specific RFC...= >> >> Why not a BCP document for TLS usage? It seems to be a charter item f= or >> the uta WG already... >=20 > Well, initially OAuth wanted some specifics that matched the > deployments then seen, but yeah, I think the world may have > moved on sufficiently that a simple reference to the UTA BCP > (which is in the RFC editor queue) [1] might be fine. I'd > say it's defo worth asking the wg if they'd have a problem > with that now. >=20 > S. >=20 > [1] https://www.rfc-editor.org/queue2.html#draft-ietf-uta-tls-bcp >=20 >=20 >> >> -Ben >> --cI4XwhMkwI0pVdHhoCu0IwEIONfxV7jOG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVHCVoAAoJEGhJURNOOiAtVPYH/0vDm02nHSfqBB1qfWaOp6QN GixjIkjBv/s0yQP9F9//s+/iKDdSR2H5Avg9T+jHSdzanDqaVQ4qkCnImn8HssL0 E1GUDfnLYxKaU0gbbHiZj4xsQJrpGkXU4IdauqSngMoTfG4RSxd1e1LW5mBZPg5d 2IX14+tvOyxBsDdX8F6x+9R4CqnZnme3G6LIJqs5G0xLF9EIbXY/awqluIEarbMb yCpRxRCXvvhkTozOAILNA5SPPuOwplfy95zWn7L9ayD7GmGqZ2SipZjpM8j2W7/u WwqOJXq9aNuhUbG4Woc5KKXzOiD7w4JffWG0t3/tSJ9mQTPX2nrizPgwaOCZQI4= =upVj -----END PGP SIGNATURE----- --cI4XwhMkwI0pVdHhoCu0IwEIONfxV7jOG-- From nobody Wed Apr 1 10:15:03 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9AB1A0056; Wed, 1 Apr 2015 10:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oTv1Y2FRINf; Wed, 1 Apr 2015 10:15:00 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E281A0055; Wed, 1 Apr 2015 10:15:00 -0700 (PDT) Received: by pddn5 with SMTP id n5so61138610pdd.2; Wed, 01 Apr 2015 10:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=vzBps80pwypn9vfYBMFed/6bWXTRGC/sdPp2MRF2SM4=; b=JFFLPKLWqLF1rP48gA+BH2rMbSH2xQqUCyMhf99bTz2ufoEYnm8QdL+bQPleA15GsN U6RfxHKIBa5+KMIV4DjMH6HbT5kMReGP7rCjP5iPtFQKmSITjP3YAZsIr414eByvaQhe D9b5hXN8qDMblNs3hhU2E7yOZylF+bIi7EWVbsTMx2tVCCUjkMVv+1XcGJBT7CGryocs bXsiycfbn4vCvBDpXrWwJPgm3dPEvWYpz0zwGsiFLs0UPwwWfdp5J1emvXNLHyx3JFVR /cPX0HH3igTkP9uw0VzEqsNEn+yr8zsgrPmO6wi2DJpmXNKgr1sQU0ob28a9Y+7PVq1d Bi8A== X-Received: by 10.68.78.65 with SMTP id z1mr79796720pbw.112.1427908499705; Wed, 01 Apr 2015 10:14:59 -0700 (PDT) Received: from [192.168.1.76] (172-3-137-150.lightspeed.sntcca.sbcglobal.net. [172.3.137.150]) by mx.google.com with ESMTPSA id je11sm2669502pbd.65.2015.04.01.10.14.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2015 10:14:59 -0700 (PDT) Message-ID: <551C2791.7090206@gmail.com> Date: Wed, 01 Apr 2015 10:14:57 -0700 From: Chris Lonvick User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org Content-Type: multipart/alternative; boundary="------------040602060508070505010801" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-appsawg-multipart-form-data-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 17:15:02 -0000 This is a multi-part message in MIME format. --------------040602060508070505010801 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. I only got a chance to skim through the document but the Security Considerations section looks to be consistent with RFC 2388, which it intends to replace. I would suggest placing the last paragraph of the Security Considerations section at the top of the section. That paragraph seems to be the most comprehensive in these considerations, and the other paragraphs seem to augment and give specific details. It just seems to me that it would provide a better flow to reading that section. Also, I'm just not sure that I'm following the second paragraph of Appendix B: More problematic is the ambiguity introduced because implementations did not follow [RFC2388 ] because it used "may" instead of "MUST" when specifying encoding of field names, and for other unknown reasons, so now, parsers need to be more complex for fuzzy matching against the possible outputs of various encoding methods. Please correct me if I'm off base here, but it sounds like the ambiguity set in because implementations WERE following RFC 2388 by making choices on their own (due to the "may"s) rather than being directed to make uniform choices which would have been mandated if that RFC had used "MUST"s. Finally, I usually advocate giving directions to implementers about what to do if they find implementations using the older, outdated spec. As an example, what should a receiver do if it gets a ContentType that does not have a "boundary" parameter? However, as I'm not really familiar with this technology, and as the document says there are many ways to do all of this, then I'm not sure that could or should be discussed. If it is something that would better define behavior then I would suggest providing some guidance here. Best regards, Chris --------------040602060508070505010801 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.

I only got a chance to skim through the document but the Security 
Considerations section looks to be consistent with RFC 2388, which it 
intends to replace.

I would suggest placing the last paragraph of the Security Considerations
section at the top of the section.  That paragraph seems to be the most
comprehensive in these considerations, and the other paragraphs seem to
augment and give specific details.  It just seems to me that it would
provide a better flow to reading that section.

Also, I'm just not sure that I'm following the second paragraph of
Appendix B:
   More problematic is the ambiguity introduced because implementations
   did not follow [RFC2388] because it used "may" instead of "MUST" when
   specifying encoding of field names, and for other unknown reasons, so
   now, parsers need to be more complex for fuzzy matching against the
   possible outputs of various encoding methods.
Please correct me if I'm off base here, but it sounds like the ambiguity
set in because implementations WERE following RFC 2388 by making
choices on their own (due to the "may"s) rather than being directed to
make uniform choices which would have been mandated if that RFC had used
"MUST"s.

Finally, I usually advocate giving directions to implementers about what
to do if they find implementations using the older, outdated spec.  As
an example, what should a receiver do if it gets a ContentType that does
not have a "boundary" parameter?  However, as I'm not really familiar 
with this technology, and as the document says there are many ways to
do all of this, then I'm not sure that could or should be discussed.  If
it is something that would better define behavior then I would suggest
providing some guidance here.

Best regards,
Chris


  


--------------040602060508070505010801--


From nobody Wed Apr  1 10:18:53 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9194E1A006B; Wed,  1 Apr 2015 10:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ft6s-mVsbji; Wed,  1 Apr 2015 10:18:47 -0700 (PDT)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2341A009C; Wed,  1 Apr 2015 10:18:46 -0700 (PDT)
Received: by lbdc10 with SMTP id c10so41283179lbd.2; Wed, 01 Apr 2015 10:18:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uYpE7IyT13OXdOfwR8T0eOOiwlbu8PN2dwakxvl/wv8=; b=cJ3FWFqiO2cQBA2d0pDQD/2SLtGQSnQL3xOTatfpzb01jl2LhT72WdfPd6Xvivk/hV mQp+/vcFcp5ZWV9wxyMHg094ae8r/WJk9XQ0lwFcY+YpHHk7gbqTYaMjvyGK58j+Mw7Y eJPGsYwMt8gA4egl7SKQDg9LUmF01xUOicMd0uPGIFT053y0iECTLHv4x4spTKu36bT/ J4Lea+3vbZgs5l1D5ONAo8rSt3CA13Li2qo5+6QHGI1LTSNlGktKFppSDZUVjE91j5XC +OziSE8YSKi/G7D6zA5COeFA/s1nH1rei56ZbfJPeWQB3gg8xqZJiVPvsNWlr6kY//MG zVcw==
MIME-Version: 1.0
X-Received: by 10.152.8.69 with SMTP id p5mr32669870laa.113.1427908724930; Wed, 01 Apr 2015 10:18:44 -0700 (PDT)
Received: by 10.112.167.101 with HTTP; Wed, 1 Apr 2015 10:18:44 -0700 (PDT)
In-Reply-To: <551C2568.3050301@gmx.net>
References:  <551C0005.2000309@gmx.net>  <551C1970.4050600@cs.tcd.ie> <551C2568.3050301@gmx.net>
Date: Wed, 1 Apr 2015 13:18:44 -0400
Message-ID: 
From: Kathleen Moriarty 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=001a11c34d3a523eb40512ace8c7
Archived-At: 
Cc: "secdir@ietf.org" , The IESG , draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org
Subject: Re: [secdir] MTI ... Re: Security review of draft-ietf-oauth-dyn-reg-management-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Apr 2015 17:18:48 -0000

--001a11c34d3a523eb40512ace8c7
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 1, 2015 at 1:05 PM, Hannes Tschofenig  wrote:

> Ben, Stephen,
>
> I believe that this would be a good idea although it does not really
> solve the underlying problem. Why? If we put a reference to the UTA BCP
> in there then we end up in the need to update our documents in the not
> too distance future to point to a new UTA BCP that talks about TLS 1.3.
>

I agree with Hannes here.  Having MTI for TLS 1.2 is fine for right now, it
must be supported, but doesn't mean other versions can't be supported once
libraries are available and it makes sense.  We can't hold this up because
TLS 1.3 is coming soon and would prefer that folks know they should be
implementing at least TLS 1.2.  A reference to the TLS BCP with this is
fine as well.  But this is one of the many OAuth drafts and not really the
place to call out specific requirements, like which of the recommended
cipher suites int eh BCP should be implemented for Oauth (I don't think
that has been done as it has for other protocols), but is not the right
place to do too much.

The web page/registry idea is a good one, so we can state current
recommendations.

Thanks,
Kathleen

>
> Ciao
> Hannes
>
>
> On 04/01/2015 06:14 PM, Stephen Farrell wrote:
> >
> >
> > On 01/04/15 17:11, Benjamin Kaduk wrote:
> >> On Wed, 1 Apr 2015, Hannes Tschofenig wrote:
> >>
> >>> I personally would like to replace these types of recommendations with
> >>> references to a page on the IETF website that talks about the most
> >>> recent TLS & ciphersuite recommendations. I am aware that this might
> >>> create problems with claiming interoperability with a specific RFC...
> >>
> >> Why not a BCP document for TLS usage?  It seems to be a charter item for
> >> the uta WG already...
> >
> > Well, initially OAuth wanted some specifics that matched the
> > deployments then seen, but yeah, I think the world may have
> > moved on sufficiently that a simple reference to the UTA BCP
> > (which is in the RFC editor queue) [1] might be fine. I'd
> > say it's defo worth asking the wg if they'd have a problem
> > with that now.
> >
> > S.
> >
> > [1] https://www.rfc-editor.org/queue2.html#draft-ietf-uta-tls-bcp
> >
> >
> >>
> >> -Ben
> >>
>
>


-- 

Best regards,
Kathleen

--001a11c34d3a523eb40512ace8c7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Apr 1, 2015 at 1:05 PM, Hannes Tschofenig <=
;hannes.tsch=
ofenig@gmx.net> wrote:
Ben,=
 Stephen,



I believe that this would be a good idea although it does not really

solve the underlying problem. Why? If we put a reference to the UTA BCP

in there then we end up in the need to update our documents in the not

too distance future to point to a new UTA BCP that talks about TLS 1.3.
=


I agree with Hannes here.=C2=A0 Having MTI=
 for TLS 1.2 is fine for right now, it must be supported, but doesn't m=
ean other versions can't be supported once libraries are available and =
it makes sense.=C2=A0 We can't hold this up because TLS 1.3 is coming s=
oon and would prefer that folks know they should be implementing at least T=
LS 1.2.=C2=A0 A reference to the TLS BCP with this is fine as well.=C2=A0 B=
ut this is one of the many OAuth drafts and not really the place to call ou=
t specific requirements, like which of the recommended cipher suites int eh=
 BCP should be implemented for Oauth (I don't think that has been done =
as it has for other protocols), but is not the right place to do too much.<=
/div>

The web page/registry idea is a good one, so we ca=
n state current recommendations. =C2=A0=C2=A0

Than=
ks,
Kathleen



Ciao

Hannes






On 04/01/2015 06:14 PM, Stephen Farrell wrote:

>

>

> On 01/04/15 17:11, Benjamin Kaduk wrote:

>> On Wed, 1 Apr 2015, Hannes Tschofenig wrote:

>>

>>> I personally would like to replace these types of recommendati=
ons with

>>> references to a page on the IETF website that talks about the =
most

>>> recent TLS & ciphersuite recommendations. I am aware that =
this might

>>> create problems with claiming interoperability with a specific=
 RFC...

>>

>> Why not a BCP document for TLS usage?=C2=A0 It seems to be a chart=
er item for

>> the uta WG already...

>

> Well, initially OAuth wanted some specifics that matched the

> deployments then seen, but yeah, I think the world may have

> moved on sufficiently that a simple reference to the UTA BCP

> (which is in the RFC editor queue) [1] might be fine. I'd

> say it's defo worth asking the wg if they'd have a problem

> with that now.

>

> S.

>

> [1] https://www.rfc-editor.org/queue2.html#draft-ietf=
-uta-tls-bcp

>

>

>>

>> -Ben

>>







-- 
=


Best regards,
Kathleen




--001a11c34d3a523eb40512ace8c7--


From nobody Wed Apr  1 10:36:51 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DC71A19F0; Wed,  1 Apr 2015 10:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghQ7Xk9WxQ4I; Wed,  1 Apr 2015 10:36:48 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D2671A06FD; Wed,  1 Apr 2015 10:36:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3CE53BEDB; Wed,  1 Apr 2015 18:36:46 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjFzOwdTJ-r6; Wed,  1 Apr 2015 18:36:44 +0100 (IST)
Received: from [127.0.0.1] (unknown [86.46.29.244]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BF1BEBE8F; Wed,  1 Apr 2015 18:36:44 +0100 (IST)
X-Priority: 3
To: hannes.tschofenig@gmx.net
From: stephen.farrell@cs.tcd.ie
In-Reply-To: <551C2568.3050301@gmx.net>
References:  <551C0005.2000309@gmx.net>  <551C1970.4050600@cs.tcd.ie> <551C2568.3050301@gmx.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Date: Wed, 1 Apr 2015 17:36:43 +0000
Message-ID: 
MIME-Version: 1.0
Archived-At: 
Cc: draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] MTI ... Re: Security review of draft-ietf-oauth-dyn-reg-management-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Apr 2015 17:36:50 -0000

DQoNCk9uIFdlZCBBcHIgMSAxODowNTo0NCAyMDE1IEdNVCswMTAwLCBIYW5uZXMgVHNjaG9mZW5p
ZyB3cm90ZToNCj4gQmVuLCBTdGVwaGVuLA0KPiANCj4gSSBiZWxpZXZlIHRoYXQgdGhpcyB3b3Vs
ZCBiZSBhIGdvb2QgaWRlYSBhbHRob3VnaCBpdCBkb2VzIG5vdCByZWFsbHkNCj4gc29sdmUgdGhl
IHVuZGVybHlpbmcgcHJvYmxlbS4gV2h5PyBJZiB3ZSBwdXQgYSByZWZlcmVuY2UgdG8gdGhlIFVU
QSBCQ1ANCj4gaW4gdGhlcmUgdGhlbiB3ZSBlbmQgdXAgaW4gdGhlIG5lZWQgdG8gdXBkYXRlIG91
ciBkb2N1bWVudHMgaW4gdGhlIG5vdA0KPiB0b28gZGlzdGFuY2UgZnV0dXJlIHRvIHBvaW50IHRv
IGEgbmV3IFVUQSBCQ1AgdGhhdCB0YWxrcyBhYm91dCBUTFMgMS4zLg0KDQoNCk5vLiBQdXQgaW4g
dGhlIGJjcCBudW1iZXIgYW5kIG5vdCB0aGUgcmZjIG51bWJlci4NCg0KUyANCg0KPiANCj4gQ2lh
bw0KPiBIYW5uZXMNCj4gDQo+IA0KPiBPbiAwNC8wMS8yMDE1IDA2OjE0IFBNLCBTdGVwaGVuIEZh
cnJlbGwgd3JvdGU6DQo+ID4gDQo+ID4gDQo+ID4gT24gMDEvMDQvMTUgMTc6MTEsIEJlbmphbWlu
IEthZHVrIHdyb3RlOg0KPiA+PiBPbiBXZWQsIDEgQXByIDIwMTUsIEhhbm5lcyBUc2Nob2Zlbmln
IHdyb3RlOg0KPiA+Pg0KPiA+Pj4gSSBwZXJzb25hbGx5IHdvdWxkIGxpa2UgdG8gcmVwbGFjZSB0
aGVzZSB0eXBlcyBvZiByZWNvbW1lbmRhdGlvbnMgd2l0aA0KPiA+Pj4gcmVmZXJlbmNlcyB0byBh
IHBhZ2Ugb24gdGhlIElFVEYgd2Vic2l0ZSB0aGF0IHRhbGtzIGFib3V0IHRoZSBtb3N0DQo+ID4+
PiByZWNlbnQgVExTICYgY2lwaGVyc3VpdGUgcmVjb21tZW5kYXRpb25zLiBJIGFtIGF3YXJlIHRo
YXQgdGhpcyBtaWdodA0KPiA+Pj4gY3JlYXRlIHByb2JsZW1zIHdpdGggY2xhaW1pbmcgaW50ZXJv
cGVyYWJpbGl0eSB3aXRoIGEgc3BlY2lmaWMgUkZDLi4uDQo+ID4+DQo+ID4+IFdoeSBub3QgYSBC
Q1AgZG9jdW1lbnQgZm9yIFRMUyB1c2FnZT8gIEl0IHNlZW1zIHRvIGJlIGEgY2hhcnRlciBpdGVt
IGZvcg0KPiA+PiB0aGUgdXRhIFdHIGFscmVhZHkuLi4NCj4gPiANCj4gPiBXZWxsLCBpbml0aWFs
bHkgT0F1dGggd2FudGVkIHNvbWUgc3BlY2lmaWNzIHRoYXQgbWF0Y2hlZCB0aGUNCj4gPiBkZXBs
b3ltZW50cyB0aGVuIHNlZW4sIGJ1dCB5ZWFoLCBJIHRoaW5rIHRoZSB3b3JsZCBtYXkgaGF2ZQ0K
PiA+IG1vdmVkIG9uIHN1ZmZpY2llbnRseSB0aGF0IGEgc2ltcGxlIHJlZmVyZW5jZSB0byB0aGUg
VVRBIEJDUA0KPiA+ICh3aGljaCBpcyBpbiB0aGUgUkZDIGVkaXRvciBxdWV1ZSkgWzFdIG1pZ2h0
IGJlIGZpbmUuIEknZA0KPiA+IHNheSBpdCdzIGRlZm8gd29ydGggYXNraW5nIHRoZSB3ZyBpZiB0
aGV5J2QgaGF2ZSBhIHByb2JsZW0NCj4gPiB3aXRoIHRoYXQgbm93Lg0KPiA+IA0KPiA+IFMuDQo+
ID4gDQo+ID4gWzFdIGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3F1ZXVlMi5odG1sI2RyYWZ0
LWlldGYtdXRhLXRscy1iY3ANCj4gPiANCj4gPiANCj4gPj4NCj4gPj4gLUJlbg0KPiA+Pg0KPiAN
Cj4=


From nobody Wed Apr  1 14:11:36 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBC51AC3E7; Wed,  1 Apr 2015 14:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDacAyLBjUgx; Wed,  1 Apr 2015 14:11:33 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 158B61AC3E3; Wed,  1 Apr 2015 14:11:32 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t31LBCgI054427 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2015 16:11:23 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Derek Atkins" 
Date: Wed, 01 Apr 2015 16:11:11 -0500
Message-ID: <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com>
In-Reply-To: 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> 
MIME-Version: 1.0
X-Mailer: MailMate (1.9.1r5083)
Archived-At: 
Cc: Jean-Marc Valin , "secdir@ietf.org" , "jspittka@gmail.com" , Roni Even , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" 
Subject: Re: [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Apr 2015 21:11:35 -0000

Hi Roni and Derek,

This thread sort of tailed off in February. Has the discussion been resolved?

Thanks!

Ben.

On 19 Feb 2015, at 11:07, Derek Atkins wrote:

> Roni,
>
> I'm not an RTP guy.  To me "SRTP" is a general class of "Secure RTP"
> protocols.  So let's work on that as my starting point:  implementations
> SHOULD protect their RTP stream.
>
> Based on that, how about a re-wording here?  Instead of just saying "MAY
> use SRTP", how about something like "SHOULD use one of the possible RTP
> Security methods (See RFC7201, RFC7202)"?  (Obviously this can be worded
> better).
>
> -derek
>
> Roni Even  writes:
>
>> Hi,
>> The reason for the may is discussed in RFC7201 and RFC 7202, it can be
>> a SHOULD and these RFCs exaplain when it is not required to use SRTP.
>> Maybe add a reference to these RFCs in the security section when
>> saying talking about good reasons for not using SRTP
>>
>> Roni Even
>>
>> ________________________________________
>> From: Jean-Marc Valin [jvalin@mozilla.com] on behalf of Jean-Marc
>> Valin [jmvalin@mozilla.com]
>> Sent: Tuesday, February 17, 2015 10:23 PM
>> To: Derek Atkins; iesg@ietf.org; secdir@ietf.org
>> Cc: payload-chairs@tools.ietf.org; koenvos74@gmail.com; jspittka@gmail.com
>> Subject: Re: sec-dir review of draft-ietf-payload-rtp-opus-08
>>
>> Hi Derek,
>>
>> There was no particular reason for the MAY, the text was merely copied
>> from other RTP payload RFC. I totally agree with making it a SHOULD.
>>
>> Thanks,
>>
>>       Jean-Marc
>>
>> On 17/02/15 02:54 PM, Derek Atkins wrote:
>>> 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 with the intent of improving
>>> security requirements and considerations in IETF drafts.  Comments
>>> not addressed in last call may be included in AD reviews during the
>>> IESG review.  Document editors and WG chairs should treat these
>>> comments just like any other last call comments.
>>>
>>> Summary:
>>>
>>> Ready to publish with a question: I question why the use of SRTP is a
>>> MAY and not a SHOULD (as detailed in the Security Considerations
>>> section).  Considering PERPASS I believe this should be a SHOULD;
>>> someone should have a very good reason why they are NOT using SRTP.
>>>
>>> Details:
>>>
>>>  This document defines the Real-time Transport Protocol (RTP) payload
>>>  format for packetization of Opus encoded speech and audio data
>>>  necessary to integrate the codec in the most compatible way.
>>>  Further, it describes media type registrations for the RTP payload
>>>  format.
>>>
>>> I have no other comments on this document.
>>>
>>> -derek
>>>
>>
>> _______________________________________________
>> secdir mailing list
>> secdir@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdir
>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>
>>
>
> -- 
>      Derek Atkins                 617-623-3745
>      derek@ihtfp.com             www.ihtfp.com
>      Computer and Internet Security Consultant


From nobody Wed Apr  1 14:22:48 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1D51A1AD0 for ; Wed,  1 Apr 2015 14:20:51 -0700 (PDT)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nsWGo1qH4jf for ; Wed,  1 Apr 2015 14:20:47 -0700 (PDT)
Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (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 4CCC41A1A75 for ; Wed,  1 Apr 2015 14:20:47 -0700 (PDT)
Received: by qcbii10 with SMTP id ii10so30122630qcb.2 for ; Wed, 01 Apr 2015 14:20:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Z5T8XQc4MFWFHv/M5z6CQPxcrhgszA6ou/ADy0N1ZhY=; b=PgDRZjiUXGMLu1dUI9iYFCIqykXDtwDm9oIcdK7EjmN6Q8CyPGAUm8B8VfMG6lJ7BZ 9lGzSgJ3ec39Mwwr2JjMkL9QPQvQ9or54S6bnt1z4nUtleZSeZrA+tt0xtJK7hg96Yp1 n0KdK7NbkJIfjhwxSwXdXBjXTn8gQt+brwxG/2hlhovT3I3tWxvxcbhgsUulS8AZndcV oO5ccCSN4T9gcC0WMZGZkgyiNSg1zy4GiXZTpKoYAOJAIwrEtsILm+Xwd/Qn+77DAYg1 +MSkX6waF/U+NFJ07sYpdTXml/Ggiyv6CTAvO7PLCEEO0RaJKVneYQ/KXhiUuuwWfQ1E vt/A==
X-Gm-Message-State: ALoCoQnK5ms+8qEtvhiwNiFO4SGvfN9PjjUU7vA9diCJ1AzMD2VBt+IkSGgEhHJym7sCWJ/uwd1O
X-Received: by 10.55.54.73 with SMTP id d70mr36343694qka.22.1427923246362; Wed, 01 Apr 2015 14:20:46 -0700 (PDT)
Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id i13sm2110774qgi.33.2015.04.01.14.20.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2015 14:20:45 -0700 (PDT)
Message-ID: <551C612B.4030702@mozilla.com>
Date: Wed, 01 Apr 2015 17:20:43 -0400
From: Jean-Marc Valin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Ben Campbell , Derek Atkins 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com>
In-Reply-To: <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
X-Mailman-Approved-At: Wed, 01 Apr 2015 14:22:35 -0700
Cc: "secdir@ietf.org" , "jspittka@gmail.com" , Roni Even , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" 
Subject: Re: [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Apr 2015 21:20:51 -0000

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

Based on Derek's latest suggestion, the text would become:

"Since Opus does not provide any confidentiality or integrity
protection, implementations SHOULD use one of the possible RTP
Security methods (See RFC7201, RFC7202)."

I think that should resolve the issue that was raised.

	Jean-Marc

On 01/04/15 05:11 PM, Ben Campbell wrote:
> Hi Roni and Derek,
> 
> This thread sort of tailed off in February. Has the discussion been
> resolved?
> 
> Thanks!
> 
> Ben.
> 
> On 19 Feb 2015, at 11:07, Derek Atkins wrote:
> 
>> Roni,
>> 
>> I'm not an RTP guy.  To me "SRTP" is a general class of "Secure
>> RTP" protocols.  So let's work on that as my starting point:
>> implementations SHOULD protect their RTP stream.
>> 
>> Based on that, how about a re-wording here?  Instead of just
>> saying "MAY use SRTP", how about something like "SHOULD use one
>> of the possible RTP Security methods (See RFC7201, RFC7202)"?
>> (Obviously this can be worded better).
>> 
>> -derek
>> 
>> Roni Even  writes:
>> 
>>> Hi, The reason for the may is discussed in RFC7201 and RFC
>>> 7202, it can be a SHOULD and these RFCs exaplain when it is not
>>> required to use SRTP. Maybe add a reference to these RFCs in
>>> the security section when saying talking about good reasons for
>>> not using SRTP
>>> 
>>> Roni Even
>>> 
>>> ________________________________________ From: Jean-Marc Valin
>>> [jvalin@mozilla.com] on behalf of Jean-Marc Valin
>>> [jmvalin@mozilla.com] Sent: Tuesday, February 17, 2015 10:23
>>> PM To: Derek Atkins; iesg@ietf.org; secdir@ietf.org Cc:
>>> payload-chairs@tools.ietf.org; koenvos74@gmail.com;
>>> jspittka@gmail.com Subject: Re: sec-dir review of
>>> draft-ietf-payload-rtp-opus-08
>>> 
>>> Hi Derek,
>>> 
>>> There was no particular reason for the MAY, the text was merely
>>> copied from other RTP payload RFC. I totally agree with making
>>> it a SHOULD.
>>> 
>>> Thanks,
>>> 
>>> Jean-Marc
>>> 
>>> On 17/02/15 02:54 PM, Derek Atkins wrote:
>>>> 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
>>>> with the intent of improving security requirements and
>>>> considerations in IETF drafts.  Comments not addressed in
>>>> last call may be included in AD reviews during the IESG
>>>> review.  Document editors and WG chairs should treat these 
>>>> comments just like any other last call comments.
>>>> 
>>>> Summary:
>>>> 
>>>> Ready to publish with a question: I question why the use of
>>>> SRTP is a MAY and not a SHOULD (as detailed in the Security
>>>> Considerations section).  Considering PERPASS I believe this
>>>> should be a SHOULD; someone should have a very good reason
>>>> why they are NOT using SRTP.
>>>> 
>>>> Details:
>>>> 
>>>> This document defines the Real-time Transport Protocol (RTP)
>>>> payload format for packetization of Opus encoded speech and
>>>> audio data necessary to integrate the codec in the most
>>>> compatible way. Further, it describes media type
>>>> registrations for the RTP payload format.
>>>> 
>>>> I have no other comments on this document.
>>>> 
>>>> -derek
>>>> 
>>> 
>>> _______________________________________________ secdir mailing
>>> list secdir@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/secdir wiki:
>>> http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>> 
>>> 
>> 
>> -- Derek Atkins                 617-623-3745 derek@ihtfp.com
>> www.ihtfp.com Computer and Internet Security Consultant
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVHGEoAAoJEJ6/8sItn9q9powH/A2SNnh6bfcVBXImXZQl4Orc
Y9yt5YbF6nWZAbJsp47T5BdtrWm3sXO6I5Uibh9uVrd45G58H39PLQfiR0YxUVif
QbdusWArFTbTWSJcFJFFIWZd8PwiugkNrKk+oLlz3KyQAHXYGU85CTk+OuxSk3Hm
UWRFYBk66ae/h/VWDEF/XVZrzi2N0mSUCZzAfdgIrqQUcE7QuXz9jdgJf9xmNFEh
CmYYHRA4hCjdXtauLHwizIr77WGWEwBUtt0axmynp8w+qPj5OlTdOyIdRR6yjEhq
tifVbMOsLJvdm3a/I/6XAQOd9LEGwjfjxhIyPdJerer4msJlK2VlOZMG3cEeEmA=
=mvYf
-----END PGP SIGNATURE-----


From nobody Wed Apr  1 15:11:12 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833FA1A8799; Wed,  1 Apr 2015 15:07:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQvx7k0wAO1p; Wed,  1 Apr 2015 15:07:49 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7501A8773; Wed,  1 Apr 2015 15:07:48 -0700 (PDT)
X-AuditID: c6180641-f790b6d000004359-24-551c09dc1be0
Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id DF.42.17241.CD90C155; Wed,  1 Apr 2015 17:08:12 +0200 (CEST)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0210.002; Wed, 1 Apr 2015 18:07:41 -0400
From: Uma Chunduri 
To: "Adam W. Montville" , The IESG , "secdir@ietf.org" , "draft-ietf-isis-extended-sequence-no-tlv.all@tools.ietf.org" 
Thread-Topic: Security review of draft-ietf-isis-extended-sequence-no-tlv-04
Thread-Index: AQHQbH/Zhsqwc8PAg0OvMaxLgCljg504XO/g
Date: Wed, 1 Apr 2015 22:07:40 +0000
Message-ID: <1B502206DFA0C544B7A60469152008633F61E19F@eusaamb105.ericsson.se>
References: <718D753F-E377-4197-9F01-C34C12EC5CA0@gmail.com>
In-Reply-To: <718D753F-E377-4197-9F01-C34C12EC5CA0@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.9]
Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F61E19Feusaamb105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPrO4dTplQg2cnZCy2PGxjsdh38x27 xYw/E5ktPix8yOLA4rFz1l12jyVLfjJ5fLn8mS2AOYrLJiU1J7MstUjfLoEr49LB/YwF6xoZ K67MiG9gXJHbxcjJISFgIjH53A1mCFtM4sK99WxdjFwcQgJHGSXeP3/MBOEsY5T4Mn8uE0gV m4CexMepP9lBEiIC3xglfj6ezAKSEBbwlvjU3cYGYosI+EhsnvSYHcI2kth07iRYM4uAisS6 SxA1vAK+Ep8+ngVbLSRgI3Fs406wek4BW4l5OyBmMgKd9P3UGrBeZgFxiVtP5jNBnCogsWTP eaizRSVePv7HCmErSuzrnw40hwOoPl/i7XF2iFWCEidnPmGZwCgyC8mkWQhVs5BUQZToSCzY /YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYOUqLU8ty040MNzECY+uYBJvjDsYFnywPMQpwMCrx 8D6QkA4VYk0sK67MPcQozcGiJM5bduVgiJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGjotC 4V3WG6cXNU8PfqIeLpyu8n17ytJ37GsyO+642U89lNqwsPx1m8yz49XPWT0XBMQ8Oxc+/8Dq z1JWUoJ3Ck+vMeVTPPBvedWpu1Ofn321t3kWR+i6tYY729dOOXnF2Pz7DJupiRKq/+XDolct OlghGqdyL+Ozov6iQrbTmq43z4V/vZzQqMRSnJFoqMVcVJwIALXdQE2OAgAA
Archived-At: 
X-Mailman-Approved-At: Wed, 01 Apr 2015 15:11:11 -0700
Subject: Re: [secdir] Security review of draft-ietf-isis-extended-sequence-no-tlv-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Apr 2015 22:07:53 -0000

--_000_1B502206DFA0C544B7A60469152008633F61E19Feusaamb105erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Adam,

Thanks for your review and suggestions.
Please see my replies in-line [Uma]:

-----Original Message-----
From: Adam W. Montville [mailto:adam.w.montville@gmail.com]
Sent: Wednesday, April 01, 2015 6:29 AM
To: The IESG; secdir@ietf.org; draft-ietf-isis-extended-sequence-no-tlv.all=
@tools.ietf.org
Subject: Security review of draft-ietf-isis-extended-sequence-no-tlv-04

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.

This draft is ready with issues.

There are two circumstances within IS-IS that are subject to replay attacks=
.  One can happen when adjacencies are brought up and an IS sends an IIH (h=
ello).  The other circumstance pertains to replaying CSNP, which may cause =
replay of PSNP and thus cause LSP flooding.

This draft proposes a sequence to mitigate replay attacks in both circumsta=
nces.  The structure of the sequence is defined as a new TLV called "ESN TL=
V".  It constists of the three fields, Type, Length, and Value, where Value=
 is to be interpreted as two separate fields.  These two fields are known a=
s Extended Session Sequence Number (ESSN; a 64-bit value, which is non-zero=
 and unsigned), and Packet Sequence Number (PSN; a 32-bit value).  A given =
ESN is associated with a particular Protocol Data Unit (PDU).  A PDU, there=
fore, "has" an ESSN, which is associated with a monotonically increasing PS=
N.  If the PSN wraps or if the device needs to be restarted, then the next =
ESSN must be larger than the previous ESSN.

This is where I see a potential issue, but maybe I'm missing a limit of pra=
cticality.  What happens when the ESSN is at 2^64-1 and needs to increment?=
  Granted that's a large number, so it might be the case that under no prac=
tical circumstance would the ESSN ever become that large; but, if that's th=
e case, then it might be best to state so in the draft.

[Uma]: As you stated though this is possible theoretically, it is almost im=
practical if the right method of encoding is used. For every PDU only 32-bi=
t PSN  increases and only when it wraps ESSN value  is incremented. There a=
re two approaches specified in Appendix (only as mere guidelines) of this d=
raft to encode ESSN (64-bit) value.  If timestamps are used (Appendix A.1) =
to encode this value I don't see the possibility for this to happen before =
the lifetime of the router perhaps.  However, in Appendix A.2, non-volatile=
 storage (Page 7)  it's clearly stated that -
    "If the non-volatile
   storage is ever repaired or upgraded such that the contents are lost,
   keys MUST be changed to prevent replay attacks."



In the Appendix, the draft also goes into how timestamps may be leveraged (=
which are potentially more effective at mitigating replay attacks than are =
sequences), but does not clearly indicate how neighbors would negotiate the=
 use of timestamps or how exactly the timestamps would be used or which for=
mat then must be used (a suggestion to look at RFC5905 is made).

[Uma]:  Appendix only proposes to use timestamps as a potential approach to=
 encode the ESSN field of the TLV to get the ever increasing property in al=
l cases. Please  note the approach for replay attack mitigation here is Ext=
ended Sequence numbers as specified in the TLV.  There could be and may be =
more mechanisms to solve the same problem at hand but those are beyond the =
scope of this document. There is *no negotiation* required with neighbor on=
 how to encode this value. This is purely a local matter as long as the "ev=
er increasing" property is maintained, when 32-bit PSN is ever wrapped/cold=
-restart cases as explained in section 3.1.

There may be valid operational reasons to favor a sequence over timestamps =
for replay mitigation, but such considerations appear absent in this draft.=
  Is there a reason timestamps are being avoided as the replay mitigation s=
olution?

[Uma]: As I said above sequence number mechanism is the chosen option to so=
lve the problem. For example, IS-IS LSP PDU already has 32-bit sequence num=
ber, which can effectively  being used also for mitigating intra-session re=
play attacks.  The current method is to extend this approach to prevent int=
er and intra session replay attacks for non-LSP PDUs.  IMO, other possible =
methods to solve this problem (as you mentioned time stamps, frequent key c=
hanges through a key management protocol etc..) is beyond the scope of the =
current work.


Nits:

There was at least one area of the text that could probably be clarified fo=
r the sake of non-security-familiar folks. The paragraph in section 2.1 cou=
ld be changed as follows, to make clear that the authenticated case of IIH =
is where mitigation can be made.

OLD
At the time of adjacency bring up an IS sends IIH packet with empty neighbo=
r list (TLV 6) and with or without the authentication information as per pr=
ovisioned authentication mechanism.  If this packet is replayed later on th=
e broadcast network all ISes in the broadcast network can bounce the adjace=
ncy to create a huge churn in the network.

NEW
When an adjacency is brought up an IS sends an IIH packet with an empty nei=
ghbor list (TLV 6), which can be sent with or without authentication inform=
ation.  Packets can be replayed later on the broadcast network which may ca=
use all ISes to bounce the adjacency, thus churning the network.  Note that=
 mitigating replay is only possible when authentication information is pres=
ent.

[Uma]: Sure, I shall change the text as you suggested. Thank you.

In general, I recommend reviewing the draft for clarity.

Kind regards,

Adam


--_000_1B502206DFA0C544B7A60469152008633F61E19Feusaamb105erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Adam,


 


Thanks for your review and suggestions.


Please see my replies in-line [Uma]:


 <=
/div>

-----Original Message=
-----


From: Adam W. Montville [mail=
to:adam.w.montville@gmail.com]



Sent: Wednesday, April 01, 2015 6:29 AM


To: The IESG; secdir@ietf.org; draft-ietf-isis-extended-sequence-no-tlv.all=
@tools.ietf.org


Subject: Security review of draft-ietf-isis-extended-sequence-no-tlv-04


 <=
/div>

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 writ=
ten primarily for the benefit of the security
area directors.


 <=
/div>

This draft is ready w=
ith issues.


 <=
/div>

There are two circums=
tances within IS-IS that are subject to replay attacks.  One can happe=
n when adjacencies are brought up and an IS sends an IIH (hello).  The=
 other circumstance pertains to replaying CSNP,
which may cause replay of PSNP and thus cause LSP flooding.  


 <=
/div>

This draft proposes a=
 sequence to mitigate replay attacks in both circumstances.  The struc=
ture of the sequence is defined as a new TLV called "ESN TLV".&nb=
sp; It constists of the three fields, Type, Length, and
Value, where Value is to be interpreted as two separate fields.  These=
 two fields are known as Extended Session Sequence Number (ESSN; a 64-bit v=
alue, which is non-zero and unsigned), and Packet Sequence Number (PSN; a 3=
2-bit value).  A given ESN is associated
with a particular Protocol Data Unit (PDU).  A PDU, therefore, "h=
as" an ESSN, which is associated with a monotonically increasing PSN.&=
nbsp; If the PSN wraps or if the device needs to be restarted, then the nex=
t ESSN must be larger than the previous ESSN.


 <=
/div>

This is where I see a=
 potential issue, but maybe I'm missing a limit of practicality.  What=
 happens when the ESSN is at 2^64-1 and needs to increment?  Granted t=
hat's a large number, so it might be the case
that under no practical circumstance would the ESSN ever become that large;=
 but, if that's the case, then it might be best to state so in the draft.


 <=
/div>

[Uma]: As you stated though this is possible theoretically, it is almo=
st impractical if the right method of encoding is used. For every PDU only =
32-bit PSN  increases and only when it wraps ESSN value  is incremente=
d. There are two approaches specified
in Appendix (only as mere guidelines) of this draft to encode ESSN (64-bit)=
 value.  If timestamps are used (Appendix A.1) to encode this value I =
don’t see the possibility for this to happen before the lifetime of t=
he router perhaps.  However, in Appendix A.2,
non-volatile storage (Page 7)  it’s clearly stated that –<=
/div>

=
    “=
If the non-volatile


=
   storage is ever repaired or upgraded such that the contents ar=
e lost,


=
   keys MUST be changed to prevent replay attacks.”<=
/font>


 <=
/div>

 <=
/div>

 <=
/div>

In the Appendix, the =
draft also goes into how timestamps may be leveraged (which are potentially=
 more effective at mitigating replay attacks than are sequences), but does =
not clearly indicate how neighbors would
negotiate the use of timestamps or how exactly the timestamps would be used=
 or which format then must be used (a suggestion to look at RFC5905 is made=
).  


 <=
/div>

[Uma]:  Appendix only proposes to use timestamps as a potential approa=
ch to encode the ESSN field of the TLV to get the ever increasing property =
in all cases. Please  note the approach for replay attack mitigation h=
ere is Extended Sequence numbers as specified
in the TLV.  There could be and may be more mechanisms to solve the same pr=
oblem at hand but those are beyond the scope of this document. There is *no negotiation* required with neighbor on how to encode this value. Th=
is is purely a local matter as long
as the “ever increasing” property is maintained, when 32-bit PS=
N is ever wrapped/cold-restart cases as explained in section 3.1.


 <=
/div>

There may be valid op=
erational reasons to favor a sequence over timestamps for replay mitigation=
, but such considerations appear absent in this draft.  Is there a rea=
son timestamps are being avoided as the replay
mitigation solution?


 <=
/div>

[Uma]: As I said above sequence number mechanism is the chosen option =
to solve the problem. For example, IS-IS LSP PDU already has 32-bit sequenc=
e number, which can effectively  being used also for mitigating intra-sessi=
on replay attacks.  The current
method is to extend this approach to prevent inter and intra session replay=
 attacks for non-LSP PDUs.  IMO, other possible methods to solve this =
problem (as you mentioned time stamps, frequent key changes through a key m=
anagement protocol etc..) is beyond the
scope of the current work.


 <=
/div>

 <=
/div>

Nits:

 <=
/div>

There was at least on=
e area of the text that could probably be clarified for the sake of non-sec=
urity-familiar folks. The paragraph in section 2.1 could be changed as foll=
ows, to make clear that the authenticated
case of IIH is where mitigation can be made.


 <=
/div>

OLD

At the time of adjace=
ncy bring up an IS sends IIH packet with empty neighbor list (TLV 6) and wi=
th or without the authentication information as per provisioned authenticat=
ion mechanism.  If this packet is replayed
later on the broadcast network all ISes in the broadcast network can bounce=
 the adjacency to create a huge churn in the network.


 <=
/div>

NEW

When an adjacency is =
brought up an IS sends an IIH packet with an empty neighbor list (TLV 6), w=
hich can be sent with or without authentication information.  Packets =
can be replayed later on the broadcast network
which may cause all ISes to bounce the adjacency, thus churning the network=
.  Note that mitigating replay is only possible when authentication in=
formation is present.


 <=
/div>

[Uma]: Sure, I shall change the text as you suggested. Thank you.

 <=
/div>

In general, I recomme=
nd reviewing the draft for clarity.


 <=
/div>

Kind regards,<=
/font>


 <=
/div>

Adam

 <=
/div>




--_000_1B502206DFA0C544B7A60469152008633F61E19Feusaamb105erics_--


From nobody Wed Apr  1 15:50:25 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E62C1A1A6D; Wed,  1 Apr 2015 15:50:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfbXAs_qiGTO; Wed,  1 Apr 2015 15:50:20 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 23E561A017F; Wed,  1 Apr 2015 15:50:20 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t31Mo4r5062535 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2015 17:50:14 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Jean-Marc Valin" 
Date: Wed, 01 Apr 2015 17:50:03 -0500
Message-ID: 
In-Reply-To: <551C612B.4030702@mozilla.com>
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5083)
Archived-At: 
Cc: "secdir@ietf.org" , "jspittka@gmail.com" , Roni Even , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" 
Subject: Re: [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Apr 2015 22:50:23 -0000

On 1 Apr 2015, at 16:20, Jean-Marc Valin wrote:

> Based on Derek's latest suggestion, the text would become:
>
> "Since Opus does not provide any confidentiality or integrity
> protection, implementations SHOULD use one of the possible RTP
> Security methods (See RFC7201, RFC7202)."
>
> I think that should resolve the issue that was raised.

I'm not sure that's the right solution. First, 7201 and 7202 are 
informational, so I'm not sure we want to insert a normative reference 
to them here.

But more to the point, while I concur with the desire to push for better 
protections, I don't think a codec payload spec is the right place to do 
it. It risks having different security requirements for different codecs 
when used by the same RTP application. I can see that if there are 
really security difference (e.g. if some codec had built in protection.)

I think this is rather the point of 7202, although I notice section 6 of 
that draft says: "It is also expected that a similar [MTI crypto spec] 
will be produced for voice-over-IP applications using SIP and RTP." 
Unfortunately, I don't think that ever happened.

So my suggestion would be something more to the effect of:

"Opus does not provide any built-in confidentiality or integrity
protection. Protection requirements vary between RTP applications.
See RFC 7201 and RFC 7202 for a discussion.

>
> 	Jean-Marc
>
> On 01/04/15 05:11 PM, Ben Campbell wrote:
>> Hi Roni and Derek,
>>
>> This thread sort of tailed off in February. Has the discussion been
>> resolved?
>>
>> Thanks!
>>
>> Ben.
>>
>> On 19 Feb 2015, at 11:07, Derek Atkins wrote:
>>
>>> Roni,
>>>
>>> I'm not an RTP guy.  To me "SRTP" is a general class of "Secure
>>> RTP" protocols.  So let's work on that as my starting point:
>>> implementations SHOULD protect their RTP stream.
>>>
>>> Based on that, how about a re-wording here?  Instead of just
>>> saying "MAY use SRTP", how about something like "SHOULD use one
>>> of the possible RTP Security methods (See RFC7201, RFC7202)"?
>>> (Obviously this can be worded better).
>>>
>>> -derek
>>>
>>> Roni Even  writes:
>>>
>>>> Hi, The reason for the may is discussed in RFC7201 and RFC
>>>> 7202, it can be a SHOULD and these RFCs exaplain when it is not
>>>> required to use SRTP. Maybe add a reference to these RFCs in
>>>> the security section when saying talking about good reasons for
>>>> not using SRTP
>>>>
>>>> Roni Even
>>>>
>>>> ________________________________________ From: Jean-Marc Valin
>>>> [jvalin@mozilla.com] on behalf of Jean-Marc Valin
>>>> [jmvalin@mozilla.com] Sent: Tuesday, February 17, 2015 10:23
>>>> PM To: Derek Atkins; iesg@ietf.org; secdir@ietf.org Cc:
>>>> payload-chairs@tools.ietf.org; koenvos74@gmail.com;
>>>> jspittka@gmail.com Subject: Re: sec-dir review of
>>>> draft-ietf-payload-rtp-opus-08
>>>>
>>>> Hi Derek,
>>>>
>>>> There was no particular reason for the MAY, the text was merely
>>>> copied from other RTP payload RFC. I totally agree with making
>>>> it a SHOULD.
>>>>
>>>> Thanks,
>>>>
>>>> Jean-Marc
>>>>
>>>> On 17/02/15 02:54 PM, Derek Atkins wrote:
>>>>> 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
>>>>> with the intent of improving security requirements and
>>>>> considerations in IETF drafts.  Comments not addressed in
>>>>> last call may be included in AD reviews during the IESG
>>>>> review.  Document editors and WG chairs should treat these
>>>>> comments just like any other last call comments.
>>>>>
>>>>> Summary:
>>>>>
>>>>> Ready to publish with a question: I question why the use of
>>>>> SRTP is a MAY and not a SHOULD (as detailed in the Security
>>>>> Considerations section).  Considering PERPASS I believe this
>>>>> should be a SHOULD; someone should have a very good reason
>>>>> why they are NOT using SRTP.
>>>>>
>>>>> Details:
>>>>>
>>>>> This document defines the Real-time Transport Protocol (RTP)
>>>>> payload format for packetization of Opus encoded speech and
>>>>> audio data necessary to integrate the codec in the most
>>>>> compatible way. Further, it describes media type
>>>>> registrations for the RTP payload format.
>>>>>
>>>>> I have no other comments on this document.
>>>>>
>>>>> -derek
>>>>>
>>>>
>>>> _______________________________________________ secdir mailing
>>>> list secdir@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/secdir wiki:
>>>> http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>>>
>>>>
>>>
>>> -- Derek Atkins                 617-623-3745 derek@ihtfp.com
>>> www.ihtfp.com Computer and Internet Security Consultant


From nobody Thu Apr  2 03:21:06 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B591B2C47 for ; Thu,  2 Apr 2015 03:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Level: 
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ4jMuAlE8L6 for ; Thu,  2 Apr 2015 03:21:03 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94CFD1B2C3A for ; Thu,  2 Apr 2015 03:21:02 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t32AL0iu012035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 2 Apr 2015 13:21:00 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t32AL0C5025523; Thu, 2 Apr 2015 13:21:00 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21789.6156.697491.30472@fireball.kivinen.iki.fi>
Date: Thu, 2 Apr 2015 13:21:00 +0300
From: Tero Kivinen 
To: secdir@ietf.org
X-Edit-Time: 1 min
X-Total-Time: 0 min
Archived-At: 
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Apr 2015 10:21:04 -0000

Review instructions and related resources are at:
http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

Hannes Tschofenig is next in the rotation.

For telechat 2015-04-09

Reviewer                 LC end     Draft
Tobias Gondrom         T 2015-03-12 draft-ietf-appsawg-uri-scheme-reg-05
Warren Kumari          T 2015-04-07 draft-ietf-netext-pmip-qos-wifi-07
Matt Lepinski          T 2015-04-02 draft-klensin-smtp-521code-05
Catherine Meadows      TR2015-03-23 draft-ietf-roll-applicability-home-building-09
Catherine Meadows      T 2015-04-02 draft-ietf-httpbis-auth-info-04
Sandy Murphy           T 2015-03-30 draft-ietf-tls-sslv3-diediedie-02
Hannes Tschofenig      TR2015-02-09 draft-ietf-ippm-ipsec-09
Sam Weiler             T 2015-02-16 draft-ietf-6man-resilient-rs-05

Last calls and special requests:

Dan Harkins              2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14
Alexey Melnikov          2015-04-08 draft-ietf-idr-flowspec-redirect-rt-bis-03
Matthew Miller           2015-04-08 draft-ietf-idr-ls-distribution-10
Magnus Nystrom           2015-04-07 draft-ietf-scim-use-cases-05
Hilarie Orman            2015-04-02 draft-ietf-httpauth-digest-15
Eric Osterweil           2015-04-29 draft-perrault-behave-deprecate-nat-mib-v1-01
Radia Perlman            2015-04-13 draft-ietf-tls-session-hash-04
Vincent Roca             2015-04-24 draft-hansen-scram-sha256-02
Joe Salowey              2015-04-16 draft-ietf-nfsv4-layout-types-03
Yaron Sheffer            2015-04-13 draft-ietf-uta-xmpp-05
Zach Shelby              2014-06-06 draft-housley-implementer-obligations-02
Takeshi Takahashi        2015-04-29 draft-perrault-behave-natv2-mib-03
-- 
kivinen@iki.fi


From nobody Thu Apr  2 04:25:45 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D95D1B2C69; Thu,  2 Apr 2015 04:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1-d5qyttPmD; Thu,  2 Apr 2015 04:25:42 -0700 (PDT)
Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9461B2C6C; Thu,  2 Apr 2015 04:25:41 -0700 (PDT)
Received: by pdbnk13 with SMTP id nk13so6660473pdb.0; Thu, 02 Apr 2015 04:25:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=fKD39/VRp997w8pcnRxjXnVTe0jkGHFAzZ2BjxL6LXk=; b=IV5qPQk7Z7hLDGpWuych1TCo1hhtN3Dy5cpmY+zMUqyscuPGlpjiwvWOgjv8F7rv08 JMDV/LGjyiq1T/ZPZwAYsojQRbkaXyqjkCO2traONfjKvpsdi2QCWRjCBj9El2dxBVdG 3p14TnxZM+DsBukH/m/iR4xSiFP28GAjV6sRvYx7OrH48ZHuhE13QN2pzKLtUkV+yXGd 8r/rfF62qjxqVlUNghHcQPRLXGGe8L0qzD0V+fLs5rEUu98TMAROSic7MXizufYRth2O LBewXo0qnFVJOJXhhAglGMHiAEMEG+bA1zbBAd4hK8I8YRmvWb60n4bEb67BMEi4EKeT xXlA==
X-Received: by 10.70.15.67 with SMTP id v3mr85310230pdc.166.1427973940982; Thu, 02 Apr 2015 04:25:40 -0700 (PDT)
Received: from ?IPv6:2602:306:3406:4f00:3927:f888:4490:4af7? ([2602:306:3406:4f00:3927:f888:4490:4af7]) by mx.google.com with ESMTPSA id bz3sm4976342pab.2.2015.04.02.04.25.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Apr 2015 04:25:40 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D9C6C73C-6752-4ED1-81C9-71EAE8283DE3"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: "Adam W. Montville" 
In-Reply-To: <1B502206DFA0C544B7A60469152008633F61E19F@eusaamb105.ericsson.se>
Date: Thu, 2 Apr 2015 06:25:37 -0500
Message-Id: <587CC58A-C9D6-4FCE-8BF0-80BC30CE5D2B@gmail.com>
References: <718D753F-E377-4197-9F01-C34C12EC5CA0@gmail.com> <1B502206DFA0C544B7A60469152008633F61E19F@eusaamb105.ericsson.se>
To: Uma Chunduri 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "draft-ietf-isis-extended-sequence-no-tlv.all@tools.ietf.org" , The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] Security review of draft-ietf-isis-extended-sequence-no-tlv-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Apr 2015 11:25:45 -0000

--Apple-Mail=_D9C6C73C-6752-4ED1-81C9-71EAE8283DE3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thanks for your response.  I have a few more comments inline.


> On Apr 1, 2015, at 5:07 PM, Uma Chunduri  =
wrote:
>=20
> Hi Adam,
> =20
> Thanks for your review and suggestions.
> Please see my replies in-line [Uma]:
> =20
> -----Original Message-----
> From: Adam W. Montville [mailto:adam.w.montville@gmail.com =
]=20
> Sent: Wednesday, April 01, 2015 6:29 AM
> To: The IESG; secdir@ietf.org ; =
draft-ietf-isis-extended-sequence-no-tlv.all@tools.ietf.org =

> Subject: Security review of =
draft-ietf-isis-extended-sequence-no-tlv-04
> =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. =
 These comments were written primarily for the benefit of the security =
area directors.
> =20
> This draft is ready with issues.
> =20
> There are two circumstances within IS-IS that are subject to replay =
attacks.  One can happen when adjacencies are brought up and an IS sends =
an IIH (hello).  The other circumstance pertains to replaying CSNP, =
which may cause replay of PSNP and thus cause LSP flooding. =20
> =20
> This draft proposes a sequence to mitigate replay attacks in both =
circumstances.  The structure of the sequence is defined as a new TLV =
called "ESN TLV".  It constists of the three fields, Type, Length, and =
Value, where Value is to be interpreted as two separate fields.  These =
two fields are known as Extended Session Sequence Number (ESSN; a 64-bit =
value, which is non-zero and unsigned), and Packet Sequence Number (PSN; =
a 32-bit value).  A given ESN is associated with a particular Protocol =
Data Unit (PDU).  A PDU, therefore, "has" an ESSN, which is associated =
with a monotonically increasing PSN.  If the PSN wraps or if the device =
needs to be restarted, then the next ESSN must be larger than the =
previous ESSN.
> =20
> This is where I see a potential issue, but maybe I'm missing a limit =
of practicality.  What happens when the ESSN is at 2^64-1 and needs to =
increment?  Granted that's a large number, so it might be the case that =
under no practical circumstance would the ESSN ever become that large; =
but, if that's the case, then it might be best to state so in the draft.
> =20
> [Uma]: As you stated though this is possible theoretically, it is =
almost impractical if the right method of encoding is used. For every =
PDU only 32-bit PSN  increases and only when it wraps ESSN value is =
incremented. There are two approaches specified in Appendix (only as =
mere guidelines) of this draft to encode ESSN (64-bit) value.  If =
timestamps are used (Appendix A.1) to encode this value I don=E2=80=99t =
see the possibility for this to happen before the lifetime of the router =
perhaps.=20


It would be useful to include such information in the draft, as it may =
not be readily clear to readers that the authors feel the 64-bit value =
is =E2=80=9Cintractable=E2=80=9D in a sense.


> However, in Appendix A.2, non-volatile storage (Page 7)  it=E2=80=99s =
clearly stated that =E2=80=93
>     =E2=80=9CIf the non-volatile
>    storage is ever repaired or upgraded such that the contents are =
lost,
>    keys MUST be changed to prevent replay attacks.=E2=80=9D
> =20
> =20
> =20
> In the Appendix, the draft also goes into how timestamps may be =
leveraged (which are potentially more effective at mitigating replay =
attacks than are sequences), but does not clearly indicate how neighbors =
would negotiate the use of timestamps or how exactly the timestamps =
would be used or which format then must be used (a suggestion to look at =
RFC5905 is made). =20
> =20
> [Uma]: Appendix only proposes to use timestamps as a potential =
approach to encode the ESSN field of the TLV to get the ever increasing =
property in all cases. Please  note the approach for replay attack =
mitigation here is Extended Sequence numbers as specified in the TLV. =
There could be and may be more mechanisms to solve the same problem at =
hand but those are beyond the scope of this document. There is *no =
negotiation* required with neighbor on how to encode this value. This is =
purely a local matter as long as the =E2=80=9Cever increasing=E2=80=9D =
property is maintained, when 32-bit PSN is ever wrapped/cold-restart =
cases as explained in section 3.1.

It may be the case that I have a less-than-complete understanding of the =
problem domain.  My understanding is that one of the mitigation =
circumstances pertains to IS-IS Hello, where neighbors are being brought =
up and sending IIH to others.  Does this not make it a neighborhood =
problem? =20

Even if all neighbors understand the =E2=80=9Cever increasing=E2=80=9D =
property, how would they understand which encoding is in place without =
some additional information?  It would probably be beneficial to provide =
some indication in the TLV as to how ESSN is encoded.  Alternatively, if =
there is a method to deduce the ever increasing property without knowing =
the ESSN encoding, that should be explained (or at least referenced, if =
explained elsewhere).


> =20
> There may be valid operational reasons to favor a sequence over =
timestamps for replay mitigation, but such considerations appear absent =
in this draft.  Is there a reason timestamps are being avoided as the =
replay mitigation solution?
> =20
> [Uma]: As I said above sequence number mechanism is the chosen option =
to solve the problem. For example, IS-IS LSP PDU already has 32-bit =
sequence number, which can effectively being used also for mitigating =
intra-session replay attacks.  The current method is to extend this =
approach to prevent inter and intra session replay attacks for non-LSP =
PDUs.  IMO, other possible methods to solve this problem (as you =
mentioned time stamps, frequent key changes through a key management =
protocol etc..) is beyond the scope of the current work.
> =20
> =20
> Nits:
> =20
> There was at least one area of the text that could probably be =
clarified for the sake of non-security-familiar folks. The paragraph in =
section 2.1 could be changed as follows, to make clear that the =
authenticated case of IIH is where mitigation can be made.
> =20
> OLD
> At the time of adjacency bring up an IS sends IIH packet with empty =
neighbor list (TLV 6) and with or without the authentication information =
as per provisioned authentication mechanism.  If this packet is replayed =
later on the broadcast network all ISes in the broadcast network can =
bounce the adjacency to create a huge churn in the network.
> =20
> NEW
> When an adjacency is brought up an IS sends an IIH packet with an =
empty neighbor list (TLV 6), which can be sent with or without =
authentication information.  Packets can be replayed later on the =
broadcast network which may cause all ISes to bounce the adjacency, thus =
churning the network.  Note that mitigating replay is only possible when =
authentication information is present.
> =20
> [Uma]: Sure, I shall change the text as you suggested. Thank you.

You are welcome.

> =20
> In general, I recommend reviewing the draft for clarity.
> =20
> Kind regards,
> =20
> Adam
> =20


--Apple-Mail=_D9C6C73C-6752-4ED1-81C9-71EAE8283DE3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Thanks for your response.  I have a few more comments =
inline.


On =
Apr 1, 2015, at 5:07 PM, Uma Chunduri <uma.chunduri@ericsson.com> wrote:

Hi Adam,
 
Thanks for your review and =
suggestions.
Please see my replies in-line =
[Uma]:
 
-----Original Message-----
From: Adam W. =
Montville [mailto:adam.w.montville@gmail.com] 
Sent: =
Wednesday, April 01, 2015 6:29 AM
To: The IESG; secdir@ietf.org; draft-ietf-isis-extended-sequence-no-tlv.all@tools.ietf.org=

Subject: Security review of =
draft-ietf-isis-extended-sequence-no-tlv-04
 
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.
 
This draft is =
ready with issues.
 
There are two =
circumstances within IS-IS that are subject to replay attacks.  One =
can happen when adjacencies are brought up and an IS sends an IIH =
(hello).  The other circumstance pertains to replaying CSNP, which =
may cause replay of PSNP and thus cause LSP flooding.  
 
This draft =
proposes a sequence to mitigate replay attacks in both =
circumstances.  The structure of the sequence is defined as a new =
TLV called "ESN TLV".  It constists of the three fields, Type, =
Length, and Value, where Value is to be interpreted as two separate =
fields.  These two fields are known as Extended Session Sequence =
Number (ESSN; a 64-bit value, which is non-zero and unsigned), and =
Packet Sequence Number (PSN; a 32-bit value).  A given ESN is =
associated with a particular Protocol Data Unit (PDU).  A PDU, =
therefore, "has" an ESSN, which is associated with a monotonically =
increasing PSN.  If the PSN wraps or if the device needs to be =
restarted, then the next ESSN must be larger than the previous =
ESSN.
 
This is where I see a potential issue, but maybe I'm missing =
a limit of practicality.  What happens when the ESSN is at 2^64-1 =
and needs to increment?  Granted that's a large number, so it might =
be the case that under no practical circumstance would the ESSN ever =
become that large; but, if that's the case, then it might be best to =
state so in the draft.
 
[Uma]: As you =
stated though this is possible theoretically, it is almost impractical =
if the right method of encoding is used. For every PDU only 32-bit =
PSN  increases and only when it wraps ESSN value is incremented. =
There are two approaches specified in Appendix (only as mere guidelines) =
of this draft to encode ESSN (64-bit) value.  If timestamps are =
used (Appendix A.1) to encode this value I don=E2=80=99t see the =
possibility for this to happen before the lifetime of the router =
perhaps.  


It would be useful to =
include such information in the draft, as it may not be readily clear to =
readers that the authors feel the 64-bit value is =E2=80=9Cintractable=E2=80=
=9D in a sense.


However, in Appendix A.2, non-volatile storage (Page 7)  =
it=E2=80=99s clearly stated that =E2=80=93
    =E2=80=9CIf the =
non-volatile
   storage is ever repaired or upgraded such =
that the contents are lost,
   keys MUST be changed to prevent replay =
attacks.=E2=80=9D
 
 
 
In the Appendix, =
the draft also goes into how timestamps may be leveraged (which are =
potentially more effective at mitigating replay attacks than are =
sequences), but does not clearly indicate how neighbors would negotiate =
the use of timestamps or how exactly the timestamps would be used or =
which format then must be used (a suggestion to look at RFC5905 is =
made).  
 
[Uma]: Appendix =
only proposes to use timestamps as a potential approach to encode the =
ESSN field of the TLV to get the ever increasing property in all cases. =
Please  note the approach for replay attack mitigation here is =
Extended Sequence numbers as specified in the TLV. There could be and =
may be more mechanisms to solve the same problem at hand but those are =
beyond the scope of this document. There is *no =
negotiation* required with neighbor on how to encode this value. =
This is purely a local matter as long as the =E2=80=9Cever increasing=E2=80=
=9D property is maintained, when 32-bit PSN is ever wrapped/cold-restart =
cases as explained in section =
3.1.

It may be the case that I have a =
less-than-complete understanding of the problem domain.  My =
understanding is that one of the mitigation circumstances pertains to =
IS-IS Hello, where neighbors are being brought up and sending IIH to =
others.  Does this not make it a neighborhood problem? =
 

Even if all neighbors =
understand the =E2=80=9Cever increasing=E2=80=9D property, how would =
they understand which encoding is in place without some additional =
information?  It would probably be beneficial to provide some =
indication in the TLV as to how ESSN is encoded.  Alternatively, if =
there is a method to deduce the ever increasing property without knowing =
the ESSN encoding, that should be explained (or at least referenced, if =
explained elsewhere).


 
There may be valid operational reasons to favor a sequence =
over timestamps for replay mitigation, but such considerations appear =
absent in this draft.  Is there a reason timestamps are being =
avoided as the replay mitigation solution?
 
[Uma]: As I said =
above sequence number mechanism is the chosen option to solve the =
problem. For example, IS-IS LSP PDU already has 32-bit sequence number, =
which can effectively being used also for mitigating intra-session =
replay attacks.  The current method is to extend this approach to =
prevent inter and intra session replay attacks for non-LSP PDUs.  =
IMO, other possible methods to solve this problem (as you mentioned time =
stamps, frequent key changes through a key management protocol etc..) is =
beyond the scope of the current work.
 
 
Nits:
 
There was at =
least one area of the text that could probably be clarified for the sake =
of non-security-familiar folks. The paragraph in section 2.1 could be =
changed as follows, to make clear that the authenticated case of IIH is =
where mitigation can be made.
 
OLD
At the time of =
adjacency bring up an IS sends IIH packet with empty neighbor list (TLV =
6) and with or without the authentication information as per provisioned =
authentication mechanism.  If this packet is replayed later on the =
broadcast network all ISes in the broadcast network can bounce the =
adjacency to create a huge churn in the network.
 
NEW
When an adjacency =
is brought up an IS sends an IIH packet with an empty neighbor list (TLV =
6), which can be sent with or without authentication information.  =
Packets can be replayed later on the broadcast network which may cause =
all ISes to bounce the adjacency, thus churning the network.  Note =
that mitigating replay is only possible when authentication information =
is present.
 
[Uma]: Sure, I =
shall change the text as you suggested. Thank you.

You are welcome.

 
In general, I =
recommend reviewing the draft for clarity.
 
Kind =
regards,
 
Adam
 

=

--Apple-Mail=_D9C6C73C-6752-4ED1-81C9-71EAE8283DE3--


From nobody Thu Apr  2 06:40:57 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44721A8AFB; Thu,  2 Apr 2015 06:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.289
X-Spam-Level: 
X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7THLBZHUDzo4; Thu,  2 Apr 2015 06:40:54 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69671A8AD9; Thu,  2 Apr 2015 06:40:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 30ED4E2058; Thu,  2 Apr 2015 09:40:52 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 29134-06; Thu,  2 Apr 2015 09:40:49 -0400 (EDT)
Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 58376E2036; Thu,  2 Apr 2015 09:40:49 -0400 (EDT)
Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t32DejmM023550; Thu, 2 Apr 2015 09:40:45 -0400
From: Derek Atkins 
To: Jean-Marc Valin 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>
Date: Thu, 02 Apr 2015 09:40:44 -0400
In-Reply-To: <551C612B.4030702@mozilla.com> (Jean-Marc Valin's message of "Wed, 01 Apr 2015 17:20:43 -0400")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: 
Cc: Ben Campbell , "secdir@ietf.org" , "jspittka@gmail.com" , Roni Even , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" 
Subject: Re: [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Apr 2015 13:40:56 -0000

Yes, this was the resolution as I recall.

-derek

Jean-Marc Valin  writes:

> Based on Derek's latest suggestion, the text would become:
>
> "Since Opus does not provide any confidentiality or integrity
> protection, implementations SHOULD use one of the possible RTP
> Security methods (See RFC7201, RFC7202)."
>
> I think that should resolve the issue that was raised.
>
> 	Jean-Marc
>
> On 01/04/15 05:11 PM, Ben Campbell wrote:
>> Hi Roni and Derek,
>> 
>> This thread sort of tailed off in February. Has the discussion been
>> resolved?
>> 
>> Thanks!
>> 
>> Ben.
>> 
>> On 19 Feb 2015, at 11:07, Derek Atkins wrote:
>> 
>>> Roni,
>>> 
>>> I'm not an RTP guy.  To me "SRTP" is a general class of "Secure
>>> RTP" protocols.  So let's work on that as my starting point:
>>> implementations SHOULD protect their RTP stream.
>>> 
>>> Based on that, how about a re-wording here?  Instead of just
>>> saying "MAY use SRTP", how about something like "SHOULD use one
>>> of the possible RTP Security methods (See RFC7201, RFC7202)"?
>>> (Obviously this can be worded better).
>>> 
>>> -derek
>>> 
>>> Roni Even  writes:
>>> 
>>>> Hi, The reason for the may is discussed in RFC7201 and RFC
>>>> 7202, it can be a SHOULD and these RFCs exaplain when it is not
>>>> required to use SRTP. Maybe add a reference to these RFCs in
>>>> the security section when saying talking about good reasons for
>>>> not using SRTP
>>>> 
>>>> Roni Even
>>>> 
>>>> ________________________________________ From: Jean-Marc Valin
>>>> [jvalin@mozilla.com] on behalf of Jean-Marc Valin
>>>> [jmvalin@mozilla.com] Sent: Tuesday, February 17, 2015 10:23
>>>> PM To: Derek Atkins; iesg@ietf.org; secdir@ietf.org Cc:
>>>> payload-chairs@tools.ietf.org; koenvos74@gmail.com;
>>>> jspittka@gmail.com Subject: Re: sec-dir review of
>>>> draft-ietf-payload-rtp-opus-08
>>>> 
>>>> Hi Derek,
>>>> 
>>>> There was no particular reason for the MAY, the text was merely
>>>> copied from other RTP payload RFC. I totally agree with making
>>>> it a SHOULD.
>>>> 
>>>> Thanks,
>>>> 
>>>> Jean-Marc
>>>> 
>>>> On 17/02/15 02:54 PM, Derek Atkins wrote:
>>>>> 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
>>>>> with the intent of improving security requirements and
>>>>> considerations in IETF drafts.  Comments not addressed in
>>>>> last call may be included in AD reviews during the IESG
>>>>> review.  Document editors and WG chairs should treat these 
>>>>> comments just like any other last call comments.
>>>>> 
>>>>> Summary:
>>>>> 
>>>>> Ready to publish with a question: I question why the use of
>>>>> SRTP is a MAY and not a SHOULD (as detailed in the Security
>>>>> Considerations section).  Considering PERPASS I believe this
>>>>> should be a SHOULD; someone should have a very good reason
>>>>> why they are NOT using SRTP.
>>>>> 
>>>>> Details:
>>>>> 
>>>>> This document defines the Real-time Transport Protocol (RTP)
>>>>> payload format for packetization of Opus encoded speech and
>>>>> audio data necessary to integrate the codec in the most
>>>>> compatible way. Further, it describes media type
>>>>> registrations for the RTP payload format.
>>>>> 
>>>>> I have no other comments on this document.
>>>>> 
>>>>> -derek
>>>>> 
>>>> 
>>>> _______________________________________________ secdir mailing
>>>> list secdir@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/secdir wiki:
>>>> http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>>> 
>>>> 
>>> 
>>> -- Derek Atkins                 617-623-3745 derek@ihtfp.com
>>> www.ihtfp.com Computer and Internet Security Consultant

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


From nobody Thu Apr  2 10:15:55 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320DC1ACEE1 for ; Thu,  2 Apr 2015 10:15:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level: 
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5m43GHM_FMR0 for ; Thu,  2 Apr 2015 10:15:53 -0700 (PDT)
Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4084B1A888E for ; Thu,  2 Apr 2015 10:15:53 -0700 (PDT)
Received: by qcbii10 with SMTP id ii10so49645919qcb.2 for ; Thu, 02 Apr 2015 10:15:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OFqirxW2ZBm90ExnOUmIfyCFTDPcBvh4Hqz7E+g+UiA=; b=O+Klzyknrm40AZ7rkKbumqEsIozSDXRMqhSx1J6UbglzmSt6ffaJFjvN1fsVOO8TVw 003QnrM/D7YpagLVGOUq4XEXiv+kqujexcOTgrbKgLLXLhwBT3Ydmy2DybRJDxfmpQ78 1tO1YHKkoVGdWzNG6xKgZM3alwHEqBpC9MQkWMe/y6i6KdSNGAVwRPFZUy52XqI3ZPJq pufx2Vl3JHyv5K0NPoa0CA07XUBZpma6GxJufWor5OfPVqFefP/RzqiZwxEHEYhwh9KD J1jJScvSkweLoLCv4wWQKYWhn2RwHbNExH8sD6FyBziyTM4JLK0imbbeaUMG2bThxoZa Xfgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OFqirxW2ZBm90ExnOUmIfyCFTDPcBvh4Hqz7E+g+UiA=; b=Cr6MXPJ91uxG1fED0Yp4DP4+hai/HCZcD0gwRxZ/QLm9/T0FZtvFfORdU4lF9t11FO +l1poeRckMmnNaTi7j+IyA9gpvbrOJ0uCyG9RLcT69vykpBSp5B141XPRaX3V9hTDD7T 064vjxgJVY+yh5eTGoX6MAa6BhdunTsobTf00+OxI6hVdOSDleT0e9lH4W2/VyyQSHSr DAnMNDEGvuxMIBPdarr4fMX5aL2HDLMmCYJxEyFWVbfm8WUzfsrleB9/U+uXg1ExFZrd ctGfEVLlqVuJfW7wu0Ap6v/upN7wYgTZsB2abhFKpVFem8rogXZ3tMoFWAZNIFQkPM3e 7j4A==
X-Gm-Message-State: ALoCoQlkGtYYik3gQqpxQ2LcFwBuKKNvO9vw7/7jFWOghFi49MlEne7k+5ER47aQR6JDvcqYSiPO
MIME-Version: 1.0
X-Received: by 10.55.49.138 with SMTP id x132mr60917188qkx.19.1427994952526; Thu, 02 Apr 2015 10:15:52 -0700 (PDT)
Received: by 10.229.178.135 with HTTP; Thu, 2 Apr 2015 10:15:52 -0700 (PDT)
In-Reply-To: 
References:  <551C0005.2000309@gmx.net>  <551C1970.4050600@cs.tcd.ie> <551C2568.3050301@gmx.net> 
Date: Thu, 2 Apr 2015 18:15:52 +0100
Message-ID: 
From: Ben Laurie 
To: Kathleen Moriarty 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "secdir@ietf.org" , The IESG , draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org
Subject: Re: [secdir] MTI ... Re: Security review of draft-ietf-oauth-dyn-reg-management-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Apr 2015 17:15:54 -0000

On 1 April 2015 at 18:18, Kathleen Moriarty
 wrote:
> I agree with Hannes here.  Having MTI for TLS 1.2 is fine for right now, it
> must be supported, but doesn't mean other versions can't be supported once
> libraries are available and it makes sense.  We can't hold this up because
> TLS 1.3 is coming soon and would prefer that folks know they should be
> implementing at least TLS 1.2.  A reference to the TLS BCP with this is fine
> as well.  But this is one of the many OAuth drafts and not really the place
> to call out specific requirements, like which of the recommended cipher
> suites int eh BCP should be implemented for Oauth (I don't think that has
> been done as it has for other protocols), but is not the right place to do
> too much.

Call it out wherever you want. _My_ job is to review this particular
I-D, and this is an issue with this particular I-D. I don't see how
the fact it is also an issue with many other I-Ds fixes that problem.


From nobody Thu Apr  2 10:25:26 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C884C1AD289; Thu,  2 Apr 2015 10:25:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNJ0xVR1DwgH; Thu,  2 Apr 2015 10:25:23 -0700 (PDT)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D90501A1B48; Thu,  2 Apr 2015 10:25:22 -0700 (PDT)
Received: by lboc7 with SMTP id c7so64212882lbo.1; Thu, 02 Apr 2015 10:25:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=di83NGPM+sPTLbc9pdkMofAkW9jODBRPFMx+9ptYcAs=; b=htUc/Zr6FctJwgogphX2PVOzFY1tC+IbC/zU1HyKTE7D0lvb5LWCpDvP+sQj4RH5oU Vtqo0QibSySN1Y/StelEv4lyC376yYLfe489Qbi9T1UPYHZN46Z/lRvGR/frzmyT08rh tWcaq9c4sP4QnkqfuuXZqy3zipOzDnAxvGs1yT6BVRojLKMNxz8A1DuTLmPAhTOvLUaa 35BGevDaaADokmTRaZzwvq1UJcas6Wm4J6Zf7MBz8XQ1XJ7/a7dky72V+4s2rmND3NST XNJaY8O97StfAF6PAhVq0B3/ZUx6hVWuO8RgWRRAdB3q4/NoxFWNJJWEnlT+nwC8IHCt 2MeA==
MIME-Version: 1.0
X-Received: by 10.112.188.227 with SMTP id gd3mr42724732lbc.0.1427995521435; Thu, 02 Apr 2015 10:25:21 -0700 (PDT)
Received: by 10.112.160.4 with HTTP; Thu, 2 Apr 2015 10:25:21 -0700 (PDT)
In-Reply-To: 
References:  <551C0005.2000309@gmx.net>  <551C1970.4050600@cs.tcd.ie> <551C2568.3050301@gmx.net>  
Date: Thu, 2 Apr 2015 13:25:21 -0400
Message-ID: 
From: Radia Perlman 
To: Ben Laurie 
Content-Type: multipart/alternative; boundary=001a11c36aa8cbcfd30512c11d44
Archived-At: 
Cc: draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org, Kathleen Moriarty , The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] MTI ... Re: Security review of draft-ietf-oauth-dyn-reg-management-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Apr 2015 17:25:24 -0000

--001a11c36aa8cbcfd30512c11d44
Content-Type: text/plain; charset=UTF-8

Can't it just say "MUST support version 1.2 or later version of TLS"?

On Thu, Apr 2, 2015 at 1:15 PM, Ben Laurie  wrote:

> On 1 April 2015 at 18:18, Kathleen Moriarty
>  wrote:
> > I agree with Hannes here.  Having MTI for TLS 1.2 is fine for right now,
> it
> > must be supported, but doesn't mean other versions can't be supported
> once
> > libraries are available and it makes sense.  We can't hold this up
> because
> > TLS 1.3 is coming soon and would prefer that folks know they should be
> > implementing at least TLS 1.2.  A reference to the TLS BCP with this is
> fine
> > as well.  But this is one of the many OAuth drafts and not really the
> place
> > to call out specific requirements, like which of the recommended cipher
> > suites int eh BCP should be implemented for Oauth (I don't think that has
> > been done as it has for other protocols), but is not the right place to
> do
> > too much.
>
> Call it out wherever you want. _My_ job is to review this particular
> I-D, and this is an issue with this particular I-D. I don't see how
> the fact it is also an issue with many other I-Ds fixes that problem.
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>

--001a11c36aa8cbcfd30512c11d44
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Can't it just say "MUST support version 1.2 or la=
ter version of TLS"?

On Thu, Apr 2, 2015 at 1:15 PM, Ben Laurie =
<benl@google.com> wrote:
On 1 April 2015 at 18=
:18, Kathleen Moriarty

<ka=
thleen.moriarty.ietf@gmail.com> wrote:

> I agree with Hannes here.=C2=A0 Having MTI for TLS 1.2 is fine for rig=
ht now, it

> must be supported, but doesn't mean other versions can't be su=
pported once

> libraries are available and it makes sense.=C2=A0 We can't hold th=
is up because

> TLS 1.3 is coming soon and would prefer that folks know they should be=


> implementing at least TLS 1.2.=C2=A0 A reference to the TLS BCP with t=
his is fine

> as well.=C2=A0 But this is one of the many OAuth drafts and not really=
 the place

> to call out specific requirements, like which of the recommended ciphe=
r

> suites int eh BCP should be implemented for Oauth (I don't think t=
hat has

> been done as it has for other protocols), but is not the right place t=
o do

> too much.



Call it out wherever you want. _My_ job is to review this particular=


I-D, and this is an issue with this particular I-D. I don't see how

the fact it is also an issue with many other I-Ds fixes that problem.




_______________________________________________

secdir mailing list

secdir@ietf.org

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

wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview




--001a11c36aa8cbcfd30512c11d44--


From nobody Thu Apr  2 11:42:42 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7251F1A19F7; Thu,  2 Apr 2015 11:42:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2A4fv_CidIm; Thu,  2 Apr 2015 11:42:36 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781A61A0404; Thu,  2 Apr 2015 11:42:36 -0700 (PDT)
Received: from [192.168.131.146] ([80.92.114.249]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MGSDw-1YiC1z3zDk-00DECL; Thu, 02 Apr 2015 20:42:04 +0200
Message-ID: <551D8D78.4000504@gmx.net>
Date: Thu, 02 Apr 2015 20:42:00 +0200
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Radia Perlman , Ben Laurie 
References:  <551C0005.2000309@gmx.net>  <551C1970.4050600@cs.tcd.ie> <551C2568.3050301@gmx.net>   
In-Reply-To: 
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UorQWkkVTJNwMrb2qJ67TQhuh5W1I68Bq"
X-Provags-ID: V03:K0:/gBhZLpr9XqVeFJAr6osWxISOkCdHU9UVp5m5OvLyIWtrjApoMf PgC+UhRMAs8YDthecVsVt7Y9TLXX+Cj6utSlIVF13IZJWH6vMcCqidHlOfddengYD7WEDMO Wo52CD7l2EVHTC9o3/jaqYDHHM1FfBZGPPxurupSCPhkjko+PQYiWYxaq2Se/N+Qx0oQ9IA KKEmx5WIxVeQEtiVbwRDA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Cc: draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org, Kathleen Moriarty , The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] MTI ... Re: Security review of draft-ietf-oauth-dyn-reg-management-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Apr 2015 18:42:38 -0000

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

Radia,

this is what we wrote in RFC 6749:

----


1.6.  TLS Version

   Whenever Transport Layer Security (TLS) is used by this
   specification, the appropriate version (or versions) of TLS will vary
   over time, based on the widespread deployment and known security
   vulnerabilities.  At the time of this writing, TLS version 1.2
   [RFC5246] is the most recent version, but has a very limited
   deployment base and might not be readily available for
   implementation.  TLS version 1.0 [RFC2246] is the most widely
   deployed version and will provide the broadest interoperability.

----

We then moved on to something shorter in RFC 7009:

----

The authorization
   server MUST use Transport Layer Security (TLS) [RFC5246] in a version
   compliant with [RFC6749], Section 1.6.  Implementations MAY also
   support additional transport-layer security mechanisms that meet
   their security requirements.

----

and now we are at:


----

   the server MUST support TLS 1.2 RFC 5246 [RFC5246] and MAY
   support additional transport-layer mechanisms meeting its security
   requirements.

----

I personally don't care too much what we are saying since folks in the
OAuth group would like to say the right thing anyway: we want to use the
most recent version of TLS. Unfortunately that is not specific enough.

If the trick Stephen suggested with referencing BCP numbers (instead of
RFCs) helps then I would go for that.

On 04/02/2015 07:25 PM, Radia Perlman wrote:
> Can't it just say "MUST support version 1.2 or later version of TLS"?

Ciao
Hannes


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJVHY14AAoJEGhJURNOOiAtgJ0H+QGSOn9Ocq3shXzDtJt8Mz9o
+O0xtQ2si/gtYLq2UjHYXDLhL/md/uGicwxUW4zFQ5CmHGJunftpHoRXxOSqE/ym
V2uGnQ9WRi7oKtG+s6tuwIP8x/4ST62plUDtNPSpfalM7r2/s230dmxYAuN+tPXG
V+5/PY2R5PnR/d/5IQrKMy49yCLPEROVIBdaQXaUBDbQm3a14FHOMMbh9/+LWBzO
9Hj6Qoi5bTqzXNjDKZLyX1DsWJtlBWUw0kndi0jcmR+TEiZ2/9bCkUhhbL93rp8F
J00NhzBYuda8fmWt8lwRIMYnVu0LKF241MuPWqLew+TYT9weQGwj2DUPKqYxwVM=
=KvPg
-----END PGP SIGNATURE-----

--UorQWkkVTJNwMrb2qJ67TQhuh5W1I68Bq--


From nobody Thu Apr  2 13:35:29 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD291A1A83 for ; Thu,  2 Apr 2015 13:35:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level: 
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B332FNVIx99T for ; Thu,  2 Apr 2015 13:35:27 -0700 (PDT)
Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F41E91A1A7B for ; Thu,  2 Apr 2015 13:35:19 -0700 (PDT)
Received: by qcgx3 with SMTP id x3so76823100qcg.3 for ; Thu, 02 Apr 2015 13:35:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mrBVmlniGYyxDPmMEOKl2deRoQ5PBUO8K+pbKV8zvRs=; b=mNiGUDbopsLaObbTRgHYO2A5Dl1+/c5rc9cnoTcH6jwXDikcLbfcFe+3eky+p6hJeP OsWN4IA0r2WYZ54hnLNykKAymacYKQ+pXYTDXO3ObXqjROpk5Qeh67KMjRk3kmlI0MkS jvh+Y2utrPMI0BL7PRVU0W/8SOH8hplLY+xgtJqyTpcsZ9k5tXnrD0/8WErgarm5tX3e Ch1qVcKw7SIQVo9899tdHkGzw2mK090VhfBx8H3d+QaBQHWbl+DnTOMydZizxwS7O4y2 Qq76r6psjavL71iM6qk9HPnBIJpRf+IRLSnlwlNe3MJkoBlHN8Rt/INehLQ6uJcL9/DF r+eQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mrBVmlniGYyxDPmMEOKl2deRoQ5PBUO8K+pbKV8zvRs=; b=PL0tp+mEItg8IbYstG9pTo7ngyuOjNjHFanlL6WLQcPpIyAEFJLVwBiVbkk4ZcY8zq ZYraL2bRSi7pzYb4ZD/DRvKraKivoXjY0WHySjeLmvHqeTKpScH7dDGhj1Sht+OISkFG rjZdBWOa2cRLhTjGmn/v6Rr9b9o3fz4a9vW4lNaODk3ncSK6TQvAZkO3wLb+fefIZuEN LSusHsy9BrxJ29A1a10wslPyX4QOXpTQPvQPHURpaTmqlU7rsWWR/Kjbg5h89NQJlKsH /RHWxfH9KfBBDyQSfqZwKnXLGaqBB8jWRn1bYlSX9hPTC4dvW723uLr5SaJCr4bc8f5h Teww==
X-Gm-Message-State: ALoCoQkYWi3fpbFsCOSpBpAVpWSYgFubph5nOz+FNwdwlqiFvi2kFUEuIaD7eGHhHFeTu94IPu88
MIME-Version: 1.0
X-Received: by 10.55.22.23 with SMTP id g23mr1576017qkh.4.1428006919238; Thu, 02 Apr 2015 13:35:19 -0700 (PDT)
Received: by 10.229.178.135 with HTTP; Thu, 2 Apr 2015 13:35:19 -0700 (PDT)
In-Reply-To: 
References:  <551C0005.2000309@gmx.net>  <551C1970.4050600@cs.tcd.ie> <551C2568.3050301@gmx.net> 
Date: Thu, 2 Apr 2015 21:35:19 +0100
Message-ID: 
From: Ben Laurie 
To: Stephen Farrell 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org, The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] MTI ... Re: Security review of draft-ietf-oauth-dyn-reg-management-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Apr 2015 20:35:27 -0000

On 1 April 2015 at 18:36,   wrote:
>
>
> On Wed Apr 1 18:05:44 2015 GMT+0100, Hannes Tschofenig wrote:
>> Ben, Stephen,
>>
>> I believe that this would be a good idea although it does not really
>> solve the underlying problem. Why? If we put a reference to the UTA BCP
>> in there then we end up in the need to update our documents in the not
>> too distance future to point to a new UTA BCP that talks about TLS 1.3.
>
>
> No. Put in the bcp number and not the rfc number.

I'd love to believe that story, because that would be awesome.

But when I look at BCPs, I see, for example:

BCP49 Delegation of IP6.ARPA R. Bush [ August 2001 ] ( TXT = 5727
bytes)(Obsoleted by RFC3596) (Updates RFC2874, RFC2772, RFC2766,
RFC2553, RFC1886) (Also RFC3152) (Status: BEST CURRENT PRACTICE)

Obsoleted? Updates? Also?

What am I, as an implementer, supposed to do, if I'm told "follow BCP
49"? "Obsoleted" is particularly worrying.


From nobody Thu Apr  2 14:08:16 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982BD1A1BFF; Thu,  2 Apr 2015 14:08:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2iWQGFlRqLE; Thu,  2 Apr 2015 14:08:07 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137D51A1C00; Thu,  2 Apr 2015 14:07:59 -0700 (PDT)
X-AuditID: c6180641-f790b6d000004359-a6-551d4d4f0fb2
Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 0C.78.17241.F4D4D155; Thu,  2 Apr 2015 16:08:16 +0200 (CEST)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0210.002; Thu, 2 Apr 2015 17:07:57 -0400
From: Uma Chunduri 
To: "Adam W. Montville" 
Thread-Topic: Security review of draft-ietf-isis-extended-sequence-no-tlv-04
Thread-Index: AQHQbH/Zhsqwc8PAg0OvMaxLgCljg504XO/ggAF8m4CAAFtuAA==
Date: Thu, 2 Apr 2015 21:07:56 +0000
Message-ID: <1B502206DFA0C544B7A60469152008633F61F2BE@eusaamb105.ericsson.se>
References: <718D753F-E377-4197-9F01-C34C12EC5CA0@gmail.com> <1B502206DFA0C544B7A60469152008633F61E19F@eusaamb105.ericsson.se> <587CC58A-C9D6-4FCE-8BF0-80BC30CE5D2B@gmail.com>
In-Reply-To: <587CC58A-C9D6-4FCE-8BF0-80BC30CE5D2B@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.10]
Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F61F2BEeusaamb105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZXLonVjfAVzbUYN1mLostD9tYLPbdfMdu MePPRGaLDwsfsjiweOycdZfdY8mSn0weXy5/ZgtgjuKySUnNySxLLdK3S+DKOLH6GWPBlwam ijdd7A2MU34xdjFyckgImEgc/32bHcIWk7hwbz0biC0kcJRR4uJnsS5GLiB7GaNER28vWIJN QE/i49SfYA0iQM1fvj1jAiliFjjEKLHuSQdYQljAW+JTdxsbRJGPxOZJj4HiHEC2k0TvLxeQ MIuAisS2pgdMIDavgK/E3N/HmCGWbWaUWD1hGzNIglPAVuJ2/zdWEJsR6Lrvp9aANTALiEvc ejKfCeJqAYkle84zQ9iiEi8f/2OFsJUkJi09xwpRny/xYl87G8QyQYmTM5+wTGAUnYVk1Cwk ZbOQlM0COptZQFNi/S59iBJFiSndD9khbA2J1jlz2ZHFFzCyr2LkKC1OLctNNzLcxAiMumMS bI47GBd8sjzEKMDBqMTDm5AlEyrEmlhWXJl7iFGag0VJnLfsysEQIYH0xJLU7NTUgtSi+KLS nNTiQ4xMHJxSDYwHXVx3qW7YYP95/1qN29+PVR4MXajhz7SdQ3ldU1PBo0oWnd/zsj4FON7x WbubZ+PHy8l7aw6nnHuW18zTZv2KSVtPdWrlOSEPtffvw6fa3jE7VnbV7sDHc7ZPVl3U2mqe mrbEccterpLtV3YenzXNuiaHo0T75OXMw6G1ppeOMbuJBf37dVNGiaU4I9FQi7moOBEAFO1H 7psCAAA=
Archived-At: 
Cc: "draft-ietf-isis-extended-sequence-no-tlv.all@tools.ietf.org" , The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] Security review of draft-ietf-isis-extended-sequence-no-tlv-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Apr 2015 21:08:10 -0000

--_000_1B502206DFA0C544B7A60469152008633F61F2BEeusaamb105erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQWRhbSwNCg0KVGhhbmsgeW91LiBNeSBxdWljayByZXNwb25zZSBpbi1saW5lIFtVbWExXToN
Cg0KLS0NClVtYSBDLg0KDQpGcm9tOiBBZGFtIFcuIE1vbnR2aWxsZSBbbWFpbHRvOmFkYW0udy5t
b250dmlsbGVAZ21haWwuY29tXQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDAyLCAyMDE1IDQ6MjYg
QU0NClRvOiBVbWEgQ2h1bmR1cmkNCkNjOiBUaGUgSUVTRzsgc2VjZGlyQGlldGYub3JnOyBkcmFm
dC1pZXRmLWlzaXMtZXh0ZW5kZWQtc2VxdWVuY2Utbm8tdGx2LmFsbEB0b29scy5pZXRmLm9yZw0K
U3ViamVjdDogUmU6IFNlY3VyaXR5IHJldmlldyBvZiBkcmFmdC1pZXRmLWlzaXMtZXh0ZW5kZWQt
c2VxdWVuY2Utbm8tdGx2LTA0DQoNClRoYW5rcyBmb3IgeW91ciByZXNwb25zZS4gIEkgaGF2ZSBh
IGZldyBtb3JlIGNvbW1lbnRzIGlubGluZS4NCg0KDQpPbiBBcHIgMSwgMjAxNSwgYXQgNTowNyBQ
TSwgVW1hIENodW5kdXJpIDx1bWEuY2h1bmR1cmlAZXJpY3Nzb24uY29tPG1haWx0bzp1bWEuY2h1
bmR1cmlAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQoNCkhpIEFkYW0sDQoNClRoYW5rcyBmb3IgeW91
ciByZXZpZXcgYW5kIHN1Z2dlc3Rpb25zLg0KUGxlYXNlIHNlZSBteSByZXBsaWVzIGluLWxpbmUg
W1VtYV06DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBZGFtIFcuIE1vbnR2
aWxsZSBbbWFpbHRvOmFkYW0udy5tb250dmlsbGVAZ21haWwuY29tXQ0KU2VudDogV2VkbmVzZGF5
LCBBcHJpbCAwMSwgMjAxNSA2OjI5IEFNDQpUbzogVGhlIElFU0c7IHNlY2RpckBpZXRmLm9yZzxt
YWlsdG86c2VjZGlyQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1pc2lzLWV4dGVuZGVkLXNlcXVlbmNl
LW5vLXRsdi5hbGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtaXNpcy1leHRlbmRl
ZC1zZXF1ZW5jZS1uby10bHYuYWxsQHRvb2xzLmlldGYub3JnPg0KU3ViamVjdDogU2VjdXJpdHkg
cmV2aWV3IG9mIGRyYWZ0LWlldGYtaXNpcy1leHRlbmRlZC1zZXF1ZW5jZS1uby10bHYtMDQNCg0K
SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGly
ZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJl
aW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBw
cmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4N
Cg0KVGhpcyBkcmFmdCBpcyByZWFkeSB3aXRoIGlzc3Vlcy4NCg0KVGhlcmUgYXJlIHR3byBjaXJj
dW1zdGFuY2VzIHdpdGhpbiBJUy1JUyB0aGF0IGFyZSBzdWJqZWN0IHRvIHJlcGxheSBhdHRhY2tz
LiAgT25lIGNhbiBoYXBwZW4gd2hlbiBhZGphY2VuY2llcyBhcmUgYnJvdWdodCB1cCBhbmQgYW4g
SVMgc2VuZHMgYW4gSUlIIChoZWxsbykuICBUaGUgb3RoZXIgY2lyY3Vtc3RhbmNlIHBlcnRhaW5z
IHRvIHJlcGxheWluZyBDU05QLCB3aGljaCBtYXkgY2F1c2UgcmVwbGF5IG9mIFBTTlAgYW5kIHRo
dXMgY2F1c2UgTFNQIGZsb29kaW5nLg0KDQpUaGlzIGRyYWZ0IHByb3Bvc2VzIGEgc2VxdWVuY2Ug
dG8gbWl0aWdhdGUgcmVwbGF5IGF0dGFja3MgaW4gYm90aCBjaXJjdW1zdGFuY2VzLiAgVGhlIHN0
cnVjdHVyZSBvZiB0aGUgc2VxdWVuY2UgaXMgZGVmaW5lZCBhcyBhIG5ldyBUTFYgY2FsbGVkICJF
U04gVExWIi4gIEl0IGNvbnN0aXN0cyBvZiB0aGUgdGhyZWUgZmllbGRzLCBUeXBlLCBMZW5ndGgs
IGFuZCBWYWx1ZSwgd2hlcmUgVmFsdWUgaXMgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgdHdvIHNlcGFy
YXRlIGZpZWxkcy4gIFRoZXNlIHR3byBmaWVsZHMgYXJlIGtub3duIGFzIEV4dGVuZGVkIFNlc3Np
b24gU2VxdWVuY2UgTnVtYmVyIChFU1NOOyBhIDY0LWJpdCB2YWx1ZSwgd2hpY2ggaXMgbm9uLXpl
cm8gYW5kIHVuc2lnbmVkKSwgYW5kIFBhY2tldCBTZXF1ZW5jZSBOdW1iZXIgKFBTTjsgYSAzMi1i
aXQgdmFsdWUpLiAgQSBnaXZlbiBFU04gaXMgYXNzb2NpYXRlZCB3aXRoIGEgcGFydGljdWxhciBQ
cm90b2NvbCBEYXRhIFVuaXQgKFBEVSkuICBBIFBEVSwgdGhlcmVmb3JlLCAiaGFzIiBhbiBFU1NO
LCB3aGljaCBpcyBhc3NvY2lhdGVkIHdpdGggYSBtb25vdG9uaWNhbGx5IGluY3JlYXNpbmcgUFNO
LiAgSWYgdGhlIFBTTiB3cmFwcyBvciBpZiB0aGUgZGV2aWNlIG5lZWRzIHRvIGJlIHJlc3RhcnRl
ZCwgdGhlbiB0aGUgbmV4dCBFU1NOIG11c3QgYmUgbGFyZ2VyIHRoYW4gdGhlIHByZXZpb3VzIEVT
U04uDQoNClRoaXMgaXMgd2hlcmUgSSBzZWUgYSBwb3RlbnRpYWwgaXNzdWUsIGJ1dCBtYXliZSBJ
J20gbWlzc2luZyBhIGxpbWl0IG9mIHByYWN0aWNhbGl0eS4gIFdoYXQgaGFwcGVucyB3aGVuIHRo
ZSBFU1NOIGlzIGF0IDJeNjQtMSBhbmQgbmVlZHMgdG8gaW5jcmVtZW50PyAgR3JhbnRlZCB0aGF0
J3MgYSBsYXJnZSBudW1iZXIsIHNvIGl0IG1pZ2h0IGJlIHRoZSBjYXNlIHRoYXQgdW5kZXIgbm8g
cHJhY3RpY2FsIGNpcmN1bXN0YW5jZSB3b3VsZCB0aGUgRVNTTiBldmVyIGJlY29tZSB0aGF0IGxh
cmdlOyBidXQsIGlmIHRoYXQncyB0aGUgY2FzZSwgdGhlbiBpdCBtaWdodCBiZSBiZXN0IHRvIHN0
YXRlIHNvIGluIHRoZSBkcmFmdC4NCg0KW1VtYV06IEFzIHlvdSBzdGF0ZWQgdGhvdWdoIHRoaXMg
aXMgcG9zc2libGUgdGhlb3JldGljYWxseSwgaXQgaXMgYWxtb3N0IGltcHJhY3RpY2FsIGlmIHRo
ZSByaWdodCBtZXRob2Qgb2YgZW5jb2RpbmcgaXMgdXNlZC4gRm9yIGV2ZXJ5IFBEVSBvbmx5IDMy
LWJpdCBQU04gIGluY3JlYXNlcyBhbmQgb25seSB3aGVuIGl0IHdyYXBzIEVTU04gdmFsdWUgaXMg
aW5jcmVtZW50ZWQuIFRoZXJlIGFyZSB0d28gYXBwcm9hY2hlcyBzcGVjaWZpZWQgaW4gQXBwZW5k
aXggKG9ubHkgYXMgbWVyZSBndWlkZWxpbmVzKSBvZiB0aGlzIGRyYWZ0IHRvIGVuY29kZSBFU1NO
ICg2NC1iaXQpIHZhbHVlLiAgSWYgdGltZXN0YW1wcyBhcmUgdXNlZCAoQXBwZW5kaXggQS4xKSB0
byBlbmNvZGUgdGhpcyB2YWx1ZSBJIGRvbuKAmXQgc2VlIHRoZSBwb3NzaWJpbGl0eSBmb3IgdGhp
cyB0byBoYXBwZW4gYmVmb3JlIHRoZSBsaWZldGltZSBvZiB0aGUgcm91dGVyIHBlcmhhcHMuDQoN
Cg0KSXQgd291bGQgYmUgdXNlZnVsIHRvIGluY2x1ZGUgc3VjaCBpbmZvcm1hdGlvbiBpbiB0aGUg
ZHJhZnQsIGFzIGl0IG1heSBub3QgYmUgcmVhZGlseSBjbGVhciB0byByZWFkZXJzIHRoYXQgdGhl
IGF1dGhvcnMgZmVlbCB0aGUgNjQtYml0IHZhbHVlIGlzIOKAnGludHJhY3RhYmxl4oCdIGluIGEg
c2Vuc2UuDQoNCltVbWExXTogSSBzaGFsbCBhZGQgYSByZWZlcmVuY2UgdG8gQXBwZW5kaXggQS4y
IHBlcmhhcHMgYW5kIGNsYXJpZmljYXRpb24gdGV4dCBzdXJyb3VuZGluZyB0aGUgc2FtZS4NCg0K
SG93ZXZlciwgaW4gQXBwZW5kaXggQS4yLCBub24tdm9sYXRpbGUgc3RvcmFnZSAoUGFnZSA3KSAg
aXTigJlzIGNsZWFybHkgc3RhdGVkIHRoYXQg4oCTDQogICAg4oCcSWYgdGhlIG5vbi12b2xhdGls
ZQ0KICAgc3RvcmFnZSBpcyBldmVyIHJlcGFpcmVkIG9yIHVwZ3JhZGVkIHN1Y2ggdGhhdCB0aGUg
Y29udGVudHMgYXJlIGxvc3QsDQogICBrZXlzIE1VU1QgYmUgY2hhbmdlZCB0byBwcmV2ZW50IHJl
cGxheSBhdHRhY2tzLuKAnQ0KDQoNCg0KSW4gdGhlIEFwcGVuZGl4LCB0aGUgZHJhZnQgYWxzbyBn
b2VzIGludG8gaG93IHRpbWVzdGFtcHMgbWF5IGJlIGxldmVyYWdlZCAod2hpY2ggYXJlIHBvdGVu
dGlhbGx5IG1vcmUgZWZmZWN0aXZlIGF0IG1pdGlnYXRpbmcgcmVwbGF5IGF0dGFja3MgdGhhbiBh
cmUgc2VxdWVuY2VzKSwgYnV0IGRvZXMgbm90IGNsZWFybHkgaW5kaWNhdGUgaG93IG5laWdoYm9y
cyB3b3VsZCBuZWdvdGlhdGUgdGhlIHVzZSBvZiB0aW1lc3RhbXBzIG9yIGhvdyBleGFjdGx5IHRo
ZSB0aW1lc3RhbXBzIHdvdWxkIGJlIHVzZWQgb3Igd2hpY2ggZm9ybWF0IHRoZW4gbXVzdCBiZSB1
c2VkIChhIHN1Z2dlc3Rpb24gdG8gbG9vayBhdCBSRkM1OTA1IGlzIG1hZGUpLg0KDQpbVW1hXTog
QXBwZW5kaXggb25seSBwcm9wb3NlcyB0byB1c2UgdGltZXN0YW1wcyBhcyBhIHBvdGVudGlhbCBh
cHByb2FjaCB0byBlbmNvZGUgdGhlIEVTU04gZmllbGQgb2YgdGhlIFRMViB0byBnZXQgdGhlIGV2
ZXIgaW5jcmVhc2luZyBwcm9wZXJ0eSBpbiBhbGwgY2FzZXMuIFBsZWFzZSAgbm90ZSB0aGUgYXBw
cm9hY2ggZm9yIHJlcGxheSBhdHRhY2sgbWl0aWdhdGlvbiBoZXJlIGlzIEV4dGVuZGVkIFNlcXVl
bmNlIG51bWJlcnMgYXMgc3BlY2lmaWVkIGluIHRoZSBUTFYuIFRoZXJlIGNvdWxkIGJlIGFuZCBt
YXkgYmUgbW9yZSBtZWNoYW5pc21zIHRvIHNvbHZlIHRoZSBzYW1lIHByb2JsZW0gYXQgaGFuZCBi
dXQgdGhvc2UgYXJlIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gVGhlcmUgaXMg
Km5vIG5lZ290aWF0aW9uKiByZXF1aXJlZCB3aXRoIG5laWdoYm9yIG9uIGhvdyB0byBlbmNvZGUg
dGhpcyB2YWx1ZS4gVGhpcyBpcyBwdXJlbHkgYSBsb2NhbCBtYXR0ZXIgYXMgbG9uZyBhcyB0aGUg
4oCcZXZlciBpbmNyZWFzaW5n4oCdIHByb3BlcnR5IGlzIG1haW50YWluZWQsIHdoZW4gMzItYml0
IFBTTiBpcyBldmVyIHdyYXBwZWQvY29sZC1yZXN0YXJ0IGNhc2VzIGFzIGV4cGxhaW5lZCBpbiBz
ZWN0aW9uIDMuMS4NCg0KSXQgbWF5IGJlIHRoZSBjYXNlIHRoYXQgSSBoYXZlIGEgbGVzcy10aGFu
LWNvbXBsZXRlIHVuZGVyc3RhbmRpbmcgb2YgdGhlIHByb2JsZW0gZG9tYWluLiAgTXkgdW5kZXJz
dGFuZGluZyBpcyB0aGF0IG9uZSBvZiB0aGUgbWl0aWdhdGlvbiBjaXJjdW1zdGFuY2VzIHBlcnRh
aW5zIHRvIElTLUlTIEhlbGxvLCB3aGVyZSBuZWlnaGJvcnMgYXJlIGJlaW5nIGJyb3VnaHQgdXAg
YW5kIHNlbmRpbmcgSUlIIHRvIG90aGVycy4gIERvZXMgdGhpcyBub3QgbWFrZSBpdCBhIG5laWdo
Ym9yaG9vZCBwcm9ibGVtPw0KRXZlbiBpZiBhbGwgbmVpZ2hib3JzIHVuZGVyc3RhbmQgdGhlIOKA
nGV2ZXIgaW5jcmVhc2luZ+KAnSBwcm9wZXJ0eSwgaG93IHdvdWxkIHRoZXkgdW5kZXJzdGFuZCB3
aGljaCBlbmNvZGluZyBpcyBpbiBwbGFjZSB3aXRob3V0IHNvbWUgYWRkaXRpb25hbCBpbmZvcm1h
dGlvbj8NCltVbWExXTogVGhlcmUgaXMgbm8gbmVlZCB0byB1bmRlcnN0YW5kIHRoZSBlbmNvZGlu
ZyBieSBuZWlnaGJvciBhcyBsb25nIGFzIGl04oCZcyBwcm9wZXJ0eSBpcyBtYWludGFpbmVkIChh
cyByZWNlaXZlciB3b3VsZCB2ZXJpZnkgdGhlIHVuc2lnbmVkIGludGVnZXIgdmFsdWUpLg0KDQpJ
dCB3b3VsZCBwcm9iYWJseSBiZSBiZW5lZmljaWFsIHRvIHByb3ZpZGUgc29tZSBpbmRpY2F0aW9u
IGluIHRoZSBUTFYgYXMgdG8gaG93IEVTU04gaXMgZW5jb2RlZC4gIEFsdGVybmF0aXZlbHksIGlm
IHRoZXJlIGlzIGEgbWV0aG9kIHRvIGRlZHVjZSB0aGUgZXZlciBpbmNyZWFzaW5nIHByb3BlcnR5
IHdpdGhvdXQga25vd2luZyB0aGUgRVNTTiBlbmNvZGluZywgdGhhdCBzaG91bGQgYmUgZXhwbGFp
bmVkIChvciBhdCBsZWFzdCByZWZlcmVuY2VkLCBpZiBleHBsYWluZWQgZWxzZXdoZXJlKS4NCg0K
IFtVbWExXTogIEkgZmVsdCBpdOKAmXMgY2xlYXIgLSBJdOKAmXMgYW4gdW5zaWduZWQgaW50ZWdl
ciB2YWx1ZSBwZXIgY3VycmVudCB0ZXh0IGF0IHRoZSBlbmQgb2YgU2VjdGlvbiAzIChsYXN0IHBh
cmFncmFwaCkuIEkgc2hhbGwgd29yayB3aXRoIHlvdSB0byBmaW5hbGl6ZSBtb3JlIGNsYXJpZnlp
bmcgdGV4dCBhcm91bmQgdGhpcy4NCg0KDQo=

--_000_1B502206DFA0C544B7A60469152008633F61F2BEeusaamb105erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu
OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250
LWZhbWlseToiQ291cmllciBOZXciLCJzZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0
YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt
c2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFw
cGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUt
bmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t
c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z
ZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw
bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE
O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl
Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu
azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsInNlcmlm
Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250
LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN
CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw
YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh
W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9
ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv
dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PkhpIEFkYW0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UuIE15IHF1aWNrIHJlc3BvbnNlIGluLWxpbmUg
W1VtYTFdOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VW1hIEMu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0
REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQWRhbSBXLiBNb250dmlsbGUgW21haWx0bzphZGFtLncubW9u
dHZpbGxlQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMDIs
IDIwMTUgNDoyNiBBTTxicj4NCjxiPlRvOjwvYj4gVW1hIENodW5kdXJpPGJyPg0KPGI+Q2M6PC9i
PiBUaGUgSUVTRzsgc2VjZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLWlzaXMtZXh0ZW5kZWQtc2Vx
dWVuY2Utbm8tdGx2LmFsbEB0b29scy5pZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog
U2VjdXJpdHkgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaXNpcy1leHRlbmRlZC1zZXF1ZW5jZS1uby10
bHYtMDQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFu
a3MgZm9yIHlvdXIgcmVzcG9uc2UuICZuYnNwO0kgaGF2ZSBhIGZldyBtb3JlIGNvbW1lbnRzIGlu
bGluZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u
IEFwciAxLCAyMDE1LCBhdCA1OjA3IFBNLCBVbWEgQ2h1bmR1cmkgJmx0OzxhIGhyZWY9Im1haWx0
bzp1bWEuY2h1bmR1cmlAZXJpY3Nzb24uY29tIj51bWEuY2h1bmR1cmlAZXJpY3Nzb24uY29tPC9h
PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpIEFkYW0sPG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoYW5r
cyBmb3IgeW91ciByZXZpZXcgYW5kIHN1Z2dlc3Rpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+UGxlYXNlIHNlZSBteSByZXBsaWVzIGluLWxpbmUgW1VtYV06PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
NC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tPGJyPg0KRnJvbTogQWRhbSBXLiBNb250dmlsbGUgWzxhIGhyZWY9Im1haWx0bzphZGFt
LncubW9udHZpbGxlQGdtYWlsLmNvbSI+bWFpbHRvOmFkYW0udy5tb250dmlsbGVAZ21haWwuY29t
PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJy
Pg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwMSwgMjAxNSA2OjI5IEFNPGJyPg0KVG86IFRoZSBJ
RVNHOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBo
cmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8L2E+OzxzcGFuIGNs
YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86
ZHJhZnQtaWV0Zi1pc2lzLWV4dGVuZGVkLXNlcXVlbmNlLW5vLXRsdi5hbGxAdG9vbHMuaWV0Zi5v
cmciPmRyYWZ0LWlldGYtaXNpcy1leHRlbmRlZC1zZXF1ZW5jZS1uby10bHYuYWxsQHRvb2xzLmll
dGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFNlY3VyaXR5IHJldmlldyBvZiBkcmFmdC1pZXRmLWlz
aXMtZXh0ZW5kZWQtc2VxdWVuY2Utbm8tdGx2LTA0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRp
cmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBi
ZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuJm5ic3A7IFRoZXNlIGNvbW1lbnRzIHdlcmUgd3Jp
dHRlbg0KIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGly
ZWN0b3JzLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGlzIGRyYWZ0IGlzIHJlYWR5IHdp
dGggaXNzdWVzLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGVyZSBhcmUgdHdvIGNpcmN1
bXN0YW5jZXMgd2l0aGluIElTLUlTIHRoYXQgYXJlIHN1YmplY3QgdG8gcmVwbGF5IGF0dGFja3Mu
Jm5ic3A7IE9uZSBjYW4gaGFwcGVuIHdoZW4gYWRqYWNlbmNpZXMgYXJlIGJyb3VnaHQgdXAgYW5k
IGFuIElTIHNlbmRzIGFuIElJSCAoaGVsbG8pLiZuYnNwOyBUaGUgb3RoZXIgY2lyY3Vtc3RhbmNl
DQogcGVydGFpbnMgdG8gcmVwbGF5aW5nIENTTlAsIHdoaWNoIG1heSBjYXVzZSByZXBsYXkgb2Yg
UFNOUCBhbmQgdGh1cyBjYXVzZSBMU1AgZmxvb2RpbmcuJm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij5UaGlzIGRyYWZ0IHByb3Bvc2VzIGEgc2VxdWVuY2UgdG8gbWl0aWdhdGUgcmVwbGF5IGF0dGFj
a3MgaW4gYm90aCBjaXJjdW1zdGFuY2VzLiZuYnNwOyBUaGUgc3RydWN0dXJlIG9mIHRoZSBzZXF1
ZW5jZSBpcyBkZWZpbmVkIGFzIGEgbmV3IFRMViBjYWxsZWQgJnF1b3Q7RVNOIFRMViZxdW90Oy4m
bmJzcDsgSXQgY29uc3Rpc3RzIG9mDQogdGhlIHRocmVlIGZpZWxkcywgVHlwZSwgTGVuZ3RoLCBh
bmQgVmFsdWUsIHdoZXJlIFZhbHVlIGlzIHRvIGJlIGludGVycHJldGVkIGFzIHR3byBzZXBhcmF0
ZSBmaWVsZHMuJm5ic3A7IFRoZXNlIHR3byBmaWVsZHMgYXJlIGtub3duIGFzIEV4dGVuZGVkIFNl
c3Npb24gU2VxdWVuY2UgTnVtYmVyIChFU1NOOyBhIDY0LWJpdCB2YWx1ZSwgd2hpY2ggaXMgbm9u
LXplcm8gYW5kIHVuc2lnbmVkKSwgYW5kIFBhY2tldCBTZXF1ZW5jZSBOdW1iZXIgKFBTTjsgYSAz
Mi1iaXQNCiB2YWx1ZSkuJm5ic3A7IEEgZ2l2ZW4gRVNOIGlzIGFzc29jaWF0ZWQgd2l0aCBhIHBh
cnRpY3VsYXIgUHJvdG9jb2wgRGF0YSBVbml0IChQRFUpLiZuYnNwOyBBIFBEVSwgdGhlcmVmb3Jl
LCAmcXVvdDtoYXMmcXVvdDsgYW4gRVNTTiwgd2hpY2ggaXMgYXNzb2NpYXRlZCB3aXRoIGEgbW9u
b3RvbmljYWxseSBpbmNyZWFzaW5nIFBTTi4mbmJzcDsgSWYgdGhlIFBTTiB3cmFwcyBvciBpZiB0
aGUgZGV2aWNlIG5lZWRzIHRvIGJlIHJlc3RhcnRlZCwgdGhlbiB0aGUgbmV4dCBFU1NOIG11c3Qg
YmUgbGFyZ2VyDQogdGhhbiB0aGUgcHJldmlvdXMgRVNTTi48L3NwYW4+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+VGhpcyBpcyB3aGVyZSBJIHNlZSBhIHBvdGVudGlhbCBpc3N1ZSwgYnV0IG1heWJlIEkn
bSBtaXNzaW5nIGEgbGltaXQgb2YgcHJhY3RpY2FsaXR5LiZuYnNwOyBXaGF0IGhhcHBlbnMgd2hl
biB0aGUgRVNTTiBpcyBhdCAyXjY0LTEgYW5kIG5lZWRzIHRvIGluY3JlbWVudD8mbmJzcDsgR3Jh
bnRlZCB0aGF0J3MgYSBsYXJnZQ0KIG51bWJlciwgc28gaXQgbWlnaHQgYmUgdGhlIGNhc2UgdGhh
dCB1bmRlciBubyBwcmFjdGljYWwgY2lyY3Vtc3RhbmNlIHdvdWxkIHRoZSBFU1NOIGV2ZXIgYmVj
b21lIHRoYXQgbGFyZ2U7IGJ1dCwgaWYgdGhhdCdzIHRoZSBjYXNlLCB0aGVuIGl0IG1pZ2h0IGJl
IGJlc3QgdG8gc3RhdGUgc28gaW4gdGhlIGRyYWZ0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij5bVW1hXTogQXMgeW91IHN0YXRlZCB0aG91Z2ggdGhpcyBpcyBwb3NzaWJsZSB0aGVvcmV0aWNh
bGx5LCBpdCBpcyBhbG1vc3QgaW1wcmFjdGljYWwgaWYgdGhlIHJpZ2h0IG1ldGhvZCBvZiBlbmNv
ZGluZyBpcyB1c2VkLiBGb3IgZXZlcnkgUERVIG9ubHkgMzItYml0IFBTTiZuYnNwOyBpbmNyZWFz
ZXMgYW5kDQogb25seSB3aGVuIGl0IHdyYXBzIEVTU04gdmFsdWUgaXMgaW5jcmVtZW50ZWQuIFRo
ZXJlIGFyZSB0d28gYXBwcm9hY2hlcyBzcGVjaWZpZWQgaW4gQXBwZW5kaXggKG9ubHkgYXMgbWVy
ZSBndWlkZWxpbmVzKSBvZiB0aGlzIGRyYWZ0IHRvIGVuY29kZSBFU1NOICg2NC1iaXQpIHZhbHVl
LiZuYnNwOyBJZiB0aW1lc3RhbXBzIGFyZSB1c2VkIChBcHBlbmRpeCBBLjEpIHRvIGVuY29kZSB0
aGlzIHZhbHVlIEkgZG9u4oCZdCBzZWUgdGhlIHBvc3NpYmlsaXR5IGZvcg0KIHRoaXMgdG8gaGFw
cGVuIGJlZm9yZSB0aGUgbGlmZXRpbWUgb2YgdGhlIHJvdXRlciBwZXJoYXBzLiZuYnNwOyA8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3b3VsZCBiZSB1c2VmdWwgdG8gaW5jbHVkZSBz
dWNoIGluZm9ybWF0aW9uIGluIHRoZSBkcmFmdCwgYXMgaXQgbWF5IG5vdCBiZSByZWFkaWx5IGNs
ZWFyIHRvIHJlYWRlcnMgdGhhdCB0aGUgYXV0aG9ycyBmZWVsIHRoZSA2NC1iaXQgdmFsdWUgaXMg
4oCcaW50cmFjdGFibGXigJ0gaW4gYSBzZW5zZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W1VtYTFdOiBJ
IHNoYWxsIGFkZCBhIHJlZmVyZW5jZSB0byBBcHBlbmRpeCBBLjIgcGVyaGFwcyBhbmQgY2xhcmlm
aWNhdGlvbiB0ZXh0IHN1cnJvdW5kaW5nIHRoZSBzYW1lLjwvc3Bhbj48YnI+DQo8YnI+DQo8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ib3dldmVyLCBpbiBBcHBlbmRpeCBBLjIsIG5vbi12b2xhdGls
ZSBzdG9yYWdlIChQYWdlIDcpJm5ic3A7IGl04oCZcyBjbGVhcmx5IHN0YXRlZCB0aGF0IOKAkzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsg4oCcPC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtz
ZXJpZiZxdW90OyI+SWYgdGhlIG5vbi12b2xhdGlsZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7IHN0b3JhZ2UgaXMgZXZlciByZXBh
aXJlZCBvciB1cGdyYWRlZCBzdWNoIHRoYXQgdGhlIGNvbnRlbnRzIGFyZSBsb3N0LDwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7IGtl
eXMgTVVTVCBiZSBjaGFuZ2VkIHRvIHByZXZlbnQgcmVwbGF5IGF0dGFja3Mu4oCdPC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JbiB0
aGUgQXBwZW5kaXgsIHRoZSBkcmFmdCBhbHNvIGdvZXMgaW50byBob3cgdGltZXN0YW1wcyBtYXkg
YmUgbGV2ZXJhZ2VkICh3aGljaCBhcmUgcG90ZW50aWFsbHkgbW9yZSBlZmZlY3RpdmUgYXQgbWl0
aWdhdGluZyByZXBsYXkgYXR0YWNrcyB0aGFuIGFyZSBzZXF1ZW5jZXMpLCBidXQgZG9lcw0KIG5v
dCBjbGVhcmx5IGluZGljYXRlIGhvdyBuZWlnaGJvcnMgd291bGQgbmVnb3RpYXRlIHRoZSB1c2Ug
b2YgdGltZXN0YW1wcyBvciBob3cgZXhhY3RseSB0aGUgdGltZXN0YW1wcyB3b3VsZCBiZSB1c2Vk
IG9yIHdoaWNoIGZvcm1hdCB0aGVuIG11c3QgYmUgdXNlZCAoYSBzdWdnZXN0aW9uIHRvIGxvb2sg
YXQgUkZDNTkwNSBpcyBtYWRlKS4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw
YWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPltVbWFdOiBBcHBl
bmRpeCBvbmx5IHByb3Bvc2VzIHRvIHVzZSB0aW1lc3RhbXBzIGFzIGEgcG90ZW50aWFsIGFwcHJv
YWNoIHRvIGVuY29kZSB0aGUgRVNTTiBmaWVsZCBvZiB0aGUgVExWIHRvIGdldCB0aGUgZXZlciBp
bmNyZWFzaW5nIHByb3BlcnR5IGluIGFsbCBjYXNlcy4gUGxlYXNlJm5ic3A7IG5vdGUNCiB0aGUg
YXBwcm9hY2ggZm9yIHJlcGxheSBhdHRhY2sgbWl0aWdhdGlvbiBoZXJlIGlzIEV4dGVuZGVkIFNl
cXVlbmNlIG51bWJlcnMgYXMgc3BlY2lmaWVkIGluIHRoZSBUTFYuIFRoZXJlIGNvdWxkIGJlIGFu
ZCBtYXkgYmUgbW9yZSBtZWNoYW5pc21zIHRvIHNvbHZlIHRoZSBzYW1lIHByb2JsZW0gYXQgaGFu
ZCBidXQgdGhvc2UgYXJlIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gVGhlcmUg
aXMgKjxiPm5vIG5lZ290aWF0aW9uPC9iPioNCiByZXF1aXJlZCB3aXRoIG5laWdoYm9yIG9uIGhv
dyB0byBlbmNvZGUgdGhpcyB2YWx1ZS4gVGhpcyBpcyBwdXJlbHkgYSBsb2NhbCBtYXR0ZXIgYXMg
bG9uZyBhcyB0aGUg4oCcZXZlciBpbmNyZWFzaW5n4oCdIHByb3BlcnR5IGlzIG1haW50YWluZWQs
IHdoZW4gMzItYml0IFBTTiBpcyBldmVyIHdyYXBwZWQvY29sZC1yZXN0YXJ0IGNhc2VzIGFzIGV4
cGxhaW5lZCBpbiBzZWN0aW9uIDMuMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgbWF5IGJlIHRoZSBjYXNlIHRo
YXQgSSBoYXZlIGEgbGVzcy10aGFuLWNvbXBsZXRlIHVuZGVyc3RhbmRpbmcgb2YgdGhlIHByb2Js
ZW0gZG9tYWluLiAmbmJzcDtNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgb25lIG9mIHRoZSBtaXRp
Z2F0aW9uIGNpcmN1bXN0YW5jZXMgcGVydGFpbnMgdG8gSVMtSVMgSGVsbG8sIHdoZXJlIG5laWdo
Ym9ycyBhcmUgYmVpbmcgYnJvdWdodCB1cCBhbmQgc2VuZGluZyBJSUggdG8gb3RoZXJzLg0KICZu
YnNwO0RvZXMgdGhpcyBub3QgbWFrZSBpdCBhIG5laWdoYm9yaG9vZCBwcm9ibGVtPyAmbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV2ZW4g
aWYgYWxsIG5laWdoYm9ycyB1bmRlcnN0YW5kIHRoZSDigJxldmVyIGluY3JlYXNpbmfigJ0gcHJv
cGVydHksIGhvdyB3b3VsZCB0aGV5IHVuZGVyc3RhbmQgd2hpY2ggZW5jb2RpbmcgaXMgaW4gcGxh
Y2Ugd2l0aG91dCBzb21lIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24/ICZuYnNwOzxzcGFuIHN0eWxl
PSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1VtYTFdOiBU
aGVyZSBpcyBubyBuZWVkIHRvIHVuZGVyc3RhbmQgdGhlIGVuY29kaW5nIGJ5IG5laWdoYm9yIGFz
IGxvbmcgYXMgaXTigJlzIHByb3BlcnR5IGlzIG1haW50YWluZWQgKGFzIHJlY2VpdmVyIHdvdWxk
IHZlcmlmeSB0aGUgdW5zaWduZWQgaW50ZWdlciB2YWx1ZSkuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkl0IHdvdWxkIHByb2JhYmx5IGJlIGJlbmVmaWNpYWwgdG8gcHJvdmlkZSBzb21lIGluZGlj
YXRpb24gaW4gdGhlIFRMViBhcyB0byBob3cgRVNTTiBpcyBlbmNvZGVkLiAmbmJzcDtBbHRlcm5h
dGl2ZWx5LCBpZiB0aGVyZSBpcyBhIG1ldGhvZCB0byBkZWR1Y2UgdGhlIGV2ZXIgaW5jcmVhc2lu
ZyBwcm9wZXJ0eSB3aXRob3V0IGtub3dpbmcgdGhlIEVTU04gZW5jb2RpbmcsIHRoYXQgc2hvdWxk
IGJlIGV4cGxhaW5lZCAob3INCiBhdCBsZWFzdCByZWZlcmVuY2VkLCBpZiBleHBsYWluZWQgZWxz
ZXdoZXJlKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9InBhZ2Ut
YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPiBbVW1hMV06ICZuYnNwO0kgZmVsdCBpdOKAmXMgY2xlYXIgLSBJdOKAmXMgYW4gdW5z
aWduZWQgaW50ZWdlciB2YWx1ZSBwZXIgY3VycmVudCB0ZXh0IGF0IHRoZSBlbmQgb2YgU2VjdGlv
biAzIChsYXN0IHBhcmFncmFwaCkuIEkgc2hhbGwgd29yayB3aXRoIHlvdSB0byBmaW5hbGl6ZSBt
b3JlIGNsYXJpZnlpbmcgdGV4dCBhcm91bmQgdGhpcy48L3NwYW4+PGJyPjxicj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_1B502206DFA0C544B7A60469152008633F61F2BEeusaamb105erics_--


From nobody Fri Apr  3 03:05:38 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548C61A7022; Fri,  3 Apr 2015 03:05:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zt-uCyeX979H; Fri,  3 Apr 2015 03:05:36 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C771A86E8; Fri,  3 Apr 2015 03:05:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 230EFBEEB; Fri,  3 Apr 2015 11:05:33 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqeEyD8_yY6e; Fri,  3 Apr 2015 11:05:30 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B42E1BEEA; Fri,  3 Apr 2015 11:05:30 +0100 (IST)
Message-ID: <551E65EA.3030404@cs.tcd.ie>
Date: Fri, 03 Apr 2015 11:05:30 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Ben Laurie 
References:  <551C0005.2000309@gmx.net>  <551C1970.4050600@cs.tcd.ie> <551C2568.3050301@gmx.net>  
In-Reply-To: 
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org, The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] MTI ... Re: Security review of draft-ietf-oauth-dyn-reg-management-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Apr 2015 10:05:37 -0000

On 02/04/15 21:35, Ben Laurie wrote:
> On 1 April 2015 at 18:36,   wrote:
>>
>>
>> On Wed Apr 1 18:05:44 2015 GMT+0100, Hannes Tschofenig wrote:
>>> Ben, Stephen,
>>>
>>> I believe that this would be a good idea although it does not really
>>> solve the underlying problem. Why? If we put a reference to the UTA BCP
>>> in there then we end up in the need to update our documents in the not
>>> too distance future to point to a new UTA BCP that talks about TLS 1.3.
>>
>>
>> No. Put in the bcp number and not the rfc number.
> 
> I'd love to believe that story, because that would be awesome.
> 
> But when I look at BCPs, I see, for example:
> 
> BCP49 Delegation of IP6.ARPA R. Bush [ August 2001 ] ( TXT = 5727
> bytes)(Obsoleted by RFC3596) (Updates RFC2874, RFC2772, RFC2766,
> RFC2553, RFC1886) (Also RFC3152) (Status: BEST CURRENT PRACTICE)
> 
> Obsoleted? Updates? Also?
> 
> What am I, as an implementer, supposed to do, if I'm told "follow BCP
> 49"? "Obsoleted" is particularly worrying.

In this particular case, it's a reference to [1] we'd be adding
and that, I believe, is clear for a developer and there is really
no immediate liklihood that we obsolete the TLS protocol. We
don't need to solve the general problem of relationships between
RFCs.

S.

[1] https://tools.ietf.org/html/draft-ietf-uta-tls-bcp


> 


From nobody Fri Apr  3 07:10:02 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59AE1AC39A; Fri,  3 Apr 2015 07:09:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrOMyNBLLb9e; Fri,  3 Apr 2015 07:09:57 -0700 (PDT)
Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::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 4022F1A92FD; Fri,  3 Apr 2015 07:09:57 -0700 (PDT)
Received: by qcbii10 with SMTP id ii10so67136803qcb.2; Fri, 03 Apr 2015 07:09:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rBe9bnoBqxRfgpIlxpWWNKTOnq35zTA5GyEw37ggABE=; b=DbeOVGH4onA862m9IVaEeQa2jfVoPt89B/h7zsXCTzYrSrDEqPgiM8VdPdWyrfE0wk 8l7x9oQmesks0Z5VIuPisgqA1DtyG9SLVpJz+vurQYRgicuwjbvolcNj4i+cNqPq4woL rdQO4L6lG8o2Aj0QPMHaPlYnFTL1/mpyrzqf/mkJfdFCXsenOT3fNUdhAU8c72YwDV9i 4MU6ns5awnirKiLH0WuVVM2fF8QW9jTd6ueX9yczlTIsf5EPhC4KOQ7xVoYkJm9v+GOx TT7HWD7ad73VlS9iJ/MHbqIjjmNLvQmACiu3z+o0Nfu8LGGJ106X3601nuIRP4Nehr5A fO8Q==
X-Received: by 10.55.51.77 with SMTP id z74mr4609890qkz.84.1428070196542; Fri, 03 Apr 2015 07:09:56 -0700 (PDT)
Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id h34sm5693887qkh.34.2015.04.03.07.09.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Apr 2015 07:09:55 -0700 (PDT)
From: Kathleen Moriarty 
X-Google-Original-From: Kathleen Moriarty 
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (11D257)
In-Reply-To: 
Date: Fri, 3 Apr 2015 10:09:54 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F8705AC-7C49-49F5-8E8F-DBD65AAB5470@gmail.com>
References:  <551C0005.2000309@gmx.net>  <551C1970.4050600@cs.tcd.ie> <551C2568.3050301@gmx.net>  
To: Ben Laurie 
Archived-At: 
Cc: "secdir@ietf.org" , The IESG , "draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org" 
Subject: Re: [secdir] MTI ... Re: Security review of draft-ietf-oauth-dyn-reg-management-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Apr 2015 14:09:59 -0000

Sorry, I was at a conference yesterday and not able to respond.

Sent from my iPhone

> On Apr 2, 2015, at 1:15 PM, Ben Laurie  wrote:
>=20
> On 1 April 2015 at 18:18, Kathleen Moriarty
>  wrote:
>> I agree with Hannes here.  Having MTI for TLS 1.2 is fine for right now, i=
t
>> must be supported, but doesn't mean other versions can't be supported onc=
e
>> libraries are available and it makes sense.  We can't hold this up becaus=
e
>> TLS 1.3 is coming soon and would prefer that folks know they should be
>> implementing at least TLS 1.2.  A reference to the TLS BCP with this is f=
ine
>> as well.  But this is one of the many OAuth drafts and not really the pla=
ce
>> to call out specific requirements, like which of the recommended cipher
>> suites int eh BCP should be implemented for Oauth (I don't think that has=

>> been done as it has for other protocols), but is not the right place to d=
o
>> too much.
>=20
> Call it out wherever you want. _My_ job is to review this particular
> I-D, and this is an issue with this particular I-D. I don't see how
> the fact it is also an issue with many other I-Ds fixes that problem.

Yes and your review is very much appreciated.  We need to discuss the review=
 to figure out what changes and doesn't in a draft.  Ideally, all of the sec=
urity needs would have been clear in a foundational document, but as Hannes p=
ointed out, requirements evolved as OAuth developed.

At this point in time, TLS 1.2 is the base requirement, which is appropriate=
.  As is a reference to the BCP that explains security for that version.  Wh=
en support for 1.3 makes that feasible, an 'updates' draft can fix that.  If=
 the BCP for 1.3 updates the current one for 1.2 (maybe there will be enough=
 of a difference to make a new #), then the BCP number will already be in th=
is draft.  We can't predict the future, but we can go off of what we know no=
w and just move into the other questions raised in this review.

Thank you,
Kathleen=


From nobody Fri Apr  3 10:12:03 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97CC1ACDD4 for ; Fri,  3 Apr 2015 10:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level: 
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 111uStiOkOUr for ; Fri,  3 Apr 2015 10:11:59 -0700 (PDT)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BAD61ACDD9 for ; Fri,  3 Apr 2015 10:11:55 -0700 (PDT)
Received: by qgfi89 with SMTP id i89so13821063qgf.1 for ; Fri, 03 Apr 2015 10:11:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IliLy1MPAyklnTRhcqgfQ86UAk1dfjb+HbhSXfYGhH8=; b=QV9zX1JxG+1/s43Us5hXLlBUDAT51J2pvZVw9oOqJ/lEqWBNfxt1oVuB2Z0B1elU6z WMgPN3Cnx8t+gq+3dI5bpEW6MxwG+ExL7zequ8mOffdRIHZlNxx6zaCjycTvVbPaiF/L SqILnsJCdUcMP5vsdmolxPWnqdur9YrKEtsPNcgB6/kTTRU5Pv2IJe9K0FYDlxYk7yV6 ISvcNKifycO4vJqvAYcDVAQQ8PFQpOUWaqo2M0aVWWToU2bsA/slMUxyRSB6ekis0lH2 YTvjUN7FbL+9tCyhafDwz2XJXVA5dQQZNzEVkjc4rGbRGRTFehm8FCeGgPx2z0aL6qNG PfVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IliLy1MPAyklnTRhcqgfQ86UAk1dfjb+HbhSXfYGhH8=; b=LDPCDAHk0WczhKMGtFrAUSzbU3AJM64LdxiSAOEGZ0KJlIucdjMgGYjybjleuAB3dI QaxH2DUwBHOdZ2a9OavMVVNoFkVEmLRu1+b321e+Zhwjh1zeisXWmiZJx5vBAf0w/3B5 ciFeJ+V57+TFay97YoQ+3IrXwyGJwxOIj3hDBT/+cldOcF7fEvCCeKp5eThJzQnoF1Fg kvrmzlPZnXIWbcsBdHiHUUgRLZmhKGPIJJgdps1SxxIm0/+viU6yBn86xCkH09clBUsl p1OTV5zjCupGVs/sE4v+SXx+3InLL/wRpfXcdaOCnQRn9vA27Nh63/VvW5FmvQM+gHpD TGqw==
X-Gm-Message-State: ALoCoQnMXJXqwIry4eqDSgtcyiSVMihSSmpLiS+zEkugUT0/4RfFuIbI/2U8QkLtmuCM+fhSqpuR
MIME-Version: 1.0
X-Received: by 10.141.18.146 with SMTP id u140mr3822751qhd.48.1428081114744; Fri, 03 Apr 2015 10:11:54 -0700 (PDT)
Received: by 10.229.178.135 with HTTP; Fri, 3 Apr 2015 10:11:54 -0700 (PDT)
In-Reply-To: <118C77E9-FAD2-48C1-A6E1-4D20D219449F@mit.edu>
References:  <118C77E9-FAD2-48C1-A6E1-4D20D219449F@mit.edu>
Date: Fri, 3 Apr 2015 18:11:54 +0100
Message-ID: 
From: Ben Laurie 
To: Justin Richer 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org, The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] Security review of draft-ietf-oauth-dyn-reg-management-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Apr 2015 17:12:00 -0000

On 3 April 2015 at 17:57, Justin Richer  wrote:
> Ben, thanks for the review. Responses to particular points inline.
>
>> On Apr 1, 2015, at 8:29 AM, Ben Laurie  wrote:
>> Issue: "Configuration Endpoint" (not a security issue)
>>
>> It looks like the definition of this is deferred to
>> draft-ietf-oauth-dyn-reg, but I couldn't find it there either.
>
> I=E2=80=99m confused by this issue: =E2=80=9CClient Configuration Endpoin=
t=E2=80=9D is defined as a term in =C2=A71.2 and its function and use are d=
efined in =C2=A72, which is the majority of the spec=E2=80=99s content. I s=
ee no use of =E2=80=9Cconfiguration endpoint=E2=80=9D apart from the full t=
erm of =E2=80=9Cclient configuration endpoint=E2=80=9D in the current docum=
ent version.

Sorry about that, I think I just got lost. You appear to be correct.

>> Issue: " Since the client configuration endpoint is an OAuth 2.0 protect=
ed
>>   resource, it SHOULD have some rate limiting on failures to prevent
>>   the registration access token from being disclosed though repeated
>>   access attempts."
>>
>> I am not sure what this is getting at. Limits on key re-use? Some kind
>> of BEAST defence? Something else?
>>
>> Without some quantification of the threat, it seems hard to act on
>> this requirement.
>
> The rate limiting is going to take a number of different forms depending =
on the platform and deployment characteristics of the authorization server,=
 so we don=E2=80=99t recommend any particular approach. This is also someth=
ing that=E2=80=99s going to be changing quickly over the years, and instead=
 of prescribing a specific solution we thought it better to describe the pr=
oblem here and say that it must be mitigated.

Solution to what? This is precisely my issue - you haven't described
the problem, you've described a solution to some problem I'm finding
hard to guess.

In other words: how could the registration access token be disclosed
through repeated access attempts?


From nobody Fri Apr  3 10:26:28 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123521ACE39 for ; Fri,  3 Apr 2015 10:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level: 
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfo0lHs7V1n9 for ; Fri,  3 Apr 2015 10:26:21 -0700 (PDT)
Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C711ACE37 for ; Fri,  3 Apr 2015 10:26:20 -0700 (PDT)
Received: by qcay5 with SMTP id y5so92760747qca.1 for ; Fri, 03 Apr 2015 10:26:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Y7Kb7CAYEGkhV9B6WOwo7snEt3GNaaHJcffemTzM+Jw=; b=OF0ChbmbOv7HWRaYwrB0HMSzt8L9A1g1g1GAcqKl7cmgSQKK27gz0THtva4Q0KSmlG +Bfp+btykJgNF5CDmQgzxxJ2ja7SG7/6CfBrNKc5XHIC9iMn64cfy8iC/4HEujWYYf4t w5uY3tNWeJjOULD4nD9OwukjPDld6KjnZgbHp3rSTJL6P8iAO1vtTzalh8Acqz8bP95V xlR6g+gi+04Uy13MvMug4Z6+wcVnxhQdp56VOwZAEwa9ICgVuKulo6LdLBLynS7aF5G+ 62w3Lcf0DyBVpGIhLyTzyZjBoowHI04wTeRf/MDCEH7SE2aR+Yc0D3xSYkNeIJrYTeDp Maiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Y7Kb7CAYEGkhV9B6WOwo7snEt3GNaaHJcffemTzM+Jw=; b=AhXfPLIyntLWde4QfUJCkkOIscy/jVpsaTWYLoYVTDuMpYSwa+Sx/9fqPrAgmnOBar eMVbDyd7chrgWG9jPk0XzCtJS47QyW6aEB4s3tgalRvMWtueYz1ITnB80HnKzdEd1IIh CrOQTLWBOaKcMEnFaeaZ8sIWItiOp43gXWx+Hm5A2jQpPdzIwPAmntuaXO789FepNXUa 4gTdL8zcJ+vK+rDnbYJsF2QVuteJYoJPd/VNRLWm6a9WYFGCDnyUDCLmAeppPA3VzHQR aBgAcY00ZlY609ZG/Pws+uvZHosLwCF7iIJre5r91D1tmxviP8EbQszyeuowdrlPtGhf TF3Q==
X-Gm-Message-State: ALoCoQkrWRa0Msl2yzWFogZ+TEtZ2BPBW0FdCLHdMoixhplzQ0UC60aQuNiQHQNSLdckXpW1D74G
MIME-Version: 1.0
X-Received: by 10.140.217.16 with SMTP id n16mr4047174qhb.82.1428081980217; Fri, 03 Apr 2015 10:26:20 -0700 (PDT)
Received: by 10.229.178.135 with HTTP; Fri, 3 Apr 2015 10:26:20 -0700 (PDT)
In-Reply-To: <951E5D91-BC5D-48CC-8B9C-D88804FB5B87@mit.edu>
References:  <118C77E9-FAD2-48C1-A6E1-4D20D219449F@mit.edu>  <951E5D91-BC5D-48CC-8B9C-D88804FB5B87@mit.edu>
Date: Fri, 3 Apr 2015 18:26:20 +0100
Message-ID: 
From: Ben Laurie 
To: Justin Richer 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org, The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] Security review of draft-ietf-oauth-dyn-reg-management-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Apr 2015 17:26:22 -0000

On 3 April 2015 at 18:22, Justin Richer  wrote:
>>
>>>> Issue: " Since the client configuration endpoint is an OAuth 2.0 prote=
cted
>>>>  resource, it SHOULD have some rate limiting on failures to prevent
>>>>  the registration access token from being disclosed though repeated
>>>>  access attempts."
>>>>
>>>> I am not sure what this is getting at. Limits on key re-use? Some kind
>>>> of BEAST defence? Something else?
>>>>
>>>> Without some quantification of the threat, it seems hard to act on
>>>> this requirement.
>>>
>>> The rate limiting is going to take a number of different forms dependin=
g on the platform and deployment characteristics of the authorization serve=
r, so we don=E2=80=99t recommend any particular approach. This is also some=
thing that=E2=80=99s going to be changing quickly over the years, and inste=
ad of prescribing a specific solution we thought it better to describe the =
problem here and say that it must be mitigated.
>>
>> Solution to what? This is precisely my issue - you haven't described
>> the problem, you've described a solution to some problem I'm finding
>> hard to guess.
>>
>> In other words: how could the registration access token be disclosed
>> through repeated access attempts?
>
> An attacker could keep poking at a client configuration endpoint with ran=
dom self-generated tokens until it finds one that works. There=E2=80=99s no=
 oracle attack or other portion that lets the attacker know they=E2=80=99re=
 getting closer to a good token, just a basic repeated hammering of a prote=
cted resource This problem is mitigated by having a sufficiently random tok=
en (as recommended in RFC6750 and RFC6819) as well as rate-limiting the con=
nections to the endpoint (also suggested by RFC6819). This is fairly common=
 advice for any endpoint protected by a secret (in this case, an OAuth toke=
n). Is there a better way to state this so that it=E2=80=99s more clear to =
developers what they should look out for?

How about making it a non-problem by requiring sufficiently strong
tokens that there is no possibility of brute force?

Mildly astonished that this attack is even considered feasible.


From nobody Fri Apr  3 11:10:14 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBDE1ACD96; Fri,  3 Apr 2015 09:57:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0wgaArHc38f; Fri,  3 Apr 2015 09:57:35 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6921ACD93; Fri,  3 Apr 2015 09:57:33 -0700 (PDT)
X-AuditID: 1209190d-f79676d000000da0-ca-551ec67cb6e6
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 9C.35.03488.C76CE155; Fri,  3 Apr 2015 12:57:32 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t33GvViT015669; Fri, 3 Apr 2015 12:57:32 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t33GvTED007163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Apr 2015 12:57:30 -0400
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_4D063B0C-4C82-498E-8D78-F2A3092CF7B4"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.5b6
From: Justin Richer 
In-Reply-To: 
Date: Fri, 3 Apr 2015 12:57:28 -0400
Message-Id: <118C77E9-FAD2-48C1-A6E1-4D20D219449F@mit.edu>
References: 
To: Ben Laurie 
X-Mailer: Apple Mail (2.2070.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrAKsWRmVeSWpSXmKPExsUixG6nrltzTC7UYNlkNYsNn6+xWZzr62K2 mPFnIrPFh4UPWRxYPBZsKvVYsuQnk8eXy5/ZApijuGxSUnMyy1KL9O0SuDKunbnDVrDNsOLn /mUsDYzXNLoYOTkkBEwkdhxawA5hi0lcuLeeDcQWEljMJHHmKWcXIxeQvYFR4nj3bmYI5wGT RNPVv6wgVcICbhIbW5aBdfMKGEjMPfWFCaSIWWAKo8T/NY/YIMZKSTS9PsYIYrMJqErMX3mL CcTmFAiU6L+6C8xmEVCRODRjMhtEcxOjxOzFVxghplpJnH/YzgJxU4DE2UtnwWwRAQWJq/96 gGwOoAXyEj2b0icwCs5CcscsZHeAJJgFtCWWLXzNDGFrSuzvXs4CYctLbH87BypuKbF45g2o uK3Erb4FTBC2ncSjaYtYFzByrGKUTcmt0s1NzMwpTk3WLU5OzMtLLdI10svNLNFLTSndxAiK LE5J3h2M7w4qHWIU4GBU4uF9ECgXKsSaWFZcmXuIUZKDSUmUd8kRoBBfUn5KZUZicUZ8UWlO avEhRhWgXY82rL7AKMWSl5+XqiTCy3wYqI43JbGyKrUoH6ZMmoNFSZx30w++ECGB9MSS1OzU 1ILUIpisDAeHkgTvUZAFgkWp6akVaZk5JQhpJg7OQ4wSHDxAw7+A1PAWFyTmFmemQ+RPMSpK ifO+B0kIgCQySvPgemEJ8RWjONBbwrzMR4GqeIDJFK77FdBgJqDBDvOkQQaXJCKkpBoY/exj d2gzCMQZZDo/+6pSbMi8PjDRX+acdGPMj0//53zMvG5idCLyy6WXZgvilIylvs9MfX1acee0 x8oX3x4z2Zhg6zw9vSuZpbQ/+XjbB+OTZ8J2H5ZlVLpttePV/p5Zuk7P55/cNcmEM9hOWd7X bHJP8ekz1z8FXdljoSu/bFkFs9fKwnXLlViKMxINtZiLihMB9cx/VWMDAAA=
Archived-At: 
X-Mailman-Approved-At: Fri, 03 Apr 2015 11:10:13 -0700
Cc: draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org, The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] Security review of draft-ietf-oauth-dyn-reg-management-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Apr 2015 16:57:37 -0000

--Apple-Mail=_4D063B0C-4C82-498E-8D78-F2A3092CF7B4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Ben, thanks for the review. Responses to particular points inline.

> On Apr 1, 2015, at 8:29 AM, Ben Laurie  wrote:
>=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.  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.
>=20
> Summary: ready with issues.
>=20
> Nit: the Security Consideration section contains normative
> requirements. I don't know if this is strictly wrong, but it is
> unusual. The style I am used to has the normative requirements in the
> main body of the I-D, with Security Considerations confining itself to
> explaining what is going on security-wise.

I=E2=80=99ve seen both styles, and we can easily switch to having no =
normative text in this section if that is preferable to the AD and =
others here.

>=20
> Issue: "Note that the authorization server decides the frequency of =
the
>   credential rotation and not the client.  Methods by which the client
>   can request credential rotation are outside the scope of this
>   document."
>=20
> Clients are presumably as likely as servers to cause credential
> compromise, hence a mechanism by which a client can request a new
> credential seems wise.
>=20

Client rotation of secrets was considered and discussed by the working =
group, but ultimately dropped from this (experimental) version of the =
spec and deferred to a future extension or update of this spec. There =
are a lot of considerations on how to do that properly, and nobody has =
(to my knowledge) implemented a client-driven secret rotation yet.

> Of course, this could be used by an attacker to lock a client out, so
> more thought required.

That=E2=80=99s only a concern if the attacker also gains the =
registration access token, which would presumably protect the credential =
rotation call as well. Since the registration access token is the =
mechanism by which a client is authorized by at the client configuration =
endpoint.

>=20
> Issue: size limits.
>=20
> There don't appear to be any limits (minimum server must accept, max
> client must send) for client data. Not necessarily a security issue,
> but seems likely to cause interop problems.

I don=E2=80=99t see a good way to have a reasonable size recommendation =
across different platforms and deployments. The server is free to reject =
any metadata values that it doesn=E2=80=99t like, including those that =
are too long. The server chooses the client_id and client_secret, so =
those aren=E2=80=99t an issue on the server side, but a client will need =
to be able to deal with =E2=80=9Ca JSON string=E2=80=9D value for each =
of these for widest interoperability. If you have suggested text for =
size restrictions that would be reasonable across platforms, please send =
it along.

>=20
> Issue: "Configuration Endpoint" (not a security issue)
>=20
> It looks like the definition of this is deferred to
> draft-ietf-oauth-dyn-reg, but I couldn't find it there either.

I=E2=80=99m confused by this issue: =E2=80=9CClient Configuration =
Endpoint=E2=80=9D is defined as a term in =C2=A71.2 and its function and =
use are defined in =C2=A72, which is the majority of the spec=E2=80=99s =
content. I see no use of =E2=80=9Cconfiguration endpoint=E2=80=9D apart =
from the full term of =E2=80=9Cclient configuration endpoint=E2=80=9D in =
the current document version.

>=20
> Issue: "The server MUST support TLS 1.2" - it seems unwise to mandate
> a particular version of TLS - work on TLS 1.3 is already under way,
> and TLS 1.2 is not (it seems) that far off deprecation!
>=20

The current text is at the request of the AD (Kathleen) and it=E2=80=99s =
meant to point to the best practice at the time of spec publication. My =
goal here is just to get people to use TLS and use it properly to =
protect the endpoints in question, but there=E2=80=99s not a good =
official way to say =E2=80=9Cjust use TLS and don=E2=80=99t be stupid" =
in the IETF yet. This, you=E2=80=99ll note, is the topic of the thread =
resulting from this original email. I=E2=80=99ll defer to the outcome of =
that thread on this point and change the draft=E2=80=99s text if =
required.

> Issue: " Since the client configuration endpoint is an OAuth 2.0 =
protected
>   resource, it SHOULD have some rate limiting on failures to prevent
>   the registration access token from being disclosed though repeated
>   access attempts."
>=20
> I am not sure what this is getting at. Limits on key re-use? Some kind
> of BEAST defence? Something else?
>=20
> Without some quantification of the threat, it seems hard to act on
> this requirement.

The rate limiting is going to take a number of different forms depending =
on the platform and deployment characteristics of the authorization =
server, so we don=E2=80=99t recommend any particular approach. This is =
also something that=E2=80=99s going to be changing quickly over the =
years, and instead of prescribing a specific solution we thought it =
better to describe the problem here and say that it must be mitigated.


Thanks again for your review,
 =E2=80=94 Justin

--Apple-Mail=_4D063B0C-4C82-498E-8D78-F2A3092CF7B4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJVHsZ4AAoJEDPAngkbd+w9Nx8H/3PFLzhHEnSCemZF4T/+4nAv
h6MH67uayraRb61C8UPt4+VIlT+I08I7rfIUyrE4R5XQ6Z5qK1b0go4/LdWuMOuM
MC3UuGklYygdghgA93LoS6rXR5OiCaoGhlOH8SqN4uN1cMBOUq8B3rFxsBHNrFhG
950OnE3CmlFJH6WD9LTg5c/GPy4dHNaQ/TbyeYlxg9LnH5By5Rw5lbB3IIIVL7WO
QK6bPO76lirT8kAFnF0+WpVeP6//Tyj07vrqc7xiiTptM1E9+l9Sn8Q/B0ICXh3t
qoCrvaCn5GTZy/IQ8jwUCt/gWu3wg63LruX1tC+9kYZCFPn6j7IYhCSCtv4jTjI=
=IQ//
-----END PGP SIGNATURE-----

--Apple-Mail=_4D063B0C-4C82-498E-8D78-F2A3092CF7B4--


From nobody Fri Apr  3 11:10:15 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C741ACE05; Fri,  3 Apr 2015 10:22:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXmik45isBbQ; Fri,  3 Apr 2015 10:22:26 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A1D1ACE07; Fri,  3 Apr 2015 10:22:26 -0700 (PDT)
X-AuditID: 1209190f-f79d16d000000d3d-1f-551ecc51e8db
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id EE.69.03389.15CCE155; Fri,  3 Apr 2015 13:22:25 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t33HMOrE018906; Fri, 3 Apr 2015 13:22:24 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t33HMLIr016145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Apr 2015 13:22:22 -0400
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_8E97A495-BD92-430C-884D-37D134560AAE"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.5b6
From: Justin Richer 
In-Reply-To: 
Date: Fri, 3 Apr 2015 13:22:20 -0400
Message-Id: <951E5D91-BC5D-48CC-8B9C-D88804FB5B87@mit.edu>
References:  <118C77E9-FAD2-48C1-A6E1-4D20D219449F@mit.edu> 
To: Ben Laurie 
X-Mailer: Apple Mail (2.2070.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrIKsWRmVeSWpSXmKPExsUixG6nrht4Ri7UoPOzoMWGz9fYLM71dTFb zPgzkdniw8KHLA4sHgs2lXosWfKTyePL5c9sAcxRXDYpqTmZZalF+nYJXBkdb1ezFnwXq/i+ eT9LA+MW4S5GTg4JAROJv39XsUPYYhIX7q1n62Lk4hASWMwksXfeb1YIZwOjRPePw2wgVUIC D5gkvixNBbGFBdwkNrYsA+vmFTCQmHvqCxNIA7PAFEaJXxv2MUKMlZJoen0MzGYTUJWYv/IW E4jNKRAosWjeblYQm0VAReLg0252iOYmRonZi68wQky1kth7eT8jxBlHGCV+Xt/HApIQEVCQ uPqvB8jmANogL9GzKX0Co+AsJIfMQnYISIJZQFti2cLXzBC2psT+7uUsELa8xPa3c6DilhKL Z96AittK3OpbwARh20k8mraIdQEjxypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdE73czBK91JTS TYyg2OKU5N/B+O2g0iFGAQ5GJR7eB4FyoUKsiWXFlbmHGCU5mJREeXVPAIX4kvJTKjMSizPi i0pzUosPMaoA7Xq0YfUFRimWvPy8VCURXubDQHW8KYmVValF+TBl0hwsSuK8m37whQgJpCeW pGanphakFsFkZTg4lCR4X50CahQsSk1PrUjLzClBSDNxcB5ilODgARrOdRpkeHFBYm5xZjpE /hSjopQ471SQZgGQREZpHlwvLCW+YhQHekuY9wtIFQ8wncJ1vwIazAQ02GGeNMjgkkSElFQD I7uVU0HHtXNXszZKbda+8eY930ublatmbbgnu3YTw8tAJ/OuC5s/R19b/urSorQov7Q7ZYLz Zi+3KehbuCHviJi9z5/FbKq3foYr1+nkhbzurkuxsk3htN5i9jPwlq+xa6Cy5ELrbsOWX693 HtD4oKlsEP9e+Y7j/S+2ak/tVnD6fztXGTfhlBJLcUaioRZzUXEiAEWYr4xkAwAA
Archived-At: 
X-Mailman-Approved-At: Fri, 03 Apr 2015 11:10:13 -0700
Cc: draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org, The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] Security review of draft-ietf-oauth-dyn-reg-management-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Apr 2015 17:22:28 -0000

--Apple-Mail=_8E97A495-BD92-430C-884D-37D134560AAE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

>=20
>>> Issue: " Since the client configuration endpoint is an OAuth 2.0 =
protected
>>>  resource, it SHOULD have some rate limiting on failures to prevent
>>>  the registration access token from being disclosed though repeated
>>>  access attempts."
>>>=20
>>> I am not sure what this is getting at. Limits on key re-use? Some =
kind
>>> of BEAST defence? Something else?
>>>=20
>>> Without some quantification of the threat, it seems hard to act on
>>> this requirement.
>>=20
>> The rate limiting is going to take a number of different forms =
depending on the platform and deployment characteristics of the =
authorization server, so we don=E2=80=99t recommend any particular =
approach. This is also something that=E2=80=99s going to be changing =
quickly over the years, and instead of prescribing a specific solution =
we thought it better to describe the problem here and say that it must =
be mitigated.
>=20
> Solution to what? This is precisely my issue - you haven't described
> the problem, you've described a solution to some problem I'm finding
> hard to guess.
>=20
> In other words: how could the registration access token be disclosed
> through repeated access attempts?

An attacker could keep poking at a client configuration endpoint with =
random self-generated tokens until it finds one that works. There=E2=80=99=
s no oracle attack or other portion that lets the attacker know =
they=E2=80=99re getting closer to a good token, just a basic repeated =
hammering of a protected resource This problem is mitigated by having a =
sufficiently random token (as recommended in RFC6750 and RFC6819) as =
well as rate-limiting the connections to the endpoint (also suggested by =
RFC6819). This is fairly common advice for any endpoint protected by a =
secret (in this case, an OAuth token). Is there a better way to state =
this so that it=E2=80=99s more clear to developers what they should look =
out for?

Thanks,
 =E2=80=94 Justin

--Apple-Mail=_8E97A495-BD92-430C-884D-37D134560AAE
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJVHsxMAAoJEDPAngkbd+w9g14IAI7vrc9rOSsks1kId+RhDvuE
ghCHbOADVKSLEl4XcPFUSe8AefrVrRIRqZRUhWI4wCI0sIJWb0mvYfiDbsqvVcxX
Syi4+E9QIqaT+Re6G8PHpF+pPs4A6viROTOnkcISIg8r0hKENktMoSAuLyZk+6Zm
RUPpLGAab1df+ElFVwUt3EaOv50Qrl7aMUakqG/NVYnaxhn+j4BGWMAoFk60nPx0
gkENZFStYm4JSoGxgfXPgq1iUrBWY55G6LjscweMvMZxpijnjbJ/fHueGqbUYf73
pB0xF7LXEvwFbnH86TNl/ngjSvFte2Z2NZrnmTzij94LxIYiEjIhRie3gLeV6rI=
=yS1t
-----END PGP SIGNATURE-----

--Apple-Mail=_8E97A495-BD92-430C-884D-37D134560AAE--


From nobody Fri Apr  3 12:03:09 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B001AD060; Fri,  3 Apr 2015 12:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hrm4Iu5elnP5; Fri,  3 Apr 2015 12:03:03 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E1F1AD05C; Fri,  3 Apr 2015 12:03:03 -0700 (PDT)
X-AuditID: 1209190e-f79a76d000000d1b-82-551ee3e5df5b
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id C0.9A.03355.5E3EE155; Fri,  3 Apr 2015 15:03:02 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t33J31tJ029739; Fri, 3 Apr 2015 15:03:01 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t33J2waM020027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Apr 2015 15:02:59 -0400
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_21DD25AF-3046-451C-A5DB-534A12413E6A"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.5b6
From: Justin Richer 
In-Reply-To: 
Date: Fri, 3 Apr 2015 15:02:58 -0400
Message-Id: <4DE7AD5F-A14A-4255-A78C-0F6DCBECE735@mit.edu>
References:  <118C77E9-FAD2-48C1-A6E1-4D20D219449F@mit.edu>  <951E5D91-BC5D-48CC-8B9C-D88804FB5B87@mit.edu> 
To: Ben Laurie 
X-Mailer: Apple Mail (2.2070.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA01SSUwTYRTOPzMt04apQ9l+ilCseAAConJAIgQuyBES8OAFRjq0xXYgnYKA HAAxRiDgFhAEbGUxoAL2ACQetEVRGqLIFmMMYjGgIGU1cQF0hmG7fe99y3t//oej8lGRAtcx JtrIUHqVWIrJJd5Hw2dnAtMiJ2pAdM/apDj6bXUFGn134yYavWz5gsVjSWZrXlJr628kaX1s TZyMnpeeUdN6XT5tPB6XIdV2bdWJcpv8C4balkQlYNOnAkhwSEZB19f3mIB94MhUt7gCSHE5 2YLAcdcgEIoeAD93je4U0whcbbMhvMWTTIRPy9vdeEyQkbDJsY7wIpS8A+D1uRUg5Cpg2cLg NhaTx2Dd4/Jts4RMgc23JrfNGBkMLaP3xYK5DMB7LeNASI2By7eXUGF0PwK/DzSKecKLDIIT W1Xc5jg3QQmrrJobwKPhwCINBxfhCZQMg+2WBVTAIfB55UNMwErYt9i40z8NW+o/7PRj4cdq MyLgOOisfSAyA7wTBKgNReEGSqdn6cxwNpNiGNoYfirCoDNF0Oo8K9j+Lj9ZP/hpU9kBiQOV OzGdEpgmF1H5bKHBDvxwROVNhHziWrILOepCLcVq0415epq1g2BulrPn0QhQYEwOQ6u8CM0w pyPUVGERbczZlfnjmMqXsP6SpcpJDWWiL9J0Lm3cZQ/juAoSM07O6GGkNXRBlk5v2qcRXGIH EHfnwp/xGoLNpQysTiPwDnBE4Uu84wmSJ7R5zJ539xTngS/3LE9ikVe5c4e6557nghEuOL7Z nw82UfuUogRc6lBeKx4OQofaEvs6CqomG2TFpdTJmhEieW3hVQbl0iXP4puOUrfOit5Ay9U/ WU7tkzdh/8pX5semfiRcybJl9VrnvC+Htvfa5F2ygRjJqHLVlpAtPytN/xZ1KDWmd1p6zlk5 9iJeme2iYl/WmwdtGxNMbYC1+69M4ehIeK3CWC11IhQ1stR/p26inmUDAAA=
Archived-At: 
Cc: draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org, The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] Security review of draft-ietf-oauth-dyn-reg-management-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Apr 2015 19:03:05 -0000

--Apple-Mail=_21DD25AF-3046-451C-A5DB-534A12413E6A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Apr 3, 2015, at 1:26 PM, Ben Laurie  wrote:
>=20
> On 3 April 2015 at 18:22, Justin Richer  wrote:
>>>=20
>>>>> Issue: " Since the client configuration endpoint is an OAuth 2.0 =
protected
>>>>> resource, it SHOULD have some rate limiting on failures to prevent
>>>>> the registration access token from being disclosed though repeated
>>>>> access attempts."
>>>>>=20
>>>>> I am not sure what this is getting at. Limits on key re-use? Some =
kind
>>>>> of BEAST defence? Something else?
>>>>>=20
>>>>> Without some quantification of the threat, it seems hard to act on
>>>>> this requirement.
>>>>=20
>>>> The rate limiting is going to take a number of different forms =
depending on the platform and deployment characteristics of the =
authorization server, so we don=E2=80=99t recommend any particular =
approach. This is also something that=E2=80=99s going to be changing =
quickly over the years, and instead of prescribing a specific solution =
we thought it better to describe the problem here and say that it must =
be mitigated.
>>>=20
>>> Solution to what? This is precisely my issue - you haven't described
>>> the problem, you've described a solution to some problem I'm finding
>>> hard to guess.
>>>=20
>>> In other words: how could the registration access token be disclosed
>>> through repeated access attempts?
>>=20
>> An attacker could keep poking at a client configuration endpoint with =
random self-generated tokens until it finds one that works. There=E2=80=99=
s no oracle attack or other portion that lets the attacker know =
they=E2=80=99re getting closer to a good token, just a basic repeated =
hammering of a protected resource This problem is mitigated by having a =
sufficiently random token (as recommended in RFC6750 and RFC6819) as =
well as rate-limiting the connections to the endpoint (also suggested by =
RFC6819). This is fairly common advice for any endpoint protected by a =
secret (in this case, an OAuth token). Is there a better way to state =
this so that it=E2=80=99s more clear to developers what they should look =
out for?
>=20
> How about making it a non-problem by requiring sufficiently strong
> tokens that there is no possibility of brute force?
>=20
> Mildly astonished that this attack is even considered feasible.

I=E2=80=99m fine with that resolution, or with just deferring to the =
appropriate sections of 6750 and 6819 here, if the AD=E2=80=99s are =
amenable to that change.

 =E2=80=94 Justin

--Apple-Mail=_21DD25AF-3046-451C-A5DB-534A12413E6A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJVHuPiAAoJEDPAngkbd+w9ER8IAKb0dmAh5aTOkUZeWlUxstxj
WLCCdUoga8xul+U987Thzp7rAIi7NyMN7e9HY9K8jK0eLA84vCtRarT2kxlpx9tH
lR0dxYrpY6TsdFndptctnouT24jQdqoTkGB5TFsZlMqrusgHHdPoLBSwrBL89uyp
kVUsynAhksnWjbJhQ/eWCEkFOSbpj94E2rIuq3K2gja7lfM6VSKyQWC+1bIihe/I
hH9yYrHQnQLZSYYP2QIrbPkoGcA58C2dmm9Tu/wppEkUehmgcYbuyx/WLuYSWe0i
7BVoGONy9ISlIE3lvBnxVImiE9e+p+BkSfKiigUEwL14eF9LFuKYInFzi3NxSh4=
=IfCw
-----END PGP SIGNATURE-----

--Apple-Mail=_21DD25AF-3046-451C-A5DB-534A12413E6A--


From nobody Fri Apr  3 12:14:10 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E879A1B2A23; Fri,  3 Apr 2015 12:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHQduA15iZSv; Fri,  3 Apr 2015 12:14:07 -0700 (PDT)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1A41AD34D; Fri,  3 Apr 2015 12:14:06 -0700 (PDT)
Received: by lagv1 with SMTP id v1so8861144lag.3; Fri, 03 Apr 2015 12:14:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CS8+LY+QiNye/v4E07cSRZL4DkvlaWIBwn43SbuSqVU=; b=xC9lYn/IOlMRtEhaaUNf/8Xlyf7YPxn/zK37LzZlRMl57ExncJbGLZqPgtLz8QShZ9 EYJBcYIQBAZS6an/8cDFNCqcLHZzhmWVKZCGXNSjNvoGl85qAbEXfHH0N76inwH+5MjQ 6tvN7moP5zbwJLt3i9sGJNnUAKALAhfQI/1pYstoQM8JxljJeYZoLYVwqm9umvgYT3vY KSNCc/xe2+S2U94++jIZPnuvOSeBmxhkc3HPsbM4NSn3kyrdzklQX21TudbbYVW5sBRs xdM7c7Da0hgVY6s3Dg4y6N7yBVX3WsU4AhMSnDc+HGt5Jhw7oJHrqcnGjeG8uHmpX0Aa B/+w==
MIME-Version: 1.0
X-Received: by 10.152.37.202 with SMTP id a10mr3445574lak.0.1428088444948; Fri, 03 Apr 2015 12:14:04 -0700 (PDT)
Received: by 10.112.167.101 with HTTP; Fri, 3 Apr 2015 12:14:04 -0700 (PDT)
In-Reply-To: <4DE7AD5F-A14A-4255-A78C-0F6DCBECE735@mit.edu>
References:  <118C77E9-FAD2-48C1-A6E1-4D20D219449F@mit.edu>  <951E5D91-BC5D-48CC-8B9C-D88804FB5B87@mit.edu>  <4DE7AD5F-A14A-4255-A78C-0F6DCBECE735@mit.edu>
Date: Fri, 3 Apr 2015 15:14:04 -0400
Message-ID: 
From: Kathleen Moriarty 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=089e014940567815310512d6c020
Archived-At: 
Cc: draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org, The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] Security review of draft-ietf-oauth-dyn-reg-management-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Apr 2015 19:14:09 -0000

--089e014940567815310512d6c020
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 3, 2015 at 3:02 PM, Justin Richer  wrote:

> On Apr 3, 2015, at 1:26 PM, Ben Laurie  wrote:
> >
> > On 3 April 2015 at 18:22, Justin Richer  wrote:
> >>>
> >>>>> Issue: " Since the client configuration endpoint is an OAuth 2.0
> protected
> >>>>> resource, it SHOULD have some rate limiting on failures to prevent
> >>>>> the registration access token from being disclosed though repeated
> >>>>> access attempts."
> >>>>>
> >>>>> I am not sure what this is getting at. Limits on key re-use? Some
> kind
> >>>>> of BEAST defence? Something else?
> >>>>>
> >>>>> Without some quantification of the threat, it seems hard to act on
> >>>>> this requirement.
> >>>>
> >>>> The rate limiting is going to take a number of different forms
> depending on the platform and deployment characteristics of the
> authorization server, so we don=E2=80=99t recommend any particular approa=
ch. This
> is also something that=E2=80=99s going to be changing quickly over the ye=
ars, and
> instead of prescribing a specific solution we thought it better to descri=
be
> the problem here and say that it must be mitigated.
> >>>
> >>> Solution to what? This is precisely my issue - you haven't described
> >>> the problem, you've described a solution to some problem I'm finding
> >>> hard to guess.
> >>>
> >>> In other words: how could the registration access token be disclosed
> >>> through repeated access attempts?
> >>
> >> An attacker could keep poking at a client configuration endpoint with
> random self-generated tokens until it finds one that works. There=E2=80=
=99s no
> oracle attack or other portion that lets the attacker know they=E2=80=99r=
e getting
> closer to a good token, just a basic repeated hammering of a protected
> resource This problem is mitigated by having a sufficiently random token
> (as recommended in RFC6750 and RFC6819) as well as rate-limiting the
> connections to the endpoint (also suggested by RFC6819). This is fairly
> common advice for any endpoint protected by a secret (in this case, an
> OAuth token). Is there a better way to state this so that it=E2=80=99s mo=
re clear
> to developers what they should look out for?
> >
> > How about making it a non-problem by requiring sufficiently strong
> > tokens that there is no possibility of brute force?
> >
> > Mildly astonished that this attack is even considered feasible.
>
> I=E2=80=99m fine with that resolution, or with just deferring to the appr=
opriate
> sections of 6750 and 6819 here, if the AD=E2=80=99s are amenable to that =
change.
>

If the WG is good with the change and there is no reason to make this a
non-problem, that would be ideal.

Thanks,
Kathleen

>
>  =E2=80=94 Justin
>



--=20

Best regards,
Kathleen

--089e014940567815310512d6c020
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Apr 3, 2015 at 3:02 PM, Justin Richer <jricher@mit.edu> wrote:
On Apr 3, 2015, at 1:26 PM, Ben Laurie <benl@google.com> wrote:

>

> On 3 April 2015 at 18:22, Justin Richer <jricher@mit.edu> wrote:

>>>

>>>>> Issue: " Since the client configuration endpoint =
is an OAuth 2.0 protected

>>>>> resource, it SHOULD have some rate limiting on failure=
s to prevent

>>>>> the registration access token from being disclosed tho=
ugh repeated

>>>>> access attempts."

>>>>>

>>>>> I am not sure what this is getting at. Limits on key r=
e-use? Some kind

>>>>> of BEAST defence? Something else?

>>>>>

>>>>> Without some quantification of the threat, it seems ha=
rd to act on

>>>>> this requirement.

>>>>

>>>> The rate limiting is going to take a number of different f=
orms depending on the platform and deployment characteristics of the author=
ization server, so we don=E2=80=99t recommend any particular approach. This=
 is also something that=E2=80=99s going to be changing quickly over the yea=
rs, and instead of prescribing a specific solution we thought it better to =
describe the problem here and say that it must be mitigated.

>>>

>>> Solution to what? This is precisely my issue - you haven't=
 described

>>> the problem, you've described a solution to some problem I=
'm finding

>>> hard to guess.

>>>

>>> In other words: how could the registration access token be dis=
closed

>>> through repeated access attempts?

>>

>> An attacker could keep poking at a client configuration endpoint w=
ith random self-generated tokens until it finds one that works. There=E2=80=
=99s no oracle attack or other portion that lets the attacker know they=E2=
=80=99re getting closer to a good token, just a basic repeated hammering of=
 a protected resource This problem is mitigated by having a sufficiently ra=
ndom token (as recommended in RFC6750 and RFC6819) as well as rate-limiting=
 the connections to the endpoint (also suggested by RFC6819). This is fairl=
y common advice for any endpoint protected by a secret (in this case, an OA=
uth token). Is there a better way to state this so that it=E2=80=99s more c=
lear to developers what they should look out for?

>

> How about making it a non-problem by requiring sufficiently strong

> tokens that there is no possibility of brute force?

>

> Mildly astonished that this attack is even considered feasible.




I=E2=80=99m fine with that resolution, or with just deferring t=
o the appropriate sections of 6750 and 6819 here, if the AD=E2=80=99s are a=
menable to that change.

If the WG is go=
od with the change and there is no reason to make this a non-problem, that =
would be ideal.

Thanks,
Kathleen=C2=A0



=C2=A0=E2=80=94 Justin





-- 

Best regards,
Kathleen




--089e014940567815310512d6c020--


From nobody Fri Apr  3 13:34:02 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56101A0250; Fri,  3 Apr 2015 13:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puSuaZyFaRxU; Fri,  3 Apr 2015 13:33:58 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 83BF81A0242; Fri,  3 Apr 2015 13:33:58 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t33KXceX052960 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2015 15:33:48 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Jean-Marc Valin" 
Date: Fri, 03 Apr 2015 15:33:38 -0500
Message-ID: 
In-Reply-To: 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , Roni Even , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" 
Subject: Re: [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Apr 2015 20:34:00 -0000

(+payload@ietf.org)

I just noticed this thread is has included the payload mail list. Since 
the discussion involves potential material changes (i.e. normative 
language changes) , the working group should at least see it.

/Ben.

On 1 Apr 2015, at 17:50, Ben Campbell wrote:

> On 1 Apr 2015, at 16:20, Jean-Marc Valin wrote:
>
>> Based on Derek's latest suggestion, the text would become:
>>
>> "Since Opus does not provide any confidentiality or integrity
>> protection, implementations SHOULD use one of the possible RTP
>> Security methods (See RFC7201, RFC7202)."
>>
>> I think that should resolve the issue that was raised.
>
> I'm not sure that's the right solution. First, 7201 and 7202 are 
> informational, so I'm not sure we want to insert a normative reference 
> to them here.
>
> But more to the point, while I concur with the desire to push for 
> better protections, I don't think a codec payload spec is the right 
> place to do it. It risks having different security requirements for 
> different codecs when used by the same RTP application. I can see that 
> if there are really security difference (e.g. if some codec had built 
> in protection.)
>
> I think this is rather the point of 7202, although I notice section 6 
> of that draft says: "It is also expected that a similar [MTI crypto 
> spec] will be produced for voice-over-IP applications using SIP and 
> RTP." Unfortunately, I don't think that ever happened.
>
> So my suggestion would be something more to the effect of:
>
> "Opus does not provide any built-in confidentiality or integrity
> protection. Protection requirements vary between RTP applications.
> See RFC 7201 and RFC 7202 for a discussion.
>
>>
>> 	Jean-Marc
>>
>> On 01/04/15 05:11 PM, Ben Campbell wrote:
>>> Hi Roni and Derek,
>>>
>>> This thread sort of tailed off in February. Has the discussion been
>>> resolved?
>>>
>>> Thanks!
>>>
>>> Ben.
>>>
>>> On 19 Feb 2015, at 11:07, Derek Atkins wrote:
>>>
>>>> Roni,
>>>>
>>>> I'm not an RTP guy.  To me "SRTP" is a general class of "Secure
>>>> RTP" protocols.  So let's work on that as my starting point:
>>>> implementations SHOULD protect their RTP stream.
>>>>
>>>> Based on that, how about a re-wording here?  Instead of just
>>>> saying "MAY use SRTP", how about something like "SHOULD use one
>>>> of the possible RTP Security methods (See RFC7201, RFC7202)"?
>>>> (Obviously this can be worded better).
>>>>
>>>> -derek
>>>>
>>>> Roni Even  writes:
>>>>
>>>>> Hi, The reason for the may is discussed in RFC7201 and RFC
>>>>> 7202, it can be a SHOULD and these RFCs exaplain when it is not
>>>>> required to use SRTP. Maybe add a reference to these RFCs in
>>>>> the security section when saying talking about good reasons for
>>>>> not using SRTP
>>>>>
>>>>> Roni Even
>>>>>
>>>>> ________________________________________ From: Jean-Marc Valin
>>>>> [jvalin@mozilla.com] on behalf of Jean-Marc Valin
>>>>> [jmvalin@mozilla.com] Sent: Tuesday, February 17, 2015 10:23
>>>>> PM To: Derek Atkins; iesg@ietf.org; secdir@ietf.org Cc:
>>>>> payload-chairs@tools.ietf.org; koenvos74@gmail.com;
>>>>> jspittka@gmail.com Subject: Re: sec-dir review of
>>>>> draft-ietf-payload-rtp-opus-08
>>>>>
>>>>> Hi Derek,
>>>>>
>>>>> There was no particular reason for the MAY, the text was merely
>>>>> copied from other RTP payload RFC. I totally agree with making
>>>>> it a SHOULD.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jean-Marc
>>>>>
>>>>> On 17/02/15 02:54 PM, Derek Atkins wrote:
>>>>>> 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
>>>>>> with the intent of improving security requirements and
>>>>>> considerations in IETF drafts.  Comments not addressed in
>>>>>> last call may be included in AD reviews during the IESG
>>>>>> review.  Document editors and WG chairs should treat these
>>>>>> comments just like any other last call comments.
>>>>>>
>>>>>> Summary:
>>>>>>
>>>>>> Ready to publish with a question: I question why the use of
>>>>>> SRTP is a MAY and not a SHOULD (as detailed in the Security
>>>>>> Considerations section).  Considering PERPASS I believe this
>>>>>> should be a SHOULD; someone should have a very good reason
>>>>>> why they are NOT using SRTP.
>>>>>>
>>>>>> Details:
>>>>>>
>>>>>> This document defines the Real-time Transport Protocol (RTP)
>>>>>> payload format for packetization of Opus encoded speech and
>>>>>> audio data necessary to integrate the codec in the most
>>>>>> compatible way. Further, it describes media type
>>>>>> registrations for the RTP payload format.
>>>>>>
>>>>>> I have no other comments on this document.
>>>>>>
>>>>>> -derek
>>>>>>
>>>>>
>>>>> _______________________________________________ secdir mailing
>>>>> list secdir@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/secdir wiki:
>>>>> http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>>>>
>>>>>
>>>>
>>>> -- Derek Atkins                 617-623-3745 derek@ihtfp.com
>>>> www.ihtfp.com Computer and Internet Security Consultant


From nobody Fri Apr  3 13:46:38 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587251A0373; Fri,  3 Apr 2015 13:44:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.977
X-Spam-Level: 
X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, SPF_FAIL=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSU0VbJA4HsB; Fri,  3 Apr 2015 13:44:13 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (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 CAB631A036C; Fri,  3 Apr 2015 13:44:13 -0700 (PDT)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 45D4CC1AC0; Fri,  3 Apr 2015 20:44:13 +0000 (UTC)
X-Virus-Scanned: amavisd-new at mozilla.org
Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqwpudNTvkqY; Fri,  3 Apr 2015 20:44:13 +0000 (UTC)
Received: from [10.252.25.225] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 26771C15B4; Fri,  3 Apr 2015 20:44:13 +0000 (UTC)
Message-ID: <551EFB9C.4040504@xiph.org>
Date: Fri, 03 Apr 2015 13:44:12 -0700
From: "Timothy B. Terriberry" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: Ben Campbell , Jean-Marc Valin 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
X-Mailman-Approved-At: Fri, 03 Apr 2015 13:46:32 -0700
Cc: "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Apr 2015 20:44:15 -0000

Ben Campbell wrote:
>> So my suggestion would be something more to the effect of:
>>
>> "Opus does not provide any built-in confidentiality or integrity
>> protection. Protection requirements vary between RTP applications.
>> See RFC 7201 and RFC 7202 for a discussion.

This seems like reasonable text to me. I agree with the rationale that 
preceded it. As much as I want to see encryption everywhere, a payload 
format is not the right place to mandate it.


From nobody Fri Apr  3 14:16:14 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCB71A1A72; Fri,  3 Apr 2015 14:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-6bCLsroxz8; Fri,  3 Apr 2015 14:16:09 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 48E7E1A1A65; Fri,  3 Apr 2015 14:16:09 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t33LFqtT056666 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2015 16:16:03 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Jean-Marc Valin" 
Date: Fri, 03 Apr 2015 16:15:52 -0500
Message-ID: <65E44C9D-D7F2-41C9-B54A-A37FDAEF04A7@nostrum.com>
In-Reply-To: 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>  
MIME-Version: 1.0
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Apr 2015 21:16:10 -0000

On 3 Apr 2015, at 15:33, Ben Campbell wrote:

> I just noticed this thread is has included the payload mail list.

Oops, I meant to say has _not_ included...


From nobody Sun Apr  5 18:51:08 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6764A1AD061 for ; Sun,  5 Apr 2015 18:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.2
X-Spam-Level: 
X-Spam-Status: No, score=0.2 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVKJiJoNlCDN for ; Sun,  5 Apr 2015 18:51:06 -0700 (PDT)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58CB1AD05F for ; Sun,  5 Apr 2015 18:51:05 -0700 (PDT)
Received: by widdi4 with SMTP id di4so18562282wid.0 for ; Sun, 05 Apr 2015 18:51:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=GdxvMqnc03ydda5EqWvD+E3lnGdoQcbhSHBOqXSmhUE=; b=SrYMd0zEyDDMU/NW6znSVOWalSd3PlyQ46zkAngQXtxP8H5TqdIBcr8Hj/1VBgAp26 dV2EQTmrDnfW2WFmIh3rIXdz174EXO0bQs7gQlGWLJbSpERsPkXlt5d1JTxcoa+ggTXb OkQ+ZiKuygxC5X0fe0Z3pgmw6xGJ7lbK6HY7jskSndJI5oEiQnhi0sVvK1FdMpzbhrbO o5mP9tA1osBcVaJUfBsdoRFTa0H+3YMOuh31syPJXoB88azpHXIciz60S7cNV3EMew88 zc+Vr/7/+6ksARud3tFO/hIA8wIcBbQ+xxSlFiuMpa2Gh6VBSdjIW+zvX0qQiEo8fFh9 M9ww==
MIME-Version: 1.0
X-Received: by 10.180.103.136 with SMTP id fw8mr54184329wib.46.1428285064681;  Sun, 05 Apr 2015 18:51:04 -0700 (PDT)
Received: by 10.180.46.131 with HTTP; Sun, 5 Apr 2015 18:51:04 -0700 (PDT)
Date: Sun, 5 Apr 2015 18:51:04 -0700
Message-ID: 
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= 
To: "secdir@ietf.org" , draft-ietf-scim-use-cases@tools.ietf.org
Content-Type: multipart/alternative; boundary=f46d04430446eb1e3505130487e3
Archived-At: 
Subject: [secdir] Secdir review of draft-ietf-scim-use-cases
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 01:51:07 -0000

--f46d04430446eb1e3505130487e3
Content-Type: text/plain; charset=UTF-8

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 memo describes the "System for Cross-domain Identity Management
(SCIM)." SCIM is a companion document to the SCIM Schema memo and the SCIM
Protocol memo.

Section 3.5: Shouldn't there also be a requirement for the secure transfer
of attributes between A and B based on matters such as A trusting
authentication results from B, a means to provide those authentication
results securely to B, etc.? Essentially similar to what was presented in
Section 3.3?

Section 3.6: Similar comment as for Section 3.5. There seems to be general
security requirements missing for these two scenarios?

Section 4: I only glanced the Security Consideration sections referenced
here, but they do seem adequate, and given that I don't see that this
memo's Security Consideration section need to contain more information.
Editorial suggestion: "only authenticated entity" -> "only authenticated
entities".

-- Magnus

--f46d04430446eb1e3505130487e3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=

I have reviewed this document as pa=
rt of the security directorate's=20
ongoing effort to review all IETF documents being processed by the IE=
SG.
 These comments were written primarily for the benefit of the security=20
area directors. Document editors and WG chairs should treat these=20
comments just like any other last call comments.
<=
div dir=3D"ltr">

This memo describes =
the "System for Cross-domain Identity Management (SCIM)." SCIM is=
 a companion document to the SCIM Schema memo and the SCIM Protocol memo.
Section 3.5: Shouldn't there also be a requirement for=
 the secure transfer of attributes between A and B based on matters such as=
 A trusting authentication results from B, a means to provide those authent=
ication results securely to B, etc.? Essentially similar to what was presen=
ted in Section 3.3?

Section 3.6: Similar comment as for S=
ection 3.5. There seems to be general security requirements missing for the=
se two scenarios?

Section 4: I only glanced the Security =
Consideration sections referenced here, but they do seem adequate, and give=
n that I don't see that this memo's Security Consideration section =
need to contain more information. Editorial suggestion: "only authenti=
cated entity" -> "only authenticated entities".

-- Magnus




--f46d04430446eb1e3505130487e3--


From nobody Mon Apr  6 09:09:40 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72B01A8AE7; Mon,  6 Apr 2015 09:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.61
X-Spam-Level: 
X-Spam-Status: No, score=0.61 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_ORG=0.611] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbB4rCQMyTzf; Mon,  6 Apr 2015 09:09:34 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF501A8AE6; Mon,  6 Apr 2015 09:09:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 06E3BE2038; Mon,  6 Apr 2015 12:09:33 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 26889-04; Mon,  6 Apr 2015 12:09:27 -0400 (EDT)
Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 78BE4E2036; Mon,  6 Apr 2015 12:09:27 -0400 (EDT)
Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t36G9Qnk017843; Mon, 6 Apr 2015 12:09:26 -0400
From: Derek Atkins 
To: "Timothy B. Terriberry" 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>
Date: Mon, 06 Apr 2015 12:09:26 -0400
In-Reply-To: <551EFB9C.4040504@xiph.org> (Timothy B. Terriberry's message of "Fri, 03 Apr 2015 13:44:12 -0700")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: 
Cc: Ben Campbell , Jean-Marc Valin , "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 16:09:38 -0000

"Timothy B. Terriberry"  writes:

> Ben Campbell wrote:
>>> So my suggestion would be something more to the effect of:
>>>
>>> "Opus does not provide any built-in confidentiality or integrity
>>> protection. Protection requirements vary between RTP applications.
>>> See RFC 7201 and RFC 7202 for a discussion.
>
> This seems like reasonable text to me. I agree with the rationale that
> preceded it. As much as I want to see encryption everywhere, a payload
> format is not the right place to mandate it.

As was stated already in this thread, the expected follow up drafts for
MTI security have not been written.

I leave it up to the Security ADs who have the real power here, but I
still prefer my original wording (including the SHOULD).

I understand your reluctance because it's a codec, but it's the first
codec to get through the process since the Perpass work, which basically
says "everything should be encrypted."  Since you cannot go back in time
to modify the existing RFCs, you can augment them going forward by other
additions.

As for the concern about "different security requirements for different
codecs", frankly I don't buy that argument.  Either your RTP application
supports security or it doesn't.  Once it does, it should be able to
negotiate that along side the codec negotitation.  So I don't see the
concern -- we're not mandating a specific security technology, just that
you SHOULD use one.  Well, that's true regardless of the codec, isn't
it?

Or are you really saying "We don't care about security.  We just want to
be able to use this codec in existing, insecure RTP applications without
adding new securty measures"?

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


From nobody Mon Apr  6 09:13:54 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC921A8AF5; Mon,  6 Apr 2015 09:13:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSuxXTk6HAjx; Mon,  6 Apr 2015 09:13:44 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 10EE21A8AED; Mon,  6 Apr 2015 09:13:44 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t36GDUo1007147 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Apr 2015 11:13:40 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Derek Atkins" 
Date: Mon, 06 Apr 2015 11:13:30 -0500
Message-ID: <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com>
In-Reply-To: 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org> 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: Jean-Marc Valin , "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" , "Timothy B. Terriberry" 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 16:13:48 -0000

On 6 Apr 2015, at 11:09, Derek Atkins wrote:

> "Timothy B. Terriberry"  writes:
>
>> Ben Campbell wrote:
>>>> So my suggestion would be something more to the effect of:
>>>>
>>>> "Opus does not provide any built-in confidentiality or integrity
>>>> protection. Protection requirements vary between RTP applications.
>>>> See RFC 7201 and RFC 7202 for a discussion.
>>
>> This seems like reasonable text to me. I agree with the rationale 
>> that
>> preceded it. As much as I want to see encryption everywhere, a 
>> payload
>> format is not the right place to mandate it.
>
> As was stated already in this thread, the expected follow up drafts 
> for
> MTI security have not been written.
>
> I leave it up to the Security ADs who have the real power here, but I
> still prefer my original wording (including the SHOULD).
>
> I understand your reluctance because it's a codec, but it's the first
> codec to get through the process since the Perpass work, which 
> basically
> says "everything should be encrypted."  Since you cannot go back in 
> time
> to modify the existing RFCs, you can augment them going forward by 
> other
> additions.
>
> As for the concern about "different security requirements for 
> different
> codecs", frankly I don't buy that argument.  Either your RTP 
> application
> supports security or it doesn't.  Once it does, it should be able to
> negotiate that along side the codec negotitation.  So I don't see the
> concern -- we're not mandating a specific security technology, just 
> that
> you SHOULD use one.  Well, that's true regardless of the codec, isn't
> it?
>
> Or are you really saying "We don't care about security.  We just want 
> to
> be able to use this codec in existing, insecure RTP applications 
> without
> adding new securty measures"?

I'm saying this is the wrong layer to solve the problem.

We had some work planned to better specify this in general for RTP. I 
think the right answer is finish that work. If we do that right, it 
should apply regardless of codec.


From nobody Mon Apr  6 11:44:52 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5375E1A90BB; Mon,  6 Apr 2015 11:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lb2ooZulJvob; Mon,  6 Apr 2015 11:44:43 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 156561A90B4; Mon,  6 Apr 2015 11:44:43 -0700 (PDT)
Received: from unnumerable-2.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t36IiZFP019732 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Apr 2015 13:44:35 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable-2.local
Message-ID: <5522D40E.8040402@nostrum.com>
Date: Mon, 06 Apr 2015 13:44:30 -0500
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Ben Campbell , Derek Atkins 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com>
In-Reply-To: <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 18:44:47 -0000

inline (particularly for Derek)

On 4/6/15 11:13 AM, Ben Campbell wrote:
> On 6 Apr 2015, at 11:09, Derek Atkins wrote:
>
>> "Timothy B. Terriberry"  writes:
>>
>>> Ben Campbell wrote:
>>>>> So my suggestion would be something more to the effect of:
>>>>>
>>>>> "Opus does not provide any built-in confidentiality or integrity
>>>>> protection. Protection requirements vary between RTP applications.
>>>>> See RFC 7201 and RFC 7202 for a discussion.
>>>
>>> This seems like reasonable text to me. I agree with the rationale that
>>> preceded it. As much as I want to see encryption everywhere, a payload
>>> format is not the right place to mandate it.
>>
>> As was stated already in this thread, the expected follow up drafts for
>> MTI security have not been written.
>>
>> I leave it up to the Security ADs who have the real power here, but I
>> still prefer my original wording (including the SHOULD).
>>
>> I understand your reluctance because it's a codec, but it's the first
>> codec to get through the process since the Perpass work, which basically
>> says "everything should be encrypted."  Since you cannot go back in time
>> to modify the existing RFCs, you can augment them going forward by other
>> additions.
>>
>> As for the concern about "different security requirements for different
>> codecs", frankly I don't buy that argument.  Either your RTP application
>> supports security or it doesn't.  Once it does, it should be able to
>> negotiate that along side the codec negotitation.  So I don't see the
>> concern -- we're not mandating a specific security technology, just that
>> you SHOULD use one.  Well, that's true regardless of the codec, isn't
>> it?
>>
>> Or are you really saying "We don't care about security.  We just want to
>> be able to use this codec in existing, insecure RTP applications without
>> adding new securty measures"?
>
> I'm saying this is the wrong layer to solve the problem.
>
> We had some work planned to better specify this in general for RTP. I 
> think the right answer is finish that work. If we do that right, it 
> should apply regardless of codec.
>
That's exactly right.

We've had this conversation several times before. The individual payload 
documents are not the place to add the kind of guidance Derek is asking 
for. They should be about how you put things in RTP, not how 
applications use (and secure RTP), unless there's something unique about 
the payload that interacts with the general mechanics for using and 
securing RTP.

Stephen will remember that we've queued up work on a document that would 
describe securing unicast RTP set up with SDP (capturing the outcome of 
the rtpsec bof at IETF68). The last I heard on the subject Dan Wing was 
taking the token to work on that document, but it's been awhile. That's 
where the effort should focus - an individual payload document is not 
the right place.


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


From nobody Mon Apr  6 11:51:05 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE771A90CA; Mon,  6 Apr 2015 11:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdMZKNhWXqe7; Mon,  6 Apr 2015 11:50:56 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A131A90C7; Mon,  6 Apr 2015 11:50:56 -0700 (PDT)
Received: from [81.187.2.149] (port=39688 helo=[192.168.0.22]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YfC6i-0001si-D2; Mon, 06 Apr 2015 19:50:52 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins 
In-Reply-To: <5522D40E.8040402@nostrum.com>
Date: Mon, 6 Apr 2015 19:50:23 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org>
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com>
To: Robert Sparks 
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: 
Cc: Ben Campbell , "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 18:51:01 -0000

On 6 Apr 2015, at 19:44, Robert Sparks  wrote:
> inline (particularly for Derek)
> On 4/6/15 11:13 AM, Ben Campbell wrote:
>> On 6 Apr 2015, at 11:09, Derek Atkins wrote:
>>=20
>>> "Timothy B. Terriberry"  writes:
>>>=20
>>>> Ben Campbell wrote:
>>>>>> So my suggestion would be something more to the effect of:
>>>>>>=20
>>>>>> "Opus does not provide any built-in confidentiality or integrity
>>>>>> protection. Protection requirements vary between RTP =
applications.
>>>>>> See RFC 7201 and RFC 7202 for a discussion.
>>>>=20
>>>> This seems like reasonable text to me. I agree with the rationale =
that
>>>> preceded it. As much as I want to see encryption everywhere, a =
payload
>>>> format is not the right place to mandate it.
>>>=20
>>> As was stated already in this thread, the expected follow up drafts =
for
>>> MTI security have not been written.
>>>=20
>>> I leave it up to the Security ADs who have the real power here, but =
I
>>> still prefer my original wording (including the SHOULD).
>>>=20
>>> I understand your reluctance because it's a codec, but it's the =
first
>>> codec to get through the process since the Perpass work, which =
basically
>>> says "everything should be encrypted."  Since you cannot go back in =
time
>>> to modify the existing RFCs, you can augment them going forward by =
other
>>> additions.
>>>=20
>>> As for the concern about "different security requirements for =
different
>>> codecs", frankly I don't buy that argument.  Either your RTP =
application
>>> supports security or it doesn't.  Once it does, it should be able to
>>> negotiate that along side the codec negotitation.  So I don't see =
the
>>> concern -- we're not mandating a specific security technology, just =
that
>>> you SHOULD use one.  Well, that's true regardless of the codec, =
isn't
>>> it?
>>>=20
>>> Or are you really saying "We don't care about security.  We just =
want to
>>> be able to use this codec in existing, insecure RTP applications =
without
>>> adding new securty measures"?
>>=20
>> I'm saying this is the wrong layer to solve the problem.
>>=20
>> We had some work planned to better specify this in general for RTP. I =
think the right answer is finish that work. If we do that right, it =
should apply regardless of codec.
>>=20
> That's exactly right.
>=20
> We've had this conversation several times before. The individual =
payload documents are not the place to add the kind of guidance Derek is =
asking for. They should be about how you put things in RTP, not how =
applications use (and secure RTP), unless there's something unique about =
the payload that interacts with the general mechanics for using and =
securing RTP.
>=20
> Stephen will remember that we've queued up work on a document that =
would describe securing unicast RTP set up with SDP (capturing the =
outcome of the rtpsec bof at IETF68). The last I heard on the subject =
Dan Wing was taking the token to work on that document, but it's been =
awhile. That's where the effort should focus - an individual payload =
document is not the right place.

+1=20

As Robert, and others, say, RTP payload format documents are not the =
right place to mandate security mechanisms. This is the point of =
RFC7202, which is about how strong security can best be defined for =
classes of RTP applications. This is not in conflict with the perpass =
work, since the goal of RFC7202 is to show how to provide strong =
security.

--=20
Colin Perkins
https://csperkins.org/





From nobody Mon Apr  6 13:15:07 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396B61A9115; Mon,  6 Apr 2015 13:15:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNEgydxn4bIZ; Mon,  6 Apr 2015 13:14:56 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 651E41A90FD; Mon,  6 Apr 2015 13:14:56 -0700 (PDT)
X-AuditID: 12074422-f79cb6d000000d7b-ed-5522e93ee5c9
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id B1.C9.03451.F39E2255; Mon,  6 Apr 2015 16:14:55 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t36KEnRx004175; Mon, 6 Apr 2015 16:14:50 -0400
Received: from [10.66.204.91] ([64.236.138.4]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t36KEjju031733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Apr 2015 16:14:47 -0400
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_E2F58AE3-467B-4CCB-8878-325A032BF063"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.5b6
From: Justin Richer 
In-Reply-To: 
Date: Mon, 6 Apr 2015 13:14:45 -0700
Message-Id: 
References:  <118C77E9-FAD2-48C1-A6E1-4D20D219449F@mit.edu>  <951E5D91-BC5D-48CC-8B9C-D88804FB5B87@mit.edu>  <4DE7AD5F-A14A-4255-A78C-0F6DCBECE735@mit.edu> 
To: Kathleen Moriarty 
X-Mailer: Apple Mail (2.2070.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDKsWRmVeSWpSXmKPExsUixG6nomv/UinU4P17Q4sNn6+xWZzr62K2 mPFnIrNFw858iw8LH7I4sHrsnHWX3WPBplKPJUt+Mnl8ufyZLYAlissmJTUnsyy1SN8ugStj +fUjTAVHgip+n3vM0sB4zq2LkZNDQsBEYs2RvUwQtpjEhXvr2UBsIYHFTBIT22y6GLmA7A2M Eh8mPGeEcFYxSSzcM4kFpEpYwE1iY8sydhCbV8BAYu6pL2CTmAWmMErcmxMMMVVKoun1MUYQ m01AVWL6mhawGk6BQIlbx76BzWERUJHYc/AL2AJmgZWMEu9fdrJCDLWSeLCrBWrzGmaJc3ev gk0SEbCQWNP8DehWDqAN8hI9m9InMArOQnLHLCR3QNhJEn/e9EDFtSWWLXzNDGFrSuzvXs6C Ka4h0fltIiuELS+x/e0cqLilxOKZN6DqbSVu9S2Ammkn8WjaItYFjNyrGGVTcqt0cxMzc4pT k3WLkxPz8lKLdE31cjNL9FJTSjcxgiPWRWkH48+DSocYBTgYlXh4X9xRDBViTSwrrsw9xCjJ waQkytv6TClUiC8pP6UyI7E4I76oNCe1+BCjCtCuRxtWX2CUYsnLz0tVEuHNuwNUx5uSWFmV WpQPUybNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgnfec6BGwaLU9NSKtMycEoQ0Ewfn IUYJDh6g4YwvQIYXFyTmFmemQ+RPMSpKifOeAGkWAElklObB9cIS7StGcaC3hHlVQdp5gEka rvsV0GAmoMH8z8AGlyQipKQaGBc/3TH/IceDh19aRZoKt6zYcfGa/JMy4yM89efuKbife+nw 8251zsVfMvLrWuK2uYp2rPTsFbkeuTloZcqitTayScqKm8QXdT0QMXizNlY/oMaIScPdT+5b sbKQzpkehQaxV1GKp9wzJvUGritcYxCVb3r12Bpef56y9auO7vj2S6czSSDyihJLcUaioRZz UXEiAPimj2iPAwAA
Archived-At: 
Cc: draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org, The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] Security review of draft-ietf-oauth-dyn-reg-management-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 20:15:04 -0000

--Apple-Mail=_E2F58AE3-467B-4CCB-8878-325A032BF063
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_1D67C66A-9140-4631-85EF-CD9C5A8CC913"


--Apple-Mail=_1D67C66A-9140-4631-85EF-CD9C5A8CC913
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Ben et. al.,

I took the proposal to the WG and have changed the draft text based on =
their feedback. The results are published here:

  http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-13

 =E2=80=94 Justin

> On Apr 3, 2015, at 12:14 PM, Kathleen Moriarty =
 wrote:
>=20
>=20
>=20
> On Fri, Apr 3, 2015 at 3:02 PM, Justin Richer > wrote:
> On Apr 3, 2015, at 1:26 PM, Ben Laurie > wrote:
> >
> > On 3 April 2015 at 18:22, Justin Richer > wrote:
> >>>
> >>>>> Issue: " Since the client configuration endpoint is an OAuth 2.0 =
protected
> >>>>> resource, it SHOULD have some rate limiting on failures to =
prevent
> >>>>> the registration access token from being disclosed though =
repeated
> >>>>> access attempts."
> >>>>>
> >>>>> I am not sure what this is getting at. Limits on key re-use? =
Some kind
> >>>>> of BEAST defence? Something else?
> >>>>>
> >>>>> Without some quantification of the threat, it seems hard to act =
on
> >>>>> this requirement.
> >>>>
> >>>> The rate limiting is going to take a number of different forms =
depending on the platform and deployment characteristics of the =
authorization server, so we don=E2=80=99t recommend any particular =
approach. This is also something that=E2=80=99s going to be changing =
quickly over the years, and instead of prescribing a specific solution =
we thought it better to describe the problem here and say that it must =
be mitigated.
> >>>
> >>> Solution to what? This is precisely my issue - you haven't =
described
> >>> the problem, you've described a solution to some problem I'm =
finding
> >>> hard to guess.
> >>>
> >>> In other words: how could the registration access token be =
disclosed
> >>> through repeated access attempts?
> >>
> >> An attacker could keep poking at a client configuration endpoint =
with random self-generated tokens until it finds one that works. =
There=E2=80=99s no oracle attack or other portion that lets the attacker =
know they=E2=80=99re getting closer to a good token, just a basic =
repeated hammering of a protected resource This problem is mitigated by =
having a sufficiently random token (as recommended in RFC6750 and =
RFC6819) as well as rate-limiting the connections to the endpoint (also =
suggested by RFC6819). This is fairly common advice for any endpoint =
protected by a secret (in this case, an OAuth token). Is there a better =
way to state this so that it=E2=80=99s more clear to developers what =
they should look out for?
> >
> > How about making it a non-problem by requiring sufficiently strong
> > tokens that there is no possibility of brute force?
> >
> > Mildly astonished that this attack is even considered feasible.
>=20
> I=E2=80=99m fine with that resolution, or with just deferring to the =
appropriate sections of 6750 and 6819 here, if the AD=E2=80=99s are =
amenable to that change.
>=20
> If the WG is good with the change and there is no reason to make this =
a non-problem, that would be ideal.
>=20
> Thanks,
> Kathleen
>=20
>  =E2=80=94 Justin
>=20
>=20
>=20
> --
>=20
> Best regards,
> Kathleen


--Apple-Mail=_1D67C66A-9140-4631-85EF-CD9C5A8CC913
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Ben et. al., 

I took the proposal to the WG and have changed the draft text =
based on their feedback. The results are published here:

  http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-=
13

 =E2=
=80=94 Justin

On =
Apr 3, 2015, at 12:14 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:



On Fri, =
Apr 3, 2015 at 3:02 PM, Justin Richer <jricher@mit.edu> wrote:
On Apr =
3, 2015, at 1:26 PM, Ben Laurie <benl@google.com> wrote:

>

> On 3 April 2015 at 18:22, Justin Richer <jricher@mit.edu> =
wrote:

>>>

>>>>> Issue: " Since the client configuration endpoint is =
an OAuth 2.0 protected

>>>>> resource, it SHOULD have some rate limiting on =
failures to prevent

>>>>> the registration access token from being disclosed =
though repeated

>>>>> access attempts."

>>>>>

>>>>> I am not sure what this is getting at. Limits on =
key re-use? Some kind

>>>>> of BEAST defence? Something else?

>>>>>

>>>>> Without some quantification of the threat, it seems =
hard to act on

>>>>> this requirement.

>>>>

>>>> The rate limiting is going to take a number of =
different forms depending on the platform and deployment characteristics =
of the authorization server, so we don=E2=80=99t recommend any =
particular approach. This is also something that=E2=80=99s going to be =
changing quickly over the years, and instead of prescribing a specific =
solution we thought it better to describe the problem here and say that =
it must be mitigated.

>>>

>>> Solution to what? This is precisely my issue - you haven't =
described

>>> the problem, you've described a solution to some problem =
I'm finding

>>> hard to guess.

>>>

>>> In other words: how could the registration access token be =
disclosed

>>> through repeated access attempts?

>>

>> An attacker could keep poking at a client configuration =
endpoint with random self-generated tokens until it finds one that =
works. There=E2=80=99s no oracle attack or other portion that lets the =
attacker know they=E2=80=99re getting closer to a good token, just a =
basic repeated hammering of a protected resource This problem is =
mitigated by having a sufficiently random token (as recommended in =
RFC6750 and RFC6819) as well as rate-limiting the connections to the =
endpoint (also suggested by RFC6819). This is fairly common advice for =
any endpoint protected by a secret (in this case, an OAuth token). Is =
there a better way to state this so that it=E2=80=99s more clear to =
developers what they should look out for?

>

> How about making it a non-problem by requiring sufficiently =
strong

> tokens that there is no possibility of brute force?

>

> Mildly astonished that this attack is even considered feasible.




I=E2=80=99m fine with that resolution, or with just =
deferring to the appropriate sections of 6750 and 6819 here, if the =
AD=E2=80=99s are amenable to that change.

If the WG is good with =
the change and there is no reason to make this a non-problem, that would =
be ideal.

Thanks,
Kathleen 



 =E2=80=94 Justin





-- 

Best regards,
Kathleen





=

--Apple-Mail=_1D67C66A-9140-4631-85EF-CD9C5A8CC913--

--Apple-Mail=_E2F58AE3-467B-4CCB-8878-325A032BF063
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJVIuk1AAoJEDPAngkbd+w9XfQIAJZe3dHCw6nWLcp1DWPwKolh
CR0Y2OjMYJAowzXATAgbh4U/wt4MbMzvE7boqzdKHAF8OfzSkIRMtCAd94lHpKvS
syvsuT62lPzZe2nqJpXmgdyBVZiGEw++yAJ/kjcrMpm+gaUG749sbm4oTLCYC2VO
TqEhgXy1yL6/5TzveNqJKW/SPg0t1fd0SFxzwQSSVZcdY3/ik6ehTjJbP4LGv2aB
aEwP6xg2fwih0E00amrjkQV167wGxttjiOsZOHZ5T3TB1XombOnv8wqdlQvAQ3h6
tGumMDQDLHNhERHSTB5crI1ZtQdYM/ZLECYKitQft0sdODxHChtyj/y4O3UlBfc=
=ZZxS
-----END PGP SIGNATURE-----

--Apple-Mail=_E2F58AE3-467B-4CCB-8878-325A032BF063--


From nobody Mon Apr  6 13:35:13 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369A61A9133; Mon,  6 Apr 2015 13:35:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4OQTr5jRxHn; Mon,  6 Apr 2015 13:35:06 -0700 (PDT)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B79B1A9130; Mon,  6 Apr 2015 13:35:06 -0700 (PDT)
Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id t36KZ3C7000665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 6 Apr 2015 16:35:04 -0400
From: Catherine Meadows 
Content-Type: multipart/alternative; boundary="Apple-Mail=_C14F8237-522E-4AC7-AC4D-57ECCA645D70"
Date: Mon, 6 Apr 2015 16:35:03 -0400
Message-Id: <276CBF09-D56C-4DFB-BCBC-D455BE33550F@nrl.navy.mil>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-httpbis-auth-info.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-CCS-MailScanner: No viruses found.
X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email
Archived-At: 
Subject: [secdir] secdir review of draft-ietf-httpbis-auth-info-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 20:35:09 -0000

--Apple-Mail=_C14F8237-522E-4AC7-AC4D-57ECCA645D70
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

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


This draft defines the =93Authentication-Info=94 and =
=93Proxy-Authentication-Info=94 response header fields for use in HTTP =
authentication.
These are used for schemes that need to return information once a =
client=92s authentication credentials have been accepted.
The document defines the syntax, and gives instructions on how it should =
be treated (e.g. proxies forwarding a response are
not allowed to modify it).  The actual semantics of the fields depend =
upon the protocols that use them.

In the Security Considerations section, the authors note that adding =
information to HTTP responses sent across an unencrypted
channel can affect security and privacy.  Indeed the presence of these =
header fields alone indicate that HTTP authentication is in use.  =
Additional information
could be exposed depending on the authentication scheme; but this is =
something that will need to be addressed in the definition of the =
schemes.

I only have one small question about the Security Considerations =
section: wouldn=92t there be other headers that indicate authentication =
is being used, such
as a header indicating that a message contains the client=92s =
credentials?  If so, I don=92t see how the introduction of an additional =
header field adds any further risk.


I believe that this ID is ready with nits.

Cathy

 =20


Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil


--Apple-Mail=_C14F8237-522E-4AC7-AC4D-57ECCA645D70
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


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 draft =
defines the =93Authentication-Info=94 and =93Proxy-Authentication-Info=94 =
response header fields for use in HTTP authentication.
These are =
used for schemes that need to return information once a client=92s =
authentication credentials have been accepted.
The document =
defines the syntax, and gives instructions on how it should be treated =
(e.g. proxies forwarding a response are
not allowed to modify =
it).  The actual semantics of the fields depend upon the protocols =
that use them.

In the Security Considerations =
section, the authors note that adding information to HTTP responses sent =
across an unencrypted
channel can affect security and privacy. =
 Indeed the presence of these header fields alone indicate that =
HTTP authentication is in use.  Additional =
information
could be exposed depending on the authentication =
scheme; but this is something that will need to be addressed in the =
definition of the schemes.

I only have one =
small question about the Security Considerations section: wouldn=92t =
there be other headers that indicate authentication is being used, =
such
as a header indicating that a message contains the =
client=92s credentials?  If so, I don=92t see how the introduction =
of an additional header field adds any further =
risk.


I believe that this ID is =
ready with =
nits.

Cathy

  =




Catherine Meadows
Naval =
Research Laboratory
Code 5543
4555 Overlook Ave., =
S.W.
Washington DC, 20375
phone: 202-767-3490
fax: =
202-404-7942
email: catherine.meadows@nrl.navy.=
mil




=

--Apple-Mail=_C14F8237-522E-4AC7-AC4D-57ECCA645D70--


From nobody Mon Apr  6 14:33:07 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799701AC438; Mon,  6 Apr 2015 14:33:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fbby2dRQymxR; Mon,  6 Apr 2015 14:33:03 -0700 (PDT)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F481AC437; Mon,  6 Apr 2015 14:33:03 -0700 (PDT)
Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id t36LX24A011142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 6 Apr 2015 17:33:02 -0400
From: Catherine Meadows 
Content-Type: multipart/alternative; boundary="Apple-Mail=_968C6142-35F7-43CC-B10C-FAC73C9E6D30"
Date: Mon, 6 Apr 2015 17:33:02 -0400
Message-Id: <50AF625A-F94C-431D-A91A-C14876FC6DD4@nrl.navy.mil>
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-roll-applicability-home-building.all@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-CCS-MailScanner: No viruses found.
X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email
Archived-At: 
Subject: [secdir] Secdir review of draft-ietf-roll-applicability-home-building-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 21:33:05 -0000

--Apple-Mail=_968C6142-35F7-43CC-B10C-FAC73C9E6D30
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

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

This document gives recommendations for the use of RPL in home =
automation and building control,
that typically provide support such things as climate and lighting =
control.  I reviewed a much earlier
version of this document, and I think this version is much improved in =
the way it scopes out the problem
and handles the security implications.  The Security Considerations =
section in particular is very
thorough.  There are a few improvements I would recommend, however:

Section 4.1.8   Security

You should  give justifications for these choices of parameters as you =
give justifications for the
other parameters described in this draft.

Section 7.1 Security considerations during initial deployment

New approaches to initial security deployment are being developed in
   [I-D.kumar-dice-dtls-relay] and
   [I-D.richardson-6tisch--security-6top].  They assume a partial
   ordering of the nodes, such that unsecured nodes are added
   sequentially with the restriction that a path between two secured
   nodes exists which passes through secured nodes only.

I found this a little hard to understand.  When does a node pass from =
being unsecured to secured?  Or does an unsecured node remain unsecured? =
If there is
a succinct way of saying this, it could go here.  Since this is only =
describing new approaches that could potentially be applied, you would =
not
want to go into a lot of detail.=20

In the home, nodes can be visually inspected by the home owner
   and simple measures like pushing buttons simultaneously on joint and
   joining devices is probably sufficient.

I think this definitely needs to be clarified!  You need to say what is =
being accomplished by pushing the buttons (device pairing)?

7.2

When nodes are lost, no additional security measures are needed, the
   network remains secure as before by not allowing the addition of new
   nodes.

I=92m not sure what this means.  Does it mean that if a node is lost, =
then it is treated as a =93new node=94 if it reappears, and is not =
allowed
to rejoin the network?

New nodes can be added by using the same protocols used for
   initial deployment.

This came right after the sentence beginning =93When nodes are lost=94 =
which said that new nodes are not added.  That contradiction needs to
be reconciled.  I=92m also not sure what =93using the same protocol=94 =
means.  Does it mean rerunning the protocol and rekeying all the nodes, =
or does
it mean using the features that protocol has for adding nodes?


Nits:

Section 1.1=20

This applicability statement
   recommends more light weight security solutions and specify the
   conditions under which these solutions are appropriate.

Should be =93specifies=94 instead of =93specify=94.  I=92m also not sure =
what is meant by =93conditions under which these solutions are =
appropriate.=94  Do
you mean light-weight as opposed to no security, or light-weight as =
opposed to heavy-weight.  Or are you talking about conditions
under which different light-weight solutions are appropriate? =46rom =
reading the rest of the draft, I would assume the last is what you mean.


I consider this document  ready with issues.


Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil


--Apple-Mail=_968C6142-35F7-43CC-B10C-FAC73C9E6D30
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

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 gives recommendations for the use of RPL in home automation and =
building control,
that typically provide support such things =
as climate and lighting control.  I reviewed a much =
earlier
version of this document, and I think this version is =
much improved in the way it scopes out the problem
and handles =
the security implications.  The Security Considerations section in =
particular is very
thorough.  There are a few =
improvements I would recommend, =
however:

Section 4.1.8   =
Security

You should  give justifications =
for these choices of parameters as you give justifications for =
the
other parameters described in this =
draft.

Section 7.1 Security considerations =
during initial deployment

New approaches =
to initial security deployment are being developed in
  =
 [I-D.kumar-dice-dtls-relay] and
  =
 [I-D.richardson-6tisch--security-6top].  They assume a =
partial
   ordering of the nodes, such that =
unsecured nodes are added
   sequentially with the =
restriction that a path between two secured
   nodes =
exists which passes through secured nodes =
only.

I found this a little hard to =
understand.  When does a node pass from being unsecured to secured? =
 Or does an unsecured node remain unsecured? If there =
is
a succinct way of saying this, it could go here. =
 Since this is only describing new approaches that could =
potentially be applied, you would not
want to go into a lot of =
detail. 

In the home, nodes can be =
visually inspected by the home owner
   and simple =
measures like pushing buttons simultaneously on joint =
and
   joining devices is probably =
sufficient.

I think this definitely needs =
to be clarified!  You need to say what is being accomplished by =
pushing the buttons (device =
pairing)?

7.2

When =
nodes are lost, no additional security measures are needed, =
the
   network remains secure as before by not allowing the =
addition of new
   nodes.

I=92m =
not sure what this means.  Does it mean that if a node is lost, =
then it is treated as a =93new node=94 if it reappears, and is not =
allowed
to rejoin the =
network?

New nodes can be added by using =
the same protocols used for
   initial =
deployment.

This came right after the =
sentence beginning =93When nodes are lost=94 which said that new nodes =
are not added.  That contradiction needs to
be =
reconciled.  I=92m also not sure what =93using the same protocol=94 =
means.  Does it mean rerunning the protocol and rekeying all the =
nodes, or does
it mean using the features that protocol has =
for adding =
nodes?


Nits:

<=
div>Section 1.1 

This applicability =
statement
   recommends more light weight security =
solutions and specify the
   conditions under which =
these solutions are appropriate.

Should be =
=93specifies=94 instead of =93specify=94.  I=92m also not sure what =
is meant by =93conditions under which these solutions are appropriate.=94 =
 Do
you mean light-weight as opposed to no security, or =
light-weight as opposed to heavy-weight.  Or are you talking about =
conditions
under which different light-weight solutions are =
appropriate? =46rom reading the rest of the draft, I would assume the =
last is what you mean.


I =
consider this document  ready with =
issues.



Catherine Meadows
Naval =
Research Laboratory
Code 5543
4555 Overlook Ave., =
S.W.
Washington DC, 20375
phone: 202-767-3490
fax: =
202-404-7942
email: catherine.meadows@nrl.navy.=
mil




=

--Apple-Mail=_968C6142-35F7-43CC-B10C-FAC73C9E6D30--


From nobody Mon Apr  6 14:37:50 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247081AC41A; Mon,  6 Apr 2015 14:37:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OasiEPGs18Pv; Mon,  6 Apr 2015 14:37:44 -0700 (PDT)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979931ACC8A; Mon,  6 Apr 2015 14:37:44 -0700 (PDT)
Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id t36LbgEw014314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 6 Apr 2015 17:37:42 -0400
From: Catherine Meadows 
Content-Type: multipart/alternative; boundary="Apple-Mail=_990CEB30-E296-4D3E-B5E9-CB3F898FC618"
Date: Mon, 6 Apr 2015 17:37:42 -0400
Message-Id: 
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-roll-applicability-home-building.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-CCS-MailScanner: No viruses found.
X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email
Archived-At: 
Subject: [secdir] Secdir review of draft-ietf-roll-applicability-home-building-09 (resend)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 21:37:47 -0000

--Apple-Mail=_990CEB30-E296-4D3E-B5E9-CB3F898FC618
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I had the draft authors=92 email address wrong on my last message, so I =
am resending it.

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

This document gives recommendations for the use of RPL in home =
automation and building control,
that typically provide support such things as climate and lighting =
control.  I reviewed a much earlier
version of this document, and I think this version is much improved in =
the way it scopes out the problem
and handles the security implications.  The Security Considerations =
section in particular is very
thorough.  There are a few improvements I would recommend, however:

Section 4.1.8   Security

You should  give justifications for these choices of parameters as you =
give justifications for the
other parameters described in this draft.

Section 7.1 Security considerations during initial deployment

New approaches to initial security deployment are being developed in
   [I-D.kumar-dice-dtls-relay] and
   [I-D.richardson-6tisch--security-6top].  They assume a partial
   ordering of the nodes, such that unsecured nodes are added
   sequentially with the restriction that a path between two secured
   nodes exists which passes through secured nodes only.

I found this a little hard to understand.  When does a node pass from =
being unsecured to secured?  Or does an unsecured node remain unsecured? =
If there is
a succinct way of saying this, it could go here.  Since this is only =
describing new approaches that could potentially be applied, you would =
not
want to go into a lot of detail.=20

In the home, nodes can be visually inspected by the home owner
   and simple measures like pushing buttons simultaneously on joint and
   joining devices is probably sufficient.

I think this definitely needs to be clarified!  You need to say what is =
being accomplished by pushing the buttons (device pairing)?

7.2

When nodes are lost, no additional security measures are needed, the
   network remains secure as before by not allowing the addition of new
   nodes.

I=92m not sure what this means.  Does it mean that if a node is lost, =
then it is treated as a =93new node=94 if it reappears, and is not =
allowed
to rejoin the network?

New nodes can be added by using the same protocols used for
   initial deployment.

This came right after the sentence beginning =93When nodes are lost=94 =
which said that new nodes are not added.  That contradiction needs to
be reconciled.  I=92m also not sure what =93using the same protocol=94 =
means.  Does it mean rerunning the protocol and rekeying all the nodes, =
or does
it mean using the features that protocol has for adding nodes?


Nits:

Section 1.1=20

This applicability statement
   recommends more light weight security solutions and specify the
   conditions under which these solutions are appropriate.

Should be =93specifies=94 instead of =93specify=94.  I=92m also not sure =
what is meant by =93conditions under which these solutions are =
appropriate.=94  Do
you mean light-weight as opposed to no security, or light-weight as =
opposed to heavy-weight.  Or are you talking about conditions
under which different light-weight solutions are appropriate? =46rom =
reading the rest of the draft, I would assume the last is what you mean.


I consider this document  ready with issues.

Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil


--Apple-Mail=_990CEB30-E296-4D3E-B5E9-CB3F898FC618
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I had =
the draft authors=92 email address wrong on my last message, so I am =
resending it.

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 gives recommendations for the use of RPL =
in home automation and building control,
that typically provide =
support such things as climate and lighting control.  I reviewed a =
much earlier
version of this document, and I think this version is =
much improved in the way it scopes out the problem
and handles the =
security implications.  The Security Considerations section in =
particular is very
thorough.  There are a few improvements I =
would recommend, however:

Section 4.1.8   =
Security

You should  give justifications for these choices =
of parameters as you give justifications for the
other parameters =
described in this draft.

Section 7.1 Security considerations =
during initial deployment

New approaches to initial security =
deployment are being developed in
  =
 [I-D.kumar-dice-dtls-relay] and
  =
 [I-D.richardson-6tisch--security-6top].  They assume a =
partial
   ordering of the nodes, such that unsecured nodes =
are added
   sequentially with the restriction that a path =
between two secured
   nodes exists which passes through =
secured nodes only.

I found this a little hard to understand. =
 When does a node pass from being unsecured to secured?  Or =
does an unsecured node remain unsecured? If there is
a succinct way =
of saying this, it could go here.  Since this is only describing =
new approaches that could potentially be applied, you would not
want =
to go into a lot of detail. 

In the home, nodes can be =
visually inspected by the home owner
   and simple measures =
like pushing buttons simultaneously on joint and
   joining =
devices is probably sufficient.

I think this definitely needs to =
be clarified!  You need to say what is being accomplished by =
pushing the buttons (device pairing)?

7.2

When nodes are =
lost, no additional security measures are needed, the
  =
 network remains secure as before by not allowing the addition of =
new
   nodes.

I=92m not sure what this means. =
 Does it mean that if a node is lost, then it is treated as a =93new =
node=94 if it reappears, and is not allowed
to rejoin the =
network?

New nodes can be added by using the same protocols used =
for
   initial deployment.

This came right after the =
sentence beginning =93When nodes are lost=94 which said that new nodes =
are not added.  That contradiction needs to
be reconciled. =
 I=92m also not sure what =93using the same protocol=94 means. =
 Does it mean rerunning the protocol and rekeying all the nodes, or =
does
it mean using the features that protocol has for adding =
nodes?


Nits:

Section 1.1 

This =
applicability statement
   recommends more light weight =
security solutions and specify the
   conditions under =
which these solutions are appropriate.

Should be =93specifies=94 =
instead of =93specify=94.  I=92m also not sure what is meant by =
=93conditions under which these solutions are appropriate.=94 =
 Do
you mean light-weight as opposed to no security, or =
light-weight as opposed to heavy-weight.  Or are you talking about =
conditions
under which different light-weight solutions are =
appropriate? =46rom reading the rest of the draft, I would assume the =
last is what you mean.


I consider this document  ready =
with issues.


Catherine Meadows
Naval =
Research Laboratory
Code 5543
4555 Overlook Ave., =
S.W.
Washington DC, 20375
phone: 202-767-3490
fax: =
202-404-7942
email: catherine.meadows@nrl.navy.=
mil




=

--Apple-Mail=_990CEB30-E296-4D3E-B5E9-CB3F898FC618--


From nobody Tue Apr  7 03:03:00 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6241A1C02; Tue,  7 Apr 2015 03:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN41rcop2Lfc; Tue,  7 Apr 2015 03:02:53 -0700 (PDT)
Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD2D1A1BF6; Tue,  7 Apr 2015 03:02:52 -0700 (PDT)
Received: from roundcube.xs4all.nl ([194.109.20.207]) by smtp-cloud3.xs4all.net with ESMTP id Cy2m1q00W4U4Moq01y2mxz; Tue, 07 Apr 2015 12:02:50 +0200
Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 07 Apr 2015 12:02:48 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Tue, 07 Apr 2015 12:02:48 +0200
From: peter van der Stok 
To: Routing Over Low power and Lossy networks 
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: 
References: 
Message-ID: 
X-Sender: stokcons@xs4all.nl (KHqKdo85l6i8RT+HxnE6e+lTyi+pbyzT)
User-Agent: XS4ALL Webmail
Archived-At: 
Cc: draft-ietf-roll-applicability-home-building.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] [Roll] Secdir review of draft-ietf-roll-applicability-home-building-09 (resend)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 10:02:59 -0000

Hi Catherine,

thanks for pointing out sources of misunderstanding. Below some 
suggestions for new text.

Considering the values of section 4.1.8; I will look for an RFC that 
explains in more detail and cite that.
@Robert, can you recommend a RFC?



> New approaches to initial security deployment are being developed in
>  [I-D.kumar-dice-dtls-relay] and
>  [I-D.richardson-6tisch--security-6top]. They assume a partial
>  ordering of the nodes, such that unsecured nodes are added
>  sequentially with the restriction that a path between two secured
>  nodes exists which passes through secured nodes only.


New approaches to initial security deployment are being developed in
  [I-D.kumar-dice-dtls-relay] and
   [I-D.richardson-6tisch--security-6top]. In these drafts an already 
secured node assists in securing an unsecured 1-hop neighbour node.
Like an onion, a new layer of unsecured nodes is secured by a former 
layer of already secured nodes until all selected nodes are secured.



> In the home, nodes can be visually inspected by the home owner
>  and simple measures like pushing buttons simultaneously on joint and
>  joining devices is probably sufficient.


In the home, nodes can be visually inspected by the home owner
  and simple measures like pushing buttons simultaneously on joint and
  joining devices are probably sufficient to guarantee that keys are 
exchanged between the two nodes without major risks of security 
breaches.



> When nodes are lost, no additional security measures are needed, the
>  network remains secure as before by not allowing the addition of new
>  nodes.


  When nodes are lost, no additional security measures are needed, the
  network remains secure as before by considering the lost nodes as new 
nodes which have to pass through the join process.


Thanks for finding the NIT.

I hope the new text above clarifies the obscure points you found.

Greetings,

Peter

Catherine Meadows schreef op 2015-04-06 23:37:
> I had the draft authors’ email address wrong on my last message, so
> I am resending it.
> 
> 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 gives recommendations for the use of RPL in home
> automation and building control,
> that typically provide support such things as climate and lighting
> control. I reviewed a much earlier
> version of this document, and I think this version is much improved in
> the way it scopes out the problem
> and handles the security implications. The Security Considerations
> section in particular is very
> thorough. There are a few improvements I would recommend, however:
> 
> Section 4.1.8 Security
> 
> You should give justifications for these choices of parameters as you
> give justifications for the
> other parameters described in this draft.
> 
> Section 7.1 Security considerations during initial deployment
> 
> New approaches to initial security deployment are being developed in
>  [I-D.kumar-dice-dtls-relay] and
>  [I-D.richardson-6tisch--security-6top]. They assume a partial
>  ordering of the nodes, such that unsecured nodes are added
>  sequentially with the restriction that a path between two secured
>  nodes exists which passes through secured nodes only.
> 
> I found this a little hard to understand. When does a node pass from
> being unsecured to secured? Or does an unsecured node remain
> unsecured? If there is
> a succinct way of saying this, it could go here. Since this is only
> describing new approaches that could potentially be applied, you would
> not
> want to go into a lot of detail.
> 
> In the home, nodes can be visually inspected by the home owner
>  and simple measures like pushing buttons simultaneously on joint and
>  joining devices is probably sufficient.
> 
> I think this definitely needs to be clarified! You need to say what is
> being accomplished by pushing the buttons (device pairing)?
> 
> 7.2
> 
> When nodes are lost, no additional security measures are needed, the
>  network remains secure as before by not allowing the addition of new
>  nodes.
> 
> I’m not sure what this means. Does it mean that if a node is lost,
> then it is treated as a “new node†if it reappears, and is not
> allowed
> to rejoin the network?
> 
> New nodes can be added by using the same protocols used for
>  initial deployment.
> 
> This came right after the sentence beginning “When nodes are lostâ€
> which said that new nodes are not added. That contradiction needs to
> be reconciled. I’m also not sure what “using the same protocolâ€
> means. Does it mean rerunning the protocol and rekeying all the nodes,
> or does
> it mean using the features that protocol has for adding nodes?
> 
> Nits:
> 
> Section 1.1
> 
> This applicability statement
>  recommends more light weight security solutions and specify the
>  conditions under which these solutions are appropriate.
> 
> Should be “specifies†instead of “specifyâ€. I’m also not
> sure what is meant by “conditions under which these solutions are
> appropriate.†Do
> you mean light-weight as opposed to no security, or light-weight as
> opposed to heavy-weight. Or are you talking about conditions
> under which different light-weight solutions are appropriate? From
> reading the rest of the draft, I would assume the last is what you
> mean.
> 
> I consider this document ready with issues.
> 
>  Catherine Meadows
> Naval Research Laboratory
> Code 5543
> 4555 Overlook Ave., S.W.
> Washington DC, 20375
> phone: 202-767-3490
> fax: 202-404-7942
> email: catherine.meadows@nrl.navy.mil
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From nobody Tue Apr  7 03:06:21 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E7E1A2130; Tue,  7 Apr 2015 03:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQDljscyCBmI; Tue,  7 Apr 2015 03:06:12 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325851A1F73; Tue,  7 Apr 2015 03:06:12 -0700 (PDT)
Received: by widdi4 with SMTP id di4so11129918wid.0; Tue, 07 Apr 2015 03:06:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=qTHiJaAZfY6Tt3S/czRdFEnZoV4UleZNNH+zbhi9NSY=; b=RKNpXX6c85hGtuj2xH534QrKUUGJRdLaT7sWTjRZQnnYuIe32+T4qrZWPH3fWPElVk ylSWJOVq60adBFQwfQmQFRfEA1FiqGtKcrtw31WQU4gXJzKbmxBRV1BmnMHPIfqWh8i6 7twNMjHMKFEzkKFIagt3irIBg95CinTeC25B198dJ8VxRsHQxWNtwVonCtJIfZDyUhLv PRSpDPV6urLpE05ai/TZy0scjbxy/5SKy1mGNvn4CDyGXwRYwRT7FF80xwxGxmIGm/5y nMms+mEWz8HIYNKi/sBJdK97NoP7pvtOTWgMugk9pmzrJck7/AQ6BgU3D+3IjKvNQjIp xVow==
X-Received: by 10.194.63.172 with SMTP id h12mr37623368wjs.48.1428401170907; Tue, 07 Apr 2015 03:06:10 -0700 (PDT)
Received: from RoniE (bzq-79-180-57-80.red.bezeqint.net. [79.180.57.80]) by mx.google.com with ESMTPSA id o5sm10709647wia.0.2015.04.07.03.06.07 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Apr 2015 03:06:10 -0700 (PDT)
From: "Roni Even" 
To: "'Colin Perkins'" , "'Robert Sparks'" 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org>
In-Reply-To: <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org>
Date: Tue, 7 Apr 2015 13:06:05 +0300
Message-ID: <035501d0711a$7856b0a0$690411e0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLAzGR07a+fOctgPDsHC1O01O6N4gIDGikzAlk6SHYBNYQq+AJmia1wAkn1xecA0xb2jwI9Vg6LAfUZxTYBDf0c5AGkRBB0AbyniQgCQquMs5qw0GDQ
Content-Language: en-us
Archived-At: 
Cc: secdir@ietf.org, payload@ietf.org, jspittka@gmail.com, iesg@ietf.org, payload-chairs@tools.ietf.org, koenvos74@gmail.com
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 10:06:16 -0000

> -----Original Message-----
> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Colin Perkins
> Sent: 06 April, 2015 9:50 PM
> To: Robert Sparks
> Cc: secdir@ietf.org; payload@ietf.org; jspittka@gmail.com; iesg@ietf.org;
> payload-chairs@tools.ietf.org; koenvos74@gmail.com; Derek Atkins
> Subject: Re: [payload] [secdir] sec-dir review of
draft-ietf-payload-rtp-opus-08
> 
> On 6 Apr 2015, at 19:44, Robert Sparks  wrote:
> > inline (particularly for Derek)
> > On 4/6/15 11:13 AM, Ben Campbell wrote:
> >> On 6 Apr 2015, at 11:09, Derek Atkins wrote:
> >>
> >>> "Timothy B. Terriberry"  writes:
> >>>
> >>>> Ben Campbell wrote:
> >>>>>> So my suggestion would be something more to the effect of:
> >>>>>>
> >>>>>> "Opus does not provide any built-in confidentiality or integrity
> >>>>>> protection. Protection requirements vary between RTP applications.
> >>>>>> See RFC 7201 and RFC 7202 for a discussion.
> >>>>
> >>>> This seems like reasonable text to me. I agree with the rationale
> >>>> that preceded it. As much as I want to see encryption everywhere, a
> >>>> payload format is not the right place to mandate it.
> >>>
> >>> As was stated already in this thread, the expected follow up drafts
> >>> for MTI security have not been written.
> >>>
> >>> I leave it up to the Security ADs who have the real power here, but
> >>> I still prefer my original wording (including the SHOULD).
> >>>
> >>> I understand your reluctance because it's a codec, but it's the
> >>> first codec to get through the process since the Perpass work, which
> >>> basically says "everything should be encrypted."  Since you cannot
> >>> go back in time to modify the existing RFCs, you can augment them
> >>> going forward by other additions.
> >>>
> >>> As for the concern about "different security requirements for
> >>> different codecs", frankly I don't buy that argument.  Either your
> >>> RTP application supports security or it doesn't.  Once it does, it
> >>> should be able to negotiate that along side the codec negotitation.
> >>> So I don't see the concern -- we're not mandating a specific
> >>> security technology, just that you SHOULD use one.  Well, that's
> >>> true regardless of the codec, isn't it?
> >>>
> >>> Or are you really saying "We don't care about security.  We just
> >>> want to be able to use this codec in existing, insecure RTP
> >>> applications without adding new securty measures"?
> >>
> >> I'm saying this is the wrong layer to solve the problem.
> >>
> >> We had some work planned to better specify this in general for RTP. I
think
> the right answer is finish that work. If we do that right, it should apply
> regardless of codec.
> >>
> > That's exactly right.
> >
> > We've had this conversation several times before. The individual payload
> documents are not the place to add the kind of guidance Derek is asking
for.
> They should be about how you put things in RTP, not how applications use
(and
> secure RTP), unless there's something unique about the payload that
interacts
> with the general mechanics for using and securing RTP.
> >
> > Stephen will remember that we've queued up work on a document that would
> describe securing unicast RTP set up with SDP (capturing the outcome of
the
> rtpsec bof at IETF68). The last I heard on the subject Dan Wing was taking
the
> token to work on that document, but it's been awhile. That's where the
effort
> should focus - an individual payload document is not the right place.
> 
> +1
> 
> As Robert, and others, say, RTP payload format documents are not the right
> place to mandate security mechanisms. This is the point of RFC7202, which
is
> about how strong security can best be defined for classes of RTP
applications.
> This is not in conflict with the perpass work, since the goal of RFC7202
is to
> show how to provide strong security.
[Roni Even] What Colin says +1

> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
> 
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload


From nobody Tue Apr  7 04:55:38 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC681B350C for ; Tue,  7 Apr 2015 04:55:35 -0700 (PDT)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhgDPua1uJHQ for ; Tue,  7 Apr 2015 04:55:30 -0700 (PDT)
Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com [209.85.220.180]) (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 60BF01B350A for ; Tue,  7 Apr 2015 04:55:30 -0700 (PDT)
Received: by qkx62 with SMTP id 62so48927213qkx.0 for ; Tue, 07 Apr 2015 04:55:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Oa9R1HU46bAKGQGYs0DPLBjAB3FRhRrghU/BNi1fSlw=; b=XiD0Nqib7Mnn+TGdXslxFZJOF1uGxE1XrgfbIZ0+Lk5jlaGElgZFJnpLJV749yMq8m MaBxqdhn4DsErHpj4eNeEsB466Wn+S0Ub1g3tXat9XFFqNJGdFdWK4aYPSOk24mtQIZn MsmfZSEeFlWmjiTTStRsvJCjSo8qtOkoPoAUnKBI8ruFNuArna5Wn9p4KxB+w8BKz1K6 ryrN/fcKDNhDr1RGpBbCMDSu/AD9I3byWWF522rXIINYUS9zJedhrmnh3q5O/cNMFhxI FCFQmrWiKOJljUnUA4+AKzdY1RbZBfk5DTzxH39ojfk+gnvDoc3i8fqjZ1KvsgZr7xSj LQxQ==
X-Gm-Message-State: ALoCoQnJBnuBS08+G50D/NANc87nlsZvc5TfMahVI4pTqxWYllcDMPohogy31HDWE3u4v6b/V5kG
X-Received: by 10.55.52.129 with SMTP id b123mr37517922qka.94.1428407729547; Tue, 07 Apr 2015 04:55:29 -0700 (PDT)
Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id e110sm5263271qga.13.2015.04.07.04.55.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2015 04:55:28 -0700 (PDT)
Message-ID: <5523C5AE.7040108@mozilla.com>
Date: Tue, 07 Apr 2015 07:55:26 -0400
From: Jean-Marc Valin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Roni Even , 'Colin Perkins' , 'Robert Sparks' 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com>
In-Reply-To: <035501d0711a$7856b0a0$690411e0$@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: secdir@ietf.org, payload@ietf.org, jspittka@gmail.com, iesg@ietf.org, payload-chairs@tools.ietf.org, koenvos74@gmail.com
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 11:55:35 -0000

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

Does anyone object to this earlier proposal?

"Opus does not provide any built-in confidentiality or integrity
protection. Protection requirements vary between RTP applications. See
RFC 7201 and RFC 7202 for a discussion."

If not, that's probably what should go in the RFC (assuming it works
for Kathleen Moriarty's DISCUSS too).

	Jean-Marc

On 07/04/15 06:06 AM, Roni Even wrote:
> 
> 
>> -----Original Message----- From: payload
>> [mailto:payload-bounces@ietf.org] On Behalf Of Colin Perkins 
>> Sent: 06 April, 2015 9:50 PM To: Robert Sparks Cc:
>> secdir@ietf.org; payload@ietf.org; jspittka@gmail.com;
>> iesg@ietf.org; payload-chairs@tools.ietf.org;
>> koenvos74@gmail.com; Derek Atkins Subject: Re: [payload] [secdir]
>> sec-dir review of
> draft-ietf-payload-rtp-opus-08
>> 
>> On 6 Apr 2015, at 19:44, Robert Sparks 
>> wrote:
>>> inline (particularly for Derek) On 4/6/15 11:13 AM, Ben
>>> Campbell wrote:
>>>> On 6 Apr 2015, at 11:09, Derek Atkins wrote:
>>>> 
>>>>> "Timothy B. Terriberry"  writes:
>>>>> 
>>>>>> Ben Campbell wrote:
>>>>>>>> So my suggestion would be something more to the
>>>>>>>> effect of:
>>>>>>>> 
>>>>>>>> "Opus does not provide any built-in confidentiality
>>>>>>>> or integrity protection. Protection requirements vary
>>>>>>>> between RTP applications. See RFC 7201 and RFC 7202
>>>>>>>> for a discussion.
>>>>>> 
>>>>>> This seems like reasonable text to me. I agree with the
>>>>>> rationale that preceded it. As much as I want to see
>>>>>> encryption everywhere, a payload format is not the right
>>>>>> place to mandate it.
>>>>> 
>>>>> As was stated already in this thread, the expected follow
>>>>> up drafts for MTI security have not been written.
>>>>> 
>>>>> I leave it up to the Security ADs who have the real power
>>>>> here, but I still prefer my original wording (including the
>>>>> SHOULD).
>>>>> 
>>>>> I understand your reluctance because it's a codec, but it's
>>>>> the first codec to get through the process since the
>>>>> Perpass work, which basically says "everything should be
>>>>> encrypted."  Since you cannot go back in time to modify the
>>>>> existing RFCs, you can augment them going forward by other
>>>>> additions.
>>>>> 
>>>>> As for the concern about "different security requirements
>>>>> for different codecs", frankly I don't buy that argument.
>>>>> Either your RTP application supports security or it
>>>>> doesn't.  Once it does, it should be able to negotiate that
>>>>> along side the codec negotitation. So I don't see the
>>>>> concern -- we're not mandating a specific security
>>>>> technology, just that you SHOULD use one.  Well, that's 
>>>>> true regardless of the codec, isn't it?
>>>>> 
>>>>> Or are you really saying "We don't care about security.  We
>>>>> just want to be able to use this codec in existing,
>>>>> insecure RTP applications without adding new securty
>>>>> measures"?
>>>> 
>>>> I'm saying this is the wrong layer to solve the problem.
>>>> 
>>>> We had some work planned to better specify this in general
>>>> for RTP. I
> think
>> the right answer is finish that work. If we do that right, it
>> should apply regardless of codec.
>>>> 
>>> That's exactly right.
>>> 
>>> We've had this conversation several times before. The
>>> individual payload
>> documents are not the place to add the kind of guidance Derek is
>> asking
> for.
>> They should be about how you put things in RTP, not how
>> applications use
> (and
>> secure RTP), unless there's something unique about the payload
>> that
> interacts
>> with the general mechanics for using and securing RTP.
>>> 
>>> Stephen will remember that we've queued up work on a document
>>> that would
>> describe securing unicast RTP set up with SDP (capturing the
>> outcome of
> the
>> rtpsec bof at IETF68). The last I heard on the subject Dan Wing
>> was taking
> the
>> token to work on that document, but it's been awhile. That's
>> where the
> effort
>> should focus - an individual payload document is not the right
>> place.
>> 
>> +1
>> 
>> As Robert, and others, say, RTP payload format documents are not
>> the right place to mandate security mechanisms. This is the point
>> of RFC7202, which
> is
>> about how strong security can best be defined for classes of RTP
> applications.
>> This is not in conflict with the perpass work, since the goal of
>> RFC7202
> is to
>> show how to provide strong security.
> [Roni Even] What Colin says +1
> 
>> 
>> -- Colin Perkins https://csperkins.org/
>> 
>> 
>> 
>> 
>> _______________________________________________ payload mailing
>> list payload@ietf.org 
>> https://www.ietf.org/mailman/listinfo/payload
> 
> _______________________________________________ payload mailing
> list payload@ietf.org 
> https://www.ietf.org/mailman/listinfo/payload
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVI8WrAAoJEJ6/8sItn9q9czQH/jWr/wOYnF/Np5pyGT/VVLQ4
CtfYkhfI3FlwZzz0xldUW7pkiiXMXAV99pQHVV85JQ+yBjpYS+TgScoLmlXKftqt
Et41PYxD4MTA/HMqR+ayIXEwu0xLKGKZiCzeI3/4eyJq2yrMa/LoYv0E+2d9+Eow
isDpaXfayJ8OmpAEml52ErJm3bRdvuEioIarVgFqgA+jBg8F01jU34PHcw18ppnK
c93yERmrCK8wDizGYnICrRpdnLojKZ3aR+xfdFGW3JA5XbkGyR3uJc6ACM7r2ap1
UjkYSYviOjSVk2vRnNzqi1pcnTpTjuWxE+GQTJ9o+rr1M3zESWBvYoLVyaenAQg=
=iesF
-----END PGP SIGNATURE-----


From nobody Tue Apr  7 06:34:14 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9360C1B3578; Tue,  7 Apr 2015 06:34:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evARzNh8jESj; Tue,  7 Apr 2015 06:34:05 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68C41B35BB; Tue,  7 Apr 2015 06:33:25 -0700 (PDT)
Received: by wiax7 with SMTP id x7so10911551wia.0; Tue, 07 Apr 2015 06:33:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=Z4NhQLbpjxCoAdHBWJh98hY3TrZjEUyyODi/z0woSE4=; b=T96IekD+u3djS5Lwa8hDydAR5sjf4GuWQpZYnVUzFldpwsXrYGQjTSpfzCTIpliZJZ 1GeXm6Swff6i9YYDHPWcjaBac8ufTZp/6UbVTkupdYg2xkF0EVmZoficVg8mhX9e9jza gPLXJeOWPz0C4IK2K3dnOg9c1kNhDJvJhIoSS1XDPJhuR8T+Mk2OvUYVW2DO2W6kTp1G 0dHobI2F5vkj0260hHpZcQWQl0s2JrjAcdatTG5I+pXmiyY2oU7vS/RlrHggrv20rr+e +2FsQrj4QdQzlOWuQiyIAddCHvkgNNlUhwYpwwPZ+0eIRNAmO60r/1M3yfbO05pSbwyD CLpw==
X-Received: by 10.194.110.38 with SMTP id hx6mr39248516wjb.128.1428413604710;  Tue, 07 Apr 2015 06:33:24 -0700 (PDT)
Received: from RoniE (bzq-79-180-57-80.red.bezeqint.net. [79.180.57.80]) by mx.google.com with ESMTPSA id kr5sm11017404wjc.1.2015.04.07.06.33.21 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Apr 2015 06:33:23 -0700 (PDT)
From: "Roni Even" 
To: "'Jean-Marc Valin'" , "'Colin Perkins'" , "'Robert Sparks'" 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>
In-Reply-To: <5523C5AE.7040108@mozilla.com>
Date: Tue, 7 Apr 2015 16:33:18 +0300
Message-ID: <036a01d07137$6b6add90$424098b0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLAzGR07a+fOctgPDsHC1O01O6N4gIDGikzAlk6SHYBNYQq+AJmia1wAkn1xecA0xb2jwI9Vg6LAfUZxTYBDf0c5AGkRBB0AbyniQgCQquMswFRQeCNAchdTqCamD0VsA==
Content-Language: en-us
Archived-At: 
Cc: secdir@ietf.org, payload@ietf.org, jspittka@gmail.com, iesg@ietf.org, payload-chairs@tools.ietf.org, koenvos74@gmail.com
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 13:34:09 -0000

Hi Jean-Marc,
I think this sounds good, I suggest also to mention RFC6562 
Roni

> -----Original Message-----
> From: Jean-Marc Valin [mailto:jmvalin@mozilla.com]
> Sent: 07 April, 2015 2:55 PM
> To: Roni Even; 'Colin Perkins'; 'Robert Sparks'
> Cc: secdir@ietf.org; payload@ietf.org; jspittka@gmail.com; iesg@ietf.org;
> payload-chairs@tools.ietf.org; koenvos74@gmail.com; 'Derek Atkins'
> Subject: Re: [payload] [secdir] sec-dir review of
draft-ietf-payload-rtp-opus-08
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Does anyone object to this earlier proposal?
> 
> "Opus does not provide any built-in confidentiality or integrity
protection.
> Protection requirements vary between RTP applications. See RFC 7201 and
RFC
> 7202 for a discussion."
> 
> If not, that's probably what should go in the RFC (assuming it works for
> Kathleen Moriarty's DISCUSS too).
> 
> 	Jean-Marc
> 
> On 07/04/15 06:06 AM, Roni Even wrote:
> >
> >
> >> -----Original Message----- From: payload
> >> [mailto:payload-bounces@ietf.org] On Behalf Of Colin Perkins
> >> Sent: 06 April, 2015 9:50 PM To: Robert Sparks Cc:
> >> secdir@ietf.org; payload@ietf.org; jspittka@gmail.com; iesg@ietf.org;
> >> payload-chairs@tools.ietf.org; koenvos74@gmail.com; Derek Atkins
> >> Subject: Re: [payload] [secdir] sec-dir review of
> > draft-ietf-payload-rtp-opus-08
> >>
> >> On 6 Apr 2015, at 19:44, Robert Sparks 
> >> wrote:
> >>> inline (particularly for Derek) On 4/6/15 11:13 AM, Ben Campbell
> >>> wrote:
> >>>> On 6 Apr 2015, at 11:09, Derek Atkins wrote:
> >>>>
> >>>>> "Timothy B. Terriberry"  writes:
> >>>>>
> >>>>>> Ben Campbell wrote:
> >>>>>>>> So my suggestion would be something more to the effect of:
> >>>>>>>>
> >>>>>>>> "Opus does not provide any built-in confidentiality or
> >>>>>>>> integrity protection. Protection requirements vary between RTP
> >>>>>>>> applications. See RFC 7201 and RFC 7202 for a discussion.
> >>>>>>
> >>>>>> This seems like reasonable text to me. I agree with the rationale
> >>>>>> that preceded it. As much as I want to see encryption everywhere,
> >>>>>> a payload format is not the right place to mandate it.
> >>>>>
> >>>>> As was stated already in this thread, the expected follow up
> >>>>> drafts for MTI security have not been written.
> >>>>>
> >>>>> I leave it up to the Security ADs who have the real power here,
> >>>>> but I still prefer my original wording (including the SHOULD).
> >>>>>
> >>>>> I understand your reluctance because it's a codec, but it's the
> >>>>> first codec to get through the process since the Perpass work,
> >>>>> which basically says "everything should be encrypted."  Since you
> >>>>> cannot go back in time to modify the existing RFCs, you can
> >>>>> augment them going forward by other additions.
> >>>>>
> >>>>> As for the concern about "different security requirements for
> >>>>> different codecs", frankly I don't buy that argument.
> >>>>> Either your RTP application supports security or it doesn't.  Once
> >>>>> it does, it should be able to negotiate that along side the codec
> >>>>> negotitation. So I don't see the concern -- we're not mandating a
> >>>>> specific security technology, just that you SHOULD use one.  Well,
> >>>>> that's true regardless of the codec, isn't it?
> >>>>>
> >>>>> Or are you really saying "We don't care about security.  We just
> >>>>> want to be able to use this codec in existing, insecure RTP
> >>>>> applications without adding new securty measures"?
> >>>>
> >>>> I'm saying this is the wrong layer to solve the problem.
> >>>>
> >>>> We had some work planned to better specify this in general for RTP.
> >>>> I
> > think
> >> the right answer is finish that work. If we do that right, it should
> >> apply regardless of codec.
> >>>>
> >>> That's exactly right.
> >>>
> >>> We've had this conversation several times before. The individual
> >>> payload
> >> documents are not the place to add the kind of guidance Derek is
> >> asking
> > for.
> >> They should be about how you put things in RTP, not how applications
> >> use
> > (and
> >> secure RTP), unless there's something unique about the payload that
> > interacts
> >> with the general mechanics for using and securing RTP.
> >>>
> >>> Stephen will remember that we've queued up work on a document that
> >>> would
> >> describe securing unicast RTP set up with SDP (capturing the outcome
> >> of
> > the
> >> rtpsec bof at IETF68). The last I heard on the subject Dan Wing was
> >> taking
> > the
> >> token to work on that document, but it's been awhile. That's where
> >> the
> > effort
> >> should focus - an individual payload document is not the right place.
> >>
> >> +1
> >>
> >> As Robert, and others, say, RTP payload format documents are not the
> >> right place to mandate security mechanisms. This is the point of
> >> RFC7202, which
> > is
> >> about how strong security can best be defined for classes of RTP
> > applications.
> >> This is not in conflict with the perpass work, since the goal of
> >> RFC7202
> > is to
> >> show how to provide strong security.
> > [Roni Even] What Colin says +1
> >
> >>
> >> -- Colin Perkins https://csperkins.org/
> >>
> >>
> >>
> >>
> >> _______________________________________________ payload mailing
> list
> >> payload@ietf.org https://www.ietf.org/mailman/listinfo/payload
> >
> > _______________________________________________ payload mailing list
> > payload@ietf.org https://www.ietf.org/mailman/listinfo/payload
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJVI8WrAAoJEJ6/8sItn9q9czQH/jWr/wOYnF/Np5pyGT/VVLQ4
> CtfYkhfI3FlwZzz0xldUW7pkiiXMXAV99pQHVV85JQ+yBjpYS+TgScoLmlXKftqt
> Et41PYxD4MTA/HMqR+ayIXEwu0xLKGKZiCzeI3/4eyJq2yrMa/LoYv0E+2d9+Eow
> isDpaXfayJ8OmpAEml52ErJm3bRdvuEioIarVgFqgA+jBg8F01jU34PHcw18ppnK
> c93yERmrCK8wDizGYnICrRpdnLojKZ3aR+xfdFGW3JA5XbkGyR3uJc6ACM7r2ap1
> UjkYSYviOjSVk2vRnNzqi1pcnTpTjuWxE+GQTJ9o+rr1M3zESWBvYoLVyaenAQg=
> =iesF
> -----END PGP SIGNATURE-----


From nobody Tue Apr  7 07:42:14 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7391B366E; Tue,  7 Apr 2015 07:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVhV0nFlWts1; Tue,  7 Apr 2015 07:41:54 -0700 (PDT)
Received: from mailscan1.extendcp.co.uk (mailscan38.extendcp.co.uk [176.32.230.32]) (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 4DA441B3660; Tue,  7 Apr 2015 07:41:54 -0700 (PDT)
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.hi.local) by mailscan-g74.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1YfUgk-0007bn-2G; Tue, 07 Apr 2015 15:41:14 +0100
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1YfUgi-0006UG-Cw; Tue, 07 Apr 2015 15:41:14 +0100
Received: from host86-156-208-9.range86-156.btcentralplus.com ([86.156.208.9] helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1YfUgQ-0007KV-7F; Tue, 07 Apr 2015 15:40:54 +0100
Message-ID: <5523EC71.1020701@gridmerge.com>
Date: Tue, 07 Apr 2015 15:40:49 +0100
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Routing Over Low power and Lossy networks ,  secdir@ietf.org, iesg@ietf.org,  draft-ietf-roll-applicability-home-building.all@tools.ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030903090900070502060301"
X-Authenticated-As: robert.cragie@gridmerge.com
X-Extend-Src: mailout
Archived-At: 
Subject: Re: [secdir] [Roll] Secdir review of draft-ietf-roll-applicability-home-building-09 (resend)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 14:42:03 -0000

This is a cryptographically signed message in MIME format.

--------------ms030903090900070502060301
Content-Type: multipart/alternative;
 boundary="------------070408000005020808070301"

This is a multi-part message in MIME format.
--------------070408000005020808070301
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Catherine,

In addition to Peter's comments, here are my comments inline, bracketed=20
by 

Robert

On 06/04/2015 22:37, Catherine Meadows wrote:
> I had the draft authors=E2=80=99 email address wrong on my last message=
, so I=20
> am resending it.
>
> 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 gives recommendations for the use of RPL in home=20
> automation and building control,
> that typically provide support such things as climate and lighting=20
> control.  I reviewed a much earlier
> version of this document, and I think this version is much improved in =

> the way it scopes out the problem
> and handles the security implications.  The Security Considerations=20
> section in particular is very
> thorough.  There are a few improvements I would recommend, however:
>
> Section 4.1.8   Security
>
> You should  give justifications for these choices of parameters as you =

> give justifications for the
> other parameters described in this draft.

The parameters are in RFC 6550. Some explanation could be added, for=20
example:


If RPL is used with secured messages, the following RPL security=20
parameter values are recommended to provide a basic level of security:

    o  Counter Time Flag: T =3D '0': Do not use timestamp in the Counter =

Field. Counters based on timestamps are typically more applicable to=20
industrial networks where strict timing synchronization between nodes is =

often implemented. Home and building networks typically do not implement =

such strict timing synchronization therefore a monotonically increasing=20
counter is more appropriate.

    o  Algorithm =3D '0': Use Counter with Cipher Block Chaining Message =

Authentication Code (CBC-MAC Mode) (CCM) with Advanced Encryption=20
Standard (AES)-128. This is the only assigned mode at present.

    o  Key Identifier Mode; KIM =3D '10': Use group key, Key Source=20
present, Key Index present. Given the relatively confined perimeter of a =

home or building network, a group key is usually sufficient to protect=20
RPL messages sent between nodes. The use of the Key Source field allows=20
multiple group keys to be used within the network.

    o  Security Level; LVL =3D 0: Use MAC-32. This is recommended as=20
integrity protection for RPL messages is the basic requirement.=20
Encryption is unlikely to be necessary given the relatively=20
non-confidential nature of RPL message payloads.


>
> Section 7.1 Security considerations during initial deployment
>
> New approaches to initial security deployment are being developed in
>    [I-D.kumar-dice-dtls-relay] and
>    [I-D.richardson-6tisch--security-6top].  They assume a partial
>    ordering of the nodes, such that unsecured nodes are added
>    sequentially with the restriction that a path between two secured
>    nodes exists which passes through secured nodes only.
>
> I found this a little hard to understand.  When does a node pass from=20
> being unsecured to secured?  Or does an unsecured node remain=20
> unsecured? If there is
> a succinct way of saying this, it could go here.  Since this is only=20
> describing new approaches that could potentially be applied, you would =
not
> want to go into a lot of detail.

I would clarify as follows, in addition to Peter's suggestion:


New approaches to initial security deployment are being developed in=20
[I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top].=20
They assume a partial ordering of the nodes, such that unsecured nodes=20
are added sequentially with the restriction that a path between two=20
secured nodes exists which passes through secured nodes only.


New approaches to initial security deployment are being developed in=20
[I-D.kumar-dice-dtls-relay] and[I-D.richardson-6tisch-security-6top]. In =

these drafts an already secured node at the perimeter of the network,=20
which is one hop away from an unsecured node wishing to access the=20
network, assists in transporting security and configuration traffic=20
between the unsecured node and the authenticator/commissioner. Once=20
secured and configured, the new node extends the perimeter of the=20
network in an "onion ring" fashion until all nodes have been secured and =

configured.


>
> In the home, nodes can be visually inspected by the home owner
>    and simple measures like pushing buttons simultaneously on joint and=

>    joining devices is probably sufficient.
>
> I think this definitely needs to be clarified!  You need to say what=20
> is being accomplished by pushing the buttons (device pairing)?

I would clarify as follows, in addition to Peter's suggestion:


In the home, nodes can be visually inspected by the home owner and=20
simple measures like pushing buttons simultaneously on joint and joining =

devices is probably sufficient.


In the home, nodes can be visually inspected by the home owner and a=20
simple procedure, e.g. pushing buttons simultaneously on an already=20
secured device and an unsecured joining device is usually sufficient to=20
ensure that the unsecured joining device is authenticated and configured =

securely, and paired appropriately.


>
> 7.2
>
> When nodes are lost, no additional security measures are needed, the
>    network remains secure as before by not allowing the addition of new=

>    nodes.
>
> I=E2=80=99m not sure what this means.  Does it mean that if a node is l=
ost,=20
> then it is treated as a =E2=80=9Cnew node=E2=80=9D if it reappears, and=
 is not allowed
> to rejoin the network?
>
> New nodes can be added by using the same protocols used for
>    initial deployment.
>
> This came right after the sentence beginning =E2=80=9CWhen nodes are lo=
st=E2=80=9D=20
> which said that new nodes are not added.  That contradiction needs to
> be reconciled.  I=E2=80=99m also not sure what =E2=80=9Cusing the same =
protocol=E2=80=9D=20
> means.  Does it mean rerunning the protocol and rekeying all the=20
> nodes, or does
> it mean using the features that protocol has for adding nodes?

I would rewrite this somewhat as the intent is unclear. I believe the=20
intent is as follows:


When nodes are lost, no additional security measures are needed, the=20
network remains secure as before by not allowing the addition of new=20
nodes. New nodes can be added by using the same protocols used for=20
initial deployment.  Some protocols may need a state change to a subset=20
of the secured nodes, other protocols only need the presence of a=20
"trusted" installation node [RFC6345], [RFC5191], or=20
[I-D.kumar-dice-dtls-relay].


Normally, the network remains secure by not allowing the addition of new =

nodes. If a new node needs to be added to the network, the network is=20
usually configured to allow the new node to join via an assisting node=20
in the manner described in Section 7.1. If an existing node becomes=20
lost, it is usually possible to re-key all other existing nodes to=20
isolate the lost node to ensure that, should it be found again, it has=20
to re-join as if it were a new node.



>
>
> Nits:
>
> Section 1.1
>
> This applicability statement
>    recommends more light weight security solutions and specify the
>    conditions under which these solutions are appropriate.
>
> Should be =E2=80=9Cspecifies=E2=80=9D instead of =E2=80=9Cspecify=E2=80=
=9D.  I=E2=80=99m also not sure what is=20
> meant by =E2=80=9Cconditions under which these solutions are appropriat=
e.=E2=80=9D  Do
> you mean light-weight as opposed to no security, or light-weight as=20
> opposed to heavy-weight.  Or are you talking about conditions
> under which different light-weight solutions are appropriate? From=20
> reading the rest of the draft, I would assume the last is what you mean=
=2E

I would reword as follows:


This applicability statement recommends more light weight security=20
solutions and specify the conditions under which these solutions are=20
appropriate.


This applicability statement recommends lighter weight security=20
solutions appropriate for home and building environments and indicates=20
why these solutions are appropriate.


>
>
> I consider this document  ready with issues.
>
> Catherine Meadows
> Naval Research Laboratory
> Code 5543
> 4555 Overlook Ave., S.W.
> Washington DC, 20375
> phone: 202-767-3490
> fax: 202-404-7942
> email: catherine.meadows@nrl.navy.mil=20
> 
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


--------------070408000005020808070301
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    Hi Catherine,

    

    In addition to Peter's comments, here are my comments inline,
    bracketed by <RCC></RCC>

    

    Robert

    

    
On 06/04/2015 22:37, Catherine Meadows=

      wrote:

    

    

      
      I had the draft authors=E2=80=99 email address wrong on my last mes=
sage,
      so I am resending it.
      


      

      
I have reviewed this document as part of the security
        directorate's=C2=A0

        ongoing effort to review all IETF documents being processed by
        the=C2=A0

        IESG. =C2=A0These comments were written primarily for the benefit=
 of
        the=C2=A0

        security area directors. =C2=A0Document editors and WG chairs sho=
uld
        treat=C2=A0

        these comments just like any other last call comments.

        

        This document gives recommendations for the use of RPL in home
        automation and building control,

        that typically provide support such things as climate and
        lighting control. =C2=A0I reviewed a much earlier

        version of this document, and I think this version is much
        improved in the way it scopes out the problem

        and handles the security implications. =C2=A0The Security
        Considerations section in particular is very

        thorough. =C2=A0There are a few improvements I would recommend,
        however:

        

        Section 4.1.8 =C2=A0 Security

        

        You should =C2=A0give justifications for these choices of paramet=
ers
        as you give justifications for the

        other parameters described in this draft.

      

    

    <RCC>

    The parameters are in RFC 6550. Some explanation could be added, for
    example:

    

    <new>

    If RPL is used with secured messages, the following RPL security
    parameter values are recommended to provide a basic level of
    security:

    

    =C2=A0=C2=A0 o=C2=A0 Counter Time Flag: T =3D '0': Do not use timesta=
mp in the
    Counter Field. Counters based on timestamps are typically more
    applicable to industrial networks where strict timing
    synchronization between nodes is often implemented. Home and
    building networks typically do not implement such strict timing
    synchronization therefore a monotonically increasing counter is more
    appropriate.

    

    =C2=A0=C2=A0 o=C2=A0 Algorithm =3D '0': Use Counter with Cipher Block=
 Chaining
    Message Authentication Code (CBC-MAC Mode) (CCM) with Advanced
    Encryption Standard (AES)-128. This is the only assigned mode at
    present.

    

    =C2=A0=C2=A0 o=C2=A0 Key Identifier Mode; KIM =3D '10': Use group key=
, Key Source
    present, Key Index present. Given the relatively confined perimeter
    of a home or building network, a group key is usually sufficient to
    protect RPL messages sent between nodes. The use of the Key Source
    field allows multiple group keys to be used within the network.

    

    =C2=A0=C2=A0 o=C2=A0 Security Level; LVL =3D 0: Use MAC-32. This is r=
ecommended as
    integrity protection for RPL messages is the basic requirement.
    Encryption is unlikely to be necessary given the relatively
    non-confidential nature of RPL message payloads.

    </new>

    </RCC>

    

      


        Section 7.1 Security considerations during initial deployment
=

        

        New approaches to initial security deployment are being
        developed in

        =C2=A0 =C2=A0[I-D.kumar-dice-dtls-relay] and

        =C2=A0 =C2=A0[I-D.richardson-6tisch--security-6top]. =C2=A0They a=
ssume a
        partial

        =C2=A0 =C2=A0ordering of the nodes, such that unsecured nodes are=
 added

        =C2=A0 =C2=A0sequentially with the restriction that a path betwee=
n two
        secured

        =C2=A0 =C2=A0nodes exists which passes through secured nodes only=
=2E

        

        I found this a little hard to understand. =C2=A0When does a node =
pass
        from being unsecured to secured? =C2=A0Or does an unsecured node
        remain unsecured? If there is

        a succinct way of saying this, it could go here. =C2=A0Since this=
 is
        only describing new approaches that could potentially be
        applied, you would not

        want to go into a lot of detail. 

      

    

    <RCC>

    I would clarify as follows, in addition to Peter's suggestion:

    

    <old>

    New approaches to initial security deployment are being developed in
    [I-D.kumar-dice-dtls-relay] and
    [I-D.richardson-6tisch--security-6top]. They assume a partial
    ordering of the nodes, such that unsecured nodes are added
    sequentially with the restriction that a path between two secured
    nodes exists which passes through secured nodes only.

    </old>

    <new>

    New approaches to initial security deployment are being developed in
    [I-D.kumar-dice-dtls-relay]
    and[I-D.richardson-6tisch-security-6top]. In these drafts an already
    secured node at the perimeter of the network, which is one hop away
    from an unsecured node wishing to access the network, assists in
    transporting security and configuration traffic between the
    unsecured node and the authenticator/commissioner. Once secured and
    configured, the new node extends the perimeter of the network in an
    "onion ring" fashion until all nodes have been secured and
    configured.

    </new>

    </RCC>

    

      


        In the home, nodes can be visually inspected by the home owner
        =C2=A0 =C2=A0and simple measures like pushing buttons simultaneou=
sly on
        joint and

        =C2=A0 =C2=A0joining devices is probably sufficient.

        

        I think this definitely needs to be clarified! =C2=A0You need to =
say
        what is being accomplished by pushing the buttons (device
        pairing)?

      

    

    <RCC>

    I would clarify as follows, in addition to Peter's suggestion:

    

    <old>

    In the home, nodes can be visually inspected by the home owner and
    simple measures like pushing buttons simultaneously on joint and
    joining devices is probably sufficient. 

    </old>

    <new>

    In the home, nodes can be visually inspected by the home owner and a
    simple procedure, e.g. pushing buttons simultaneously on an already
    secured device and an unsecured joining device is usually sufficient
    to ensure that the unsecured joining device is authenticated and
    configured securely, and paired appropriately.

    </new> 

    </RCC>

    

      


        7.2

        

        When nodes are lost, no additional security measures are needed,
        the

        =C2=A0 =C2=A0network remains secure as before by not allowing the=
 addition
        of new

        =C2=A0 =C2=A0nodes.

        

        I=E2=80=99m not sure what this means. =C2=A0Does it mean that if =
a node is
        lost, then it is treated as a =E2=80=9Cnew node=E2=80=9D if it re=
appears, and is
        not allowed

        to rejoin the network?

        

        New nodes can be added by using the same protocols used for

        =C2=A0 =C2=A0initial deployment.

        

        This came right after the sentence beginning =E2=80=9CWhen nodes =
are
        lost=E2=80=9D which said that new nodes are not added. =C2=A0That=

        contradiction needs to

        be reconciled. =C2=A0I=E2=80=99m also not sure what =E2=80=9Cusin=
g the same protocol=E2=80=9D
        means. =C2=A0Does it mean rerunning the protocol and rekeying all=
 the
        nodes, or does

        it mean using the features that protocol has for adding nodes?
      

    

    <RCC>

    I would rewrite this somewhat as the intent is unclear. I believe
    the intent is as follows:

    

    <old>

    When nodes are lost, no additional security measures are needed, the
    network remains secure as before by not allowing the addition of new
    nodes. New nodes can be added by using the same protocols used for
    initial deployment.=C2=A0 Some protocols may need a state change to a=

    subset of the secured nodes, other protocols only need the presence
    of a "trusted" installation node [RFC6345], [RFC5191], or
    [I-D.kumar-dice-dtls-relay].

    </old>

    <new>

    Normally, the network remains secure by not allowing the addition of
    new nodes. If a new node needs to be added to the network, the
    network is usually configured to allow the new node to join via an
    assisting node in the manner described in Section 7.1. If an
    existing node becomes lost, it is usually possible to re-key all
    other existing nodes to isolate the lost node to ensure that, should
    it be found again, it has to re-join as if it were a new node.

    </new>

    </RCC>

    

    

      


        

        Nits:

        

        Section 1.1=C2=A0

        

        This applicability statement

        =C2=A0 =C2=A0recommends more light weight security solutions and =
specify
        the

        =C2=A0 =C2=A0conditions under which these solutions are appropria=
te.

        

        Should be =E2=80=9Cspecifies=E2=80=9D instead of =E2=80=9Cspecify=
=E2=80=9D. =C2=A0I=E2=80=99m also not sure
        what is meant by =E2=80=9Cconditions under which these solutions =
are
        appropriate.=E2=80=9D =C2=A0Do

        you mean light-weight as opposed to no security, or light-weight
        as opposed to heavy-weight. =C2=A0Or are you talking about condit=
ions

        under which different light-weight solutions are appropriate?
        From reading the rest of the draft, I would assume the last is
        what you mean.

      

    

    <RCC>

    I would reword as follows:

    

    <old>

    This applicability statement recommends more light weight security
    solutions and specify the conditions under which these solutions are
    appropriate.

    </old>

    <new>

    This applicability statement recommends lighter weight security
    solutions appropriate for home and building environments and
    indicates why these solutions are appropriate.

    </new>

    </RCC>

    

      


        

        I consider this document =C2=A0ready with issues.

        

        

          Catherine
            Meadows

            Naval Research Laboratory

            Code 5543

            4555 Overlook Ave., S.W.

            Washington DC, 20375

            phone: 202-767-3490

            fax: 202-404-7942

            email:=C2=A0catherine.me=
adows@nrl.navy.mil
        

        

      

      

      

      

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


    

    

  


--------------070408000005020808070301--

--------------ms030903090900070502060301
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRnzCC
BXQwggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UE
BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w
MDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS
R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g
Q0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3
o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkU
a+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwU
q37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PK
LrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwbKIpcInu0q5jZ7uBRg8MJ
Rk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNaJLS6qVY9z2+q/0lYvvCo
//S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx688O3T2plqFIvTz3r7UN
IkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7199QalVGv6CjKGF/
cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BCiH+jMzouXB5B
EYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4onZzMv7NR
2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD
VR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E
BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3Js
LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEE
KTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEB
DAUAA4IBAQBkv4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1
uouhbcRUCXXH4ycOXYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VX
aX2S2FLKc4G/HPPmuG5mEQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeW
ukhNkPKUyKlzousGeyOd3qLzTVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla
4EEkHbKPFWBYR9vvbkb9FfXZX5qz29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCC
A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC
R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n
9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz
KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF
lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t
GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV
HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI
MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j
cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG
CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N
T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh
LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81
zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa
l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp
WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM
UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW
CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X
72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60
ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv
dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN
XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggY5
MIIFIaADAgECAhEAkJNVgmy0T3j/sFnejfTMyTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa
MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQwOTE2MDAwMDAwWhcN
MTcwOTE1MjM1OTU5WjCCATcxCzAJBgNVBAYTAkdCMRAwDgYDVQQREwdXRjQgNFdBMRcwFQYD
VQQIEw5XZXN0IFlvcmtzaGlyZTESMBAGA1UEBxMJV2FrZWZpZWxkMRQwEgYDVQQJEwtHcmFu
Z2UgTW9vcjEfMB0GA1UECRMWODkgR3JlZW5maWVsZCBDcmVzY2VudDEXMBUGA1UEChMOR3Jp
ZG1lcmdlIEx0ZC4xNDAyBgNVBAsTK0lzc3VlZCB0aHJvdWdoIEdyaWRtZXJnZSBMdGQuIEUt
UEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT
DVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl
LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTtrEYc/EYQZDn+/Byj786j
qzQJukVnEZ0qu6G8Y/QZphmITLPJJCxlCvJhRGCt5zRDfwG1lM0k77mTVP166mrPMKfEbhAF
mhW54app3f02j/E0T73Wkwqhc2xj+vs6ox+kXRZIiEa/VY1TXd8ALZZAJ2uPQm+3QByE0cO6
7Q7jr5dmZuXAuygh5Q7MvzxL0vKmxhJ1n0veVDwk+BifimRX+HHU3XTGrqySkiN4Amdm7ESD
qdO7UAoezIGZoA/fTJE9CS4f4tVXcKhfGlp/Tw3K9q9cp6cjYD802hnFoiSQ9PgLviP20lcH
CIGn91WkYhuYG9u8Fzgzmu0yVK5L0kkCAwEAAaOCAdswggHXMB8GA1UdIwQYMBaAFIKvbIz4
xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTSD2iG48824eEQkBLu4BgdWzh49TAOBgNVHQ8B
Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw
RgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1
cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j
YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy
bDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNv
bS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG
CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0
LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAq8C9mIiSV9Nj9ZjHa
1kupbDGYy57v5fCk9lT++uiwGBP9yIFd9Gr8wISOl+96l9OLo8E+5CcPLyt96H4ez/ksXjC1
5EhzuhUB7HNi2b9GLDenjiHW4vBmSoIAbt9Pnz6zZsPH7eBPBcqkIWLFuqKBYUoXKLpzrVtr
Kgv6PM3t2+4YakBnMWjpcqzinurEeGq4mh3gHTv03wcyT6eQVCu5k4yaJxoQReYtYIjv+W+m
LmT/ZW61ZATZb2adV8xPejUlWSq4+2bpRbXZpD9FAmomNC8fSvGUUhMfYq5t5IUPHfP0kEH5
WQVWgVfpcf6Q8rnpWznsMiJrucUpJf8ZenHtMYIEKDCCBCQCAQEwga0wgZcxCzAJBgNVBAYT
AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY
BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB
dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTAJ
BgUrDgMCGgUAoIICTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNTA0MDcxNDQwNDlaMCMGCSqGSIb3DQEJBDEWBBR+Q1hLI9LCIrWwAfbCTN0fLWG3uDBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w
gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT
B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g
UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0
T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQBt3hcNOBALkdJ9R5Zmlmo27JlhQmKxY4bx
Sj/zPOxQbbvyuIXuDMY8REDHPKNt2i/S+WizzW1M0UjPMlxj+9g442ed+llbPB9MtY21D14T
MnTSMtQbZ23XYsHMDnTEXZ/fziiN6ewrHh3uKjJ2bfdiqtzZX6I5B9p6bD/MHGcY6vYxA9WC
H6fN9+LG8dr7O8mFHHqugFHbgN0XJfAqAGv4ebSdFFzhANeLmernG3r1NW3r9/ZR/BjtDcT6
KooPdzNlxIbOwCC1H4fFTiOFw0X4pNWM32yiZ2fLXX587at9wqdlW37FN+VLY4TjGlcaTAbr
tzIxi+jiSOFT/IwRggGaAAAAAAAA
--------------ms030903090900070502060301--


From nobody Tue Apr  7 07:43:28 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D8F1B3659; Tue,  7 Apr 2015 07:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.289
X-Spam-Level: 
X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsoFJvbBxyGf; Tue,  7 Apr 2015 07:43:25 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C771B3660; Tue,  7 Apr 2015 07:43:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id A67E5E2038; Tue,  7 Apr 2015 10:43:03 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 02205-04; Tue,  7 Apr 2015 10:43:02 -0400 (EDT)
Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id AC2EBE2036; Tue,  7 Apr 2015 10:43:01 -0400 (EDT)
Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t37EgxLG007527; Tue, 7 Apr 2015 10:42:59 -0400
From: Derek Atkins 
To: Jean-Marc Valin 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>
Date: Tue, 07 Apr 2015 10:42:59 -0400
In-Reply-To: <5523C5AE.7040108@mozilla.com> (Jean-Marc Valin's message of "Tue, 07 Apr 2015 07:55:26 -0400")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: 
Cc: Roni Even , secdir@ietf.org, payload@ietf.org, jspittka@gmail.com, iesg@ietf.org, payload-chairs@tools.ietf.org, koenvos74@gmail.com, 'Colin Perkins' , 'Robert Sparks' 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 14:43:27 -0000

Hi,

Jean-Marc Valin  writes:

> Does anyone object to this earlier proposal?
>
> "Opus does not provide any built-in confidentiality or integrity
> protection. Protection requirements vary between RTP applications. See
> RFC 7201 and RFC 7202 for a discussion."
>
> If not, that's probably what should go in the RFC (assuming it works
> for Kathleen Moriarty's DISCUSS too).
>
> 	Jean-Marc

It's not quite as strong a statement as I'd like to see, but if Kathleen
is okay with it then I'm okay with it.

-derek

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


From nobody Tue Apr  7 07:53:53 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6CE1A0271; Tue,  7 Apr 2015 07:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Level: 
X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noczTiltHAH6; Tue,  7 Apr 2015 07:53:47 -0700 (PDT)
Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5B71A1BD1; Tue,  7 Apr 2015 07:53:47 -0700 (PDT)
Received: from [192.168.1.197] (unknown [217.91.35.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 66C6B15A01E4; Tue,  7 Apr 2015 16:53:45 +0200 (CEST)
Message-ID: <5523EF7A.70009@greenbytes.de>
Date: Tue, 07 Apr 2015 16:53:46 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Catherine Meadows , iesg@ietf.org,  secdir@ietf.org, draft-ietf-httpbis-auth-info.all@tools.ietf.org
References: <276CBF09-D56C-4DFB-BCBC-D455BE33550F@nrl.navy.mil>
In-Reply-To: <276CBF09-D56C-4DFB-BCBC-D455BE33550F@nrl.navy.mil>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [secdir] secdir review of draft-ietf-httpbis-auth-info-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 14:53:49 -0000

On 2015-04-06 22:35, Catherine Meadows 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.
>
>
> This draft defines the “Authentication-Info” and
> “Proxy-Authentication-Info” response header fields for use in HTTP
> authentication.
> These are used for schemes that need to return information once a
> client’s authentication credentials have been accepted.
> The document defines the syntax, and gives instructions on how it should
> be treated (e.g. proxies forwarding a response are
> not allowed to modify it).  The actual semantics of the fields depend
> upon the protocols that use them.
>
> In the Security Considerations section, the authors note that adding
> information to HTTP responses sent across an unencrypted
> channel can affect security and privacy.  Indeed the presence of these
> header fields alone indicate that HTTP authentication is in use.
>   Additional information
> could be exposed depending on the authentication scheme; but this is
> something that will need to be addressed in the definition of the schemes.
>
> I only have one small question about the Security Considerations
> section: wouldn’t there be other headers that indicate authentication is
> being used, such
> as a header indicating that a message contains the client’s credentials?
>   If so, I don’t see how the introduction of an additional header field
> adds any further risk.
> ...

Other header fields might indeed be present, but not necessarily on the 
HTTP *response*.

> I believe that this ID is ready with nits.
>
> Cathy

Best regards, Julian


From nobody Tue Apr  7 08:47:56 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF651B3750 for ; Tue,  7 Apr 2015 08:40:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.298
X-Spam-Level: 
X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvbqBCxDIiQ5 for ; Tue,  7 Apr 2015 08:39:56 -0700 (PDT)
Received: from out4133-98.mail.aliyun.com (out4133-98.mail.aliyun.com [42.120.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2341B37EE for ; Tue,  7 Apr 2015 08:35:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1428420956; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=vH6K2+H3dZvrpoohFDveuFhVP3OD6J24VP5BVy1MYSw=; b=tsQA57vP/OirjeTdCACfLUkNSx62YO34yZMOv1/kc+zX3MHjYCQKHZtuzFcyKakQ5uC6BAm5ppyid0WpiP9rw34QxSZs+EbuziFT2E+eCj/Icv8Asbu44D85Xb4qXvASZGYGwzvQUbq5PBjrVg9jWrt3x1h0ShmJ21fynQsOpLU=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R471e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r46d02010; MF=kepeng.lkp@alibaba-inc.com; PH=DS;  RN=3; RT=3; SR=0; 
Received: from 10.22.49.47(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Tue, 07 Apr 2015 23:35:48 +0800
User-Agent: Microsoft-MacOutlook/14.4.8.150116
Date: Tue, 07 Apr 2015 23:35:43 +0800
From: "Kepeng Li" 
To: Magnus =?ISO-8859-1?B?TnlzdHL2bQ==?= , "secdir@ietf.org" , 
Message-ID: 
Thread-Topic: Secdir review of draft-ietf-scim-use-cases
References: 
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3511294548_3671932"
Archived-At: 
X-Mailman-Approved-At: Tue, 07 Apr 2015 08:47:50 -0700
Subject: Re: [secdir] Secdir review of draft-ietf-scim-use-cases
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 15:40:00 -0000

> ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð
´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£

--B_3511294548_3671932
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

Hi Magnus,

Thanks for the review.

>Section 3.5: Shouldn't there also be a requirement for the secure transfer=
 of
attributes between A and B based on matters such as A trusting authenticati=
on
results from B, a means to provide those authentication results securely to=
 B,
etc.? Essentially similar to what was presented in Section 3.3?

OK, I propose to add the following to section 3.5 as requirements:

      Relying party B must be able to authenticate the end user
      Relying party B must be able to securely provide the authentication
results to directory service A
      Directory service A must be able to securely provide end user=E2=80=99s
identity information (e.g., attributes) to relying party B

>Section 3.6: Similar comment as for Section 3.5. There seems to be general
security requirements missing for these two scenarios?

Similarly, I propose to add the following sentences to section 3.6 as
requirements:

      Relying party B must be able to authenticate the end user
      Relying party B must be able to securely provide the authentication
results to directory service A
      Directory service A must be able to securely provide end user=E2=80=99s
changed identity information (e.g., attributes) to relying party B

>Section 4:  Editorial suggestion: "only authenticated entity" -> "only
authenticated entities=E2=80=9D.

OK.

Thanks,

Kind Regards
Kepeng


=E5=8F=91=E4=BB=B6=E4=BA=BA:  Magnus Nystr=C3=B6m 
=E6=97=A5=E6=9C=9F:  Monday, 6 April, 2015 9:51 am
=E8=87=B3:  "secdir@ietf.org" ,

=E4=B8=BB=E9=A2=98:  Secdir review of draft-ietf-scim-use-cases
=E9=87=8D=E5=8F=91=E5=8F=91=E4=BB=B6=E4=BA=BA:  
=E9=87=8D=E5=8F=91=E6=94=B6=E4=BB=B6=E4=BA=BA:  
=E9=87=8D=E5=8F=91=E6=97=A5=E6=9C=9F:  Sun,  5 Apr 2015 18:51:14 -0700 (PDT)


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 memo describes the "System for Cross-domain Identity Management
(SCIM)." SCIM is a companion document to the SCIM Schema memo and the SCIM
Protocol memo.

Section 3.5: Shouldn't there also be a requirement for the secure transfer
of attributes between A and B based on matters such as A trusting
authentication results from B, a means to provide those authentication
results securely to B, etc.? Essentially similar to what was presented in
Section 3.3?

Section 3.6: Similar comment as for Section 3.5. There seems to be general
security requirements missing for these two scenarios?

Section 4: I only glanced the Security Consideration sections referenced
here, but they do seem adequate, and given that I don't see that this memo'=
s
Security Consideration section need to contain more information. Editorial
suggestion: "only authenticated entity" -> "only authenticated entities".

-- Magnus



--B_3511294548_3671932
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


Hi Magnus,

Thanks for the review.

>Section 3.5: =
Shouldn't there also be a requirement for the secure transfer of attributes =
between A and B based on matters such as A trusting authentication results f=
rom B, a means to provide those authentication results securely to B, etc.? =
Essentially similar to what was presented in Section 3.3?

=
OK, I propose to add the following to section 3.5 as requirements:

      Relying party B must be able to au=
thenticate the end user 
      Relying party B=
 must be able to securely provide the authentication results to directory se=
rvice A 
      Directory service A must be abl=
e to securely provide end user’s identity information (e.g., attribute=
s) to relying party B 

>Section 3.6: =
Similar comment as for Section 3.5. There seems to be general security requi=
rements missing for these two scenarios?

Similarly,=
 I propose to add the following sentences to section 3.6 as requirements:

      Relying party B must be abl=
e to authenticate the end user 
      Relying =
party B must be able to securely provide the authentication results to direc=
tory service A 
      Directory service A must=
 be able to securely provide end user’s changed identity information (=
e.g., attributes) to relying party B 

>Section 4=
:  Editorial suggestion: "only authenticated entity" -> "only authen=
ticated entities”.

OK.

Thanks,

Kind Regards
Kepeng


=E5=8F=91=E4=BB=B6=E4=BA=BA:  Magnus Nystr=C3=B6m <magnusn@gmail.com>
=E6=97=A5=E6=9C=9F:  Monday, 6 April, 20=
15 9:51 am
=E8=87=B3:  "secdir@ietf.org" <se=
cdir@ietf.org>, <draft-ietf-scim-use-cases@tools.ietf.org>
=E4=B8=BB=E9=A2=98:  Secdir review of draft-ietf-scim-use-cases=E9=87=8D=E5=8F=91=E5=8F=91=E4=BB=B6=E4=BA=BA:  <magnusn@gmail.com>
=E9=87=8D=E5=8F=91=E6=94=B6=E4=BB=B6=E4=BA=BA:  <draft-ietf-scim-use-cases@ietf.org>
=E9=87=8D=E5=8F=91=E6=97=A5=E6=9C=9F:  Sun,  5 Apr 2015 18:51:14 -0700 (PDT)


I have reviewed this document as pa=
rt of the security directorate's 
ongoing effort to review all IETF documents being processed by the IE=
SG.
 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 memo describes the "System for Cross-domain Identity Man=
agement (SCIM)." SCIM is a companion document to the SCIM Schema memo and th=
e SCIM Protocol memo.

Section 3.5: Shouldn't there also be=
 a requirement for the secure transfer of attributes between A and B based o=
n matters such as A trusting authentication results from B, a means to provi=
de those authentication results securely to B, etc.? Essentially similar to =
what was presented in Section 3.3?

Section 3.6: Similar co=
mment as for Section 3.5. There seems to be general security requirements mi=
ssing for these two scenarios?

Section 4: I only glanced t=
he Security Consideration sections referenced here, but they do seem adequat=
e, and given that I don't see that this memo's Security Consideration sectio=
n need to contain more information. Editorial suggestion: "only authenticate=
d entity" -> "only authenticated entities".

-- Magnus
=



--B_3511294548_3671932--



From nobody Tue Apr  7 08:59:47 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05001B3726; Tue,  7 Apr 2015 08:59:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zeo2XUPdpx7t; Tue,  7 Apr 2015 08:59:41 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E831B3723; Tue,  7 Apr 2015 08:59:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 679AEBE64; Tue,  7 Apr 2015 16:59:39 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Il5B2vZx2p2; Tue,  7 Apr 2015 16:59:39 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 395E9BE57; Tue,  7 Apr 2015 16:59:39 +0100 (IST)
Message-ID: <5523FEEB.60000@cs.tcd.ie>
Date: Tue, 07 Apr 2015 16:59:39 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Robert Sparks , Ben Campbell ,  Derek Atkins 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com>
In-Reply-To: <5522D40E.8040402@nostrum.com>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 15:59:47 -0000

Hiya,

Sorry for coming late to this thread (#include  :-)

On 06/04/15 19:44, Robert Sparks wrote:
[...]
>>
>> I'm saying this is the wrong layer to solve the problem.
>>
>> We had some work planned to better specify this in general for RTP. I
>> think the right answer is finish that work. If we do that right, it
>> should apply regardless of codec.
>>
> That's exactly right.
> 
> We've had this conversation several times before. The individual payload
> documents are not the place to add the kind of guidance Derek is asking
> for. They should be about how you put things in RTP, not how
> applications use (and secure RTP), unless there's something unique about
> the payload that interacts with the general mechanics for using and
> securing RTP.

Robert is correct.

> Stephen will remember that we've queued up work on a document that would
> describe securing unicast RTP set up with SDP (capturing the outcome of
> the rtpsec bof at IETF68). The last I heard on the subject Dan Wing was
> taking the token to work on that document, but it's been awhile. That's
> where the effort should focus - an individual payload document is not
> the right place.

I do recall that now that you mention it. But if it's not actually
going to happen, then maybe we should rethink the approach, even if
that'd result in repeated text in payload format drafts.

Who knows the status of that work?

S.


> 
> 
>>
>> _______________________________________________
>> payload mailing list
>> payload@ietf.org
>> https://www.ietf.org/mailman/listinfo/payload
> 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview


From nobody Tue Apr  7 09:08:49 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59281B378B; Tue,  7 Apr 2015 09:08:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4i4fR_aFOqPY; Tue,  7 Apr 2015 09:08:42 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 57A671B3774; Tue,  7 Apr 2015 09:08:25 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t37G83hm043734 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2015 11:08:14 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Stephen Farrell" 
Date: Tue, 07 Apr 2015 11:08:03 -0500
Message-ID: 
In-Reply-To: <5523FEEB.60000@cs.tcd.ie>
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <5523FEEB.60000@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" , Robert Sparks 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 16:08:44 -0000

On 7 Apr 2015, at 10:59, Stephen Farrell wrote:

> Hiya,
>
> Sorry for coming late to this thread (#include  :-)
>
> On 06/04/15 19:44, Robert Sparks wrote:
> [...]
>>>
>>> I'm saying this is the wrong layer to solve the problem.
>>>
>>> We had some work planned to better specify this in general for RTP. 
>>> I
>>> think the right answer is finish that work. If we do that right, it
>>> should apply regardless of codec.
>>>
>> That's exactly right.
>>
>> We've had this conversation several times before. The individual 
>> payload
>> documents are not the place to add the kind of guidance Derek is 
>> asking
>> for. They should be about how you put things in RTP, not how
>> applications use (and secure RTP), unless there's something unique 
>> about
>> the payload that interacts with the general mechanics for using and
>> securing RTP.
>
> Robert is correct.
>
>> Stephen will remember that we've queued up work on a document that 
>> would
>> describe securing unicast RTP set up with SDP (capturing the outcome 
>> of
>> the rtpsec bof at IETF68). The last I heard on the subject Dan Wing 
>> was
>> taking the token to work on that document, but it's been awhile. 
>> That's
>> where the effort should focus - an individual payload document is not
>> the right place.
>
> I do recall that now that you mention it. But if it's not actually
> going to happen, then maybe we should rethink the approach, even if
> that'd result in repeated text in payload format drafts.
>
> Who knows the status of that work?

I am trying to track that down. But I am working under the assumption it 
didn't go anywhere.

But I'd rather try to revive that work than to take a piecemeal approach 
of adding it to payload drafts. That doesn't help with pre-existing 
payload formats, and I think asking RTP application designers to treat 
privacy requirements on a per-codec basis is untenable. I suspect the 
best we could expect out of that is for people to ignore us.

If we can agree to leave this out of payload drafts, I will track down 
and try really hard to restart the RTP level effort.

/Ben


From nobody Tue Apr  7 09:12:34 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE2A1B3750; Tue,  7 Apr 2015 09:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiKBtt-ibzqo; Tue,  7 Apr 2015 09:12:31 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606E11A8A0B; Tue,  7 Apr 2015 09:12:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2A3A6BE64; Tue,  7 Apr 2015 17:12:30 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVWx5PNL7Ljv; Tue,  7 Apr 2015 17:12:30 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F2AE3BE51; Tue,  7 Apr 2015 17:12:29 +0100 (IST)
Message-ID: <552401ED.6060106@cs.tcd.ie>
Date: Tue, 07 Apr 2015 17:12:29 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Ben Campbell 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <5523FEEB.60000@cs.tcd.ie> 
In-Reply-To: 
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" , Robert Sparks 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 16:12:32 -0000

Thanks Ben,

On 07/04/15 17:08, Ben Campbell wrote:
>>
>> Who knows the status of that work?
> 
> I am trying to track that down. But I am working under the assumption it
> didn't go anywhere.
> 
> But I'd rather try to revive that work than to take a piecemeal approach
> of adding it to payload drafts. That doesn't help with pre-existing
> payload formats, and I think asking RTP application designers to treat
> privacy requirements on a per-codec basis is untenable. I suspect the
> best we could expect out of that is for people to ignore us.
> 
> If we can agree to leave this out of payload drafts, I will track down
> and try really hard to restart the RTP level effort.

Yes, that'd definitely be the best approach. I do get how it's
not so easy to motivate someone to get it done though, but maybe
another push at it will work. I'm happy to help as I can as well
too.

Cheers,
S.



From nobody Tue Apr  7 09:16:09 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773021B379A; Tue,  7 Apr 2015 09:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiHV9xBbj0lc; Tue,  7 Apr 2015 09:16:01 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 1D8151B3791; Tue,  7 Apr 2015 09:16:01 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 95CA5216065D1; Tue,  7 Apr 2015 16:15:56 +0000 (GMT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t37GFuSI010407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Apr 2015 18:15:56 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 7 Apr 2015 18:15:56 +0200
From: "DRAGE, Keith (Keith)" 
To: Derek Atkins , "Timothy B. Terriberry" 
Thread-Topic: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08
Thread-Index: AQHQcIQN7a+fOctgPDsHC1O01O6N4p1BtiGg
Date: Tue, 7 Apr 2015 16:15:55 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A124E8A@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "secdir@ietf.org" , "payload@ietf.org" , "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 16:16:06 -0000

You seem to be arguing that there are no security requirements specific for=
 this codec.

I would suggest that the consequence of that is that we do not need RFC 211=
9 language in this document, and that Ben's language is actually more appro=
priate. RFC 2119 language should only be used in this area if there is a sp=
ecific requirement for the codec.

If someone wants to introduce a SHOULD level strength requirement as a resu=
lt on the perpass discussion, then that should be a separate generic docume=
nt that updates the document that defines the concept of payload type defin=
itions in the first place (is that currently RFC 4855?).

RFC 7202 is only an informative document and does not contain any requireme=
nts in this respect, merely giving guidance.

So if someone wants a normative statement in this respect, assuming one can=
 be written that is actually specific enough to test, then a new document i=
s required, probably from AVTCORE.

Keith

> -----Original Message-----
> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of=20
> Derek Atkins
> Sent: 06 April 2015 17:09
> To: Timothy B. Terriberry
> Cc: secdir@ietf.org; payload@ietf.org; jspittka@gmail.com;=20
> iesg@ietf.org; payload-chairs@tools.ietf.org;=20
> koenvos74@gmail.com; Derek Atkins
> Subject: Re: [payload] [secdir] sec-dir review of=20
> draft-ietf-payload-rtp-opus-08
>=20
> "Timothy B. Terriberry"  writes:
>=20
> > Ben Campbell wrote:
> >>> So my suggestion would be something more to the effect of:
> >>>
> >>> "Opus does not provide any built-in confidentiality or integrity=20
> >>> protection. Protection requirements vary between RTP applications.
> >>> See RFC 7201 and RFC 7202 for a discussion.
> >
> > This seems like reasonable text to me. I agree with the=20
> rationale that=20
> > preceded it. As much as I want to see encryption=20
> everywhere, a payload=20
> > format is not the right place to mandate it.
>=20
> As was stated already in this thread, the expected follow up=20
> drafts for MTI security have not been written.
>=20
> I leave it up to the Security ADs who have the real power=20
> here, but I still prefer my original wording (including the SHOULD).
>=20
> I understand your reluctance because it's a codec, but it's=20
> the first codec to get through the process since the Perpass=20
> work, which basically says "everything should be encrypted." =20
> Since you cannot go back in time to modify the existing RFCs,=20
> you can augment them going forward by other additions.
>=20
> As for the concern about "different security requirements for=20
> different codecs", frankly I don't buy that argument.  Either=20
> your RTP application supports security or it doesn't.  Once=20
> it does, it should be able to negotiate that along side the=20
> codec negotitation.  So I don't see the concern -- we're not=20
> mandating a specific security technology, just that you=20
> SHOULD use one.  Well, that's true regardless of the codec, isn't it?
>=20
> Or are you really saying "We don't care about security.  We=20
> just want to be able to use this codec in existing, insecure=20
> RTP applications without adding new securty measures"?
>=20
> -derek
> --=20
>        Derek Atkins                 617-623-3745
>        derek@ihtfp.com             www.ihtfp.com
>        Computer and Internet Security Consultant
>=20
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
> =


From nobody Tue Apr  7 09:23:59 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54D41A8A50; Tue,  7 Apr 2015 09:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2e2ox7vLhcr4; Tue,  7 Apr 2015 09:23:53 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9621A8A51; Tue,  7 Apr 2015 09:23:53 -0700 (PDT)
Received: from [130.209.247.112] (port=53060 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YfWI1-0003ca-C4; Tue, 07 Apr 2015 17:23:50 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins 
In-Reply-To: <5523FEEB.60000@cs.tcd.ie>
Date: Tue, 7 Apr 2015 17:23:33 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <5523FEEB.60000@cs.tcd.ie>
To: Stephen Farrell 
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: 
Cc: Ben Campbell , "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" , Robert Sparks 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 16:23:55 -0000

On 7 Apr 2015, at 16:59, Stephen Farrell  =
wrote:
> Hiya,
>=20
> Sorry for coming late to this thread (#include  :-)
>=20
> On 06/04/15 19:44, Robert Sparks wrote:
> [...]
>>>=20
>>> I'm saying this is the wrong layer to solve the problem.
>>>=20
>>> We had some work planned to better specify this in general for RTP. =
I
>>> think the right answer is finish that work. If we do that right, it
>>> should apply regardless of codec.
>>>=20
>> That's exactly right.
>>=20
>> We've had this conversation several times before. The individual =
payload
>> documents are not the place to add the kind of guidance Derek is =
asking
>> for. They should be about how you put things in RTP, not how
>> applications use (and secure RTP), unless there's something unique =
about
>> the payload that interacts with the general mechanics for using and
>> securing RTP.
>=20
> Robert is correct.
>=20
>> Stephen will remember that we've queued up work on a document that =
would
>> describe securing unicast RTP set up with SDP (capturing the outcome =
of
>> the rtpsec bof at IETF68). The last I heard on the subject Dan Wing =
was
>> taking the token to work on that document, but it's been awhile. =
That's
>> where the effort should focus - an individual payload document is not
>> the right place.
>=20
> I do recall that now that you mention it. But if it's not actually
> going to happen, then maybe we should rethink the approach, even if
> that'd result in repeated text in payload format drafts.
>=20
> Who knows the status of that work?

I don't know the status of that work, but irrespective of that, payload =
format documents are not the right place to mandate security for RTP.=20

An RTP payload format is a media type registration. RTP is a transport =
protocol. Transport security should be defined for the transport, not =
for the media type being transported, since there are different ways of =
transporting the media that can have different security properties. This =
is the argument of RFC 7202.=20

--=20
Colin Perkins
https://csperkins.org/





From nobody Tue Apr  7 17:12:28 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A8E1ACDE7; Tue,  7 Apr 2015 17:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUpd6Pyj9pwM; Tue,  7 Apr 2015 17:12:22 -0700 (PDT)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD2D1ACDE6; Tue,  7 Apr 2015 17:12:21 -0700 (PDT)
Received: by lbbqq2 with SMTP id qq2so46356281lbb.3; Tue, 07 Apr 2015 17:12:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f/5tONVwPB86J5yMSrjNO5p1qHyWbzPUeZ/HbDrG21k=; b=f1uMC9lim1amZyxSf2UoiMKGuukZ4v0jKovkaiglaaYuBTaAsdxIYJtX3lyCvqARbs ERXCojmZ4q+0gnazR8VIFeZ/V/9fHR+pyFa2t/TxZO+pIaoo1/A4zv6OUXfOdLn1Jbdh XSdJTWglVKJhos2XWrm+/0CVDzmHDXGn4CNTeuvaqQh2XrAciLEIl+Oja6ACjF1zTTyK 49r+POxBcIp9xCbWrbZz8GsPfGsJfEIaxydP8PwK1nYeF/Cx1LPainFz8L+sm+Burnxq azOQmqvWp+KprZMioEzp74Z5BOdBvjPaNJXb+QBAsIv71fAwq9Qw7y2yd5YkNpCdfMWE C9cQ==
MIME-Version: 1.0
X-Received: by 10.112.167.228 with SMTP id zr4mr20352402lbb.113.1428451939828;  Tue, 07 Apr 2015 17:12:19 -0700 (PDT)
Received: by 10.112.167.101 with HTTP; Tue, 7 Apr 2015 17:12:19 -0700 (PDT)
In-Reply-To: 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> 
Date: Tue, 7 Apr 2015 20:12:19 -0400
Message-ID: 
From: Kathleen Moriarty 
To: Derek Atkins 
Content-Type: multipart/alternative; boundary=001a11c2432a73c7e005132b6237
Archived-At: 
Cc: Roni Even , Jean-Marc Valin , "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins , Robert Sparks 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 00:12:24 -0000

--001a11c2432a73c7e005132b6237
Content-Type: text/plain; charset=UTF-8

On Tue, Apr 7, 2015 at 10:42 AM, Derek Atkins  wrote:

> Hi,
>
> Jean-Marc Valin  writes:
>
> > Does anyone object to this earlier proposal?
> >
> > "Opus does not provide any built-in confidentiality or integrity
> > protection. Protection requirements vary between RTP applications. See
> > RFC 7201 and RFC 7202 for a discussion."
>

I'm okay with this text and did read the subsequent messages in this
thread.  Since there is a MAY already for session encryption, that's why we
were inserting a SHOULD.  I'm fine with getting rid of the RFC2119
language, but having some generic advice about RTP payloads.  Since there
is no draft ready or in the works to fix this problem where it should be
fixed, I do think it's a good idea to address the concern here and going
forward.  Once it's fixed int eh right place, then references and text
changes going forward.

Thanks for the discussion on this.

Kathleen

>
> > If not, that's probably what should go in the RFC (assuming it works
> > for Kathleen Moriarty's DISCUSS too).
> >
> >       Jean-Marc
>
> It's not quite as strong a statement as I'd like to see, but if Kathleen
> is okay with it then I'm okay with it.
>
> -derek
>
> --
>        Derek Atkins                 617-623-3745
>        derek@ihtfp.com             www.ihtfp.com
>        Computer and Internet Security Consultant
>
>


-- 

Best regards,
Kathleen

--001a11c2432a73c7e005132b6237
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Apr 7, 2015 at 10:42 AM, Derek Atkins <derek@ihtfp.com> wrote:
Hi,



Jean-Marc Valin <jmvalin@mozilla.=
com> writes:



> Does anyone object to this earlier proposal?

>

> "Opus does not provide any built-in confidentiality or integrity<=
br>
> protection. Protection requirements vary between RTP applications. See=


> RFC 7201 and RFC 7202 for a discussion."
<=
div>
I'm okay with this text and did read the subsequent =
messages in this thread.=C2=A0 Since there is a MAY already for session enc=
ryption, that's why we were inserting a SHOULD.=C2=A0 I'm fine with=
 getting rid of the RFC2119 language, but having some generic advice about =
RTP payloads.=C2=A0 Since there is no draft ready or in the works to fix th=
is problem where it should be fixed, I do think it's a good idea to add=
ress the concern here and going forward.=C2=A0 Once it's fixed int eh r=
ight place, then references and text changes going forward.

<=
/div>
Thanks for the discussion on this.

Kathl=
een


>

> If not, that's probably what should go in the RFC (assuming it wor=
ks

> for Kathleen Moriarty's DISCUSS too).

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Jean-Marc



It's not quite as strong a statement as I'd like to see, but=
 if Kathleen

is okay with it then I'm okay with it.




-derek



--

=C2=A0 =C2=A0 =C2=A0 =C2=A0Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0617-623-3745

=C2=A0 =C2=A0 =C2=A0 =C2=A0derek@ihtfp.c=
om=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0www.ihtfp.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0Computer and Internet Security Consultant







-- 
=


Best regards,
Kathleen




--001a11c2432a73c7e005132b6237--


From nobody Wed Apr  8 02:08:36 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3356E1A1A7B; Wed,  8 Apr 2015 02:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojpD6LajkMeX; Wed,  8 Apr 2015 02:08:31 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B3F1A0078; Wed,  8 Apr 2015 02:08:30 -0700 (PDT)
Received: from [130.209.247.112] (port=58266 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YflyG-00035Y-Bt; Wed, 08 Apr 2015 10:08:28 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_38F10A7C-6333-4A3E-881D-A1158D3B11CA"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins 
In-Reply-To: 
Date: Wed, 8 Apr 2015 10:08:14 +0100
Message-Id: <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>  
To: Kathleen Moriarty 
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: 
Cc: Roni Even , Jean-Marc Valin , "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Robert Sparks 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 09:08:33 -0000

--Apple-Mail=_38F10A7C-6333-4A3E-881D-A1158D3B11CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 8 Apr 2015, at 01:12, Kathleen Moriarty =
 wrote:
> On Tue, Apr 7, 2015 at 10:42 AM, Derek Atkins  wrote:
> Hi,
>=20
> Jean-Marc Valin  writes:
>=20
> > Does anyone object to this earlier proposal?
> >
> > "Opus does not provide any built-in confidentiality or integrity
> > protection. Protection requirements vary between RTP applications. =
See
> > RFC 7201 and RFC 7202 for a discussion."
>=20
> I'm okay with this text and did read the subsequent messages in this =
thread.  Since there is a MAY already for session encryption, that's why =
we were inserting a SHOULD.  I'm fine with getting rid of the RFC2119 =
language, but having some generic advice about RTP payloads.  Since =
there is no draft ready or in the works to fix this problem where it =
should be fixed, I do think it's a good idea to address the concern here =
and going forward.  Once it's fixed int eh right place, then references =
and text changes going forward.

There is some guidance in draft-ietf-payload-rtp-howto-13 sections 7.2 =
and A.13 for payload format text. That draft is in the RFC Editor queue, =
but I'm sure Magnus would be pleased to receive feedback if the =
suggestions there are not clear.


--=20
Colin Perkins
https://csperkins.org/





--Apple-Mail=_38F10A7C-6333-4A3E-881D-A1158D3B11CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On 8 =
Apr 2015, at 01:12, Kathleen Moriarty <kathleen.moriarty.ietf@gm=
ail.com> wrote:
On Tue, Apr 7, 2015 at =
10:42 AM, Derek Atkins <derek@ihtfp.com> wrote:
Hi,



Jean-Marc Valin <jmvalin@mozilla.com> =
writes:



> Does anyone object to this earlier proposal?

>

> "Opus does not provide any built-in confidentiality or =
integrity

> protection. Protection requirements vary between RTP applications. =
See

> RFC 7201 and RFC 7202 for a =
discussion."

I'm okay with =
this text and did read the subsequent messages in this thread.  =
Since there is a MAY already for session encryption, that's why we were =
inserting a SHOULD.  I'm fine with getting rid of the RFC2119 =
language, but having some generic advice about RTP payloads.  Since =
there is no draft ready or in the works to fix this problem where it =
should be fixed, I do think it's a good idea to address the concern here =
and going forward.  Once it's fixed int eh right place, then =
references and text changes going =
forward.

There is =
some guidance in draft-ietf-payload-rtp-howto-13 sections 7.2 and A.13 =
for payload format text. That draft is in the RFC Editor queue, but I'm =
sure Magnus would be pleased to receive feedback if the suggestions =
there are not clear.


-- 
Colin Perkins

<=
/div>





=

--Apple-Mail=_38F10A7C-6333-4A3E-881D-A1158D3B11CA--


From nobody Wed Apr  8 04:38:11 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F59B1B302A for ; Wed,  8 Apr 2015 04:38:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level: 
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJV6GQgFQQkH for ; Wed,  8 Apr 2015 04:38:03 -0700 (PDT)
Received: from mail-vn0-x22d.google.com (mail-vn0-x22d.google.com [IPv6:2607:f8b0:400c:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBCEA1B3028 for ; Wed,  8 Apr 2015 04:38:02 -0700 (PDT)
Received: by vnbf1 with SMTP id f1so14478591vnb.5 for ; Wed, 08 Apr 2015 04:38:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=9gvkhP15Orzlas+3aESGslYIMimmZN5Fg8bLc0Tc4pU=; b=bvFIGgUfN2X8soEfGiXc8EENQc6fY4msiEGP3xbIhjyPmqaUzuZMF1oYgHbEodr3+n jRPoXKP+vV8JW4n7b1uhpZd14gURZMOSc0zotfN+0eOfgRBJ+xNI4bKt6F3f/6n3JbB7 P22MfDv3n/i+bafb6KTBl7jDnqJ0WZjhk8XCItxwrspxMgm4Ybvu4+PwDHu8MTU8ksEu YQibrjVGrTOh5SXoEgswuuIJmWuym1L675a5ICI7AvCHINF1tGbW+nOCOUdSA9u/K833 iaVlMd2LGomUM3G8IAOcAmSxeTHvit1O40lyBU7tPcbpUxgprm6aWY83RCwvpsjHk2GU EXLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9gvkhP15Orzlas+3aESGslYIMimmZN5Fg8bLc0Tc4pU=; b=lfGgQb3niFziTFpw9DLdRExoKcI6yu/jTXXE7JMzyzGs1ylfQni2m9uO3kSEn0IGoL W53B8Sh94MaBfBpjlz3CQeErUxEKfK2a0N0WYrsq9wtaedw+Zc4b9TeDBwhged0rT7Wv KRdqZ9zS62H2ELirFCG7mxSKZ7E2J8ZbMGpI0Nude0cPNaPsdfJ8/EUQQQ6bMXeBcCX/ Lf/iiuJ/je6TIqKVwX1ylNrWfOLlR9hgEeOc1TbCDPl7BvvPvBqA2T7KDZkJOjgSRH5h eZqkztmEGs9H2vT7faDoWT1mP7l5WtYvdR7Jv/F0X4QEzxvlKEF0/vs1mWkj/Xougkna 5W0A==
X-Gm-Message-State: ALoCoQnt7Ol0stSqSx0NeYoiFE045EHlwREnSjwK6FudECrxONcsRR0V4HjcQn50JWzuBCQh9rCU
MIME-Version: 1.0
X-Received: by 10.140.92.51 with SMTP id a48mr28433525qge.30.1428493082101; Wed, 08 Apr 2015 04:38:02 -0700 (PDT)
Received: by 10.229.178.135 with HTTP; Wed, 8 Apr 2015 04:38:01 -0700 (PDT)
In-Reply-To: 
References:  <118C77E9-FAD2-48C1-A6E1-4D20D219449F@mit.edu>  <951E5D91-BC5D-48CC-8B9C-D88804FB5B87@mit.edu>  <4DE7AD5F-A14A-4255-A78C-0F6DCBECE735@mit.edu>  
Date: Wed, 8 Apr 2015 12:38:01 +0100
Message-ID: 
From: Ben Laurie 
To: Justin Richer 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org, Kathleen Moriarty , The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] Security review of draft-ietf-oauth-dyn-reg-management-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 11:38:06 -0000

On 6 April 2015 at 21:14, Justin Richer  wrote:
> Ben et. al.,
>
> I took the proposal to the WG and have changed the draft text based on th=
eir
> feedback. The results are published here:
>
>   http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-13

Looks good.

>
>  =E2=80=94 Justin
>
> On Apr 3, 2015, at 12:14 PM, Kathleen Moriarty
>  wrote:
>
>
>
> On Fri, Apr 3, 2015 at 3:02 PM, Justin Richer  wrote:
>>
>> On Apr 3, 2015, at 1:26 PM, Ben Laurie  wrote:
>> >
>> > On 3 April 2015 at 18:22, Justin Richer  wrote:
>> >>>
>> >>>>> Issue: " Since the client configuration endpoint is an OAuth 2.0
>> >>>>> protected
>> >>>>> resource, it SHOULD have some rate limiting on failures to prevent
>> >>>>> the registration access token from being disclosed though repeated
>> >>>>> access attempts."
>> >>>>>
>> >>>>> I am not sure what this is getting at. Limits on key re-use? Some
>> >>>>> kind
>> >>>>> of BEAST defence? Something else?
>> >>>>>
>> >>>>> Without some quantification of the threat, it seems hard to act on
>> >>>>> this requirement.
>> >>>>
>> >>>> The rate limiting is going to take a number of different forms
>> >>>> depending on the platform and deployment characteristics of the
>> >>>> authorization server, so we don=E2=80=99t recommend any particular =
approach. This is
>> >>>> also something that=E2=80=99s going to be changing quickly over the=
 years, and
>> >>>> instead of prescribing a specific solution we thought it better to =
describe
>> >>>> the problem here and say that it must be mitigated.
>> >>>
>> >>> Solution to what? This is precisely my issue - you haven't described
>> >>> the problem, you've described a solution to some problem I'm finding
>> >>> hard to guess.
>> >>>
>> >>> In other words: how could the registration access token be disclosed
>> >>> through repeated access attempts?
>> >>
>> >> An attacker could keep poking at a client configuration endpoint with
>> >> random self-generated tokens until it finds one that works. There=E2=
=80=99s no
>> >> oracle attack or other portion that lets the attacker know they=E2=80=
=99re getting
>> >> closer to a good token, just a basic repeated hammering of a protecte=
d
>> >> resource This problem is mitigated by having a sufficiently random to=
ken (as
>> >> recommended in RFC6750 and RFC6819) as well as rate-limiting the conn=
ections
>> >> to the endpoint (also suggested by RFC6819). This is fairly common ad=
vice
>> >> for any endpoint protected by a secret (in this case, an OAuth token)=
. Is
>> >> there a better way to state this so that it=E2=80=99s more clear to d=
evelopers what
>> >> they should look out for?
>> >
>> > How about making it a non-problem by requiring sufficiently strong
>> > tokens that there is no possibility of brute force?
>> >
>> > Mildly astonished that this attack is even considered feasible.
>>
>> I=E2=80=99m fine with that resolution, or with just deferring to the app=
ropriate
>> sections of 6750 and 6819 here, if the AD=E2=80=99s are amenable to that=
 change.
>
>
> If the WG is good with the change and there is no reason to make this a
> non-problem, that would be ideal.
>
> Thanks,
> Kathleen
>>
>>
>>  =E2=80=94 Justin
>
>
>
>
> --
>
> Best regards,
> Kathleen
>
>


From nobody Wed Apr  8 06:38:44 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D28B1A6EE7; Wed,  8 Apr 2015 06:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKwepufpBgpF; Wed,  8 Apr 2015 06:38:40 -0700 (PDT)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A671A871A; Wed,  8 Apr 2015 06:38:38 -0700 (PDT)
Received: by iggg4 with SMTP id g4so39336017igg.0; Wed, 08 Apr 2015 06:38:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7Nv53X6Ckl5j/0drWFN09wcvv+qmwfEfUUtuAW+KM/Q=; b=Rj9dA7DLcHuuiJv18h4IBthafSLXbZky4tT7Nm5/Zdabnj2w0JiODXeK6rVjH8ZhLY 2iv0ybYJrr5KYGcfOsbQBXCxGCdiN0lZBOgZHlpn1Swm5QcyxQOr8oUsce1Dl0xo20Or /DujSbeuo8IE+MohSFYK6G4NbH71qKXLajWGj9aFEsDtTrjsV0jmpEaowkylaG//tDaf tBFm1fAuX8RNIk2DUPPTFWmEsHlxeJCbzSELkdFiDPxo8Kr9YnjXoe9K2fGHlrqss+lE wwYxSQM2AYMaw0ZkLarOJU2QbmboaQ8fwYnbiB15aVy7xE/dSe1hx+JnS/xYlFioWZwX QciA==
MIME-Version: 1.0
X-Received: by 10.107.3.17 with SMTP id 17mr37441367iod.60.1428500318338; Wed, 08 Apr 2015 06:38:38 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.107.7.130 with HTTP; Wed, 8 Apr 2015 06:38:38 -0700 (PDT)
In-Reply-To: <22407EB2-5E94-42F1-B191-6955F35F4098@adobe.com>
References: <551C2791.7090206@gmail.com> <22407EB2-5E94-42F1-B191-6955F35F4098@adobe.com>
Date: Wed, 8 Apr 2015 09:38:38 -0400
X-Google-Sender-Auth: _s83POg1Yh27WuNjnORBBUyTXMA
Message-ID: 
From: Barry Leiba 
To: Larry Masinter 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: 
Cc: "draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" 
Subject: Re: [secdir] SECDIR review of draft-ietf-appsawg-multipart-form-data-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 13:38:41 -0000

>> I would suggest placing the last paragraph of the Security Considerations
>> section at the top of the section. That paragraph seems to be the most
>> comprehensive in these considerations, and the other paragraphs seem to
>> augment and give specific details. It just seems to me that it would provide
>> a better flow to reading that section.
>
> I tried it and it didn't flow any better.  I'd make the edit if I felt it
> made a difference but I don't think it helps.

At least three ADs have now agreed with Chris, and I have to say that
I do as well.  None of us think it's at the level of DISCUSS, and if
you, Larry, really feel strongly about leaving it as it is I won't
hold things up for it.  But please do consider that a Security
Directorate reviewer thinks it would read better with the last graf up
front, and that four ADs agree.

Barry


From nobody Wed Apr  8 07:24:57 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472FD1B3119; Wed,  8 Apr 2015 07:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.289
X-Spam-Level: 
X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbKDAsQxRcTH; Wed,  8 Apr 2015 07:24:53 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68AC71B310F; Wed,  8 Apr 2015 07:24:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id E10F3E2039; Wed,  8 Apr 2015 10:24:48 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 09597-01; Wed,  8 Apr 2015 10:24:41 -0400 (EDT)
Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id BE1FDE2038; Wed,  8 Apr 2015 10:24:41 -0400 (EDT)
Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t38EOdge013770; Wed, 8 Apr 2015 10:24:39 -0400
From: Derek Atkins 
To: Colin Perkins 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>
Date: Wed, 08 Apr 2015 10:24:39 -0400
In-Reply-To: <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> (Colin Perkins's message of "Wed, 8 Apr 2015 10:08:14 +0100")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: 
Cc: Roni Even , Jean-Marc Valin , "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Robert Sparks 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 14:24:54 -0000

Colin, et all,

I suggest you take a closer look at the existing document.  In
particular, I do not accept the argument that this is the wrong place to
recommend security, because the existing draft already does.  See below:

Colin Perkins  writes:

> On 8 Apr 2015, at 01:12, Kathleen Moriarty 
> wrote:
>
>     On Tue, Apr 7, 2015 at 10:42 AM, Derek Atkins  wrote:
>    
>         Hi,
>        
>         Jean-Marc Valin  writes:
>        
>         > Does anyone object to this earlier proposal?
>         >
>         > "Opus does not provide any built-in confidentiality or integrity
>         > protection. Protection requirements vary between RTP applications.
>         See
>         > RFC 7201 and RFC 7202 for a discussion."
>
>     I'm okay with this text and did read the subsequent messages in this
>     thread.  Since there is a MAY already for session encryption, that's why
>     we were inserting a SHOULD.  I'm fine with getting rid of the RFC2119
>     language, but having some generic advice about RTP payloads.  Since there
>     is no draft ready or in the works to fix this problem where it should be
>     fixed, I do think it's a good idea to address the concern here and going
>     forward.  Once it's fixed int eh right place, then references and text
>     changes going forward.
>
> There is some guidance in draft-ietf-payload-rtp-howto-13 sections 7.2 and
> A.13 for payload format text. That draft is in the RFC Editor queue, but I'm
> sure Magnus would be pleased to receive feedback if the suggestions there are
> not clear.

Let me quote a section of the draft, in particular section 8. Security
Considerations:

   This payload format transports Opus encoded speech or audio data.
   Hence, security issues include confidentiality, integrity protection,
   and authentication of the speech or audio itself.  Opus does not
   provide any confidentiality or integrity protection.  Any suitable
   external mechanisms, such as SRTP [RFC3711], MAY be used.

So this draft already DOES make a recommendation about the transport
layer security.  I was saying that you should change this MAY to a
SHOULD, which is where this all started.

You may say "this is the wrong layer", but from where I sit that horse
has already left the barn.  The WG already let it pass with this
recommendation as a MAY.  As a memeber of the Security Area Directorate
I think this MAY should be changed to a SHOULD.

Thanks,

-derek

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


From nobody Wed Apr  8 07:35:34 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350DA1B3155 for ; Wed,  8 Apr 2015 07:35:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfqLOoH2XU2L for ; Wed,  8 Apr 2015 07:35:28 -0700 (PDT)
Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 113161B3154 for ; Wed,  8 Apr 2015 07:35:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1428503708; d=isode.com; s=selector; i=@isode.com; bh=ahnQDUMBVgS/lPu/b2JNoigQzobAnhokDY5AIpNlZ+A=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=IqNmO7J8ThO8PxoUCMJGj8Yt13ASzNhUhcmBtw8uLme1H+1DKfJUf5i4VvQ01CJF4Xsszz C16ycWS8+/30/yQ5goFWIfYkueIxuE2E7leS+GuEZ0NRveuvBsUjnloPgmxMYffZuNI2Sm PKbabv7PdFq1fD74uQdTQUEaOCjuBBs=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215])  by statler.isode.com (submission channel) via TCP with ESMTPSA  id ; Wed, 8 Apr 2015 15:35:08 +0100
Message-ID: <55253C8D.5070305@isode.com>
Date: Wed, 08 Apr 2015 15:34:53 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
To: secdir@ietf.org, draft-ietf-idr-flowspec-redirect-rt-bis.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [secdir] SecDir review of draft-ietf-idr-flowspec-redirect-rt-bis-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 14:35:33 -0000

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 clarifies the formatting of the the BGP Flowspec Redirect 
Extended Community, originally documented in RFC 5575 (Dissemination of 
Flow Specification Rules).

This document is a straightforward clarification to RFC 5575. 
Documenting existing practice will improve security of implementations. 
Pointing to the Security Considerations of RFC 5575 is appropriate for 
this document.

I believe that this ID is ready for publication.




From nobody Wed Apr  8 07:35:44 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBAA1B315A; Wed,  8 Apr 2015 07:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of-ERTznzXoQ; Wed,  8 Apr 2015 07:35:37 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB14F1B3100; Wed,  8 Apr 2015 07:35:17 -0700 (PDT)
Received: from [130.209.247.112] (port=61738 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Yfr4S-0007u1-PX; Wed, 08 Apr 2015 15:35:14 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins 
In-Reply-To: 
Date: Wed, 8 Apr 2015 15:35:02 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org>
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> 
To: Derek Atkins 
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: 
Cc: Roni Even , Magnus Westerlund , Jean-Marc Valin , "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Robert Sparks 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 14:35:43 -0000

On 8 Apr 2015, at 15:24, Derek Atkins  wrote:
> Colin, et all,
>=20
> I suggest you take a closer look at the existing document.  In
> particular, I do not accept the argument that this is the wrong place =
to
> recommend security, because the existing draft already does.  See =
below:
>=20
> Colin Perkins  writes:
>=20
>> On 8 Apr 2015, at 01:12, Kathleen Moriarty =

>> wrote:
>>=20
>>    On Tue, Apr 7, 2015 at 10:42 AM, Derek Atkins  =
wrote:
>>=20
>>        Hi,
>>=20
>>        Jean-Marc Valin  writes:
>>=20
>>> Does anyone object to this earlier proposal?
>>>=20
>>> "Opus does not provide any built-in confidentiality or integrity
>>> protection. Protection requirements vary between RTP applications.
>>        See
>>> RFC 7201 and RFC 7202 for a discussion."
>>=20
>>    I'm okay with this text and did read the subsequent messages in =
this
>>    thread.  Since there is a MAY already for session encryption, =
that's why
>>    we were inserting a SHOULD.  I'm fine with getting rid of the =
RFC2119
>>    language, but having some generic advice about RTP payloads.  =
Since there
>>    is no draft ready or in the works to fix this problem where it =
should be
>>    fixed, I do think it's a good idea to address the concern here and =
going
>>    forward.  Once it's fixed int eh right place, then references and =
text
>>    changes going forward.
>>=20
>> There is some guidance in draft-ietf-payload-rtp-howto-13 sections =
7.2 and
>> A.13 for payload format text. That draft is in the RFC Editor queue, =
but I'm
>> sure Magnus would be pleased to receive feedback if the suggestions =
there are
>> not clear.
>=20
> Let me quote a section of the draft, in particular section 8. Security
> Considerations:
>=20
>   This payload format transports Opus encoded speech or audio data.
>   Hence, security issues include confidentiality, integrity =
protection,
>   and authentication of the speech or audio itself.  Opus does not
>   provide any confidentiality or integrity protection.  Any suitable
>   external mechanisms, such as SRTP [RFC3711], MAY be used.
>=20
> So this draft already DOES make a recommendation about the transport
> layer security.  I was saying that you should change this MAY to a
> SHOULD, which is where this all started.
>=20
> You may say "this is the wrong layer", but from where I sit that horse
> has already left the barn.  The WG already let it pass with this
> recommendation as a MAY.  As a memeber of the Security Area =
Directorate
> I think this MAY should be changed to a SHOULD.

And as I keep saying, I believe that is inappropriate, since it's =
recommending SRTP which is not suitable for many applications. The =
rtp-howto draft suggests the following text:

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification RFC3550, and in any applicable RTP profile such as
   RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
   SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
   Why RTP Does Not Mandate a Single Media Security Solution"
   [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
   formats responsibility to discuss or mandate what solutions are used
   to meet the basic security goals like confidentiality, integrity and
   source authenticity for RTP in general.  This responsibility lays on
   anyone using RTP in an application.  They can find guidance on
   available security mechanisms and important considerations in Options
   for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].

(The two drafts referenced are what became RFCs 7201 and 7202).

If you want to augment that with a "strong security SHOULD/MUST be =
used", then I certainly don't object. However, a payload format really =
shouldn't be trying to recommend use of a particular RTP security =
solution, such as SRTP.

--=20
Colin Perkins
https://csperkins.org/





From nobody Wed Apr  8 07:43:09 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5D61B3173; Wed,  8 Apr 2015 07:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.289
X-Spam-Level: 
X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44kgDEeQf67S; Wed,  8 Apr 2015 07:43:03 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E281B3171; Wed,  8 Apr 2015 07:43:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 2AC29E2036; Wed,  8 Apr 2015 10:43:02 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 09597-07; Wed,  8 Apr 2015 10:42:59 -0400 (EDT)
Received: by mail2.ihtfp.org (Postfix, from userid 48) id ABEE5E2038; Wed,  8 Apr 2015 10:42:59 -0400 (EDT)
Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 8 Apr 2015 10:42:59 -0400
Message-ID: <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>
In-Reply-To: <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org>
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org>
Date: Wed, 8 Apr 2015 10:42:59 -0400
From: "Derek Atkins" 
To: "Colin Perkins" 
User-Agent: SquirrelMail/1.4.22-14.fc20
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: 
Cc: Roni Even , Magnus Westerlund , Jean-Marc Valin , "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Robert Sparks 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 14:43:04 -0000

On Wed, April 8, 2015 10:35 am, Colin Perkins wrote:
[snip]
>
> And as I keep saying, I believe that is inappropriate, since it's
> recommending SRTP which is not suitable for many applications. The
> rtp-howto draft suggests the following text:
>
[sniped and added below]
>
> (The two drafts referenced are what became RFCs 7201 and 7202).
>
> If you want to augment that with a "strong security SHOULD/MUST be used",
> then I certainly don't object. However, a payload format really shouldn't
> be trying to recommend use of a particular RTP security solution, such as
> SRTP.

Okay, so if you want to change the text completely (which I'm fine with),
how about just adding a single sentence to the end of what you have:

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification RFC3550, and in any applicable RTP profile such as
   RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
   SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
   Why RTP Does Not Mandate a Single Media Security Solution"
   [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
   formats responsibility to discuss or mandate what solutions are used
   to meet the basic security goals like confidentiality, integrity and
   source authenticity for RTP in general.  This responsibility lays on
   anyone using RTP in an application.  They can find guidance on
   available security mechanisms and important considerations in Options
   for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
   Applications SHOULD implement at least one of the strong security
   measures suggested by those references.

> --
> Colin Perkins
> https://csperkins.org/

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


From nobody Wed Apr  8 08:03:22 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93231AD377; Tue,  7 Apr 2015 23:31:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jC3UxZ6j1eof; Tue,  7 Apr 2015 23:31:03 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0626.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:626]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A131A1AD37C; Tue,  7 Apr 2015 23:31:02 -0700 (PDT)
Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1324.namprd02.prod.outlook.com (25.161.142.23) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 8 Apr 2015 06:30:44 +0000
Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0118.029; Wed, 8 Apr 2015 06:30:44 +0000
From: Larry Masinter 
To: Chris Lonvick , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org" 
Thread-Topic: SECDIR review of draft-ietf-appsawg-multipart-form-data-08
Thread-Index: AQHQbJ9sAFA7MLO800ael97UJqkWgZ1CPHyA
Date: Wed, 8 Apr 2015 06:30:44 +0000
Message-ID: <22407EB2-5E94-42F1-B191-6955F35F4098@adobe.com>
References: <551C2791.7090206@gmail.com>
In-Reply-To: <551C2791.7090206@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/15.8.0.150303
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [50.184.24.49]
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1324;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(377454003)(479174004)(66066001)(2201001)(46102003)(2900100001)(2950100001)(87936001)(2656002)(92566002)(16236675004)(36756003)(15975445007)(102836002)(54356999)(122556002)(50986999)(40100003)(76176999)(107886001)(82746002)(83506001)(86362001)(33656002)(230783001)(62966003)(83716003)(99286002)(19580405001)(77156002)(19617315012)(16601075003)(19580395003)(2501003)(106116001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1324; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR02MB1324; BCL:0; PCL:0; RULEID:;  SRVR:DM2PR02MB1324; 
x-forefront-prvs: 0540846A1D
Content-Type: multipart/alternative; boundary="_000_22407EB25E9442F1B1916955F35F4098adobecom_"
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 06:30:44.2221 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1324
Archived-At: 
X-Mailman-Approved-At: Wed, 08 Apr 2015 08:03:20 -0700
Subject: Re: [secdir] SECDIR review of draft-ietf-appsawg-multipart-form-data-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 06:31:06 -0000

--_000_22407EB25E9442F1B1916955F35F4098adobecom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCk9uIDQvMS8xNSwgMTA6MTQgQU0sICJDaHJpcyBMb252aWNrIiA8bG9udmljay5pZXRmQGdt
YWlsLmNvbTxtYWlsdG86bG9udmljay5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KPiBJIHdvdWxk
IHN1Z2dlc3QgcGxhY2luZyB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgdGhlIFNlY3VyaXR5IENvbnNp
ZGVyYXRpb25zIHNlY3Rpb24gYXQgdGhlIHRvcCBvZiB0aGUgc2VjdGlvbi4gVGhhdCBwYXJhZ3Jh
cGggc2VlbXMgdG8gYmUgdGhlIG1vc3QgY29tcHJlaGVuc2l2ZSBpbiB0aGVzZSBjb25zaWRlcmF0
aW9ucywgYW5kIHRoZSBvdGhlciBwYXJhZ3JhcGhzIHNlZW0gdG8gYXVnbWVudCBhbmQgZ2l2ZSBz
cGVjaWZpYyBkZXRhaWxzLiBJdCBqdXN0IHNlZW1zIHRvIG1lIHRoYXQgaXQgd291bGQgcHJvdmlk
ZSBhIGJldHRlciBmbG93IHRvIHJlYWRpbmcgdGhhdCBzZWN0aW9uLg0KDQpJIHRyaWVkIGl0IGFu
ZCBpdCBkaWRu4oCZdCBmbG93IGFueSBiZXR0ZXIuICBJ4oCZZCBtYWtlIHRoZSBlZGl0IGlmIEkg
ZmVsdCBpdCBtYWRlIGEgZGlmZmVyZW5jZSBidXQgSSBkb27igJl0IHRoaW5rIGl0IGhlbHBzLg0K
DQoNCkFsc28sIEknbSBqdXN0IG5vdCBzdXJlIHRoYXQgSSdtIGZvbGxvd2luZyB0aGUgc2Vjb25k
IHBhcmFncmFwaCBvZg0KQXBwZW5kaXggQjoNCiAgIE1vcmUgcHJvYmxlbWF0aWMgaXMgdGhlIGFt
YmlndWl0eSBpbnRyb2R1Y2VkIGJlY2F1c2UgaW1wbGVtZW50YXRpb25zDQogICBkaWQgbm90IGZv
bGxvdyBbUkZDMjM4ODxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjM4OD5dIGJlY2F1
c2UgaXQgdXNlZCAibWF5IiBpbnN0ZWFkIG9mICJNVVNUIiB3aGVuDQogICBzcGVjaWZ5aW5nIGVu
Y29kaW5nIG9mIGZpZWxkIG5hbWVzLCBhbmQgZm9yIG90aGVyIHVua25vd24gcmVhc29ucywgc28N
CiAgIG5vdywgcGFyc2VycyBuZWVkIHRvIGJlIG1vcmUgY29tcGxleCBmb3IgZnV6enkgbWF0Y2hp
bmcgYWdhaW5zdCB0aGUNCiAgIHBvc3NpYmxlIG91dHB1dHMgb2YgdmFyaW91cyBlbmNvZGluZyBt
ZXRob2RzLg0KUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSdtIG9mZiBiYXNlIGhlcmUsIGJ1dCBpdCBz
b3VuZHMgbGlrZSB0aGUgYW1iaWd1aXR5DQpzZXQgaW4gYmVjYXVzZSBpbXBsZW1lbnRhdGlvbnMg
V0VSRSBmb2xsb3dpbmcgUkZDIDIzODggYnkgbWFraW5nDQpjaG9pY2VzIG9uIHRoZWlyIG93biAo
ZHVlIHRvIHRoZSAibWF5InMpIHJhdGhlciB0aGFuIGJlaW5nIGRpcmVjdGVkIHRvDQptYWtlIHVu
aWZvcm0gY2hvaWNlcyB3aGljaCB3b3VsZCBoYXZlIGJlZW4gbWFuZGF0ZWQgaWYgdGhhdCBSRkMg
aGFkIHVzZWQNCiJNVVNUInMuDQoNClRoaXMgaXMgYWxzbyBlZGl0b3JpYWwsIGFzIHRvIHdobyBp
cyBhdCBmYXVsdC4gIGlmIHRoZSBzcGVjIHNheXMg4oCceW91IGNhbiB1c2UgbWV0aG9kIEEgZm9y
IHNpdHVhdGlvbiBT4oCdIGFuZA0KaW1wbGVtZW50b3Igc2F5cyDigJxkaWRu4oCZdCBzYXkgTVVT
VCwgc28gSeKAmWxsIHVzZSBtZXRob2QgQiBpbnN0ZWFk4oCdLCBkbyB5b3UgYmxhbWUgdGhlIHNw
ZWMgd3JpdGVyIG9yDQp0aGUgaW1wbGVtZW50b3IuICBJJ2QgaW1wbGVtZW50b3JzIHRvIHJlYWQg
SUVURiBSRkNzIHdpdGggZW5naW5lZXJpbmcgY29tbW9uIHNlbnNlIGFuZCBub3QgcGxheQ0KbGVn
YWxpc3RpYyBnYW1lcyBhcm91bmQgbm9ybWF0aXZlIHRlcm1zLiBTbyBJ4oCZbG0gZ29pbmcgdG8g
c3RpY2sgd2l0aCBteSBsYW5ndWFnZS4NCg0KDQpGaW5hbGx5LCBJIHVzdWFsbHkgYWR2b2NhdGUg
Z2l2aW5nIGRpcmVjdGlvbnMgdG8gaW1wbGVtZW50ZXJzIGFib3V0IHdoYXQgdG8gZG8gaWYgdGhl
eSBmaW5kIGltcGxlbWVudGF0aW9ucyB1c2luZyB0aGUgb2xkZXIsIG91dGRhdGVkIHNwZWMuIEFz
IGFuIGV4YW1wbGUsIHdoYXQgc2hvdWxkIGEgcmVjZWl2ZXIgZG8gaWYgaXQgZ2V0cyBhIENvbnRl
bnRUeXBlIHRoYXQgZG9lcyBub3QgaGF2ZSBhICJib3VuZGFyeSIgcGFyYW1ldGVyPyBIb3dldmVy
LCBhcyBJJ20gbm90IHJlYWxseSBmYW1pbGlhciB3aXRoIHRoaXMgdGVjaG5vbG9neSwgYW5kIGFz
IHRoZSBkb2N1bWVudCBzYXlzIHRoZXJlIGFyZSBtYW55IHdheXMgdG8gZG8gYWxsIG9mIHRoaXMs
IHRoZW4gSSdtIG5vdCBzdXJlIHRoYXQgY291bGQgb3Igc2hvdWxkIGJlIGRpc2N1c3NlZC4gSWYg
aXQgaXMgc29tZXRoaW5nIHRoYXQgd291bGQgYmV0dGVyIGRlZmluZSBiZWhhdmlvciB0aGVuIEkg
d291bGQgc3VnZ2VzdCBwcm92aWRpbmcgc29tZSBndWlkYW5jZSBoZXJlLg0KDQp0aGUgYm91bmRh
cnkgcGFyYW1ldGVyIGlzIHVzZWQgaW4gYWxsIG11bHRpcGFydCB0eXBlcywgd2hpY2ggYXJlIHdp
ZGVzcHJlYWQgaW4gdGhlIEludGVybmV0LiBUaGUNCmNvbW1vbiB1bmRlcnN0YW5kaW5nIG9mIG11
bHRpcGFydCBpcyB3aHkgd2UgcGlja2VkIGl0IGZvciBmcmFtaW5nIGZvcm0tZGF0YSwgZXZlbiB0
aG91Z2ggaXTigJlzDQp1Z2x5IGFuZCB0aGUgcHJvYmFiaWxpc3RpYyBib3VuZGFyeSBnZW5lcmF0
aW9uIGRyaXZlcyBsb3RzIG9mIHBlb3BsZSBjcmF6eS4gU28gdGhpcyBraW5kIG9mIHN0dWZmIHRo
YXQNCmlzIGluaGVyaXRlZCBmcm9tIE1JTUUgZG9lc27igJl0IG5lZWQgZGlzY3Vzc2luZy4NCg0K
VGhlIG1haW4gcmVhc29uIHRoaXMgdXBkYXRlIHdhcyBldmVuIG5lY2Vzc2FyeSBpcyBiZWNhdXNl
IHRoYXQgYWR2YW50YWdlIHdhc27igJl0IGFzIGdyZWF0IGFueSBtb3JlLA0KYW5kIHRodXMgdGhl
IGRpdmVyZ2VuY2VzIGZyb20gb3RoZXIgbXVsdGlwYXJ0IHR5cGVzLg0KDQpMYXJyeQ0K4oCUDQpo
dHRwOi8vbGFycnkubWFzaW50ZXIubmV0DQoNCg0K

--_000_22407EB25E9442F1B1916955F35F4098adobecom_
Content-Type: text/html; charset="utf-8"
Content-ID: <97C98C65226FF540B2E62A54152E3CEF@namprd02.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05B
VFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K
PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2Pk9uIDQvMS8xNSwg
MTA6MTQgQU0sICZxdW90O0NocmlzIExvbnZpY2smcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzps
b252aWNrLmlldGZAZ21haWwuY29tIj5sb252aWNrLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3Jv
dGU6PC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBweDsg
Ym9yZGVyOm5vbmU7IHBhZGRpbmc6MHB4OyI+DQo8ZGl2PjxpPiZndDsgSSB3b3VsZCBzdWdnZXN0
IHBsYWNpbmcgdGhlIGxhc3QgcGFyYWdyYXBoIG9mIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9u
cyBzZWN0aW9uIGF0IHRoZSB0b3Agb2YgdGhlIHNlY3Rpb24uIFRoYXQgcGFyYWdyYXBoIHNlZW1z
IHRvIGJlIHRoZSBtb3N0IGNvbXByZWhlbnNpdmUgaW4gdGhlc2UgY29uc2lkZXJhdGlvbnMsIGFu
ZCB0aGUgb3RoZXIgcGFyYWdyYXBocyBzZWVtIHRvIGF1Z21lbnQgYW5kIGdpdmUgc3BlY2lmaWMg
ZGV0YWlscy4NCiBJdCBqdXN0IHNlZW1zIHRvIG1lIHRoYXQgaXQgd291bGQgcHJvdmlkZSBhIGJl
dHRlciBmbG93IHRvIHJlYWRpbmcgdGhhdCBzZWN0aW9uLjwvaT48L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgdHJpZWQgaXQgYW5kIGl0IGRp
ZG7igJl0IGZsb3cgYW55IGJldHRlci4gJm5ic3A7SeKAmWQgbWFrZSB0aGUgZWRpdCBpZiBJIGZl
bHQgaXQgbWFkZSBhIGRpZmZlcmVuY2UgYnV0IEkgZG9u4oCZdCB0aGluayBpdCBoZWxwcy48L2Rp
dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K
PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBweDsgYm9yZGVyOm5vbmU7
IHBhZGRpbmc6MHB4OyI+DQo8ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPg0K
PHByZSBjbGFzcz0id2lraSI+PGk+QWxzbywgSSdtIGp1c3Qgbm90IHN1cmUgdGhhdCBJJ20gZm9s
bG93aW5nIHRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mDQpBcHBlbmRpeCBCOg0KICAgTW9yZSBwcm9i
bGVtYXRpYyBpcyB0aGUgYW1iaWd1aXR5IGludHJvZHVjZWQgYmVjYXVzZSBpbXBsZW1lbnRhdGlv
bnMNCiAgIGRpZCBub3QgZm9sbG93IFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvcmZjMjM4OCIgdGl0bGU9IiZxdW90O1JldHVybmluZyBWYWx1ZXMgZnJvbSBGb3JtczogbXVs
dGlwYXJ0LyBmb3JtLWRhdGEmcXVvdDsiPlJGQzIzODg8L2E+XSBiZWNhdXNlIGl0IHVzZWQgJnF1
b3Q7bWF5JnF1b3Q7IGluc3RlYWQgb2YgJnF1b3Q7TVVTVCZxdW90OyB3aGVuDQogICBzcGVjaWZ5
aW5nIGVuY29kaW5nIG9mIGZpZWxkIG5hbWVzLCBhbmQgZm9yIG90aGVyIHVua25vd24gcmVhc29u
cywgc28NCiAgIG5vdywgcGFyc2VycyBuZWVkIHRvIGJlIG1vcmUgY29tcGxleCBmb3IgZnV6enkg
bWF0Y2hpbmcgYWdhaW5zdCB0aGUNCiAgIHBvc3NpYmxlIG91dHB1dHMgb2YgdmFyaW91cyBlbmNv
ZGluZyBtZXRob2RzLg0KUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSdtIG9mZiBiYXNlIGhlcmUsIGJ1
dCBpdCBzb3VuZHMgbGlrZSB0aGUgYW1iaWd1aXR5DQpzZXQgaW4gYmVjYXVzZSBpbXBsZW1lbnRh
dGlvbnMgV0VSRSBmb2xsb3dpbmcgUkZDIDIzODggYnkgbWFraW5nDQpjaG9pY2VzIG9uIHRoZWly
IG93biAoZHVlIHRvIHRoZSAmcXVvdDttYXkmcXVvdDtzKSByYXRoZXIgdGhhbiBiZWluZyBkaXJl
Y3RlZCB0bw0KbWFrZSB1bmlmb3JtIGNob2ljZXMgd2hpY2ggd291bGQgaGF2ZSBiZWVuIG1hbmRh
dGVkIGlmIHRoYXQgUkZDIGhhZCB1c2VkDQomcXVvdDtNVVNUJnF1b3Q7cy48L2k+PC9wcmU+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj5UaGlzIGlzIGFsc28g
ZWRpdG9yaWFsLCBhcyB0byB3aG8gaXMgYXQgZmF1bHQuICZuYnNwO2lmIHRoZSBzcGVjIHNheXMg
4oCceW91IGNhbiB1c2UgbWV0aG9kIEEgZm9yIHNpdHVhdGlvbiBT4oCdIGFuZDwvZGl2Pg0KPGRp
dj5pbXBsZW1lbnRvciBzYXlzIOKAnGRpZG7igJl0IHNheSBNVVNULCBzbyBJ4oCZbGwgdXNlIG1l
dGhvZCBCIGluc3RlYWTigJ0sIGRvIHlvdSBibGFtZSB0aGUgc3BlYyB3cml0ZXIgb3I8L2Rpdj4N
CjxkaXY+dGhlIGltcGxlbWVudG9yLiAmbmJzcDtJJ2QgaW1wbGVtZW50b3JzIHRvIHJlYWQgSUVU
RiBSRkNzIHdpdGggZW5naW5lZXJpbmcgY29tbW9uIHNlbnNlIGFuZCBub3QgcGxheTwvZGl2Pg0K
PGRpdj5sZWdhbGlzdGljIGdhbWVzIGFyb3VuZCBub3JtYXRpdmUgdGVybXMuIFNvIEnigJlsbSBn
b2luZyB0byBzdGljayB3aXRoIG15IGxhbmd1YWdlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N
CjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luOjAgMCAwIDQwcHg7IGJvcmRlcjpub25lOyBwYWRkaW5nOjBweDsiPg0KPGRpdiB0ZXh0PSIj
MDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCjxwcmUgY2xhc3M9Indpa2kiPjxwcmUgY2xhc3M9
Im5ld3BhZ2UiPjwvcHJlPjxpPkZpbmFsbHksIEkgdXN1YWxseSBhZHZvY2F0ZSBnaXZpbmcgZGly
ZWN0aW9ucyB0byBpbXBsZW1lbnRlcnMgYWJvdXQgd2hhdA0KdG8gZG8gaWYgdGhleSBmaW5kIGlt
cGxlbWVudGF0aW9ucyB1c2luZyB0aGUgb2xkZXIsIG91dGRhdGVkIHNwZWMuICBBcw0KYW4gZXhh
bXBsZSwgd2hhdCBzaG91bGQgYSByZWNlaXZlciBkbyBpZiBpdCBnZXRzIGEgQ29udGVudFR5cGUg
dGhhdCBkb2VzDQpub3QgaGF2ZSBhICZxdW90O2JvdW5kYXJ5JnF1b3Q7IHBhcmFtZXRlcj8gIEhv
d2V2ZXIsIGFzIEknbSBub3QgcmVhbGx5IGZhbWlsaWFyIA0Kd2l0aCB0aGlzIHRlY2hub2xvZ3ks
IGFuZCBhcyB0aGUgZG9jdW1lbnQgc2F5cyB0aGVyZSBhcmUgbWFueSB3YXlzIHRvDQpkbyBhbGwg
b2YgdGhpcywgdGhlbiBJJ20gbm90IHN1cmUgdGhhdCBjb3VsZCBvciBzaG91bGQgYmUgZGlzY3Vz
c2VkLiAgSWYNCml0IGlzIHNvbWV0aGluZyB0aGF0IHdvdWxkIGJldHRlciBkZWZpbmUgYmVoYXZp
b3IgdGhlbiBJIHdvdWxkIHN1Z2dlc3QNCnByb3ZpZGluZyBzb21lIGd1aWRhbmNlIGhlcmUuPC9p
Pg0KPC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+dGhlIGJvdW5k
YXJ5IHBhcmFtZXRlciBpcyB1c2VkIGluIGFsbCBtdWx0aXBhcnQgdHlwZXMsIHdoaWNoIGFyZSB3
aWRlc3ByZWFkIGluIHRoZSBJbnRlcm5ldC4gVGhlPC9kaXY+DQo8ZGl2PmNvbW1vbiB1bmRlcnN0
YW5kaW5nIG9mIG11bHRpcGFydCBpcyB3aHkgd2UgcGlja2VkIGl0IGZvciBmcmFtaW5nIGZvcm0t
ZGF0YSwgZXZlbiB0aG91Z2ggaXTigJlzPC9kaXY+DQo8ZGl2PnVnbHkgYW5kIHRoZSBwcm9iYWJp
bGlzdGljIGJvdW5kYXJ5IGdlbmVyYXRpb24gZHJpdmVzIGxvdHMgb2YgcGVvcGxlIGNyYXp5LiBT
byB0aGlzIGtpbmQgb2Ygc3R1ZmYgdGhhdDwvZGl2Pg0KPGRpdj5pcyBpbmhlcml0ZWQgZnJvbSBN
SU1FIGRvZXNu4oCZdCBuZWVkIGRpc2N1c3NpbmcuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPGRpdj5UaGUgbWFpbiByZWFzb24gdGhpcyB1cGRhdGUgd2FzIGV2ZW4gbmVjZXNzYXJ5
IGlzIGJlY2F1c2UgdGhhdCBhZHZhbnRhZ2Ugd2FzbuKAmXQgYXMgZ3JlYXQgYW55IG1vcmUsPC9k
aXY+DQo8ZGl2PmFuZCB0aHVzIHRoZSBkaXZlcmdlbmNlcyBmcm9tIG90aGVyIG11bHRpcGFydCB0
eXBlcy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkxhcnJ5PC9kaXY+DQo8ZGl2PuKA
lDwvZGl2Pg0KPGRpdj5odHRwOi8vbGFycnkubWFzaW50ZXIubmV0PC9kaXY+DQo8ZGl2Pjxicj4N
CjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4
OyI+DQo8ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPg0KPHByZSBjbGFzcz0i
d2lraSI+PGJyPjwvcHJlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+
DQo8L2h0bWw+DQo=

--_000_22407EB25E9442F1B1916955F35F4098adobecom_--


From nobody Wed Apr  8 09:01:25 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519BC1B332E; Wed,  8 Apr 2015 09:01:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iy-B_icQeT6D; Wed,  8 Apr 2015 09:01:18 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A6B1B333F; Wed,  8 Apr 2015 08:59:21 -0700 (PDT)
Received: from [130.209.247.112] (port=62464 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YfsNq-0006cd-IS; Wed, 08 Apr 2015 16:59:18 +0100
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: text/plain; charset=us-ascii
From: Colin Perkins 
X-Priority: 3 (Normal)
In-Reply-To: <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>
Date: Wed, 8 Apr 2015 16:59:12 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>
To: Derek Atkins 
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: 
Cc: Roni Even , Magnus Westerlund , Jean-Marc Valin , "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Robert Sparks 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 16:01:20 -0000

On 8 Apr 2015, at 15:42, Derek Atkins  wrote:
> On Wed, April 8, 2015 10:35 am, Colin Perkins wrote:
> [snip]
>>=20
>> And as I keep saying, I believe that is inappropriate, since it's
>> recommending SRTP which is not suitable for many applications. The
>> rtp-howto draft suggests the following text:
>>=20
> [sniped and added below]
>>=20
>> (The two drafts referenced are what became RFCs 7201 and 7202).
>>=20
>> If you want to augment that with a "strong security SHOULD/MUST be =
used",
>> then I certainly don't object. However, a payload format really =
shouldn't
>> be trying to recommend use of a particular RTP security solution, =
such as
>> SRTP.
>=20
> Okay, so if you want to change the text completely (which I'm fine =
with),
> how about just adding a single sentence to the end of what you have:
>=20
>   RTP packets using the payload format defined in this specification
>   are subject to the security considerations discussed in the RTP
>   specification RFC3550, and in any applicable RTP profile such as
>   RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
>   SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
>   Why RTP Does Not Mandate a Single Media Security Solution"
>   [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
>   formats responsibility to discuss or mandate what solutions are used
>   to meet the basic security goals like confidentiality, integrity and
>   source authenticity for RTP in general.  This responsibility lays on
>   anyone using RTP in an application.  They can find guidance on
>   available security mechanisms and important considerations in =
Options
>   for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
>   Applications SHOULD implement at least one of the strong security
>   measures suggested by those references.

Sure, that's fine (Magnus might want to update the rtp-howto with that =
extra text too).

--=20
Colin Perkins
https://csperkins.org/





From nobody Wed Apr  8 09:56:58 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A1F1B3469; Wed,  8 Apr 2015 09:56:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YI-CdR1h0im9; Wed,  8 Apr 2015 09:56:53 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0064.outbound.protection.outlook.com [207.46.100.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE1F1B3480; Wed,  8 Apr 2015 09:56:45 -0700 (PDT)
Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1324.namprd02.prod.outlook.com (25.161.142.23) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 8 Apr 2015 16:56:43 +0000
Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0118.029; Wed, 8 Apr 2015 16:56:43 +0000
From: Larry Masinter 
To: Barry Leiba 
Thread-Topic: New Version Notification for draft-ietf-appsawg-multipart-form-data-10.txt
Thread-Index: AQHQchz9cL6gWwvF/0Kwne7pYXQgPw==
Date: Wed, 8 Apr 2015 16:56:43 +0000
Message-ID: <868AA964-D30D-4750-8F3D-5DE7073BA0C6@adobe.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/15.8.0.150303
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [50.184.24.49]
authentication-results: computer.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1324;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(33656002)(230783001)(62966003)(99286002)(82746002)(40100003)(110136001)(83506001)(86362001)(229853001)(19580395003)(106116001)(77156002)(83716003)(87936001)(2656002)(2900100001)(1720100001)(46102003)(66066001)(2420400003)(122556002)(50986999)(102836002)(54356999)(92566002)(36756003)(15975445007)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1324; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR02MB1324; BCL:0; PCL:0; RULEID:;  SRVR:DM2PR02MB1324; 
x-forefront-prvs: 0540846A1D
Content-Type: text/plain; charset="utf-8"
Content-ID: <67ACFC53840DC34EA7243713E09E777C@namprd02.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 16:56:43.3455 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1324
Archived-At: 
Cc: "draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" 
Subject: [secdir] New Version Notification for draft-ietf-appsawg-multipart-form-data-10.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 16:56:55 -0000

VG8gYWRkcmVzcyBJRVNHIGxhc3QgY2FsbCBjb21tZW50cyBiZXR0ZXI6DQoNClVSTDogICAgICAg
ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWFwcHNh
d2ctbXVsdGlwYXJ0LWZvcm0tZGF0YS0xMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2Rh
dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWFwcHNhd2ctbXVsdGlwYXJ0LWZvcm0t
ZGF0YS8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p
ZXRmLWFwcHNhd2ctbXVsdGlwYXJ0LWZvcm0tZGF0YS0xMA0KRGlmZjogICAgICAgICAgIGh0dHA6
Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYXBwc2F3Zy1tdWx0aXBhcnQt
Zm9ybS1kYXRhLTEwDQoNCj09PT09PQ0KDQphZGRpdGlvbmFsIHR5cG9zIG5vdGVkIG5vdyBmaXhl
ZC4NCg0KcmV2aXNpdGluZyBwcmV2aW91cyByZXBsaWVzOg0KDQoNClNlY3VyaXR5IGNvbnNpZGVy
YXRpb25zOg0KDQpVbmNsZS4gSSB3YXMganVzdCB1bmhhcHB5IHRoYXQgdGhlIFNlY3VyaXR5IENv
bnNpZGVyYXRpb25zIHNlY3Rpb24gY291bGQgYmUNCmJldHRlciwgbW9yZSBjb2hlcmVudCwgYW5k
IGFjdHVhbGx5IGZsb3dlZCByYXRoZXIgdGhhbiB3aGF04oCZcyB0aGVyZS4NCkJ1dCBhcyBzdWdn
ZXN0ZWQsIEkgaGF2ZSBtb3ZlZCB0aGUgbGFzdCBwYXJhZ3JhcGggdG8gdGhlIGZpcnN0Lg0KDQoN
CkluIC0xMCBJIGFsc28gcmV3cm90ZSBteSBwcmV2aW91c2x5IHNuYXJreToNCk9MRA0KICAgTW9y
ZSBwcm9ibGVtYXRpYyBpcyB0aGUgYW1iaWd1aXR5IGludHJvZHVjZWQgYmVjYXVzZSBpbXBsZW1l
bnRhdGlvbnMNCiAgIGRpZCBub3QgZm9sbG93IFtSRkMyMzg4XSBiZWNhdXNlIGl0IHVzZWQgIm1h
eSIgaW5zdGVhZCBvZiAiTVVTVCIgd2hlbg0KICAgc3BlY2lmeWluZyBlbmNvZGluZyBvZiBmaWVs
ZCBuYW1lcywgYW5kIGZvciBvdGhlciB1bmtub3duIHJlYXNvbnMsIHNvDQogICBub3csIHBhcnNl
cnMgbmVlZCB0byBiZSBtb3JlIGNvbXBsZXggZm9yIGZ1enp5IG1hdGNoaW5nIGFnYWluc3QgdGhl
DQogICBwb3NzaWJsZSBvdXRwdXRzIG9mIHZhcmlvdXMgZW5jb2RpbmcgbWV0aG9kcy4NCg0KDQp0
byBhIGxlc3Mgc25hcmt5Og0KTkVXDQogICBNb3JlIHByb2JsZW1hdGljIGFyZSB0aGUgZGlmZmVy
ZW5jZXMgaW50cm9kdWNlZCB3aGVuIGltcGxlbWVudG9ycw0KICAgb3B0ZWQgdG8gbm90IGZvbGxv
dyBbUkZDMjM4OF0gd2hlbiBlbmNvZGluZyBub24tQVNDSUkgZmllbGQgbmFtZXMNCiAgIChwZXJo
YXBzIGJlY2F1c2UgIm1heSIgc2hvdWxkIGhhdmUgYmVlbiAiTVVTVCIpLiAgQXMgYSByZXN1bHQs
DQogICBwYXJzZXJzIG5lZWQgdG8gYmUgbW9yZSBjb21wbGV4IGZvciBtYXRjaGluZyBhZ2FpbnN0
IHRoZSBwb3NzaWJsZQ0KICAgb3V0cHV0cyBvZiB2YXJpb3VzIGVuY29kaW5nIG1ldGhvZHMuDQoN
Cg0KdG8gbm90IGZ1cnRoZXIgZGlzcGFyYWdlIGltcGxlbWVudG9yIGlubm92YXRpb24uDQoNCkxh
cnJ5DQrigJQNCmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5uZXQNCg0KDQoNCg0KDQo=


From nobody Wed Apr  8 11:53:09 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568011B34FC; Wed,  8 Apr 2015 11:53:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14i58711_8g3; Wed,  8 Apr 2015 11:53:04 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 750191B34FA; Wed,  8 Apr 2015 11:53:01 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t38Iqhrp060012 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2015 13:52:54 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Derek Atkins" 
Date: Wed, 08 Apr 2015 13:52:43 -0500
Message-ID: 
In-Reply-To: <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>
References:  <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 18:53:05 -0000

On 8 Apr 2015, at 9:42, Derek Atkins wrote:

> On Wed, April 8, 2015 10:35 am, Colin Perkins wrote:
> [snip]
>>
>> And as I keep saying, I believe that is inappropriate, since it's
>> recommending SRTP which is not suitable for many applications. The
>> rtp-howto draft suggests the following text:
>>
> [sniped and added below]
>>
>> (The two drafts referenced are what became RFCs 7201 and 7202).
>>
>> If you want to augment that with a "strong security SHOULD/MUST be 
>> used",
>> then I certainly don't object. However, a payload format really 
>> shouldn't
>> be trying to recommend use of a particular RTP security solution, 
>> such as
>> SRTP.
>
> Okay, so if you want to change the text completely (which I'm fine 
> with),
> how about just adding a single sentence to the end of what you have:
>
>  RTP packets using the payload format defined in this specification
>  are subject to the security considerations discussed in the RTP
>  specification RFC3550, and in any applicable RTP profile such as
>  RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
>  SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
>  Why RTP Does Not Mandate a Single Media Security Solution"
>  [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
>  formats responsibility to discuss or mandate what solutions are used
>  to meet the basic security goals like confidentiality, integrity and
>  source authenticity for RTP in general.  This responsibility lays on
>  anyone using RTP in an application.  They can find guidance on
>  available security mechanisms and important considerations in Options
>  for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
>  Applications SHOULD implement at least one of the strong security
>  measures suggested by those references.

I'm okay with using the rtp-howto text. But _strictly_as_an_individual_, 
I'd prefer not to add the last sentence, for 2 reasons:

1) This effectively creates a normative downref to informational RFCs 
(7201/7202). That's mainly a process issue, and we can do that if it's 
the right thing to do. But...

2) ... I still don't think a payload format is the right place to put 
this sort of thing (that is, the last sentence.) Now, if our plan is to 
put that text into all future payload formats, that's not quite as bad. 
But unless we plan to revise legacy formats, it still creates confusing 
inconsistency between formats.

For an extreme example, having that sentence in Codec format A and not 
format B could lead to implementor decisions on the order of "I don't 
want to bother with crypto, so I will choose codec B because it has 
lighter requirements" might appear to make sense to someone not steeped 
in this argument.

What I'd _really_ like to do is take the energy in this thread and apply 
it to creating a standards-track security document for RTP unicast 
applications.


From nobody Wed Apr  8 12:38:26 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685081B3564; Wed,  8 Apr 2015 12:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5YSvfGtpH3Q; Wed,  8 Apr 2015 12:38:19 -0700 (PDT)
Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F2A1B3554; Wed,  8 Apr 2015 12:38:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 859F6E2036; Wed,  8 Apr 2015 15:38:17 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 11189-08; Wed,  8 Apr 2015 15:38:13 -0400 (EDT)
Received: by mail2.ihtfp.org (Postfix, from userid 48) id 0CFA3E2038; Wed,  8 Apr 2015 15:38:13 -0400 (EDT)
Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 8 Apr 2015 15:38:13 -0400
Message-ID: 
In-Reply-To: 
References:  <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> 
Date: Wed, 8 Apr 2015 15:38:13 -0400
From: "Derek Atkins" 
To: "Ben Campbell" 
User-Agent: SquirrelMail/1.4.22-14.fc20
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 19:38:21 -0000

Ben,

On Wed, April 8, 2015 2:52 pm, Ben Campbell wrote:
> On 8 Apr 2015, at 9:42, Derek Atkins wrote:
>
>> On Wed, April 8, 2015 10:35 am, Colin Perkins wrote:
>> [snip]
>>>
>>> And as I keep saying, I believe that is inappropriate, since it's
>>> recommending SRTP which is not suitable for many applications. The
>>> rtp-howto draft suggests the following text:
>>>
>> [sniped and added below]
>>>
>>> (The two drafts referenced are what became RFCs 7201 and 7202).
>>>
>>> If you want to augment that with a "strong security SHOULD/MUST be
>>> used",
>>> then I certainly don't object. However, a payload format really
>>> shouldn't
>>> be trying to recommend use of a particular RTP security solution,
>>> such as
>>> SRTP.
>>
>> Okay, so if you want to change the text completely (which I'm fine
>> with),
>> how about just adding a single sentence to the end of what you have:
>>
>>  RTP packets using the payload format defined in this specification
>>  are subject to the security considerations discussed in the RTP
>>  specification RFC3550, and in any applicable RTP profile such as
>>  RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
>>  SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
>>  Why RTP Does Not Mandate a Single Media Security Solution"
>>  [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
>>  formats responsibility to discuss or mandate what solutions are used
>>  to meet the basic security goals like confidentiality, integrity and
>>  source authenticity for RTP in general.  This responsibility lays on
>>  anyone using RTP in an application.  They can find guidance on
>>  available security mechanisms and important considerations in Options
>>  for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
>>  Applications SHOULD implement at least one of the strong security
>>  measures suggested by those references.
>
> I'm okay with using the rtp-howto text. But _strictly_as_an_individual_,
> I'd prefer not to add the last sentence, for 2 reasons:
>
> 1) This effectively creates a normative downref to informational RFCs
> (7201/7202). That's mainly a process issue, and we can do that if it's
> the right thing to do. But...

It's technically not a downref because the referred documents are guidance
and not protocols.  So I don't think there would be any issue.  There is
already precedent for that.

> 2) ... I still don't think a payload format is the right place to put
> this sort of thing (that is, the last sentence.) Now, if our plan is to
> put that text into all future payload formats, that's not quite as bad.
> But unless we plan to revise legacy formats, it still creates confusing
> inconsistency between formats.

I'll point out, again, that the original draft *already did this*, so you
should be talking to the working group about that and not to me.  From
where I sit, I saw the "MAY encrypt" and said "please change that from MAY
to SHOULD."  That's where this all started.

Now, you could say (possibly even correctly -- I wont make that judgement
call) that the WG made a mistake putting that sentence into the Security
Considerations at all in the first place, but they did.  Clearly the WG
decided it was worthwhile to mention that; I'm just suggesting to make the
mention stronger than what was there in -08.

> For an extreme example, having that sentence in Codec format A and not
> format B could lead to implementor decisions on the order of "I don't
> want to bother with crypto, so I will choose codec B because it has
> lighter requirements" might appear to make sense to someone not steeped
> in this argument.
>
> What I'd _really_ like to do is take the energy in this thread and apply
> it to creating a standards-track security document for RTP unicast
> applications.

Are you willing to hold up this document until that work is done so it can
refer to the (yet-to-be-written) protocol security update draft?  I'm fine
with that approach and I'm willing to review whatever draft you guys
produce if that's how you'd like to proceed.

Or you can hold your nose and live with the "UGGH" of it based on what the
WG original created in -08 and move forward for now, knowing that you can
(and should) correct it "right" later.

I have no skin in that decision :)

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


From nobody Wed Apr  8 12:49:26 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CFC1B357E; Wed,  8 Apr 2015 12:49:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ofd_AwwhPQM; Wed,  8 Apr 2015 12:49:21 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 8C33F1B3581; Wed,  8 Apr 2015 12:49:21 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t38Jn6hS065356 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2015 14:49:17 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Derek Atkins" 
Date: Wed, 08 Apr 2015 14:49:05 -0500
Message-ID: <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com>
In-Reply-To: 
References:  <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>  
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 19:49:24 -0000

On 8 Apr 2015, at 14:38, Derek Atkins wrote:

> Ben,
>
> On Wed, April 8, 2015 2:52 pm, Ben Campbell wrote:
>> On 8 Apr 2015, at 9:42, Derek Atkins wrote:
>>
>>> On Wed, April 8, 2015 10:35 am, Colin Perkins wrote:
>>> [snip]
>>>>
>>>> And as I keep saying, I believe that is inappropriate, since it's
>>>> recommending SRTP which is not suitable for many applications. The
>>>> rtp-howto draft suggests the following text:
>>>>
>>> [sniped and added below]
>>>>
>>>> (The two drafts referenced are what became RFCs 7201 and 7202).
>>>>
>>>> If you want to augment that with a "strong security SHOULD/MUST be
>>>> used",
>>>> then I certainly don't object. However, a payload format really
>>>> shouldn't
>>>> be trying to recommend use of a particular RTP security solution,
>>>> such as
>>>> SRTP.
>>>
>>> Okay, so if you want to change the text completely (which I'm fine
>>> with),
>>> how about just adding a single sentence to the end of what you have:
>>>
>>> RTP packets using the payload format defined in this specification
>>> are subject to the security considerations discussed in the RTP
>>> specification RFC3550, and in any applicable RTP profile such as
>>> RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
>>> SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
>>> Why RTP Does Not Mandate a Single Media Security Solution"
>>> [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
>>> formats responsibility to discuss or mandate what solutions are used
>>> to meet the basic security goals like confidentiality, integrity and
>>> source authenticity for RTP in general.  This responsibility lays on
>>> anyone using RTP in an application.  They can find guidance on
>>> available security mechanisms and important considerations in 
>>> Options
>>> for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
>>> Applications SHOULD implement at least one of the strong security
>>> measures suggested by those references.
>>
>> I'm okay with using the rtp-howto text. But 
>> _strictly_as_an_individual_,
>> I'd prefer not to add the last sentence, for 2 reasons:
>>
>> 1) This effectively creates a normative downref to informational RFCs
>> (7201/7202). That's mainly a process issue, and we can do that if 
>> it's
>> the right thing to do. But...
>
> It's technically not a downref because the referred documents are 
> guidance
> and not protocols.  So I don't think there would be any issue.  There 
> is
> already precedent for that.

As I said, it's just process.

>
>> 2) ... I still don't think a payload format is the right place to put
>> this sort of thing (that is, the last sentence.) Now, if our plan is 
>> to
>> put that text into all future payload formats, that's not quite as 
>> bad.
>> But unless we plan to revise legacy formats, it still creates 
>> confusing
>> inconsistency between formats.
>
> I'll point out, again, that the original draft *already did this*, so 
> you
> should be talking to the working group about that and not to me.  From
> where I sit, I saw the "MAY encrypt" and said "please change that from 
> MAY
> to SHOULD."  That's where this all started.
>
> Now, you could say (possibly even correctly -- I wont make that 
> judgement
> call) that the WG made a mistake putting that sentence into the 
> Security
> Considerations at all in the first place, but they did.  Clearly the 
> WG
> decided it was worthwhile to mention that; I'm just suggesting to make 
> the
> mention stronger than what was there in -08.

I'm not convinced. SHOULD is considerably more constraining that MAY.

>
>> For an extreme example, having that sentence in Codec format A and 
>> not
>> format B could lead to implementor decisions on the order of "I don't
>> want to bother with crypto, so I will choose codec B because it has
>> lighter requirements" might appear to make sense to someone not 
>> steeped
>> in this argument.
>>
>> What I'd _really_ like to do is take the energy in this thread and 
>> apply
>> it to creating a standards-track security document for RTP unicast
>> applications.
>
> Are you willing to hold up this document until that work is done so it 
> can
> refer to the (yet-to-be-written) protocol security update draft?  I'm 
> fine
> with that approach and I'm willing to review whatever draft you guys
> produce if that's how you'd like to proceed.

No, I will go with the consensus on this one. I note that several WG 
participants objected to the orignally proposed SHOULD. I am pointing 
out that this SHOULD is not much different, but I will go with what 
people want to do.

OTOH, what I would like to do would fix the problem for this, and all 
other codec payload formats, after the fact if we do it right (since it 
would apply to the application)

>
> Or you can hold your nose and live with the "UGGH" of it based on what 
> the
> WG original created in -08 and move forward for now, knowing that you 
> can
> (and should) correct it "right" later.

The work group did not put in a SHOULD. I think this is more of a 
question of whether people are willing to hold there collective noses 
about the lack of _normative_ privacy guidance for RTP in general, and 
if they are willing to let payload formats continue to progress while 
that is being worked out.

>
> I have no skin in that decision :)
>
> -derek
> -- 
>      Derek Atkins                 617-623-3745
>      derek@ihtfp.com             www.ihtfp.com
>      Computer and Internet Security Consultant


From nobody Wed Apr  8 12:49:30 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96D01B357E; Wed,  8 Apr 2015 12:49:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Otwp-6Upopz; Wed,  8 Apr 2015 12:49:24 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4E41B357F; Wed,  8 Apr 2015 12:49:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AAD5EBEE1; Wed,  8 Apr 2015 20:49:21 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N423azQ3jPkN; Wed,  8 Apr 2015 20:49:20 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 71509BEDF; Wed,  8 Apr 2015 20:49:20 +0100 (IST)
Message-ID: <5525863D.2050006@cs.tcd.ie>
Date: Wed, 08 Apr 2015 20:49:17 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Ben Campbell , Derek Atkins 
References:  <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> 
In-Reply-To: 
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 19:49:26 -0000

On 08/04/15 19:52, Ben Campbell wrote:
> 
> What I'd _really_ like to do is take the energy in this thread and apply
> it to creating a standards-track security document for RTP unicast
> applications.

Fully agree that, if it's achievable, that is better.

As with Derek, I'm not objecting to this draft handling this
either with Derek's latest suggested SHOULD, nor with the
original, nor if it ends up tweaked to match other payload
specs.

S.


From nobody Wed Apr  8 13:40:07 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933EE1B363A; Wed,  8 Apr 2015 13:40:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBjMkZmoziPo; Wed,  8 Apr 2015 13:40:01 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20BFC1B3637; Wed,  8 Apr 2015 13:40:01 -0700 (PDT)
Received: by qkgx75 with SMTP id x75so96107323qkg.1; Wed, 08 Apr 2015 13:40:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=345UK6C4sX8p4KnxC3gaO3pb9/IVaNMsFd1cEKpBnwo=; b=M7/MW9aV9y/9PjeV0rmZwt3dtPRpV5pvzvHgeFAEhW82eafECjJAiNSxAf3qfQfpRG eHWYOF9WZVf1mdIAnGvIait547t9V1GI03kc5DXz94sRMUiHourX+kp/hUuj+dcfV3rL W+uY570iSL1A2ezA8I6FzsknYG389YhGqWVQTxm+CcoO/PYmYl+Q5hjz8bQvJil6E1CZ 4jkfikG4o7ZfbSNWDOiCUa7LmlALv3nifIN4ML1qouBL9OBUAaBaSJUwhiIEfWHfDTTE AwpWqeMbDayEzB+TzbvIOQHnsCcEisq3U9Uc71JWWWGVfueCXTZP0dRI7NMIOTnRh/Gr ahAw==
X-Received: by 10.55.15.129 with SMTP id 1mr53946955qkp.29.1428525600460; Wed, 08 Apr 2015 13:40:00 -0700 (PDT)
Received: from [172.20.28.228] ([66.228.68.140]) by mx.google.com with ESMTPSA id 28sm8216890qkw.13.2015.04.08.13.39.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Apr 2015 13:39:58 -0700 (PDT)
From: Kathleen Moriarty 
X-Google-Original-From: Kathleen Moriarty 
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (11D257)
In-Reply-To: <5525863D.2050006@cs.tcd.ie>
Date: Wed, 8 Apr 2015 16:39:58 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <8F0ACB34-EE96-4348-AC20-EB6727A1EDA7@gmail.com>
References:  <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>  <5525863D.2050006@cs.tcd.ie>
To: Stephen Farrell 
Archived-At: 
Cc: Ben Campbell , "secdir@ietf.org" , "payload@ietf.org" , "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" , Colin Perkins 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 20:40:02 -0000

Sent from my iPhone

> On Apr 8, 2015, at 3:49 PM, Stephen Farrell  wr=
ote:
>=20
>=20
>=20
>> On 08/04/15 19:52, Ben Campbell wrote:
>>=20
>> What I'd _really_ like to do is take the energy in this thread and apply
>> it to creating a standards-track security document for RTP unicast
>> applications.
>=20
> Fully agree that, if it's achievable, that is better.
>=20
> As with Derek, I'm not objecting to this draft handling this
> either with Derek's latest suggested SHOULD, nor with the
> original, nor if it ends up tweaked to match other payload
> specs.
>=20
> S.

Sorry I've been tied up in meetings.   Where are we at with text changes for=
 this draft versus what's planned in another draft?  It would be good to cle=
ar my discuss before tomorrow if we can.

Thanks,
Kathleen=20=


From nobody Wed Apr  8 15:19:52 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963DC1A9057; Wed,  8 Apr 2015 15:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.211
X-Spam-Level: 
X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5sVtDSrlGvI; Wed,  8 Apr 2015 15:19:49 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387EC1A9062; Wed,  8 Apr 2015 15:19:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2278; q=dns/txt; s=iport; t=1428531583; x=1429741183; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=ju7P58caE8AddNNhGQZ1b6EdvcZIpnPzOspTGWvp9O4=; b=UEC/PyhuChExmSGNBPbJnTZZRrQE2exArX4BlGAw03kJyrhquRFZXHnR OeCegACtwpQ30f5bNVk21Xq/pPxonvXaubmBw7L2xC8MVxQUIQIrvtFFM zgUnUJe2lqWz6RKxcV5BgjSR2U5FLjL9qzlbIHkTC9ilcuSAE7Uitq5Sd Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A7BQCsqCVV/4cNJK1cgwhSXAWDEMIqhzNMAQEBAQEBfoRJDwF7AgUhAhECNhYBDAYCAQGIJrZWllkBAQEBAQUBAQEBAQEYBIEhkXWBRQWLJ4lFhg+BHYM3gkKJe4NKIoICHYFvUIFEfwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,546,1422921600"; d="scan'208";a="410365429"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP; 08 Apr 2015 22:19:42 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t38MJgMM003821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Apr 2015 22:19:42 GMT
Received: from [64.101.72.33] (64.101.72.33) by xhc-aln-x02.cisco.com (173.36.12.76) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 8 Apr 2015 17:19:41 -0500
Message-ID: <5525A97D.70607@cisco.com>
Date: Wed, 8 Apr 2015 16:19:41 -0600
From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: The IESG , IETF Security Directorate , 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [64.101.72.33]
Archived-At: 
Subject: [secdir] secdir review of draft-ietf-idr-ls-distribution
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 22:19:50 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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 that had
arrived in a more timely manner.

I think the document is ready, but I have a couple of nits.  Please
note that I am not well versed in the subject of network routing,
so these nits might be irrelevant due to my naivete.

*  Section 6.2.6. is written in terms of what an operator ought to
   do, but I'm not entirely sure what that means to an implementer.
   Does that mean the implementer MUST provide some sort of mechanism
   to allow the operator do follow the SHOULD?  I admittedly only
   glanced through RFC 5706 and RFC 4271, so if this is actually
   covered more generally then please ignore this item.

*  In Section 8., second paragraph, are there known cases where it
   might be ok to accept Consumer peer updates, therefore violating
   the SHOULD NOT?  If there are not, I would think MUST NOT is more
   appropriate.  If there are cases where the SHOULD NOT can be
   ignored, does it makes sense to briefly describe one or two of
   them?  While there are several places in this document where SHOULD
   (or SHOULD NOT) is used without any such exceptions described, it
   seems pertinent to me to describe a case or two for such a SHOULD
   (NOT) in the Security Considerations.


Thank you for your consideration,

- -- 
- - m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJVJal9AAoJEDWi+S0W7cO1Dc8H/j9UqCwTn+VecPTnd2b5UQ2W
mhFM5SGMc+KRpBjriTmxs/snwoLFtuD+u5aGuEEp+mvebR8C2Tg2wDga4TE1R5cu
fs+kmmvzgGkoKtQGcg3MfnAp5F+MEKGRh9iLUt6bBzSEZqMjDvchx+Ha9z+Raxs4
W2Paw6UUr6+RIsKgeioRKYjk+hMQHabtSrb9rdJEjSLgcMcOgXPeLwMz/wlq/pVZ
j5qPVSYTnOcfDEhRle6K99HZ/MZucGwxAv0fe8ukc0X5Ate9P0HrA3pW2oNyAVSX
4MdTvkxcIHucbeiWKpWMy8LpK+9e9CeVKBmvEitixnvOjqLq3qmS0SBu5O7P+qI=
=8yaG
-----END PGP SIGNATURE-----


From nobody Wed Apr  8 15:29:46 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327651A9078; Wed,  8 Apr 2015 15:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdOKyd50Fq-9; Wed,  8 Apr 2015 15:29:37 -0700 (PDT)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5B51A9076; Wed,  8 Apr 2015 15:29:36 -0700 (PDT)
Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id t38MTYpP025503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Apr 2015 18:29:35 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_D9F3BEFA-2C93-4312-B719-FA44558C3618"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Catherine Meadows 
In-Reply-To: <5523EC71.1020701@gridmerge.com>
Date: Wed, 8 Apr 2015 18:29:34 -0400
Message-Id: <29DD884A-AA96-4614-B81B-A8936FD5E6B5@nrl.navy.mil>
References:  <5523EC71.1020701@gridmerge.com>
To: Routing Over Low power and Lossy networks , draft-ietf-roll-applicability-home-building.all@tools.ietf.org
X-Mailer: Apple Mail (2.1878.6)
X-CCS-MailScanner: No viruses found.
X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email
Archived-At: 
Cc: iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] [Roll] Secdir review of draft-ietf-roll-applicability-home-building-09 (resend)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 22:29:41 -0000

--Apple-Mail=_D9F3BEFA-2C93-4312-B719-FA44558C3618
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Thanks much, Robert and Peter!

These make things much clearer.

Cathy


Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil

On Apr 7, 2015, at 10:40 AM, Robert Cragie  =
wrote:

> Hi Catherine,
>=20
> In addition to Peter's comments, here are my comments inline, =
bracketed by 
>=20
> Robert
>=20
> On 06/04/2015 22:37, Catherine Meadows wrote:
>> I had the draft authors=92 email address wrong on my last message, so =
I am resending it.
>>=20
>> I have reviewed this document as part of the security directorate's=20=

>> ongoing effort to review all IETF documents being processed by the=20
>> IESG.  These comments were written primarily for the benefit of the=20=

>> security area directors.  Document editors and WG chairs should treat=20=

>> these comments just like any other last call comments.
>>=20
>> This document gives recommendations for the use of RPL in home =
automation and building control,
>> that typically provide support such things as climate and lighting =
control.  I reviewed a much earlier
>> version of this document, and I think this version is much improved =
in the way it scopes out the problem
>> and handles the security implications.  The Security Considerations =
section in particular is very
>> thorough.  There are a few improvements I would recommend, however:
>>=20
>> Section 4.1.8   Security
>>=20
>> You should  give justifications for these choices of parameters as =
you give justifications for the
>> other parameters described in this draft.
> 
> The parameters are in RFC 6550. Some explanation could be added, for =
example:
>=20
> 
> If RPL is used with secured messages, the following RPL security =
parameter values are recommended to provide a basic level of security:
>=20
>    o  Counter Time Flag: T =3D '0': Do not use timestamp in the =
Counter Field. Counters based on timestamps are typically more =
applicable to industrial networks where strict timing synchronization =
between nodes is often implemented. Home and building networks typically =
do not implement such strict timing synchronization therefore a =
monotonically increasing counter is more appropriate.
>=20
>    o  Algorithm =3D '0': Use Counter with Cipher Block Chaining =
Message Authentication Code (CBC-MAC Mode) (CCM) with Advanced =
Encryption Standard (AES)-128. This is the only assigned mode at =
present.
>=20
>    o  Key Identifier Mode; KIM =3D '10': Use group key, Key Source =
present, Key Index present. Given the relatively confined perimeter of a =
home or building network, a group key is usually sufficient to protect =
RPL messages sent between nodes. The use of the Key Source field allows =
multiple group keys to be used within the network.
>=20
>    o  Security Level; LVL =3D 0: Use MAC-32. This is recommended as =
integrity protection for RPL messages is the basic requirement. =
Encryption is unlikely to be necessary given the relatively =
non-confidential nature of RPL message payloads.
> 
> 
>>=20
>> Section 7.1 Security considerations during initial deployment
>>=20
>> New approaches to initial security deployment are being developed in
>>    [I-D.kumar-dice-dtls-relay] and
>>    [I-D.richardson-6tisch--security-6top].  They assume a partial
>>    ordering of the nodes, such that unsecured nodes are added
>>    sequentially with the restriction that a path between two secured
>>    nodes exists which passes through secured nodes only.
>>=20
>> I found this a little hard to understand.  When does a node pass from =
being unsecured to secured?  Or does an unsecured node remain unsecured? =
If there is
>> a succinct way of saying this, it could go here.  Since this is only =
describing new approaches that could potentially be applied, you would =
not
>> want to go into a lot of detail.=20
> 
> I would clarify as follows, in addition to Peter's suggestion:
>=20
> 
> New approaches to initial security deployment are being developed in =
[I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. =
They assume a partial ordering of the nodes, such that unsecured nodes =
are added sequentially with the restriction that a path between two =
secured nodes exists which passes through secured nodes only.
> 
> 
> New approaches to initial security deployment are being developed in =
[I-D.kumar-dice-dtls-relay] and[I-D.richardson-6tisch-security-6top]. In =
these drafts an already secured node at the perimeter of the network, =
which is one hop away from an unsecured node wishing to access the =
network, assists in transporting security and configuration traffic =
between the unsecured node and the authenticator/commissioner. Once =
secured and configured, the new node extends the perimeter of the =
network in an "onion ring" fashion until all nodes have been secured and =
configured.
> 
> 
>>=20
>> In the home, nodes can be visually inspected by the home owner
>>    and simple measures like pushing buttons simultaneously on joint =
and
>>    joining devices is probably sufficient.
>>=20
>> I think this definitely needs to be clarified!  You need to say what =
is being accomplished by pushing the buttons (device pairing)?
> 
> I would clarify as follows, in addition to Peter's suggestion:
>=20
> 
> In the home, nodes can be visually inspected by the home owner and =
simple measures like pushing buttons simultaneously on joint and joining =
devices is probably sufficient.=20
> 
> 
> In the home, nodes can be visually inspected by the home owner and a =
simple procedure, e.g. pushing buttons simultaneously on an already =
secured device and an unsecured joining device is usually sufficient to =
ensure that the unsecured joining device is authenticated and configured =
securely, and paired appropriately.
> =20
> 
>>=20
>> 7.2
>>=20
>> When nodes are lost, no additional security measures are needed, the
>>    network remains secure as before by not allowing the addition of =
new
>>    nodes.
>>=20
>> I=92m not sure what this means.  Does it mean that if a node is lost, =
then it is treated as a =93new node=94 if it reappears, and is not =
allowed
>> to rejoin the network?
>>=20
>> New nodes can be added by using the same protocols used for
>>    initial deployment.
>>=20
>> This came right after the sentence beginning =93When nodes are lost=94 =
which said that new nodes are not added.  That contradiction needs to
>> be reconciled.  I=92m also not sure what =93using the same protocol=94 =
means.  Does it mean rerunning the protocol and rekeying all the nodes, =
or does
>> it mean using the features that protocol has for adding nodes?
> 
> I would rewrite this somewhat as the intent is unclear. I believe the =
intent is as follows:
>=20
> 
> When nodes are lost, no additional security measures are needed, the =
network remains secure as before by not allowing the addition of new =
nodes. New nodes can be added by using the same protocols used for =
initial deployment.  Some protocols may need a state change to a subset =
of the secured nodes, other protocols only need the presence of a =
"trusted" installation node [RFC6345], [RFC5191], or =
[I-D.kumar-dice-dtls-relay].
> 
> 
> Normally, the network remains secure by not allowing the addition of =
new nodes. If a new node needs to be added to the network, the network =
is usually configured to allow the new node to join via an assisting =
node in the manner described in Section 7.1. If an existing node becomes =
lost, it is usually possible to re-key all other existing nodes to =
isolate the lost node to ensure that, should it be found again, it has =
to re-join as if it were a new node.
> 
> 
>=20
>>=20
>>=20
>> Nits:
>>=20
>> Section 1.1=20
>>=20
>> This applicability statement
>>    recommends more light weight security solutions and specify the
>>    conditions under which these solutions are appropriate.
>>=20
>> Should be =93specifies=94 instead of =93specify=94.  I=92m also not =
sure what is meant by =93conditions under which these solutions are =
appropriate.=94  Do
>> you mean light-weight as opposed to no security, or light-weight as =
opposed to heavy-weight.  Or are you talking about conditions
>> under which different light-weight solutions are appropriate? =46rom =
reading the rest of the draft, I would assume the last is what you mean.
> 
> I would reword as follows:
>=20
> 
> This applicability statement recommends more light weight security =
solutions and specify the conditions under which these solutions are =
appropriate.
> 
> 
> This applicability statement recommends lighter weight security =
solutions appropriate for home and building environments and indicates =
why these solutions are appropriate.
> 
> 
>>=20
>>=20
>> I consider this document  ready with issues.
>>=20
>> Catherine Meadows
>> Naval Research Laboratory
>> Code 5543
>> 4555 Overlook Ave., S.W.
>> Washington DC, 20375
>> phone: 202-767-3490
>> fax: 202-404-7942
>> email: catherine.meadows@nrl.navy.mil
>>=20
>>=20
>>=20
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>=20


--Apple-Mail=_D9F3BEFA-2C93-4312-B719-FA44558C3618
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Thanks =
much, Robert and Peter!

These make things much =
clearer.

Cathy



Catherine Meadows
Naval =
Research Laboratory
Code 5543
4555 Overlook Ave., =
S.W.
Washington DC, 20375
phone: 202-767-3490
fax: =
202-404-7942
email: catherine.meadows@nrl.navy.=
mil




On Apr 7, 2015, at 10:40 AM, Robert Cragie <robert.cragie@gridmerge.com> wrote:


 =20
    
 =20
  

    Hi Catherine,

    

    In addition to Peter's comments, here are my comments inline,
    bracketed by <RCC></RCC>

    

    Robert

    

    
On 06/04/2015 22:37, Catherine =
Meadows
      wrote:

    

    

      
      I had the draft authors=92 email address wrong on my last message,
      so I am resending it.
      


      

      
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 gives recommendations for the use of RPL in home
        automation and building control,

        that typically provide support such things as climate and
        lighting control.  I reviewed a much earlier

        version of this document, and I think this version is much
        improved in the way it scopes out the problem

        and handles the security implications.  The Security
        Considerations section in particular is very

        thorough.  There are a few improvements I would recommend,
        however:

        

        Section 4.1.8   Security

        

        You should  give justifications for these choices of =
parameters
        as you give justifications for the

        other parameters described in this draft.

      

    

    <RCC>

    The parameters are in RFC 6550. Some explanation could be added, for
    example:

    

    <new>

    If RPL is used with secured messages, the following RPL security
    parameter values are recommended to provide a basic level of
    security:

    

       o  Counter Time Flag: T =3D '0': Do not use =
timestamp in the
    Counter Field. Counters based on timestamps are typically more
    applicable to industrial networks where strict timing
    synchronization between nodes is often implemented. Home and
    building networks typically do not implement such strict timing
    synchronization therefore a monotonically increasing counter is more
    appropriate.

    

       o  Algorithm =3D '0': Use Counter with Cipher =
Block Chaining
    Message Authentication Code (CBC-MAC Mode) (CCM) with Advanced
    Encryption Standard (AES)-128. This is the only assigned mode at
    present.

    

       o  Key Identifier Mode; KIM =3D '10': Use group =
key, Key Source
    present, Key Index present. Given the relatively confined perimeter
    of a home or building network, a group key is usually sufficient to
    protect RPL messages sent between nodes. The use of the Key Source
    field allows multiple group keys to be used within the network.

    

       o  Security Level; LVL =3D 0: Use MAC-32. This is =
recommended as
    integrity protection for RPL messages is the basic requirement.
    Encryption is unlikely to be necessary given the relatively
    non-confidential nature of RPL message payloads.

    </new>

    </RCC>

    

      


        Section 7.1 Security considerations during initial =
deployment

        

        New approaches to initial security deployment are being
        developed in

           [I-D.kumar-dice-dtls-relay] and

           [I-D.richardson-6tisch--security-6top].  They =
assume a
        partial

           ordering of the nodes, such that unsecured nodes =
are added

           sequentially with the restriction that a path =
between two
        secured

           nodes exists which passes through secured nodes =
only.

        

        I found this a little hard to understand.  When does a node =
pass
        from being unsecured to secured?  Or does an unsecured node
        remain unsecured? If there is

        a succinct way of saying this, it could go here.  Since =
this is
        only describing new approaches that could potentially be
        applied, you would not

        want to go into a lot of detail. 

      

    

    <RCC>

    I would clarify as follows, in addition to Peter's suggestion:

    

    <old>

    New approaches to initial security deployment are being developed in
    [I-D.kumar-dice-dtls-relay] and
    [I-D.richardson-6tisch--security-6top]. They assume a partial
    ordering of the nodes, such that unsecured nodes are added
    sequentially with the restriction that a path between two secured
    nodes exists which passes through secured nodes only.

    </old>

    <new>

    New approaches to initial security deployment are being developed in
    [I-D.kumar-dice-dtls-relay]
    and[I-D.richardson-6tisch-security-6top]. In these drafts an already
    secured node at the perimeter of the network, which is one hop away
    from an unsecured node wishing to access the network, assists in
    transporting security and configuration traffic between the
    unsecured node and the authenticator/commissioner. Once secured and
    configured, the new node extends the perimeter of the network in an
    "onion ring" fashion until all nodes have been secured and
    configured.

    </new>

    </RCC>

    

      


        In the home, nodes can be visually inspected by the home =
owner

           and simple measures like pushing buttons =
simultaneously on
        joint and

           joining devices is probably sufficient.

        

        I think this definitely needs to be clarified!  You need to =
say
        what is being accomplished by pushing the buttons (device
        pairing)?

      

    

    <RCC>

    I would clarify as follows, in addition to Peter's suggestion:

    

    <old>

    In the home, nodes can be visually inspected by the home owner and
    simple measures like pushing buttons simultaneously on joint and
    joining devices is probably sufficient. 

    </old>

    <new>

    In the home, nodes can be visually inspected by the home owner and a
    simple procedure, e.g. pushing buttons simultaneously on an already
    secured device and an unsecured joining device is usually sufficient
    to ensure that the unsecured joining device is authenticated and
    configured securely, and paired appropriately.

    </new> 

    </RCC>

    

      


        7.2

        

        When nodes are lost, no additional security measures are needed,
        the

           network remains secure as before by not allowing =
the addition
        of new

           nodes.

        

        I=92m not sure what this means.  Does it mean that if a =
node is
        lost, then it is treated as a =93new node=94 if it reappears, =
and is
        not allowed

        to rejoin the network?

        

        New nodes can be added by using the same protocols used for

           initial deployment.

        

        This came right after the sentence beginning =93When nodes are
        lost=94 which said that new nodes are not added.  That
        contradiction needs to

        be reconciled.  I=92m also not sure what =93using the same =
protocol=94
        means.  Does it mean rerunning the protocol and rekeying =
all the
        nodes, or does

        it mean using the features that protocol has for adding =
nodes?

      

    

    <RCC>

    I would rewrite this somewhat as the intent is unclear. I believe
    the intent is as follows:

    

    <old>

    When nodes are lost, no additional security measures are needed, the
    network remains secure as before by not allowing the addition of new
    nodes. New nodes can be added by using the same protocols used for
    initial deployment.  Some protocols may need a state change to =
a
    subset of the secured nodes, other protocols only need the presence
    of a "trusted" installation node [RFC6345], [RFC5191], or
    [I-D.kumar-dice-dtls-relay].

    </old>

    <new>

    Normally, the network remains secure by not allowing the addition of
    new nodes. If a new node needs to be added to the network, the
    network is usually configured to allow the new node to join via an
    assisting node in the manner described in Section 7.1. If an
    existing node becomes lost, it is usually possible to re-key all
    other existing nodes to isolate the lost node to ensure that, should
    it be found again, it has to re-join as if it were a new node.

    </new>

    </RCC>

    

    

      


        

        Nits:

        

        Section 1.1 

        

        This applicability statement

           recommends more light weight security solutions and =
specify
        the

           conditions under which these solutions are =
appropriate.

        

        Should be =93specifies=94 instead of =93specify=94.  I=92m =
also not sure
        what is meant by =93conditions under which these solutions are
        appropriate.=94  Do

        you mean light-weight as opposed to no security, or light-weight
        as opposed to heavy-weight.  Or are you talking about =
conditions

        under which different light-weight solutions are appropriate?
        =46rom reading the rest of the draft, I would assume the last is
        what you mean.

      

    

    <RCC>

    I would reword as follows:

    

    <old>

    This applicability statement recommends more light weight security
    solutions and specify the conditions under which these solutions are
    appropriate.

    </old>

    <new>

    This applicability statement recommends lighter weight security
    solutions appropriate for home and building environments and
    indicates why these solutions are appropriate.

    </new>

    </RCC>

    

      
      

      

      

      
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m=
ailman/listinfo/roll


    

    

  




=

--Apple-Mail=_D9F3BEFA-2C93-4312-B719-FA44558C3618--


From nobody Wed Apr  8 16:04:33 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311671A9165; Wed,  8 Apr 2015 16:04:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.69
X-Spam-Level: 
X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_NONE=-0.0001, T_FROM_12LTRDOM=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sllM3yRdNq7; Wed,  8 Apr 2015 16:04:29 -0700 (PDT)
Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B0791A9164; Wed,  8 Apr 2015 16:04:29 -0700 (PDT)
Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Yfz1H-00016e-98; Wed, 08 Apr 2015 17:04:27 -0600
Received: from [72.250.219.84] (helo=sylvester.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1Yfz1G-0004AB-C3; Wed, 08 Apr 2015 17:04:27 -0600
Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id t38N49Pe016520; Wed, 8 Apr 2015 17:04:09 -0600
Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id t38N48Ga016518; Wed, 8 Apr 2015 17:04:08 -0600
Date: Wed, 8 Apr 2015 17:04:08 -0600
Message-Id: <201504082304.t38N48Ga016518@sylvester.rhmr.com>
From: "Hilarie Orman" 
To: iesg@ietf.org
X-XM-AID: U2FsdGVkX19IgXMXHGciIYGgpcTYHcN+
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
X-Spam-Relay-Country: 
X-Spam-Timing: total 484 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 4.2 (0.9%), b_tie_ro: 3.0 (0.6%), parse: 1.03 (0.2%), extract_message_metadata: 6 (1.2%), get_uri_detail_list: 3.1 (0.6%), tests_pri_-1000: 3.8 (0.8%), tests_pri_-950: 1.61 (0.3%), tests_pri_-900: 1.21 (0.3%), tests_pri_-400: 25 (5.1%), check_bayes: 23 (4.7%), b_tokenize: 7 (1.4%), b_tok_get_all: 7 (1.4%), b_comp_prob: 3.2 (0.7%), b_tok_touch_all: 3.3 (0.7%), b_finish: 0.84 (0.2%), tests_pri_0: 433 (89.5%), tests_pri_500: 4.7 (1.0%), rewrite_mail: 0.00 (0.0%)
X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600)
X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com)
Archived-At: 
Cc: draft-ietf-httpauth-digest.all@tools.ietf.org, secdir@ietf.org
Subject: [secdir] Review of draft-ietf-httpauth-digest-15
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Hilarie Orman 
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 23:04:30 -0000

Security review of
HTTP Digest Access Authentication
draft-ietf-httpauth-digest-15

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.

HTTP authentication can be done via username and password.  This
document defines two hash function based methods for sending a binding
between the password, username, and other information.  The password
can be verified on a server by checking the hash using the recorded
password and the current information.  The method defines the use of
newer hash functions but keeps backwards compatibility with MD5.

"Section 3.1 Overall Operation
   ....
   The security of this protocol is critically dependent on the
   randomness of the randomly chosen parameters, such as client and
   server nonces.  These should be generated by a strong random or
   properly seeded pseudorandom source (see [RFC4086])."

The above seems to be something that should go into the noticeably
absent "Security Considerations" section.

Page 5, discussions the "nonce".  The "secret-data" is what requires
the high-quality randomness mentioned in section 3.1.  This should be
explicitly noted.  There should be some guidance on the minimum
acceptable length of the secret-data ... 128 bits seems reasonable to
me.  The maximum length should also be specified, and I would
recommend that it be no more than 512 bits at most.

I would further recommend that the secret data be generated explicitly
for digest authentication and not copied from some other random value
used by the server for other security purposes.  Further, the
"secret-data" should be changed periodically, not just on server
restart.

"Also, IP address spoofing is not that hard." would be better stated
as "Source IP addresses are no guarantee of end-to-end integrity."

Page 5, "opaque" data string.  What is the minimum acceptable length?
16 bytes?  Maximum?  There should be a maximum.

Page 6
" algorithm

      A string indicating a pair of algorithms used to produce the
      digest and a checksum.  If this is not present it is assumed to be
      "MD5". 
"

How is "MD5" a pair of algorithms?  Is "MD5,MD5" a pair?  Or is the
there actually a single algorithm that will be used in two ways (keyed
and unkeyed digest)?

It would be helpful to note that "KD" means "Keyed digest". It would
be better to use HMAC than the concatenation shown.

Rather than "checksum", it would be more appropriate to say "digest"
or "unkeyed digest".  E.g, "to produce a keyed digest and an unkeyed
digest."

Page 8, what is the minimum acceptable length for cnonce?  Maximum length?

Page 10, "cnounce" should be "cnonce".

I would recommend that the keyed digest be done in the following way:

K = H(password)
C = concatenation of a bunch of non-secret stuff
KD(K, C) = HMAC(K, C) = H(K, H(K, C))

For the H-ness calculations, 

C' = unq(username) ":" unq(realm) ":" unq(nonce-prime) ":" unq(cnonce-prime)

 A1 = HMAC(K, C')

and then 

 KD ( A1, C ) = HMAC(A1, C) = H(A2, H(A1, C))


Hilarie


From nobody Wed Apr  8 18:00:09 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BFF1ACCE5; Wed,  8 Apr 2015 17:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Level: 
X-Spam-Status: No, score=-0.799 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, J_CHICKENPOX_21=0.6, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4GwyilqEjOV; Wed,  8 Apr 2015 17:56:40 -0700 (PDT)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22551AC44B; Wed,  8 Apr 2015 17:56:39 -0700 (PDT)
Received: by oblw8 with SMTP id w8so114435213obl.0; Wed, 08 Apr 2015 17:56:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MZ07QGiXu4CEoIGBlmC9K0PlCUCpPQCSFjSt7/YQT/Q=; b=MS9tT8qeCr8iowqm4YfROl2RxdIdQLuw5of89lCCWPr7tS5o/nb1MLblaeOaKoQQCC kTMWjVDChn8i8rks+PJ7OZ+XObXFtaE/SK6A0HsWjYAmDQYzVjypTMqcPh+6lhccIax8 PxyDQRI1JtfgLUWrRGUx2VWXSUfEb/Wrr1OGb7/Xl8RA+Rm9u4Co652GAl4FCNKvPWP/ xGDTQ5ScCzY3dkSPdnVBMTI6mIWHPQVHaVqH8Ts/QFj8C1R/+xfL6h2S5NABFaCI6kFv S4ej2NxcFtifZjh+YYmzG0XsSHHezvdYP2l8d08DwiU59BQPmwczKq7fa0+KaSSeNf2I ZWyw==
MIME-Version: 1.0
X-Received: by 10.182.255.195 with SMTP id as3mr35617592obd.56.1428540999430;  Wed, 08 Apr 2015 17:56:39 -0700 (PDT)
Received: by 10.202.93.69 with HTTP; Wed, 8 Apr 2015 17:56:39 -0700 (PDT)
In-Reply-To: <201504082304.t38N48Ga016518@sylvester.rhmr.com>
References: <201504082304.t38N48Ga016518@sylvester.rhmr.com>
Date: Wed, 8 Apr 2015 20:56:39 -0400
Message-ID: 
From: Rifaat Shekh-Yusef 
To: Hilarie Orman 
Content-Type: multipart/alternative; boundary=001a1134a616d1779f0513401e2e
Archived-At: 
X-Mailman-Approved-At: Wed, 08 Apr 2015 18:00:08 -0700
Cc: draft-ietf-httpauth-digest.all@tools.ietf.org, The IESG , secdir@ietf.org
Subject: Re: [secdir] Review of draft-ietf-httpauth-digest-15
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 00:56:42 -0000

--001a1134a616d1779f0513401e2e
Content-Type: text/plain; charset=ISO-8859-1

Hi Hilarie,

Thanks for your review and comments.
Please, see my reply inline...

Regards,
 Rifaat


On Wed, Apr 8, 2015 at 7:04 PM, Hilarie Orman 
wrote:

> Security review of
> HTTP Digest Access Authentication
> draft-ietf-httpauth-digest-15
>
> 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.
>
> HTTP authentication can be done via username and password.  This
> document defines two hash function based methods for sending a binding
> between the password, username, and other information.  The password
> can be verified on a server by checking the hash using the recorded
> password and the current information.  The method defines the use of
> newer hash functions but keeps backwards compatibility with MD5.
>
> "Section 3.1 Overall Operation
>    ....
>    The security of this protocol is critically dependent on the
>    randomness of the randomly chosen parameters, such as client and
>    server nonces.  These should be generated by a strong random or
>    properly seeded pseudorandom source (see [RFC4086])."
>
> The above seems to be something that should go into the noticeably
> absent "Security Considerations" section.
>
>
Hmmm, did you miss section 5?




> Page 5, discussions the "nonce".  The "secret-data" is what requires
> the high-quality randomness mentioned in section 3.1.  This should be
> explicitly noted.  There should be some guidance on the minimum
> acceptable length of the secret-data ... 128 bits seems reasonable to
> me.  The maximum length should also be specified, and I would
> recommend that it be no more than 512 bits at most.
>
> I would further recommend that the secret data be generated explicitly
> for digest authentication and not copied from some other random value
> used by the server for other security purposes.  Further, the
> "secret-data" should be changed periodically, not just on server
> restart.
>
>
The document explicitly states that "The contents of the nonce are
implementation dependent".
The text was copied from RFC2617, and unless there is a good chance that
people would be interested in implementing these new ideas, I would rather
we keep it as is.
Also, can you explain why do you recommend 128 bits as minimum and 512 bits
as maximum?



> "Also, IP address spoofing is not that hard." would be better stated
> as "Source IP addresses are no guarantee of end-to-end integrity."
>
>
Well, the existing text at least states why you should not rely on IP
address. With your proposed text, you state something but do not explain
what is that the case.



> Page 5, "opaque" data string.  What is the minimum acceptable length?
> 16 bytes?  Maximum?  There should be a maximum.
>
>
Again, this is implementation dependent.



> Page 6
> " algorithm
>
>       A string indicating a pair of algorithms used to produce the
>       digest and a checksum.  If this is not present it is assumed to be
>       "MD5".
> "
>
> How is "MD5" a pair of algorithms?  Is "MD5,MD5" a pair?  Or is the
> there actually a single algorithm that will be used in two ways (keyed
> and unkeyed digest)?
>
>
This is the way it was stated in RFC2617. It is the same algorithm used to
hash different things. I will fix it.



> It would be helpful to note that "KD" means "Keyed digest".


Ok.



> It would
> be better to use HMAC than the concatenation shown.
>
>
Yeah, as I mentioned in a response to a previous review, and I would be
happy to do that if there is interest and support for adding HMAC support.



> Rather than "checksum", it would be more appropriate to say "digest"
> or "unkeyed digest".  E.g, "to produce a keyed digest and an unkeyed
> digest."
>
>
Ok.



> Page 8, what is the minimum acceptable length for cnonce?  Maximum length?
>
>
This is implementation dependent.



> Page 10, "cnounce" should be "cnonce".
>
>
Ok



> I would recommend that the keyed digest be done in the following way:
>
> K = H(password)
> C = concatenation of a bunch of non-secret stuff
> KD(K, C) = HMAC(K, C) = H(K, H(K, C))
>
> For the H-ness calculations,
>
> C' = unq(username) ":" unq(realm) ":" unq(nonce-prime) ":"
> unq(cnonce-prime)
>
>  A1 = HMAC(K, C')
>
> and then
>
>  KD ( A1, C ) = HMAC(A1, C) = H(A2, H(A1, C))
>
>
Let's first see if there is support for the idea of adding HMAC support;
after that we will deal with these details.

Regards,
 Rifaat



> Hilarie
>

--001a1134a616d1779f0513401e2e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi Hilarie,

Thanks for your review and =
comments.
Please, see my reply inline...

Regards,
=A0Rifaat


On Wed, Apr 8, 2015 at 7:04 PM, Hilarie Or=
man <hilarie@purplestreak.com> wrote:
Security review of

HTTP Digest Access Authentication

draft-ietf-httpauth-digest-15



Do not be alarmed.=A0 I have reviewed this document as part of the

security directorate's ongoing effort to review all IETF documents

being processed by the IESG.=A0 These comments were written primarily

for the benefit of the security area directors.=A0 Document editors and

WG chairs should treat these comments just like any other last call

comments.



HTTP authentication can be done via username and password.=A0 This

document defines two hash function based methods for sending a binding

between the password, username, and other information.=A0 The password

can be verified on a server by checking the hash using the recorded

password and the current information.=A0 The method defines the use of

newer hash functions but keeps backwards compatibility with MD5.



"Section 3.1 Overall Operation

=A0 =A0....

=A0 =A0The security of this protocol is critically dependent on the

=A0 =A0randomness of the randomly chosen parameters, such as client and

=A0 =A0server nonces.=A0 These should be generated by a strong random or
=A0 =A0properly seeded pseudorandom source (see [RFC4086])."



The above seems to be something that should go into the noticeably

absent "Security Considerations" section.



Hmmm, did you miss section 5?


=A0

Page 5, discussions the "nonce".=A0 The "secret-data" i=
s what requires

the high-quality randomness mentioned in section 3.1.=A0 This should be

explicitly noted.=A0 There should be some guidance on the minimum

acceptable length of the secret-data ... 128 bits seems reasonable to

me.=A0 The maximum length should also be specified, and I would

recommend that it be no more than 512 bits at most.



I would further recommend that the secret data be generated explicitly

for digest authentication and not copied from some other random value

used by the server for other security purposes.=A0 Further, the

"secret-data" should be changed periodically, not just on server<=
br>
restart.



The document explicitly states th=
at "The contents of the nonce are implementation dependent".
The text was copied from RFC2617, and unless there is a good ch=
ance that people would be interested in implementing these new ideas, I wou=
ld rather we keep it as is.
Also, can you explain why do you reco=
mmend 128 bits as minimum and 512 bits as maximum?

=A0

"Also, IP address spoofing is not that hard." would be better sta=
ted

as "Source IP addresses are no guarantee of end-to-end integrity."=
;



Well, the existing text at least state=
s why you should not rely on IP address. With your proposed text, you state=
 something but do not explain what is that the case.

=A0

Page 5, "opaque" data string.=A0 What is the minimum acceptable l=
ength?

16 bytes?=A0 Maximum?=A0 There should be a maximum.



Again, this is implementation dependen=
t.

=A0

Page 6

" algorithm



=A0 =A0 =A0 A string indicating a pair of algorithms used to produce the
=A0 =A0 =A0 digest and a checksum.=A0 If this is not present it is assumed =
to be

=A0 =A0 =A0 "MD5".

"



How is "MD5" a pair of algorithms?=A0 Is "MD5,MD5" a pa=
ir?=A0 Or is the

there actually a single algorithm that will be used in two ways (keyed

and unkeyed digest)?



This is the way it was stated in RFC26=
17. It is the same algorithm used to hash different things. I will fix it.<=
/div>

=A0

It would be helpful to note that "KD" means "Keyed digest&qu=
ot;. 

Ok.

=A0
It would

be better to use HMAC than the concatenation shown.



Yeah, as I mentioned in a response to =
a previous review, and I would be happy to do that if there is interest and=
 support for adding HMAC support.

=A0

Rather than "checksum", it would be more appropriate to say "=
;digest"

or "unkeyed digest".=A0 E.g, "to produce a keyed digest and =
an unkeyed

digest."



Ok.

=A0
=


Page 8, what is the minimum acceptable length for cnonce?=A0 Maximum length=
?



This is implementation dependent.

=A0

Page 10, "cnounce" should be "cnonce".



Ok

=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex">
I would recommend that the keyed digest be done in the following way:



K =3D H(password)

C =3D concatenation of a bunch of non-secret stuff

KD(K, C) =3D HMAC(K, C) =3D H(K, H(K, C))



For the H-ness calculations,



C' =3D unq(username) ":" unq(realm) ":" unq(nonce-p=
rime) ":" unq(cnonce-prime)



=A0A1 =3D HMAC(K, C')



and then



=A0KD ( A1, C ) =3D HMAC(A1, C) =3D H(A2, H(A1, C))



Let's first see if there is support for the idea of adding HMAC s=
upport; after that we will deal with these details.

Regards,
=A0Rifaat





Hilarie





--001a1134a616d1779f0513401e2e--


From nobody Wed Apr  8 19:54:03 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64561B3744; Wed,  8 Apr 2015 19:54:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiZyyTB15DXE; Wed,  8 Apr 2015 19:53:58 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5871B3741; Wed,  8 Apr 2015 19:53:58 -0700 (PDT)
Received: from [192.168.10.171] ([207.47.25.82]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MDFB2-1YcifY1dds-00GazW; Thu, 09 Apr 2015 04:53:33 +0200
Message-ID: <5525E9A3.6010906@gmx.net>
Date: Thu, 09 Apr 2015 04:53:23 +0200
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Kostas Pentikousis ,  "secdir@ietf.org" , "iesg@ietf.org >> The IESG" ,  "draft-ietf-ippm-ipsec@tools.ietf.org" 
References: <54D85781.2080009@gmx.net> <0C7EDCF89AB9E2478B5D010026CFF4AEB5AB748D98@SBS2008.eict.local>
In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEB5AB748D98@SBS2008.eict.local>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fjbUha1aNdkc8DqwArNFq9H6fOSswwXHB"
X-Provags-ID: V03:K0:W9JcsYYCh58bWFYA7DiQpUouobLxlXBAGBDIVQUqU3jZgEqfW3O 38hQDBjx5WOHBX1T1RpCmZjvJZac9BkcL2PPlLprYQCsfcMnTtQQt73DYefWPOdDYVSSFoH Vr/JWaTV8snQBOZlftTmXubTCbYIzf7azgrNnfv+51WOphiNi4xbhlsf+38vZk/rT0NGxEN hl0+CD5usiju156vyX5kw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Subject: Re: [secdir] Security review of draft-ietf-ippm-ipsec-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 02:54:02 -0000

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

Hi Kostas,

thanks for responding to my review.

A few remarks inline.

On 02/12/2015 01:29 PM, Kostas Pentikousis wrote:
> Hi Hannes,
>=20
> 
>=20
> | 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.
>=20
> Many thanks for the thorough review. Much appreciated.
>=20
> 
>=20
>=20
> | In the introduction you point out that IKEv2 is very commonly
> deployed. | You even say that "In mobile telecommunication networks,
> the deployment rate | of IPsec exceeds 95% with respect to the LTE
> serving network." | | While the exact number is probably not that
> important (and very likely hard to
>=20
> This text originates from the motivation that got this draft going.
> In particular, the nearly 10-year old RFC 4656 argues in sec. 6.6
> (https://tools.ietf.org/html/rfc4656#section-6.6), among other
> things, that
>=20
> "The deployment paths of IPsec and OWAMP could be separate if OWAMP=20
> does not depend on IPsec.  After nine years of IPsec, only 0.05% of
> traffic on an advanced backbone network, such as Abilene, uses IPsec
> (for comparison purposes with encryption above layer 4, SSH use is at
> 2-4% and HTTPS use is at 0.2-0.6%).  It is desirable to be able to
> deploy OWAMP on as large a number of different platforms as
> possible."
>=20
> I don't think we need to argue about the numbers for IPsec, HTTPS and
> so on today (esp. as we look towards 2020), but I would make the case
> that it's likely that IPsec is more widely deployed today than OWAMP
> is. Perhaps I'm wrong, please correct me. Hence, during the early
> phase of development of this draft we included this text to
> illustrate eminent use cases for this draft (such as the LTE case).
> If you think that "95%" should be replaced with "the vast majority
> of" or something of that nature, please let us know. If you have
> completely different numbers from operators, research studies or
> vendors for this type of deployment (or other settings for that
> matter), I'll be happy to hear them.

I just got a hung up on the numbers you mention since you do not provide
any description of where these numbers came from. So, I would prefer to
say something like widely deployed or so.


>=20
>=20
> | verify) the statement does, however, raise some questions. You seem
> to expect | that you can re-use already deployed IKEv2 for the
> special version of IKEv2 | you are describing in this document and
> that's unfortunately very unlikely to | be true.
>=20
> I don't agree this is the case when I read the text.

When you talk in the introduction about the widespread deployment of
IPsec and IKEv2 in operator networks, then state that using IPsec /
IKEv2 is a "viable alternative" for protecting O/TWAMP
and then document the solution then it is easy to come up with the idea
that
this existing deployment can be re-used.

I believe that the reason for stating that IPsec/IKEv2 is already so
widely deployed is to create the argument for going with the IPsec/IKEv2
solution approach.

In all fairness for operators, who read this specification, they should
not be under the impression that they can might necessarily be able to
re-use their existing IPsec/IKEv2 stack since the described solution is
a bit special IMHO.


>=20
> | The solution described in the document requires a very tight
> integration | between an IKEv2 implementation (not IPsec) and the
> O/TWAMP application and | the text in the document gives me the
> impression that you are not entirely | aware that this will actually
> need to happen. This may lead to unpleasant | surprises when you
> implement it.
>=20
> I don't agree with the term "very tight integration". In fact, we had
> the API discussion several times with folks in ipsecme over the last
> 2 years and a bit.

What was the outcome of that discussion? Can you send me a pointer to it?=


> I heard some of the background, and I agree that
> perhaps an IPsec vendor with *no interest in TWAMP* may have to think
> more if they want to invest the effort to support this spec.

Of course, an IPsec VPN vendor who provides a solution as described
in the document will not encounter a problem. This, however, supports
my impression that a random IPsec VPN solution (I call it
"of-the-shelve" stack) might not work.

> But for
> vendors with both implementations in house, I would leave it to their
> respective implementation teams. This spec would facilitate
> interoperability in this latter case.

It is great to describe aspects that concern interoperability
but it is also important to point to potential
implementation/operational issues.

>=20
> As an aside, and given that this is an IPPM draft, I would like to
> point out that TWAMP per se (RFC 5357, sec. 1.2:
> https://tools.ietf.org/html/rfc5357#section-1.2) does leave certain
> interactions "unspecified", which "may be proprietary protocols".

=2E.. which is not good for interoperability.

>=20
> | First, you will have to trigger the IKEv2 exchange from the
> application. | Second, you definitely do not want the IKEv2 exchange
> to create IPsec SAs
>=20
> 
>=20
> | "IPPM" ). IMHO no off-the-shelf IKEv2 implementation will let
> applications | access the SK_d directly nor will it have an API to
> the IKEv2 SA either.
>=20
> Agreed, wrt "off-the-shelf" (in general), after all this is not an
> RFC yet. But please see above.
>=20
>=20
> | It might also want to think about potential interactions from the |
> IKEv2-> to O/TWAMP side, such as rekeying. I am not sure whether
> there | are issues to take into account but have you thought about
> them?
>=20
> This is addressed in the last paragraph of sec. 5.1
> (https://tools.ietf.org/html/draft-ietf-ippm-ipsec-09#section-5.1).
> If you would like other text to be added or this to be edited, please
> kindly send a proposal.
>=20
> 
>=20

Here is the current text:

"

   If rekeying for the IKEv2 SA or deletion of the IKEv2 SA occurs, the
   corresponding shared secret key generated from the SA can continue to
   be used until the O/TWAMP session terminates.
"

I would prefer to have this paragraph written in a normative way (i.e.,
using RFC 2119 language). It seems that you leave it up to the
implementation on how to react to re-keying / IKEv2 SA deletion.
Wouldn't this create potential issues when one side decides to derive
new keying material and the other side doesn't? What happens if one side
has the policy to delete the O/TWAMP keying material in response to the
IKEv2 SA being deleted?

Was there a reason why rekeying of an IKEv2 SA shouldn't lead to new
keying material be derived mandatorily? Also, one would think when the
underlying IKEv2 SA is deleted then the keying material for the O/TWAMP
also be deleted.

>=20
> | In Section 5.1 you describe a way to obtain for the O/TWAMP
> implementation to | interact with the IKEv2 code as follows: | | " |
> the IPSec layer can perform a lookup |    in the Security Association
> Database (SAD) using the IP address of |    the server and thus match
> the corresponding IKEv2 SA.  At the server |    side, the IPSec layer
> can look up the corresponding IKEv2 SA by using |    the SPIs sent by
> the client, and therefore extract the shared secret " | | I believe
> that this approach will not work since your use of IKEv2 shouldn't |
> actually require any interaction with IPsec at all.
>=20
> We use IPsec to refer to IKE+ESP/AH in this draft. If you would like
> to propose alternative, better refined text, please let us know.
>=20
> 
>=20
>=20
> | I could imagine that a network management protocol could be used to
> provision | the shared secrets to the appropriate nodes. While public
> key cryptography | makes some aspects of the key distribution easier
> it does raise other | questions, such as distribution of trust
> anchors and the question about | authorization. Since you do not
> discuss authorization in the document I am not | sure it is of
> concern with the use of O/TWAMP.
>=20
> Indeed, a network management protocol _could_ be used, but this is
> not standardized and, imo, orthogonal to the problem at hand. Perhaps
> we should start a separate draft for OAM-based shared secret
> distribution for TWAMP.

In the above paragraph I have been trying to express a question
regarding authorization. In a shared secret environment the
authorization procedure is often dealt-with implicitly but with public
key cryptography you have to deal with authorization separate. How do
you expect authorization to be handled here?

>=20
>=20
> | I am not sure why you include the text in Section 5.4 where you
> describe | O/TWAMP over an IPsec tunnel since in the introduction you
> argue that this is | not an approach that you favour since it
> introduces delays into the | measurements.
>=20
> This was introduced as part of the consensus process in the WG. If
> your comment is editorial in nature, then [editor hat on] I would let
> it go [editor hat off]. If it's substantial, blocking, then I would
> be happy to remove sec. 5.4. Mind you, several parts of the draft
> have been repeatedly tuned to reach consensus over the last 2 years.

Since I have not participated in the working group I am not aware of
these discussions. Just from reading the document it felt a bit strange
to find the text in Section 5.4 while the introduction argues differently=
=2E

>=20
>=20
> | I am also wondering whether this solution offers crypto agility.
> The text | describes that you use AES-CBC (for encryption) and
> HMAC-SHA1 (for data origin | authentication and integrity
> protection). IKEv2 could, of course, allow you to | negotiate other
> algorithms and particularly the more modern AEAD ciphers.
>=20
> AES-CBC and HMAC-SHA1 are algorithms defined in the O/TWAMP RFCs.
> Perhaps there is space for another draft in this direction as well,
> i.e. to allow for more crypto agility in TWAMP beyond has been
> standardized so far.
>=20

It is up to the IESG to decide how to take crypto agility in IETF
specifications into account.

I personally would make use of IKEv2 (and the algorithm negotiation
capabilities) as well as take steps to support state-of-the-art algorithm=
s.

>=20
> | In a few parts of the document you say " |    The new Modes value
> indicating support for this |    specification is IKEv2Derived and is
> equal to 128 (i.e. bit set in |    position 7) [NOTE to IANA: remove
> before allocation and final | publication]". | | I am not sure what
> you are asking IANA to do. I believe what you are trying to | say is
> that you have proposed a specific value for this extension and you
> want | IANA to confirm that allocation.
>=20
> 
>=20
> Done in -09

Thanks.


>=20
>=20
> | I would also remove this paragraph in the Security Consideration
> section: | | | " |    As a more general note, the IPPM community may
> want to revisit the |    arguments listed in [RFC4656], Sec. 6.6.
> Other widely-used Internet |    security mechanisms, such as TLS and
> DTLS, may also be considered for |    future use over and above of
> what is already specified in [RFC4656] |    [RFC5357]. | " | | While
> it is true that DTLS/TLS could also used (and are probably a better |
> choice) it feels like the wrong statement in this document. It makes
> the | reader feel like that even the authors are not convinced that
> this is the | right solution approach.
>=20
> We have removed this paragraph in -09, as per your request:
> http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-ippm-ipsec-08&url2=3Ddraf=
t-ietf-ippm-ipsec-09.
> However, this brings us back to motivation discussion at the
> beginning of this email.

Thanks. Btw, I also agree with you that DTLS would have been a better
choice ...

A last question: Has someone implemented this specification? I am
curious about the challenges they ran into.

Ciao
Hannes

>=20
> Once again, many thanks.
>=20
> Best regards,
>=20
> Kostas
>=20


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJVJemjAAoJEGhJURNOOiAtdl0H/jrRtdEuYfGQ7lq8qmyGC10S
IpX0a4wSHRFTKcXpyi2pURMgPuOgYdGIgBmXDn08ZYAu+QvxgCeYPiCSOTZtZNAO
oa+K64LGkOORa0eDCRRA1X3UPRlavxac/9S1po49L57RisgoT+GMuJfKM0wJoCGo
DgUiYVxjIazWA+ztrp1T06K6n5ZklDOWH4RN8ERRwcvBu5CVAz7mEmnplOF6pYL9
ku/SgCkZLkJbthwQF9UmoS7qV0Q9jndZSvn2YVn4rRZ3y4QgViVZVPMs5hLb8RxY
0CFP4NSAijUTqeDwY7uLQNQmy/Gh3Aw5g22VCCZvDKTNj5rOCfEndtDXWM/jylo=
=j6I+
-----END PGP SIGNATURE-----

--fjbUha1aNdkc8DqwArNFq9H6fOSswwXHB--


From nobody Wed Apr  8 20:05:10 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD9D1B3766; Wed,  8 Apr 2015 20:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GVJnWfo-jvA; Wed,  8 Apr 2015 20:05:07 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8AC91B3765; Wed,  8 Apr 2015 20:05:04 -0700 (PDT)
Received: from [192.168.10.171] ([207.47.25.82]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M96Jd-1YY1V424k9-00CSRr; Thu, 09 Apr 2015 05:04:56 +0200
Message-ID: <5525EC51.3040903@gmx.net>
Date: Thu, 09 Apr 2015 05:04:49 +0200
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: The IESG , draft-ietf-uta-xmpp@tools.ietf.org,  "secdir@ietf.org" 
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nn2IfaXALDb9ntHxcehXOEA9ppddMsOCA"
X-Provags-ID: V03:K0:3b5ctptCDjXDX3UJfx1LZpY7OtIvl7hFeu22C8gi0Yf2wn1UZl5 paI2ibYe+pq3xGZJG1UbbOIG/IWgKYN/jvuKwoAsqu8eUN2KCnthE9xZkfZ5LGKcY2CVmmu 8DZOOLLWWfCmPedMI/iTE3gLTHqi09hXh8th5aQ88PXy8/XpwjF6ozgj5JQgTEdW5Gf7JpI 2GsPPBMzFu5NEB7yFH9NQ==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Subject: [secdir] Security review of draft-ietf-uta-xmpp-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 03:05:09 -0000

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

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 is ready for publication.

I have only one small comment: draft-ietf-uta-xmpp does not really
recommend anything that has not already been recommended in the other
referenced specifications. Hence it appears a bit redundant.


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJVJexRAAoJEGhJURNOOiAtzaIIAI+wzaWBvqXgnTs4xkjf3Lez
NpeMHntB4svr/YcatilvK6RzcNZrXeBA8uw7bSLQn5chq1DvJMbF8g5qr4HkDvNo
ZUux7/y63CqXq0aSetYqmNz05p879GTVb1XAyQ8FXRpUTvAJYF20KVUcDOobtx4p
ZSpH4BnJkesIwlPwdJg6Wn4Mu++B/567vWI6rOQTdF6Smu+pih3gTWB5dJgafQfC
AbY+Y8uCjYrkozRlMht7pCCzwJxsZp+GQ9cT/is56c5MRt47kEqxOCJohc9vYigB
yRQ+5xTO4gH44wwsbolohW1AsOBZDztzSry32r6Neh9EkV29aW2iaVetowJIqko=
=uuFG
-----END PGP SIGNATURE-----

--nn2IfaXALDb9ntHxcehXOEA9ppddMsOCA--


From nobody Thu Apr  9 02:24:16 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30101B29EB for ; Thu,  9 Apr 2015 02:24:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Level: 
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBvkMDEJObW4 for ; Thu,  9 Apr 2015 02:24:13 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78E5B1A890D for ; Thu,  9 Apr 2015 02:24:13 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t399OArc015326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 9 Apr 2015 12:24:10 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t399OAwX018786; Thu, 9 Apr 2015 12:24:10 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21798.17722.95493.866533@fireball.kivinen.iki.fi>
Date: Thu, 9 Apr 2015 12:24:10 +0300
From: Tero Kivinen 
To: secdir@ietf.org
X-Edit-Time: 0 min
X-Total-Time: 0 min
Archived-At: 
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 09:24:15 -0000

Review instructions and related resources are at:
http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

Tom Yu is next in the rotation.

For telechat 2015-04-09

Reviewer                 LC end     Draft
Tobias Gondrom         T 2015-03-12 draft-ietf-appsawg-uri-scheme-reg-06
Warren Kumari          T 2015-04-07 draft-ietf-netext-pmip-qos-wifi-07
Matt Lepinski          T 2015-04-02 draft-klensin-smtp-521code-05
Sandy Murphy           T 2015-03-30 draft-ietf-tls-sslv3-diediedie-02
Sam Weiler             T 2015-02-16 draft-ietf-6man-resilient-rs-05

Last calls and special requests:

Dan Harkins              2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14
Eric Osterweil           2015-04-29 draft-perrault-behave-deprecate-nat-mib-v1-01
Radia Perlman            2015-04-13 draft-ietf-tls-session-hash-04
Vincent Roca             2015-04-24 draft-hansen-scram-sha256-02
Joe Salowey              2015-04-16 draft-ietf-nfsv4-layout-types-03
Zach Shelby              2014-06-06 draft-housley-implementer-obligations-02
Takeshi Takahashi        2015-04-29 draft-perrault-behave-natv2-mib-03
Tina TSOU                2015-05-05 draft-hallambaker-tlsfeature-09
Sean Turner              2015-04-20 draft-ietf-bmwg-traffic-management-04
Carl Wallace             2015-04-17 draft-ietf-dane-srv-12
David Waltermire         2015-04-20 draft-ietf-opsawg-hmac-sha-2-usm-snmp-05
Sam Weiler               2015-04-20 draft-ietf-scim-api-16
Brian Weis               2015-04-20 draft-ietf-scim-core-schema-17
Klaas Wierenga           2015-04-17 draft-ietf-tls-negotiated-ff-dhe-08
Paul Wouters             2015-04-20 draft-ietf-v6ops-cidr-prefix-01
-- 
kivinen@iki.fi


From nobody Thu Apr  9 02:50:59 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD08E1B2D51; Thu,  9 Apr 2015 02:50:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qodO7cqIhI4r; Thu,  9 Apr 2015 02:50:52 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1ED1B2D4D; Thu,  9 Apr 2015 02:50:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 612FFBED1; Thu,  9 Apr 2015 10:50:50 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbVvo0dhR3lR; Thu,  9 Apr 2015 10:50:47 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 92661BE57; Thu,  9 Apr 2015 10:50:45 +0100 (IST)
Message-ID: <55264B70.80401@cs.tcd.ie>
Date: Thu, 09 Apr 2015 10:50:40 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Hannes Tschofenig ,  Kostas Pentikousis , "secdir@ietf.org" ,  "iesg@ietf.org >> The IESG" , "draft-ietf-ippm-ipsec@tools.ietf.org" 
References: <54D85781.2080009@gmx.net> <0C7EDCF89AB9E2478B5D010026CFF4AEB5AB748D98@SBS2008.eict.local> <5525E9A3.6010906@gmx.net>
In-Reply-To: <5525E9A3.6010906@gmx.net>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EiQEkK5JsO5UwxUSifmioe1piOlxrVhql"
Archived-At: 
Subject: Re: [secdir] Security review of draft-ietf-ippm-ipsec-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 09:50:55 -0000

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


Ah - that makes me wonder about another thing. I've
updated my discuss ballot with the text below. (If
this is already clear in the text, I'll clear as soon
as you show me where.)

Cheers,
Stephen.

The text added to my discuss ballot [1] is:

"(2) Is it clear what to do if a key needs to be derived for
O/TWAMP whilst re-keying is in progress for the IKE SA?
(Hannes' review made me wonder, and I don't recall if
the text on this is quite clear enough to not allow for a
case where the two sides end up with different values
derived from the DH share.)"

[1]
https://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ballot/#stephen-fa=
rrell

On 09/04/15 03:53, Hannes Tschofenig wrote:
> Hi Kostas,
>=20
> thanks for responding to my review.
>=20
> A few remarks inline.
>=20
> On 02/12/2015 01:29 PM, Kostas Pentikousis wrote:
>> Hi Hannes,
>>
>> 
>>
>> | 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.
>>
>> Many thanks for the thorough review. Much appreciated.
>>
>> 
>>
>>
>> | In the introduction you point out that IKEv2 is very commonly
>> deployed. | You even say that "In mobile telecommunication networks,
>> the deployment rate | of IPsec exceeds 95% with respect to the LTE
>> serving network." | | While the exact number is probably not that
>> important (and very likely hard to
>>
>> This text originates from the motivation that got this draft going.
>> In particular, the nearly 10-year old RFC 4656 argues in sec. 6.6
>> (https://tools.ietf.org/html/rfc4656#section-6.6), among other
>> things, that
>>
>> "The deployment paths of IPsec and OWAMP could be separate if OWAMP=20
>> does not depend on IPsec.  After nine years of IPsec, only 0.05% of
>> traffic on an advanced backbone network, such as Abilene, uses IPsec
>> (for comparison purposes with encryption above layer 4, SSH use is at
>> 2-4% and HTTPS use is at 0.2-0.6%).  It is desirable to be able to
>> deploy OWAMP on as large a number of different platforms as
>> possible."
>>
>> I don't think we need to argue about the numbers for IPsec, HTTPS and
>> so on today (esp. as we look towards 2020), but I would make the case
>> that it's likely that IPsec is more widely deployed today than OWAMP
>> is. Perhaps I'm wrong, please correct me. Hence, during the early
>> phase of development of this draft we included this text to
>> illustrate eminent use cases for this draft (such as the LTE case).
>> If you think that "95%" should be replaced with "the vast majority
>> of" or something of that nature, please let us know. If you have
>> completely different numbers from operators, research studies or
>> vendors for this type of deployment (or other settings for that
>> matter), I'll be happy to hear them.
>=20
> I just got a hung up on the numbers you mention since you do not provid=
e
> any description of where these numbers came from. So, I would prefer to=

> say something like widely deployed or so.
>=20
>=20
>>
>>
>> | verify) the statement does, however, raise some questions. You seem
>> to expect | that you can re-use already deployed IKEv2 for the
>> special version of IKEv2 | you are describing in this document and
>> that's unfortunately very unlikely to | be true.
>>
>> I don't agree this is the case when I read the text.
>=20
> When you talk in the introduction about the widespread deployment of
> IPsec and IKEv2 in operator networks, then state that using IPsec /
> IKEv2 is a "viable alternative" for protecting O/TWAMP
> and then document the solution then it is easy to come up with the idea=

> that
> this existing deployment can be re-used.
>=20
> I believe that the reason for stating that IPsec/IKEv2 is already so
> widely deployed is to create the argument for going with the IPsec/IKEv=
2
> solution approach.
>=20
> In all fairness for operators, who read this specification, they should=

> not be under the impression that they can might necessarily be able to
> re-use their existing IPsec/IKEv2 stack since the described solution is=

> a bit special IMHO.
>=20
>=20
>>
>> | The solution described in the document requires a very tight
>> integration | between an IKEv2 implementation (not IPsec) and the
>> O/TWAMP application and | the text in the document gives me the
>> impression that you are not entirely | aware that this will actually
>> need to happen. This may lead to unpleasant | surprises when you
>> implement it.
>>
>> I don't agree with the term "very tight integration". In fact, we had
>> the API discussion several times with folks in ipsecme over the last
>> 2 years and a bit.
>=20
> What was the outcome of that discussion? Can you send me a pointer to i=
t?
>=20
>> I heard some of the background, and I agree that
>> perhaps an IPsec vendor with *no interest in TWAMP* may have to think
>> more if they want to invest the effort to support this spec.
>=20
> Of course, an IPsec VPN vendor who provides a solution as described
> in the document will not encounter a problem. This, however, supports
> my impression that a random IPsec VPN solution (I call it
> "of-the-shelve" stack) might not work.
>=20
>> But for
>> vendors with both implementations in house, I would leave it to their
>> respective implementation teams. This spec would facilitate
>> interoperability in this latter case.
>=20
> It is great to describe aspects that concern interoperability
> but it is also important to point to potential
> implementation/operational issues.
>=20
>>
>> As an aside, and given that this is an IPPM draft, I would like to
>> point out that TWAMP per se (RFC 5357, sec. 1.2:
>> https://tools.ietf.org/html/rfc5357#section-1.2) does leave certain
>> interactions "unspecified", which "may be proprietary protocols".
>=20
> ... which is not good for interoperability.
>=20
>>
>> | First, you will have to trigger the IKEv2 exchange from the
>> application. | Second, you definitely do not want the IKEv2 exchange
>> to create IPsec SAs
>>
>> 
>>
>> | "IPPM" ). IMHO no off-the-shelf IKEv2 implementation will let
>> applications | access the SK_d directly nor will it have an API to
>> the IKEv2 SA either.
>>
>> Agreed, wrt "off-the-shelf" (in general), after all this is not an
>> RFC yet. But please see above.
>>
>>
>> | It might also want to think about potential interactions from the |
>> IKEv2-> to O/TWAMP side, such as rekeying. I am not sure whether
>> there | are issues to take into account but have you thought about
>> them?
>>
>> This is addressed in the last paragraph of sec. 5.1
>> (https://tools.ietf.org/html/draft-ietf-ippm-ipsec-09#section-5.1).
>> If you would like other text to be added or this to be edited, please
>> kindly send a proposal.
>>
>> 
>>
>=20
> Here is the current text:
>=20
> "
>=20
>    If rekeying for the IKEv2 SA or deletion of the IKEv2 SA occurs, the=

>    corresponding shared secret key generated from the SA can continue t=
o
>    be used until the O/TWAMP session terminates.
> "
>=20
> I would prefer to have this paragraph written in a normative way (i.e.,=

> using RFC 2119 language). It seems that you leave it up to the
> implementation on how to react to re-keying / IKEv2 SA deletion.
> Wouldn't this create potential issues when one side decides to derive
> new keying material and the other side doesn't? What happens if one sid=
e
> has the policy to delete the O/TWAMP keying material in response to the=

> IKEv2 SA being deleted?
>=20
> Was there a reason why rekeying of an IKEv2 SA shouldn't lead to new
> keying material be derived mandatorily? Also, one would think when the
> underlying IKEv2 SA is deleted then the keying material for the O/TWAMP=

> also be deleted.
>=20
>>
>> | In Section 5.1 you describe a way to obtain for the O/TWAMP
>> implementation to | interact with the IKEv2 code as follows: | | " |
>> the IPSec layer can perform a lookup |    in the Security Association
>> Database (SAD) using the IP address of |    the server and thus match
>> the corresponding IKEv2 SA.  At the server |    side, the IPSec layer
>> can look up the corresponding IKEv2 SA by using |    the SPIs sent by
>> the client, and therefore extract the shared secret " | | I believe
>> that this approach will not work since your use of IKEv2 shouldn't |
>> actually require any interaction with IPsec at all.
>>
>> We use IPsec to refer to IKE+ESP/AH in this draft. If you would like
>> to propose alternative, better refined text, please let us know.
>>
>> 
>>
>>
>> | I could imagine that a network management protocol could be used to
>> provision | the shared secrets to the appropriate nodes. While public
>> key cryptography | makes some aspects of the key distribution easier
>> it does raise other | questions, such as distribution of trust
>> anchors and the question about | authorization. Since you do not
>> discuss authorization in the document I am not | sure it is of
>> concern with the use of O/TWAMP.
>>
>> Indeed, a network management protocol _could_ be used, but this is
>> not standardized and, imo, orthogonal to the problem at hand. Perhaps
>> we should start a separate draft for OAM-based shared secret
>> distribution for TWAMP.
>=20
> In the above paragraph I have been trying to express a question
> regarding authorization. In a shared secret environment the
> authorization procedure is often dealt-with implicitly but with public
> key cryptography you have to deal with authorization separate. How do
> you expect authorization to be handled here?
>=20
>>
>>
>> | I am not sure why you include the text in Section 5.4 where you
>> describe | O/TWAMP over an IPsec tunnel since in the introduction you
>> argue that this is | not an approach that you favour since it
>> introduces delays into the | measurements.
>>
>> This was introduced as part of the consensus process in the WG. If
>> your comment is editorial in nature, then [editor hat on] I would let
>> it go [editor hat off]. If it's substantial, blocking, then I would
>> be happy to remove sec. 5.4. Mind you, several parts of the draft
>> have been repeatedly tuned to reach consensus over the last 2 years.
>=20
> Since I have not participated in the working group I am not aware of
> these discussions. Just from reading the document it felt a bit strange=

> to find the text in Section 5.4 while the introduction argues different=
ly.
>=20
>>
>>
>> | I am also wondering whether this solution offers crypto agility.
>> The text | describes that you use AES-CBC (for encryption) and
>> HMAC-SHA1 (for data origin | authentication and integrity
>> protection). IKEv2 could, of course, allow you to | negotiate other
>> algorithms and particularly the more modern AEAD ciphers.
>>
>> AES-CBC and HMAC-SHA1 are algorithms defined in the O/TWAMP RFCs.
>> Perhaps there is space for another draft in this direction as well,
>> i.e. to allow for more crypto agility in TWAMP beyond has been
>> standardized so far.
>>
>=20
> It is up to the IESG to decide how to take crypto agility in IETF
> specifications into account.
>=20
> I personally would make use of IKEv2 (and the algorithm negotiation
> capabilities) as well as take steps to support state-of-the-art algorit=
hms.
>=20
>>
>> | In a few parts of the document you say " |    The new Modes value
>> indicating support for this |    specification is IKEv2Derived and is
>> equal to 128 (i.e. bit set in |    position 7) [NOTE to IANA: remove
>> before allocation and final | publication]". | | I am not sure what
>> you are asking IANA to do. I believe what you are trying to | say is
>> that you have proposed a specific value for this extension and you
>> want | IANA to confirm that allocation.
>>
>> 
>>
>> Done in -09
>=20
> Thanks.
>=20
>=20
>>
>>
>> | I would also remove this paragraph in the Security Consideration
>> section: | | | " |    As a more general note, the IPPM community may
>> want to revisit the |    arguments listed in [RFC4656], Sec. 6.6.
>> Other widely-used Internet |    security mechanisms, such as TLS and
>> DTLS, may also be considered for |    future use over and above of
>> what is already specified in [RFC4656] |    [RFC5357]. | " | | While
>> it is true that DTLS/TLS could also used (and are probably a better |
>> choice) it feels like the wrong statement in this document. It makes
>> the | reader feel like that even the authors are not convinced that
>> this is the | right solution approach.
>>
>> We have removed this paragraph in -09, as per your request:
>> http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-ippm-ipsec-08&url2=3Ddra=
ft-ietf-ippm-ipsec-09.
>> However, this brings us back to motivation discussion at the
>> beginning of this email.
>=20
> Thanks. Btw, I also agree with you that DTLS would have been a better
> choice ...
>=20
> A last question: Has someone implemented this specification? I am
> curious about the challenges they ran into.
>=20
> Ciao
> Hannes
>=20
>>
>> Once again, many thanks.
>>
>> Best regards,
>>
>> Kostas
>>
>=20
>=20
>=20
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>=20


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJVJkt1AAoJEC88hzaAX42iVjgH/0gxe/4kFAS/ysDYle1ma73w
bzKySLhrQqlKZAk72OR9xtKoX+Xnm2MJ76AgHuAxzutuntOyb79IhNy97aYk9YPj
3dDl4wuQ+LQuQVB/jZaRMS72xKcfH41AdRcyyHqjGOHK0//xvMS7NZ83n0YYaKAk
d/V33HKPZlUqfk56nxPj1djSUXcsmrGwvq1wJ0Vu59As84+1wJI7MV9S27XxGvIR
AqQ9zX5iybJrdbsLfLf35yLfM/v2yQYZdjTW75/xNrOFEfJASdn2+iv3e97uCS0H
rrAeTzQIR98ZfY0w/uihZH7N25rffOgmHLQZDOK3JS27WuQ1qoJICxq1k8Kk+6o=
=TT2o
-----END PGP SIGNATURE-----

--EiQEkK5JsO5UwxUSifmioe1piOlxrVhql--


From nobody Thu Apr  9 02:58:46 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D6E1B2D6B; Thu,  9 Apr 2015 02:58:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJOzNCKcwYwE; Thu,  9 Apr 2015 02:58:38 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67411AD0AA; Thu,  9 Apr 2015 02:58:38 -0700 (PDT)
Received: from [81.187.2.149] (port=33612 helo=[192.168.0.18]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Yg9EG-0001bd-UM; Thu, 09 Apr 2015 10:58:35 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins 
In-Reply-To: <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com>
Date: Thu, 9 Apr 2015 10:58:17 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>
References:  <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>   <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com>
To: Ben Campbell 
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 09:58:40 -0000

On 8 Apr 2015, at 20:49, Ben Campbell  wrote:
> On 8 Apr 2015, at 14:38, Derek Atkins wrote:
>>=20
>> On Wed, April 8, 2015 2:52 pm, Ben Campbell wrote:
>>> On 8 Apr 2015, at 9:42, Derek Atkins wrote:
...snip...
>>> For an extreme example, having that sentence in Codec format A and =
not
>>> format B could lead to implementor decisions on the order of "I =
don't
>>> want to bother with crypto, so I will choose codec B because it has
>>> lighter requirements" might appear to make sense to someone not =
steeped
>>> in this argument.
>>>=20
>>> What I'd _really_ like to do is take the energy in this thread and =
apply
>>> it to creating a standards-track security document for RTP unicast
>>> applications.
>>=20
>> Are you willing to hold up this document until that work is done so =
it can
>> refer to the (yet-to-be-written) protocol security update draft?  I'm =
fine
>> with that approach and I'm willing to review whatever draft you guys
>> produce if that's how you'd like to proceed.
>=20
> No, I will go with the consensus on this one. I note that several WG =
participants objected to the orignally proposed SHOULD. I am pointing =
out that this SHOULD is not much different, but I will go with what =
people want to do.

I think "SHOULD use an appropriate strong security mechanism" is quite =
different to "SHOULD use SRTP", since we know of cases where SRTP isn't =
suitable. That was my objection to the original text.

> OTOH, what I would like to do would fix the problem for this, and all =
other codec payload formats, after the fact if we do it right (since it =
would apply to the application)
>=20
>>=20
>> Or you can hold your nose and live with the "UGGH" of it based on =
what the
>> WG original created in -08 and move forward for now, knowing that you =
can
>> (and should) correct it "right" later.
>=20
> The work group did not put in a SHOULD. I think this is more of a =
question of whether people are willing to hold there collective noses =
about the lack of _normative_ privacy guidance for RTP in general, and =
if they are willing to let payload formats continue to progress while =
that is being worked out.

One of the things RFC 7202 tries to convey is that "normative privacy =
guidance for RTP in general" is not possible. The privacy requirements, =
for example, of broadcast TV are different to those for a phone call, =
but both can use RTP.=20

A document giving normative security guidance for unicast SIP-based =
telephony using RTP is something we need, I agree. I'm happy to help =
reviewing such a thing, but it should be authored by someone more =
familiar with the deployed security mechanisms.


--=20
Colin Perkins
https://csperkins.org/





From nobody Thu Apr  9 03:04:36 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE6F1B2DA8; Thu,  9 Apr 2015 03:04:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twiwlq6upyO6; Thu,  9 Apr 2015 03:04:30 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BFC11B2DA7; Thu,  9 Apr 2015 03:04:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2181BBECA; Thu,  9 Apr 2015 11:04:29 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azZWJc-XVRzv; Thu,  9 Apr 2015 11:04:28 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7906CBED1; Thu,  9 Apr 2015 11:04:27 +0100 (IST)
Message-ID: <55264EAB.6090804@cs.tcd.ie>
Date: Thu, 09 Apr 2015 11:04:27 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Colin Perkins , Ben Campbell 
References:  <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>   <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>
In-Reply-To: <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 10:04:31 -0000

I do agree with Colin here (and with Ben and Robert) but...

On 09/04/15 10:58, Colin Perkins wrote:
> A document giving normative security guidance for unicast SIP-based
> telephony using RTP is something we need, I agree. I'm happy to help
> reviewing such a thing, but it should be authored by someone more
> familiar with the deployed security mechanisms.

I've just gotten offlist mail from another secdir reviewer who
noted that we had exactly the same discussion 7 years ago for
another payload document. And I recall it myself more recently.

So that unicast SIP/RTP document really would save us all some
time and might help those implementing and deploying security
stuff in such cases. (And even if folks were not implementing
or deploying security stuff for this 7 years ago, I would say
that it's much more likely they will be doing that today and
in future.)

S.


From nobody Thu Apr  9 03:10:50 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C7C1B2DC1; Thu,  9 Apr 2015 03:10:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIw9ZHXQJ6TJ; Thu,  9 Apr 2015 03:10:44 -0700 (PDT)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF211B2DC0; Thu,  9 Apr 2015 03:10:44 -0700 (PDT)
Received: by wgsk9 with SMTP id k9so92327178wgs.3; Thu, 09 Apr 2015 03:10:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=3Rku2aadSWhpxRV/cF86B0xs8b9/9g9N/cdl9ctw08M=; b=PGsDbUVysk+YvZt4Zqvy9saUKoBNCvPM8P4KLRO/4PT9jVtVRcvXlP7C0Bcmc+zGHT /ptdfhbRKEpuu7HQYDJY3LyCsdDvb4jruN8pvpqmqB+wTkTg6slWuIr/W/lBJ94vvstt 5p9Yp5cOKpVq861n0s5rL7RhT1jnfTKWhi58YUd2PSn+IvyJv815TTQjhJeI40/vgIt3 MrwPtw/egm7UPGABSoSdlCrvhXnnKWNp8fPhLofuN0ZcjnVFna8zm+C/m9D2fQTG88Qk y8NNsz1zzeb5yr1/TcFt4CWzukKFzTkpLhk8Er/B4K9nj4667EZsfpey1r7YJCzLjrdK Pnag==
X-Received: by 10.180.208.7 with SMTP id ma7mr4995445wic.0.1428574242808; Thu, 09 Apr 2015 03:10:42 -0700 (PDT)
Received: from RoniE (bzq-79-183-196-8.red.bezeqint.net. [79.183.196.8]) by mx.google.com with ESMTPSA id mc20sm14944120wic.15.2015.04.09.03.10.38 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Apr 2015 03:10:42 -0700 (PDT)
From: "Roni Even" 
To: "'Colin Perkins'" , "'Ben Campbell'" 
References:  <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>   <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>
In-Reply-To: <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>
Date: Thu, 9 Apr 2015 13:10:34 +0300
Message-ID: <04a301d072ad$6ee870a0$4cb951e0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLAzGR07a+fOctgPDsHC1O01O6N4gJZOkh2ATWEKvgCZomtcAJJ9cXnANMW9o8CPVYOiwH1GcU2AQ39HOQBpEQQdAG8p4kIAkKrjLMBUUHgjQHIXU6gAppERrgBK5MMvQKboLQIAa/Y3NwBfX3BqQKwtyf3Aft3YkEBlH20xgMMyKefAePqaP+aBT9KYA==
Content-Language: en-us
Archived-At: 
Cc: secdir@ietf.org, payload@ietf.org, jspittka@gmail.com, 'Kathleen Moriarty' , iesg@ietf.org, payload-chairs@tools.ietf.org, koenvos74@gmail.com
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 10:10:46 -0000

Hi,
I support what Colin says about SRTP being a security tool for unicast
telephony but other applications including multicast and broadcast that use
RTP may use other security mechanism.
Defining security for media in a specific application may be done when
defining the application like in RTCweb
(https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-23 section 4.2)
Roni Even

> -----Original Message-----
> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Colin Perkins
> Sent: 09 April, 2015 12:58 PM
> To: Ben Campbell
> Cc: secdir@ietf.org; payload@ietf.org; jspittka@gmail.com; Kathleen
Moriarty;
> iesg@ietf.org; payload-chairs@tools.ietf.org; koenvos74@gmail.com; Derek
> Atkins
> Subject: Re: [payload] [secdir] sec-dir review of
draft-ietf-payload-rtp-opus-08
> 
> On 8 Apr 2015, at 20:49, Ben Campbell  wrote:
> > On 8 Apr 2015, at 14:38, Derek Atkins wrote:
> >>
> >> On Wed, April 8, 2015 2:52 pm, Ben Campbell wrote:
> >>> On 8 Apr 2015, at 9:42, Derek Atkins wrote:
> ...snip...
> >>> For an extreme example, having that sentence in Codec format A and
> >>> not format B could lead to implementor decisions on the order of "I
> >>> don't want to bother with crypto, so I will choose codec B because
> >>> it has lighter requirements" might appear to make sense to someone
> >>> not steeped in this argument.
> >>>
> >>> What I'd _really_ like to do is take the energy in this thread and
> >>> apply it to creating a standards-track security document for RTP
> >>> unicast applications.
> >>
> >> Are you willing to hold up this document until that work is done so
> >> it can refer to the (yet-to-be-written) protocol security update
> >> draft?  I'm fine with that approach and I'm willing to review
> >> whatever draft you guys produce if that's how you'd like to proceed.
> >
> > No, I will go with the consensus on this one. I note that several WG
> participants objected to the orignally proposed SHOULD. I am pointing out
that
> this SHOULD is not much different, but I will go with what people want to
do.
> 
> I think "SHOULD use an appropriate strong security mechanism" is quite
> different to "SHOULD use SRTP", since we know of cases where SRTP isn't
> suitable. That was my objection to the original text.
> 
> > OTOH, what I would like to do would fix the problem for this, and all
> > other codec payload formats, after the fact if we do it right (since
> > it would apply to the application)
> >
> >>
> >> Or you can hold your nose and live with the "UGGH" of it based on
> >> what the WG original created in -08 and move forward for now, knowing
> >> that you can (and should) correct it "right" later.
> >
> > The work group did not put in a SHOULD. I think this is more of a
question of
> whether people are willing to hold there collective noses about the lack
of
> _normative_ privacy guidance for RTP in general, and if they are willing
to let
> payload formats continue to progress while that is being worked out.
> 
> One of the things RFC 7202 tries to convey is that "normative privacy
guidance
> for RTP in general" is not possible. The privacy requirements, for
example, of
> broadcast TV are different to those for a phone call, but both can use
RTP.
> 
> A document giving normative security guidance for unicast SIP-based
telephony
> using RTP is something we need, I agree. I'm happy to help reviewing such
a
> thing, but it should be authored by someone more familiar with the
deployed
> security mechanisms.
> 
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
> 
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload


From nobody Thu Apr  9 03:11:28 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222BF1B2DC3; Thu,  9 Apr 2015 03:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIn5TJCF2eJ8; Thu,  9 Apr 2015 03:11:23 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79A281B2DC1; Thu,  9 Apr 2015 03:11:23 -0700 (PDT)
Received: from [81.187.2.149] (port=39994 helo=[192.168.0.18]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Yg9Qf-00089G-59; Thu, 09 Apr 2015 11:11:21 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins 
In-Reply-To: <55264EAB.6090804@cs.tcd.ie>
Date: Thu, 9 Apr 2015 11:11:08 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5D09A2DB-8A85-43ED-9EEC-C5CC2867F68A@csperkins.org>
References:  <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>   <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> <55264EAB.609080 4@cs.tcd.ie>
To: Stephen Farrell 
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: 
Cc: Ben Campbell , "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 10:11:25 -0000

On 9 Apr 2015, at 11:04, Stephen Farrell  =
wrote:
> I do agree with Colin here (and with Ben and Robert) but...
>=20
> On 09/04/15 10:58, Colin Perkins wrote:
>> A document giving normative security guidance for unicast SIP-based
>> telephony using RTP is something we need, I agree. I'm happy to help
>> reviewing such a thing, but it should be authored by someone more
>> familiar with the deployed security mechanisms.
>=20
> I've just gotten offlist mail from another secdir reviewer who
> noted that we had exactly the same discussion 7 years ago for
> another payload document. And I recall it myself more recently.

We've been around this loop multiple times. That's why we wrote RFCs =
7201 and 7202, to try to stop repeating the same discussion by =
explaining the issues and providing guidance. The recommended text for =
new RTP payload formats in the rtp-howto was also intended to help =
clarify. Clearly something more is needed. If the issue is that RFC7202 =
isn't clear, then I'm happy to work with someone to clarify in an =
update, but I suspect we need the suggested documents giving normative =
requirements for different application classes.

> So that unicast SIP/RTP document really would save us all some
> time and might help those implementing and deploying security
> stuff in such cases. (And even if folks were not implementing
> or deploying security stuff for this 7 years ago, I would say
> that it's much more likely they will be doing that today and
> in future.)

Agreed.

--=20
Colin Perkins
https://csperkins.org/





From nobody Thu Apr  9 06:25:05 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE9F1A1A7C; Thu,  9 Apr 2015 06:25:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ilsbqx_tD3k; Thu,  9 Apr 2015 06:25:01 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 1FA831B2D3E; Thu,  9 Apr 2015 06:24:54 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t39DOWb4087002 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 08:24:43 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Colin Perkins" 
Date: Thu, 09 Apr 2015 08:24:32 -0500
Message-ID: 
In-Reply-To: <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>
References:  <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>   <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 13:25:02 -0000

On 9 Apr 2015, at 4:58, Colin Perkins wrote:

> The work group did not put in a SHOULD. I think this is more of a 
> question of whether people are willing to hold there collective noses 
> about the lack of _normative_ privacy guidance for RTP in general, and 
> if they are willing to let payload formats continue to progress while 
> that is being worked out.
>
>
> One of the things RFC 7202 tries to convey is that "normative privacy 
> guidance for RTP in general" is not possible. The privacy 
> requirements, for example, of broadcast TV are different to those for 
> a phone call, but both can use RTP.
>
> A document giving normative security guidance for unicast SIP-based 
> telephony using RTP is something we need, I agree. I'm happy to help 
> reviewing such a thing, but it should be authored by someone more 
> familiar with the deployed security mechanisms.

Sorry, I mean for unicast. I just dropped the word when typing :-)


From nobody Thu Apr  9 06:32:50 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C001A700D; Thu,  9 Apr 2015 06:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcbbVyXEkczz; Thu,  9 Apr 2015 06:32:47 -0700 (PDT)
Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CF5D1B2D2F; Thu,  9 Apr 2015 06:31:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id C7CB6E2038; Thu,  9 Apr 2015 09:31:51 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16692-02; Thu,  9 Apr 2015 09:31:46 -0400 (EDT)
Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 2AE79E2036; Thu,  9 Apr 2015 09:31:46 -0400 (EDT)
Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t39DViFJ016134; Thu, 9 Apr 2015 09:31:44 -0400
From: Derek Atkins 
To: Colin Perkins 
References:  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>  <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>
Date: Thu, 09 Apr 2015 09:31:43 -0400
In-Reply-To: <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> (Colin Perkins's message of "Thu, 9 Apr 2015 10:58:17 +0100")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: 
Cc: Ben Campbell , "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 13:32:49 -0000

Colin Perkins  writes:

> I think "SHOULD use an appropriate strong security mechanism" is quite
> different to "SHOULD use SRTP", since we know of cases where SRTP
> isn't suitable. That was my objection to the original text.

I'm fine with "SHOULD use an appropriate strong security mechanism",
which is what I tried to convey with my added sentence to the guidance
paragraph.

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


From nobody Thu Apr  9 06:33:52 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3131B2D83; Thu,  9 Apr 2015 06:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVT5gCgoQ7TD; Thu,  9 Apr 2015 06:33:49 -0700 (PDT)
Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873B21B2D80; Thu,  9 Apr 2015 06:33:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 48497E203A; Thu,  9 Apr 2015 09:33:01 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16692-03; Thu,  9 Apr 2015 09:32:55 -0400 (EDT)
Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id C6ECDE2039; Thu,  9 Apr 2015 09:32:55 -0400 (EDT)
Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t39DWr26016182; Thu, 9 Apr 2015 09:32:53 -0400
From: Derek Atkins 
To: Kathleen Moriarty 
References:  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>  <5525863D.2050006@cs.tcd.ie> <8F0ACB34-EE96-4348-AC20-EB6727A1EDA7@gmail.com>
Date: Thu, 09 Apr 2015 09:32:53 -0400
In-Reply-To: <8F0ACB34-EE96-4348-AC20-EB6727A1EDA7@gmail.com> (Kathleen Moriarty's message of "Wed, 8 Apr 2015 16:39:58 -0400")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: 
Cc: Ben Campbell , "secdir@ietf.org" , "payload@ietf.org" , "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" , Colin Perkins 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 13:33:50 -0000

Hi,

Kathleen Moriarty  writes:

> Sorry I've been tied up in meetings.  Where are we at with text
> changes for this draft versus what's planned in another draft?  It
> would be good to clear my discuss before tomorrow if we can.

We have some proposed text (which was a sentence I added to a paragraph
that came from the guidance document), but I don't know if we've come to
consensus on that suggestion.

> Thanks,
> Kathleen 

-derek

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


From nobody Thu Apr  9 06:41:32 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F4F1B2D85; Thu,  9 Apr 2015 06:41:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7Xqt-BEMwQW; Thu,  9 Apr 2015 06:41:28 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 07A411B2D80; Thu,  9 Apr 2015 06:41:22 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t39Df1tb088420 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 08:41:11 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Colin Perkins" 
Date: Thu, 09 Apr 2015 08:41:01 -0500
Message-ID: 
In-Reply-To: <5D09A2DB-8A85-43ED-9EEC-C5CC2867F68A@csperkins.org>
References:  <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>   <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> <55264EAB.609080 4@cs.tcd.ie> <5D09A2DB-8A85-43ED-9EEC-C5CC2867F68A@csperkins.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 13:41:30 -0000

On 9 Apr 2015, at 5:11, Colin Perkins wrote:

> On 9 Apr 2015, at 11:04, Stephen Farrell  
> wrote:
>> I do agree with Colin here (and with Ben and Robert) but...
>>
>> On 09/04/15 10:58, Colin Perkins wrote:
>>> A document giving normative security guidance for unicast SIP-based
>>> telephony using RTP is something we need, I agree. I'm happy to help
>>> reviewing such a thing, but it should be authored by someone more
>>> familiar with the deployed security mechanisms.
>>
>> I've just gotten offlist mail from another secdir reviewer who
>> noted that we had exactly the same discussion 7 years ago for
>> another payload document. And I recall it myself more recently.
>
> We've been around this loop multiple times. That's why we wrote RFCs 
> 7201 and 7202, to try to stop repeating the same discussion by 
> explaining the issues and providing guidance. The recommended text for 
> new RTP payload formats in the rtp-howto was also intended to help 
> clarify. Clearly something more is needed. If the issue is that 
> RFC7202 isn't clear, then I'm happy to work with someone to clarify in 
> an update, but I suspect we need the suggested documents giving 
> normative requirements for different application classes.

The problem is not that 7202 is not clear. It "clearly" says that the 
each class of RTP application needs to specify MTI strong security. The 
problem is that no such specification exists for SIP-based RTP unicast 
applications. So saying we SHOULD follow 7202 doesn't really help.

>
>> So that unicast SIP/RTP document really would save us all some
>> time and might help those implementing and deploying security
>> stuff in such cases. (And even if folks were not implementing
>> or deploying security stuff for this 7 years ago, I would say
>> that it's much more likely they will be doing that today and
>> in future.)
>
> Agreed.
>
> -- 
> Colin Perkins
> https://csperkins.org/


From nobody Thu Apr  9 06:45:33 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E191A00F1; Thu,  9 Apr 2015 06:45:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqQN8z8Iw7Ee; Thu,  9 Apr 2015 06:45:23 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 9B72C1A01D5; Thu,  9 Apr 2015 06:45:23 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t39Dj5Dh088743 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 08:45:15 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Derek Atkins" 
Date: Thu, 09 Apr 2015 08:45:05 -0500
Message-ID: 
In-Reply-To: 
References:  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>  <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 13:45:29 -0000

On 9 Apr 2015, at 8:31, Derek Atkins wrote:

> Colin Perkins  writes:
>
>> I think "SHOULD use an appropriate strong security mechanism" is 
>> quite
>> different to "SHOULD use SRTP", since we know of cases where SRTP
>> isn't suitable. That was my objection to the original text.
>
> I'm fine with "SHOULD use an appropriate strong security mechanism",
> which is what I tried to convey with my added sentence to the guidance
> paragraph.

I would be okay with "SHOULD use an appropriate strong security 
mechanism". I assume the intended difference is the removal of the "as 
suggested by those references" part.

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


From nobody Thu Apr  9 06:55:40 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646D51A1AE3; Thu,  9 Apr 2015 06:55:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCqJlBjuqe66; Thu,  9 Apr 2015 06:55:34 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 6737D1A1ADB; Thu,  9 Apr 2015 06:55:33 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t39DtGpr089659 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 08:55:26 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Derek Atkins" 
Date: Thu, 09 Apr 2015 08:55:15 -0500
Message-ID: 
In-Reply-To: 
References:  <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com>   <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>  <5525863D.2050006@cs.tcd.ie> <8F0ACB34-EE96-4348-AC20-EB6727A1EDA7@gmail.com> 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: "secdir@ietf.org" , "payload@ietf.org" , "jspittka@gmail.com" , Kathleen Moriarty , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" , Colin Perkins 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 13:55:35 -0000

I think we have a general agreement for text that talks about how the 
choice of MTI security depends on the RTP application class. There's an 
ongoing discussion as to whether that should include something to the 
effect of "SHOULD implement appropriate protections".

I seemed to be the principle nay-sayer as of this morning, and I'm okay 
with Derek's latest suggestion, so I _think_ people are very close to an 
agreement on exact language.

On 9 Apr 2015, at 8:32, Derek Atkins wrote:

> Hi,
>
> Kathleen Moriarty  writes:
>
>> Sorry I've been tied up in meetings.  Where are we at with text
>> changes for this draft versus what's planned in another draft?  It
>> would be good to clear my discuss before tomorrow if we can.
>
> We have some proposed text (which was a sentence I added to a 
> paragraph
> that came from the guidance document), but I don't know if we've come 
> to
> consensus on that suggestion.
>
>> Thanks,
>> Kathleen
>
> -derek
>
> -- 
>      Derek Atkins                 617-623-3745
>      derek@ihtfp.com             www.ihtfp.com
>      Computer and Internet Security Consultant


From nobody Thu Apr  9 07:00:39 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12661A1B2E; Thu,  9 Apr 2015 07:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.289
X-Spam-Level: 
X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QyBfGb0bxqH; Thu,  9 Apr 2015 07:00:33 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF941A1B0B; Thu,  9 Apr 2015 07:00:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id EBAB5E2038; Thu,  9 Apr 2015 10:00:31 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16926-02; Thu,  9 Apr 2015 10:00:29 -0400 (EDT)
Received: by mail2.ihtfp.org (Postfix, from userid 48) id 84D63E2039; Thu,  9 Apr 2015 10:00:29 -0400 (EDT)
Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 9 Apr 2015 10:00:29 -0400
Message-ID: <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org>
In-Reply-To: 
References:    <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>  <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>  
Date: Thu, 9 Apr 2015 10:00:29 -0400
From: "Derek Atkins" 
To: "Ben Campbell" 
User-Agent: SquirrelMail/1.4.22-14.fc20
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 14:00:36 -0000

Ben,

On Thu, April 9, 2015 9:45 am, Ben Campbell wrote:
> On 9 Apr 2015, at 8:31, Derek Atkins wrote:
>
>> Colin Perkins  writes:
>>
>>> I think "SHOULD use an appropriate strong security mechanism" is
>>> quite
>>> different to "SHOULD use SRTP", since we know of cases where SRTP
>>> isn't suitable. That was my objection to the original text.
>>
>> I'm fine with "SHOULD use an appropriate strong security mechanism",
>> which is what I tried to convey with my added sentence to the guidance
>> paragraph.
>
> I would be okay with "SHOULD use an appropriate strong security
> mechanism". I assume the intended difference is the removal of the "as
> suggested by those references" part.

So you're suggesting (and would be okay with) this text:

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification RFC3550, and in any applicable RTP profile such as
   RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
   SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
   Why RTP Does Not Mandate a Single Media Security Solution"
   [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
   formats responsibility to discuss or mandate what solutions are used
   to meet the basic security goals like confidentiality, integrity and
   source authenticity for RTP in general.  This responsibility lays on
   anyone using RTP in an application.  They can find guidance on
   available security mechanisms and important considerations in Options
   for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
   Applications SHOULD use an appropriate strong security mechanism.

I think I'm okay with this.  (I kind of prefer my previous wording,
"Applications SHOULD implement at least one of the strong security
measures suggested by those references" only because it suggests that
multiple mechanisms are okay, whereas this new wording seems to imply
choosing only one).

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


From nobody Thu Apr  9 07:08:16 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D631A1B29; Thu,  9 Apr 2015 07:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25Qv1XCpXd1e; Thu,  9 Apr 2015 07:08:10 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 7218C1A1B51; Thu,  9 Apr 2015 07:08:10 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t39E7ufX090728 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 09:08:06 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Derek Atkins" 
Date: Thu, 09 Apr 2015 09:07:55 -0500
Message-ID: 
In-Reply-To: <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org>
References:    <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>  <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>   <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 14:08:11 -0000

On 9 Apr 2015, at 9:00, Derek Atkins wrote:

> Ben,
>
> On Thu, April 9, 2015 9:45 am, Ben Campbell wrote:
>> On 9 Apr 2015, at 8:31, Derek Atkins wrote:
>>
>>> Colin Perkins  writes:
>>>
>>>> I think "SHOULD use an appropriate strong security mechanism" is
>>>> quite
>>>> different to "SHOULD use SRTP", since we know of cases where SRTP
>>>> isn't suitable. That was my objection to the original text.
>>>
>>> I'm fine with "SHOULD use an appropriate strong security mechanism",
>>> which is what I tried to convey with my added sentence to the 
>>> guidance
>>> paragraph.
>>
>> I would be okay with "SHOULD use an appropriate strong security
>> mechanism". I assume the intended difference is the removal of the 
>> "as
>> suggested by those references" part.
>
> So you're suggesting (and would be okay with) this text:
>
>  RTP packets using the payload format defined in this specification
>  are subject to the security considerations discussed in the RTP
>  specification RFC3550, and in any applicable RTP profile such as
>  RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
>  SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
>  Why RTP Does Not Mandate a Single Media Security Solution"
>  [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
>  formats responsibility to discuss or mandate what solutions are used
>  to meet the basic security goals like confidentiality, integrity and
>  source authenticity for RTP in general.  This responsibility lays on
>  anyone using RTP in an application.  They can find guidance on
>  available security mechanisms and important considerations in Options
>  for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
>  Applications SHOULD use an appropriate strong security mechanism.
>

I am okay with that text.

> I think I'm okay with this.  (I kind of prefer my previous wording,
> "Applications SHOULD implement at least one of the strong security
> measures suggested by those references" only because it suggests that
> multiple mechanisms are okay, whereas this new wording seems to imply
> choosing only one).

How about "Applications SHOULD use one or more strong security 
mechanisms, as appropriate"?

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


From nobody Thu Apr  9 07:19:42 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64AC1A6F02; Thu,  9 Apr 2015 07:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.289
X-Spam-Level: 
X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhqOe9T9nh37; Thu,  9 Apr 2015 07:19:39 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB7B1A1F00; Thu,  9 Apr 2015 07:19:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 31EB8E2036; Thu,  9 Apr 2015 10:19:38 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 17099-01; Thu,  9 Apr 2015 10:19:35 -0400 (EDT)
Received: by mail2.ihtfp.org (Postfix, from userid 48) id A0B74E2038; Thu,  9 Apr 2015 10:19:35 -0400 (EDT)
Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 9 Apr 2015 10:19:35 -0400
Message-ID: 
In-Reply-To: 
References:  <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>  <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>   <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org> 
Date: Thu, 9 Apr 2015 10:19:35 -0400
From: "Derek Atkins" 
To: "Ben Campbell" 
User-Agent: SquirrelMail/1.4.22-14.fc20
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 14:19:40 -0000

On Thu, April 9, 2015 10:07 am, Ben Campbell wrote:
> On 9 Apr 2015, at 9:00, Derek Atkins wrote:
>
>> Ben,
>>
[snip]
>> So you're suggesting (and would be okay with) this text:
>>
>>  RTP packets using the payload format defined in this specification
>>  are subject to the security considerations discussed in the RTP
>>  specification RFC3550, and in any applicable RTP profile such as
>>  RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
>>  SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
>>  Why RTP Does Not Mandate a Single Media Security Solution"
>>  [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
>>  formats responsibility to discuss or mandate what solutions are used
>>  to meet the basic security goals like confidentiality, integrity and
>>  source authenticity for RTP in general.  This responsibility lays on
>>  anyone using RTP in an application.  They can find guidance on
>>  available security mechanisms and important considerations in Options
>>  for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
>>  Applications SHOULD use an appropriate strong security mechanism.
>>
>
> I am okay with that text.
>
>> I think I'm okay with this.  (I kind of prefer my previous wording,
>> "Applications SHOULD implement at least one of the strong security
>> measures suggested by those references" only because it suggests that
>> multiple mechanisms are okay, whereas this new wording seems to imply
>> choosing only one).
>
> How about "Applications SHOULD use one or more strong security
> mechanisms, as appropriate"?

Clearly now we're just getting down to wordsmithing..  :)

How about "Applications SHOULD use one or more appropriate strong security
mechanisms"?  (The subclause "as apporpriate" feels to me like it could be
ignored, as in "well, using a strong security mechanism isn't
appropriate").  I think the goal is to make sure that "appropriate"
modifies the "strong security mechanism" and not the "SHOULD use"  ;)

What say you?

-derek

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


From nobody Thu Apr  9 07:22:15 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36941A6F27; Thu,  9 Apr 2015 07:22:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5l9LSg56hmI2; Thu,  9 Apr 2015 07:22:12 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 C16941A212D; Thu,  9 Apr 2015 07:22:11 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t39ELvxb091995 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 09:22:08 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Derek Atkins" 
Date: Thu, 09 Apr 2015 09:21:57 -0500
Message-ID: <6666FE0B-39E1-4FA5-94C4-72AAEF5CB7C2@nostrum.com>
In-Reply-To: 
References:  <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>  <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>   <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org>  
MIME-Version: 1.0
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 14:22:13 -0000

On 9 Apr 2015, at 9:19, Derek Atkins wrote:

> On Thu, April 9, 2015 10:07 am, Ben Campbell wrote:
>> On 9 Apr 2015, at 9:00, Derek Atkins wrote:
>>
>>> Ben,
>>>
> [snip]
>>> So you're suggesting (and would be okay with) this text:
>>>
>>> RTP packets using the payload format defined in this specification
>>> are subject to the security considerations discussed in the RTP
>>> specification RFC3550, and in any applicable RTP profile such as
>>> RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
>>> SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
>>> Why RTP Does Not Mandate a Single Media Security Solution"
>>> [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
>>> formats responsibility to discuss or mandate what solutions are used
>>> to meet the basic security goals like confidentiality, integrity and
>>> source authenticity for RTP in general.  This responsibility lays on
>>> anyone using RTP in an application.  They can find guidance on
>>> available security mechanisms and important considerations in Options
>>> for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
>>> Applications SHOULD use an appropriate strong security mechanism.
>>>
>>
>> I am okay with that text.
>>
>>> I think I'm okay with this.  (I kind of prefer my previous wording,
>>> "Applications SHOULD implement at least one of the strong security
>>> measures suggested by those references" only because it suggests that
>>> multiple mechanisms are okay, whereas this new wording seems to imply
>>> choosing only one).
>>
>> How about "Applications SHOULD use one or more strong security
>> mechanisms, as appropriate"?
>
> Clearly now we're just getting down to wordsmithing..  :)

Yeah, we should probably let the authors wordsmith their own draft :-)

>
> How about "Applications SHOULD use one or more appropriate strong security
> mechanisms"?  (The subclause "as apporpriate" feels to me like it could be
> ignored, as in "well, using a strong security mechanism isn't
> appropriate").  I think the goal is to make sure that "appropriate"
> modifies the "strong security mechanism" and not the "SHOULD use"  ;)
>
> What say you?

WFM

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


From nobody Thu Apr  9 07:24:39 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EC91A6F27; Thu,  9 Apr 2015 07:24:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTGLlg7l3ISl; Thu,  9 Apr 2015 07:24:35 -0700 (PDT)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97511A6F1E; Thu,  9 Apr 2015 07:24:34 -0700 (PDT)
Received: by labbd9 with SMTP id bd9so79374648lab.2; Thu, 09 Apr 2015 07:24:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sePa/wHDFIqpRK17xjkk6smoE4LEpfe7lvwy9zaNf1w=; b=HXRHMTIKUQGT5E4Pn5FLuN+iHhhfr6n/b9f/vdjfZjn76UByb3a5aKi/krF6wAIKu/ mfgEnYfJrH5O0VAqEhWEm7SOzyKSUal928Rx4wTXACdKazo9bASfaWqL5HxzHDF8gbH1 +LnguvIXg4WxxK9dd0G/JhFOgMI7kihH2EEqmHwzuUPLQ+8wY+TAX5+rJDL2yG2+nkvT aPRpiiFyAp+LYPAI+vHy/2Xd8IlmFAt0FffznKXrn3cu3mD/6NjMtp5j2NfJqbp8iM34 ZCXyxYi1TuvXhZgC8a5aQGBdIXEd2aq/kegVvRc4dN9wY96GECAVo/bWe1eXHYritT4e ejiQ==
MIME-Version: 1.0
X-Received: by 10.152.120.70 with SMTP id la6mr4945472lab.65.1428589473168; Thu, 09 Apr 2015 07:24:33 -0700 (PDT)
Received: by 10.112.167.101 with HTTP; Thu, 9 Apr 2015 07:24:32 -0700 (PDT)
In-Reply-To: <6666FE0B-39E1-4FA5-94C4-72AAEF5CB7C2@nostrum.com>
References:  <551EFB9C.4040504@xiph.org>  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>  <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>   <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org>   <6666FE0B-39E1-4FA5-94C4-72AAEF5CB7C2@nostrum.com>
Date: Thu, 9 Apr 2015 10:24:32 -0400
Message-ID: 
From: Kathleen Moriarty 
To: Ben Campbell 
Content-Type: multipart/alternative; boundary=089e012299d414006d05134b6893
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 14:24:37 -0000

--089e012299d414006d05134b6893
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 9, 2015 at 10:21 AM, Ben Campbell  wrote:

> On 9 Apr 2015, at 9:19, Derek Atkins wrote:
>
> > On Thu, April 9, 2015 10:07 am, Ben Campbell wrote:
> >> On 9 Apr 2015, at 9:00, Derek Atkins wrote:
> >>
> >>> Ben,
> >>>
> > [snip]
> >>> So you're suggesting (and would be okay with) this text:
> >>>
> >>> RTP packets using the payload format defined in this specification
> >>> are subject to the security considerations discussed in the RTP
> >>> specification RFC3550, and in any applicable RTP profile such as
> >>> RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
> >>> SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
> >>> Why RTP Does Not Mandate a Single Media Security Solution"
> >>> [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
> >>> formats responsibility to discuss or mandate what solutions are used
> >>> to meet the basic security goals like confidentiality, integrity and
> >>> source authenticity for RTP in general.  This responsibility lays on
> >>> anyone using RTP in an application.  They can find guidance on
> >>> available security mechanisms and important considerations in Options
> >>> for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
> >>> Applications SHOULD use an appropriate strong security mechanism.
> >>>
> >>
> >> I am okay with that text.
> >>
> >>> I think I'm okay with this.  (I kind of prefer my previous wording,
> >>> "Applications SHOULD implement at least one of the strong security
> >>> measures suggested by those references" only because it suggests that
> >>> multiple mechanisms are okay, whereas this new wording seems to imply
> >>> choosing only one).
> >>
> >> How about "Applications SHOULD use one or more strong security
> >> mechanisms, as appropriate"?
> >
> > Clearly now we're just getting down to wordsmithing..  :)
>
> Yeah, we should probably let the authors wordsmith their own draft :-)
>
> >
> > How about "Applications SHOULD use one or more appropriate strong
> security
> > mechanisms"?  (The subclause "as apporpriate" feels to me like it could
> be
> > ignored, as in "well, using a strong security mechanism isn't
> > appropriate").  I think the goal is to make sure that "appropriate"
> > modifies the "strong security mechanism" and not the "SHOULD use"  ;)
> >
> > What say you?
>
> WFM
>

This text works for me as well.  Please let me know once the draft has been
updated and thanks for the discussion on this point.

Kathleen

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



-- 

Best regards,
Kathleen

--089e012299d414006d05134b6893
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Apr 9, 2015 at 10:21 AM, Ben Campbell <ben@nostrum.com> wrote:
On 9 Apr 2015, at 9:19, Derek Atkins wrote:



> On Thu, April 9, 2015 10:07 am, Ben Campbell wrote:

>> On 9 Apr 2015, at 9:00, Derek Atkins wrote:

>>

>>> Ben,

>>>

> [snip]

>>> So you're suggesting (and would be okay with) this text:
>>>

>>> RTP packets using the payload format defined in this specifica=
tion

>>> are subject to the security considerations discussed in the RT=
P

>>> specification RFC3550, and in any applicable RTP profile such =
as

>>> RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or R=
TP/

>>> SAVPF [RFC5124].=C2=A0 However, as "Securing the RTP Prot=
ocol Framework:

>>> Why RTP Does Not Mandate a Single Media Security Solution"=
;

>>> [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP p=
ayload

>>> formats responsibility to discuss or mandate what solutions ar=
e used

>>> to meet the basic security goals like confidentiality, integri=
ty and

>>> source authenticity for RTP in general.=C2=A0 This responsibil=
ity lays on

>>> anyone using RTP in an application.=C2=A0 They can find guidan=
ce on

>>> available security mechanisms and important considerations in =
Options

>>> for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-optio=
ns].

>>> Applications SHOULD use an appropriate strong security mechani=
sm.

>>>

>>

>> I am okay with that text.

>>

>>> I think I'm okay with this.=C2=A0 (I kind of prefer my pre=
vious wording,

>>> "Applications SHOULD implement at least one of the strong=
 security

>>> measures suggested by those references" only because it s=
uggests that

>>> multiple mechanisms are okay, whereas this new wording seems t=
o imply

>>> choosing only one).

>>

>> How about "Applications SHOULD use one or more strong securit=
y

>> mechanisms, as appropriate"?

>

> Clearly now we're just getting down to wordsmithing..=C2=A0 :)




Yeah, we should probably let the authors wordsmith their own dr=
aft :-)



>

> How about "Applications SHOULD use one or more appropriate strong=
 security

> mechanisms"?=C2=A0 (The subclause "as apporpriate" feel=
s to me like it could be

> ignored, as in "well, using a strong security mechanism isn't=


> appropriate").=C2=A0 I think the goal is to make sure that "=
appropriate"

> modifies the "strong security mechanism" and not the "S=
HOULD use"=C2=A0 ;)

>

> What say you?



WFM

This text works for me as we=
ll.=C2=A0 Please let me know once the draft has been updated and thanks for=
 the discussion on this point.

Kathleen=C2=A0




>

> -derek

>

> --

>=C2=A0 =C2=A0 =C2=A0 Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0617-623-3745

>=C2=A0 =C2=A0 =C2=A0 derek@ihtfp.com=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0www.ihtfp.com

>=C2=A0 =C2=A0 =C2=A0 Computer and Internet Security Consultant





-- 
=


Best regards,
Kathleen




--089e012299d414006d05134b6893--


From nobody Thu Apr  9 07:27:42 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25EC1A6F30 for ; Thu,  9 Apr 2015 07:27:35 -0700 (PDT)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7CXlRRSGTTk for ; Thu,  9 Apr 2015 07:27:31 -0700 (PDT)
Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com [209.85.220.176]) (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 662EE1A6F3A for ; Thu,  9 Apr 2015 07:27:31 -0700 (PDT)
Received: by qku63 with SMTP id 63so126064671qku.3 for ; Thu, 09 Apr 2015 07:27:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZpO6J98U3naU/96/r0uWWFgxV3xLrdzN4hQ1HpC0xjU=; b=IXD0uRHpDRm5VMavtBey7DnvOMNaV6Y2agNGLqEOae0n6l+l0fMnbKTJWjmtsQ64eA 8WIU4+WzxGusJo1p5G5Hp2w/mB17PnFC0Y02CbcLHnHv8PI/2VZsqko7DpetXvGBbdsH 6F6k1dJbl+ED/qhKVR1pyR04kQvbM1gBSrTBqpCV2eV6hzlAFQhWJ4eJprecl1bODEit CFY3g8dijM3SD7+lrR9dn2hOw6Yzrfu4vFygfJSYqUcuId7m1/HQmBcaawcP+T1z0Thf VnOCuaNgcuKOfLNZdc8OtH2QXPTsdPsNCYiGztTKtJBcnf6eGD8kKgqGUFcsu/gY5ddI mWPw==
X-Gm-Message-State: ALoCoQmzJhojYXLwUUWrmZjU3/3wveDwCQiFqvRojuWMGMzHg7IkOTu4z+t4/1VhmErw5ijVAQxd
X-Received: by 10.140.239.76 with SMTP id k73mr20854769qhc.66.1428589650705; Thu, 09 Apr 2015 07:27:30 -0700 (PDT)
Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id 138sm9880801qhx.7.2015.04.09.07.27.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 07:27:29 -0700 (PDT)
Message-ID: <55268C4F.6020608@mozilla.com>
Date: Thu, 09 Apr 2015 10:27:27 -0400
From: Jean-Marc Valin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Ben Campbell , Derek Atkins 
References:  <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>  <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>   <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org>   <6666FE0B-39E1-4FA5-94C4-72AAEF5CB7C2@nostrum.com>
In-Reply-To: <6666FE0B-39E1-4FA5-94C4-72AAEF5CB7C2@nostrum.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 14:27:36 -0000

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



On 09/04/15 10:21 AM, Ben Campbell wrote:
>> Clearly now we're just getting down to wordsmithing..  :)
> 
> Yeah, we should probably let the authors wordsmith their own draft
> :-)

Actually, on that one I'd rather not wordsmith myself. If there's
consensus on exact text, I'd rather just put it in as-is.

	Jean-Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVJoxNAAoJEJ6/8sItn9q90aQH/219fCXj07/QN96Msaffe9oG
pMRwKtIUPH6BvHZFj8cNNkyT0VF9TsTAXzQ7dRb1DgCPRLiTBnqiUUAeXByb0F7Z
5EVXqLyZM0QXLrnqNjokh6nQJ3YQgOnq9TCq5JmOFWB6BgMSmIjNl6DNu0WH9uqU
SmI73lxKV/l+2Hbag2qcf9HsN/Rz3rBtXRswBsYWBJm0bq0mNLchfN2OWJm2KhsM
CZxz0h3DCiZm7g5bXRsUeRlwLBr5pw/eTBm7bmVjLOFXwd74hMFG2SBgwqdVkOUs
qHgnx1PxPDSVu86T1cxwD0GMLyKGG/6iZbuvEkmGu7SMAnXHqTHcWYcF4i10P0Y=
=tJx3
-----END PGP SIGNATURE-----


From nobody Thu Apr  9 17:28:20 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50661B37E4 for ; Thu,  9 Apr 2015 17:28:17 -0700 (PDT)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUCBYe4HGHy3 for ; Thu,  9 Apr 2015 17:28:15 -0700 (PDT)
Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (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 AD2B61B37D8 for ; Thu,  9 Apr 2015 17:28:15 -0700 (PDT)
Received: by iejt8 with SMTP id t8so5704314iej.2 for ; Thu, 09 Apr 2015 17:28:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wLPFn/AcdvxCmSz2ySXgYTIUGcPMQ3HEih2YXq9nW+c=; b=bBOKbqeqVJuIWPFRbP4rumWOeE7v510U9M1LZc5IwEZiZrlKDjbYQgDOWOHh5KQ7a4 sZkcShGZ2DyMJSih+uWMmHWp+gMFfz0gQ69oHoNn7A9iv1Uc4bCOXGArBX7DE1naeKDo zJwpK27/+igc/IiqZR/E0jPwGA3zptzihucpDqSl8s4BzBbprk4sPkETGqsXc8uLo0eK UISg9bbPjn5Shoh97Icju5eL0za3/O5vKF+mZfZr9sf+UY1tjoBSmwBNQuk8H6PkI1HF zz8+PUnH1wOcUT8uON53nE7duDsH5xqzLB27xfhswJKb6VF9jF16LGd4QdN0zzhCn48M lduQ==
X-Gm-Message-State: ALoCoQnJHPoTdagKrEViiobMnI7UlTL0u+dSY2NcKJ106s6LQsED6nXWiAh8aonz2pvLVxKgGUFC
X-Received: by 10.107.4.196 with SMTP id 187mr31980518ioe.6.1428625695017; Thu, 09 Apr 2015 17:28:15 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id o196sm259041ioe.26.2015.04.09.17.28.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 17:28:14 -0700 (PDT)
Message-ID: <5527191C.1060404@andyet.net>
Date: Thu, 09 Apr 2015 18:28:12 -0600
From: Peter Saint-Andre - &yet 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Hannes Tschofenig , The IESG , draft-ietf-uta-xmpp@tools.ietf.org, "secdir@ietf.org" 
References: <5525EC51.3040903@gmx.net>
In-Reply-To: <5525EC51.3040903@gmx.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [secdir] Security review of draft-ietf-uta-xmpp-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Apr 2015 00:28:17 -0000

On 4/8/15 9:04 PM, Hannes Tschofenig 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.
>
> This document is ready for publication.
>
> I have only one small comment: draft-ietf-uta-xmpp does not really
> recommend anything that has not already been recommended in the other
> referenced specifications. Hence it appears a bit redundant.

Hallo Hannes,

One thing that is missing from the current version is an explicit update 
to RFC 6120 to make it clear that the best current practices recommended 
in draft-ietf-uta-tls-bcp apply to XMPP. Roni Even also pointed this out 
in his Gen-ART review. I suggested some text to remedy that oversight here:

http://www.ietf.org/mail-archive/web/uta/current/msg01108.html

Tschüss,

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Thu Apr  9 23:52:41 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADF71AD0A9; Thu,  9 Apr 2015 23:52:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PzemeL4KoiY; Thu,  9 Apr 2015 23:52:36 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 364741AD0A7; Thu,  9 Apr 2015 23:52:34 -0700 (PDT)
X-AuditID: c1b4fb2d-f79a46d0000006b4-70-552773301751
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E7.40.01716.03377255; Fri, 10 Apr 2015 08:52:33 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.210.2; Fri, 10 Apr 2015 08:52:32 +0200
Message-ID: <5527732E.60701@ericsson.com>
Date: Fri, 10 Apr 2015 08:52:30 +0200
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Derek Atkins , Ben Campbell 
References:  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>  <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>   <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org>  
In-Reply-To: 
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvja5hsXqowcrVbBbzO0+zWyx/eYLR YuWkHewWM/5MZLa4OfcQo0XDznyLE4f/MlqcDrS4dPEsk8WHhQ9ZHLg8pt2/z+axc9Zddo8l S34yeSz/+oDFY9bOJyweXy5/Zgtgi+KySUnNySxLLdK3S+DKOL/oLFvBU6mKiSvvsDUw3hft YuTkkBAwkXh3cDEThC0mceHeejYQW0jgKKPEuycGXYxcQPZyRonGD9/AErwCmhLt1xqZQWwW AVWJVR2fwJrZBCwkbv5oBKsRFQiWaHrRyA5RLyhxcuYTFhBbRMBJYv/DPYwgQ5kFOpkkejZt B2sWFgiQuDr9PjvE5qvsEtOexIHYnAIeEh1rf7GC2MwCBhJHFs2BsuUlmrfOZoao15ZoaOpg ncAoOAvJvllIWmYhaVnAyLyKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzBGDm75rbuDcfVr x0OMAhyMSjy8D9LUQ4VYE8uKK3MPMUpzsCiJ89oZHwoREkhPLEnNTk0tSC2KLyrNSS0+xMjE wSnVwDhr7vdlqtu+i02vZL/a+U/8MbtX3k6TxxJNTDq7fh5rcxB7stmlM05mz+/tTbwC/GKG 8eVmpSGzG4r6vXdaCFVd/nSPr0rXkiGraOO/qQ93W4v5ZtWuEeLwbt5zWnz/vB/Lpbq+H757 e/vzrU76h46KBezMct369FI+S3WCcNlBTWvx31MXeCqxFGckGmoxFxUnAgAtfjI/cgIAAA==
Archived-At: 
Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Apr 2015 06:52:37 -0000

On 2015-04-09 16:19, Derek Atkins wrote:
> 
> On Thu, April 9, 2015 10:07 am, Ben Campbell wrote:
>> On 9 Apr 2015, at 9:00, Derek Atkins wrote:
>>
>>> Ben,
>>>
> [snip]
>>> So you're suggesting (and would be okay with) this text:
>>>
>>>  RTP packets using the payload format defined in this specification
>>>  are subject to the security considerations discussed in the RTP
>>>  specification RFC3550, and in any applicable RTP profile such as
>>>  RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
>>>  SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
>>>  Why RTP Does Not Mandate a Single Media Security Solution"
>>>  [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
>>>  formats responsibility to discuss or mandate what solutions are used
>>>  to meet the basic security goals like confidentiality, integrity and
>>>  source authenticity for RTP in general.  This responsibility lays on
>>>  anyone using RTP in an application.  They can find guidance on
>>>  available security mechanisms and important considerations in Options
>>>  for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
>>>  Applications SHOULD use an appropriate strong security mechanism.
>>>
>>
>> I am okay with that text.
>>
>>> I think I'm okay with this.  (I kind of prefer my previous wording,
>>> "Applications SHOULD implement at least one of the strong security
>>> measures suggested by those references" only because it suggests that
>>> multiple mechanisms are okay, whereas this new wording seems to imply
>>> choosing only one).
>>
>> How about "Applications SHOULD use one or more strong security
>> mechanisms, as appropriate"?
> 
> Clearly now we're just getting down to wordsmithing..  :)
> 
> How about "Applications SHOULD use one or more appropriate strong security
> mechanisms"?  (The subclause "as apporpriate" feels to me like it could be
> ignored, as in "well, using a strong security mechanism isn't
> appropriate").  I think the goal is to make sure that "appropriate"
> modifies the "strong security mechanism" and not the "SHOULD use"  ;)
> 
> What say you?

Yes, I think that is fine. I don't see this contradicting RFC7202, and
are happy to include this in draft-ietf-payload-rtp-howto's template
text. I will wait a week before submitting an update version of the
HOWTO with this text and updated references. I will send an separate
email to the list and IESG to make clear that we are proposing this
change. I note that the document is approved by IESG and thus I like to
ensure that we still have consensus on this.

I hope that other RTP Payload format authors are paying attention to
this. The template text is fairly carefully constructed  to be clear and
not blur the lines of responsibility in this matter. The point of the
above paragraph of template is to avoid this type of discussions.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From nobody Thu Apr  9 23:56:32 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2D01AD0C4; Thu,  9 Apr 2015 23:56:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YAk1tvY2V_e; Thu,  9 Apr 2015 23:56:24 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BF71AD0C1; Thu,  9 Apr 2015 23:56:23 -0700 (PDT)
X-AuditID: c1b4fb3a-f79146d0000070a3-ab-5527741584d0
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E1.D1.28835.51477255; Fri, 10 Apr 2015 08:56:22 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.210.2; Fri, 10 Apr 2015 08:56:21 +0200
Message-ID: <55277415.9060309@ericsson.com>
Date: Fri, 10 Apr 2015 08:56:21 +0200
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Derek Atkins , Ben Campbell 
References:  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>  <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>   <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org>  
In-Reply-To: 
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+Jvja5YiXqowaR7jBbzO0+zW6yctIPd YsaficwWDTvzLS5dPMtk8WHhQxYHNo+ds+6yeyxZ8pPJY/nXBywes3Y+YQlgieKySUnNySxL LdK3S+DKOL/oLFvBU6mKiSvvsDUw3hftYuTkkBAwkVjesZwFwhaTuHBvPVsXIxeHkMBRRokD e68zQTjLGSX+9M5gBKniFdCWWPn1OTOIzSKgKtGw4i4riM0mYCFx80cjG4gtKhAs0fSikR2i XlDi5MwnYBtEBJwk9j/cwwgylFlgCqPElEnzwAYJCwRIXJ1+H6xBSOAqu8S0J3EgNqeAh0TH 2l9gC5gFDCSOLJoDZctLNG+dzQxRry3R0NTBOoFRcBaSfbOQtMxC0rKAkXkVo2hxanFxbrqR kV5qUWZycXF+nl5easkmRmCwH9zy22oH48HnjocYBTgYlXh4H6SphwqxJpYVV+YeYpTmYFES 57UzPhQiJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXHq+VPbPsh7fuHvimcvvKm1y+dU4OXW Z57HJTo/VEysTOcID7x+xtL1vcOW35vy4rdwzj5+JPbm2QUXl4quvhwmoxLpV+njvbPY+2nT Is3D3JpN02IyNly346yy3nh7utDsSevKBL+kTBJYcaB6lvDxmn2Xri4xWPJ3Gc+vtEfV2jbb Iho+bpquxFKckWioxVxUnAgAOcQpblcCAAA=
Archived-At: 
Cc: Kathleen Moriarty , "iesg@ietf.org" , payload@ietf.org, "secdir@ietf.org" 
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Apr 2015 06:56:26 -0000

On 2015-04-09 16:19, Derek Atkins wrote:
> 
> On Thu, April 9, 2015 10:07 am, Ben Campbell wrote:
>> On 9 Apr 2015, at 9:00, Derek Atkins wrote:
>>
>>> Ben,
>>>
> [snip]
>>> So you're suggesting (and would be okay with) this text:
>>>
>>>  RTP packets using the payload format defined in this specification
>>>  are subject to the security considerations discussed in the RTP
>>>  specification RFC3550, and in any applicable RTP profile such as
>>>  RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
>>>  SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
>>>  Why RTP Does Not Mandate a Single Media Security Solution"
>>>  [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
>>>  formats responsibility to discuss or mandate what solutions are used
>>>  to meet the basic security goals like confidentiality, integrity and
>>>  source authenticity for RTP in general.  This responsibility lays on
>>>  anyone using RTP in an application.  They can find guidance on
>>>  available security mechanisms and important considerations in Options
>>>  for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
>>>  Applications SHOULD use an appropriate strong security mechanism.
>>>
>>
>> I am okay with that text.
>>
>>> I think I'm okay with this.  (I kind of prefer my previous wording,
>>> "Applications SHOULD implement at least one of the strong security
>>> measures suggested by those references" only because it suggests that
>>> multiple mechanisms are okay, whereas this new wording seems to imply
>>> choosing only one).
>>
>> How about "Applications SHOULD use one or more strong security
>> mechanisms, as appropriate"?
> 
> Clearly now we're just getting down to wordsmithing..  :)
> 
> How about "Applications SHOULD use one or more appropriate strong security
> mechanisms"?  (The subclause "as apporpriate" feels to me like it could be
> ignored, as in "well, using a strong security mechanism isn't
> appropriate").  I think the goal is to make sure that "appropriate"
> modifies the "strong security mechanism" and not the "SHOULD use"  ;)
> 
> What say you?

Yes, I think that is fine. I don't see this contradicting RFC7202, and
are happy to include this in draft-ietf-payload-rtp-howto's template
text. I will wait a week before submitting an update version of the
HOWTO with this text and updated references. I will send an separate
email to the list and IESG to make clear that we are proposing this
change. I note that the document is approved by IESG and thus I like to
ensure that we still have consensus on this.

I hope that other RTP Payload format authors are paying attention to
this. The template text is fairly carefully constructed  to be clear and
not blur the lines of responsibility in this matter. The point of the
above paragraph of template is to avoid this type of discussions.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From nobody Fri Apr 10 00:24:23 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAF01A00B5; Fri, 10 Apr 2015 00:24:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYjxShkM5Tl5; Fri, 10 Apr 2015 00:24:20 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3401A00B7; Fri, 10 Apr 2015 00:24:11 -0700 (PDT)
Received: from [81.187.2.149] (port=38464 helo=[192.168.0.18]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YgTIO-0005Sg-LW; Fri, 10 Apr 2015 08:24:09 +0100
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins 
In-Reply-To: <5527732E.60701@ericsson.com>
Date: Fri, 10 Apr 2015 08:24:01 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>   <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>  <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>  <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>   <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org>   <5527732E.60701@ ericsson.com>
To: Magnus Westerlund 
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: 
Cc: Ben Campbell , "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Apr 2015 07:24:22 -0000

On 10 Apr 2015, at 07:52, Magnus Westerlund =
 wrote:
> On 2015-04-09 16:19, Derek Atkins wrote:
>>=20
>> On Thu, April 9, 2015 10:07 am, Ben Campbell wrote:
>>> On 9 Apr 2015, at 9:00, Derek Atkins wrote:
>>>=20
>>>> Ben,
>>>>=20
>> [snip]
>>>> So you're suggesting (and would be okay with) this text:
>>>>=20
>>>> RTP packets using the payload format defined in this specification
>>>> are subject to the security considerations discussed in the RTP
>>>> specification RFC3550, and in any applicable RTP profile such as
>>>> RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
>>>> SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
>>>> Why RTP Does Not Mandate a Single Media Security Solution"
>>>> [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP =
payload
>>>> formats responsibility to discuss or mandate what solutions are =
used
>>>> to meet the basic security goals like confidentiality, integrity =
and
>>>> source authenticity for RTP in general.  This responsibility lays =
on
>>>> anyone using RTP in an application.  They can find guidance on
>>>> available security mechanisms and important considerations in =
Options
>>>> for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
>>>> Applications SHOULD use an appropriate strong security mechanism.
>>>>=20
>>>=20
>>> I am okay with that text.
>>>=20
>>>> I think I'm okay with this.  (I kind of prefer my previous wording,
>>>> "Applications SHOULD implement at least one of the strong security
>>>> measures suggested by those references" only because it suggests =
that
>>>> multiple mechanisms are okay, whereas this new wording seems to =
imply
>>>> choosing only one).
>>>=20
>>> How about "Applications SHOULD use one or more strong security
>>> mechanisms, as appropriate"?
>>=20
>> Clearly now we're just getting down to wordsmithing..  :)
>>=20
>> How about "Applications SHOULD use one or more appropriate strong =
security
>> mechanisms"?  (The subclause "as apporpriate" feels to me like it =
could be
>> ignored, as in "well, using a strong security mechanism isn't
>> appropriate").  I think the goal is to make sure that "appropriate"
>> modifies the "strong security mechanism" and not the "SHOULD use"  ;)
>>=20
>> What say you?
>=20
> Yes, I think that is fine. I don't see this contradicting RFC7202, and
> are happy to include this in draft-ietf-payload-rtp-howto's template
> text. I will wait a week before submitting an update version of the
> HOWTO with this text and updated references. I will send an separate
> email to the list and IESG to make clear that we are proposing this
> change. I note that the document is approved by IESG and thus I like =
to
> ensure that we still have consensus on this.
>=20
> I hope that other RTP Payload format authors are paying attention to
> this. The template text is fairly carefully constructed  to be clear =
and
> not blur the lines of responsibility in this matter. The point of the
> above paragraph of template is to avoid this type of discussions.

+1 no objections


--=20
Colin Perkins
https://csperkins.org/





From nobody Fri Apr 10 06:55:14 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1581B361B for ; Fri, 10 Apr 2015 06:55:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.155
X-Spam-Level: 
X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xpi4JvaAS_L4 for ; Fri, 10 Apr 2015 06:55:12 -0700 (PDT)
Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id D64151B3617 for ; Fri, 10 Apr 2015 06:55:11 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.142; 
From: "Susan Hares" 
To: 
Date: Fri, 10 Apr 2015 09:55:05 -0400
Message-ID: <006201d07395$f35268d0$d9f73a70$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01D07374.6C420150"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdBzlaJVW/QIjj+YR8efQISk4dWylA==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Cc: Kathleen Moriarty 
Subject: [secdir] ietf-idr-as-migration-04.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Apr 2015 13:55:12 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0063_01D07374.6C420150
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Security directorate: 

 

This is to request a final review draft-ietf-idr-as-migration-04.txt. This
draft has been revised after being sent to the IESG to address some textual
concerns that Kathleen and Stephen had.  

 

Please let me know if you can do this final review within 2 weeks. 

 

Sue Hares 


------=_NextPart_000_0063_01D07374.6C420150
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Security =
directorate: 
 
This is to request a final review =
draft-ietf-idr-as-migration-04.txt. This draft has been revised after =
being sent to the IESG to address some textual concerns that Kathleen =
and Stephen had.  
 
Please let =
me know if you can do this final review within 2 weeks. =

 
Sue Hares 

------=_NextPart_000_0063_01D07374.6C420150--


From nobody Fri Apr 10 09:07:04 2015
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 3764A1A8727; Fri, 10 Apr 2015 09:04:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1428681895; bh=r2MjtFrRANBgCHV1D4+7CSpM/QplQ3gFFtskjydDhqo=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=RArH3gju1ZFZFPiwUnoySPhmS6nkhGXVyFRpZQ1PsRv74gb5IAUE4SNICa6AS7NQd +Svxp0hFIUuXHn6pH0w28t0f8tx5GCoYg/bJdbv5MtHJRf3r30X0rWRbLy+ZL40YCp PFvtHxT8iK8PNGhxXRMkezOfNwpRFS7yjStv8npY=
X-Original-To: new-work@ietfa.amsl.com
Delivered-To: new-work@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B431A8718; Fri, 10 Apr 2015 09:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOPedb52ZjUp; Fri, 10 Apr 2015 09:04:47 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A19261A8724; Fri, 10 Apr 2015 09:04:47 -0700 (PDT)
MIME-Version: 1.0
From: The IESG 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150410160447.19868.40582.idtracker@ietfa.amsl.com>
Date: Fri, 10 Apr 2015 09:04:47 -0700
Archived-At: 
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Apr 2015 09:07:03 -0700
Subject: [secdir] [new-work] WG Review: Routing Over Low power and Lossy networks (roll)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Apr 2015 16:04:55 -0000

The Routing Over Low power and Lossy networks (roll) working group in the
Routing Area of the IETF is undergoing rechartering. 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 at ietf.org) by 2015-04-20.

Routing Over Low power and Lossy networks (roll)
------------------------------------------------
Current Status: Active WG

Chairs:
  Ines Robles 
  Michael Richardson 

Technical advisors:
  Rene Struik 

Assigned Area Director:
  Alvaro Retana 

Mailing list
  Address: roll@ietf.org
  To Subscribe: http://www.ietf.org/mailman/listinfo/roll
  Archive: http://www.ietf.org/mail-archive/web/roll/

Charter:

Low power and Lossy Networks (LLNs) are made up of many embedded devices
with limited power, memory, and processing resources. They are
interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth,
Low Power WiFi, wired or other low power PLC (Powerline Communication)
links. LLNs are transitioning to an end-to-end IP-based solution to avoid
the problem of non-interoperable networks interconnected by protocol
translation gateways and proxies.

Generally speaking, LLNs have at least five distinguishing
characteristics:

LLNs operate with a hard, very small bound on state.  In most cases, LLN
optimize for saving energy.  Typical traffic patterns are not simply
unicast flows (e.g. in some cases most if not all traffic can be point to
multipoint). In most cases, LLNs will be employed over link layers with
restricted frame-sizes, thus a routing protocol for LLNs should be
specifically adapted for such link layers.  LLN routing protocols have to
be very careful when trading off efficiency for generality; many LLN
nodes do not have resources to waste.

These specific properties cause LLNs to have specific routing
requirements.

Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been
evaluated by the working group and have in their current form been found
to not satisfy all of these specific routing requirements.

The Working Group is focused on routing issues for LLN.

There is a wide scope of application areas for LLNs, including industrial
monitoring, building automation (HVAC, lighting, access control, fire),
connected homes, health care, environmental monitoring, urban sensor
networks (e.g. Smart Grid), asset tracking. The Working Group focuses on
routing solutions for a subset of these: industrial, connected home,
building and urban sensor networks for which routing requirements have
been specified. These application-specific routing requirement documents
were used for protocol design.

The Working Group focuses only on IPv6 routing architectural framework
for these application scenarios. The Framework will take into
consideration various aspects including high reliability in the presence
of time varying loss characteristics and connectivity while permitting
low-power operation with very modest memory and CPU pressure in networks
potentially comprising a very large number (several thousands) of nodes.

The Working Group will pay particular attention to routing security and
manageability (e.g., self routing configuration) issues. It will also
need to consider the transport characteristic the routing protocol
messages will experience. Mechanisms that protect an LLN from congestion
collapse or that establish some degree of fairness between concurrent
communication sessions are out of scope of the Working Group. It is
expected that upper-layer applications utilizing LLNs define appropriate
mechanisms. The solution must include unicast and multicast
considerations.

The Working Group will document how non-control packets are routed when
they cross the LLN, and when they enter and exit the LLN: the appropriate
use of RH3 (RFC6553), RPI (RFC6554) and IPv6-in-IPv6 encapsulation
including how routing loops are detected. In consultation with the 6lo
WG, the Working Group will design a method to compress these routing
headers into a single block.  The WGLC on this work will be shared with
6lo.

ROLL is responsible for maintenance of the protocols that is has
developed, including RPL and MPL.  AD approval is required for each new
work item that is proposed.

Work Items:

- Details about when to use RFC6553, RFC6554, and IPv6-in-IPv6
encapsulation.

- Details about how to compress RFC6553, RFC6554, and IP headers in the
6LoWPAN
adaptation layer context

Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work


From nobody Mon Apr 13 08:54:17 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F024F1ACE08; Mon, 13 Apr 2015 08:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.298
X-Spam-Level: ***
X-Spam-Status: No, score=3.298 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-aLxSSymngN; Mon, 13 Apr 2015 08:54:12 -0700 (PDT)
Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FFB81ACDC4; Mon, 13 Apr 2015 08:54:12 -0700 (PDT)
Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp  with ESMTP id t3DFs8DT023656; Tue, 14 Apr 2015 00:54:08 +0900 (JST)
Received: from TakeVaioVJP13 (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp  with ESMTP id t3DFs50Y023650; Tue, 14 Apr 2015 00:54:06 +0900 (JST)
From: "Takeshi Takahashi" 
To: 
Date: Tue, 14 Apr 2015 00:54:07 +0900
Message-ID: <008201d07602$149a67e0$3dcf37a0$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdB111/h0yd7zQHoRkKk9EAsY4rZpw==
Content-Language: ja
X-Virus-Scanned: clamav-milter 0.98.5 at zenith2
X-Virus-Status: Clean
Archived-At: 
Cc: behave-chairs@tools.ietf.org, 'The IESG' , secdir@ietf.org
Subject: [secdir] Secdir review of draft-perrault-behave-natv2-mib-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Apr 2015 15:54:14 -0000

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.

This document is ready for publication.

[summary of this document]

This draft defines a portion of the MIB for devices implementing the NAT
function.
The new MIB module defined in this document, NATv2-MIB is intended to
replace module NAT-MIB (RFC 4008).
The document claims that the version 2 has more focus on measurement, while
the version 1 has more focus on configuration.
This document begins with defining four types of content the NATv2-MIB
module provides, followed by the outline of MIB module organization (OID
map) and detailed explanation of MIB-related tables.

[comment on security consideration]

The biggest concern I had when reading this draft was the manipulation of
the MIB by malicious parties.
Access control and encryption need to be addressed.
The current security consideration section raises adequate concerns on that,
and I think the section is fine.

[minor questions]

Let me ask minor three questions to deepen my understanding on this draft.
Note that these questions are purely for deepening my understanding, and I
am not asking to change the sentences of the draft at all by these
questions.

1. [Section 3.1.2 in page 7]
   question on natv2NotificationPoolUsageHigh and
natv2NotificationPoolUsageLow.

It is easy to imagine the use of "natv2NotificationPoolUsageHigh", but I am
not sure what kind of usage we have on the "natv2NotificationPoolUsageLow".
The notification indicates that "usage equals or has fallen below a lower
threshold".
What kind of actions are we going to take by receiving the notification?
Are we going to aggregate two rarely-used NAT modules into one based on this
notification?

The NATv2-MIB provides state information, as described in Section 3.1.3.
I assume that administrators of NAT modules monitor the state information
periodically in order to redesign NAT modules (if needed).
If so, I do not think administrators rely on the
natv2NotificationPoolUsageLow notification; I do not see the need to receive
real-time notification of rarely-used NAT.
I might have totally misunderstood; I would appreciate some guidance on
this.


2. [Section 3.1.2 in page 7]
   question on disabling notifications.

"A given notification can be disabled by setting the threshold to 0
(default)" with the exception of natv2PoolThresholdUsageLow, which uses "-1"
to disable its notification.
Having two different values on the same kind of issues is a bit confusing to
me.
I wonder whether we could have any problem if we use the value "-1" for all
the threshold values to disable notifications.
Are there any disadvantages using "-1" instead of using the mixture of "0"
and "-1" for the threshold values?


3. [Section 3.1.4 in page 10]
   question on Statistics.

This question is related to the counters "address/port map limit drops".
According to the draft, the counters are incremented based on the threshold
values for address/port mapping.
Then, I would avoid setting a value that is more than the NAT module's
capability.
Do we have any means to check the appropriateness of the threshold value?
(I am not sure whether it is possible to measure NAT's processing
capabilities in advance.)

Thank you.

Take




From nobody Mon Apr 13 10:44:02 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A411E1ACEAE for ; Mon, 13 Apr 2015 10:43:59 -0700 (PDT)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FpoQj8BcueY for ; Mon, 13 Apr 2015 10:43:58 -0700 (PDT)
Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) (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 AEAC41AD0BB for ; Mon, 13 Apr 2015 10:43:58 -0700 (PDT)
Received: by qkx62 with SMTP id 62so191068502qkx.0 for ; Mon, 13 Apr 2015 10:43:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-type:content-transfer-encoding; bh=HgY/euQOzAk5UatC4vhyegtuf3r/F+y+TdE+O34H6Fo=; b=QB0LPbbQKGEIW1joQgFi9ybBqx74apbYJ2NR0J9RnvkjmZgVrCwfV7OzFJW5VesATf C5hL/NhVVYhK6BsiuEi9MpbaRStjXt5WjC/n+whn+ILQdT3q1RNejB7VaTAPxT+DAESQ 7x+flWw0Ljf3niBQP6A79SOlK9A2lAsbpodtwnGiP8bUwEUqbhyHy4a3sQSsuJxc+7Vr O9cf+PUvHv3PNbgpDX5tn/2lmRFo9LO8eYcNh6upSSuJ+ZCBVzf6sG+mLkdbc+SDtkfX U3eW3OE88OtMIXBwMzHJ3JKHg5BB9mntJeC5FingmcMkzT65C+stgDsyMs/iheKdb9tr /OYg==
X-Gm-Message-State: ALoCoQm5elt749zpsDNNNXmkzhG1AHDqOk9bQtb4lZzIitIDKi8eBY9EBpmxqOn7/e1hrsyAIbUt
X-Received: by 10.229.214.199 with SMTP id hb7mr20285641qcb.12.1428947037034;  Mon, 13 Apr 2015 10:43:57 -0700 (PDT)
Received: from [192.168.2.27] (pool-96-241-148-223.washdc.fios.verizon.net. [96.241.148.223]) by mx.google.com with ESMTPSA id n72sm6289424qha.19.2015.04.13.10.43.55 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Apr 2015 10:43:56 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.4.7.141117
Date: Mon, 13 Apr 2015 13:43:53 -0400
From: Carl Wallace 
To: , , 
Message-ID: 
Thread-Topic: secdir review of draft-ietf-dane-srv-12
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: 
Subject: [secdir] secdir review of draft-ietf-dane-srv-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Apr 2015 17:43:59 -0000

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 is basically ready. A few minor nits are below. The primary
comment is that there are a few instances where abbreviated certificate
checks are cited and potentially mask a need to do full certification path
validation.

Therefore this document provides guidelines that enable protocols that
rely on SRV lookups to locate and use TLSA records.

In section 1
- May be worth adding a note to the third bullet to clarify that multiple
target endpoints may be defined for a given service domain, including a
mix of endpoints that have and do not have TLSA records.
- Should the "always use" in the third bullet be "MUST use"?
- May be worth clarifying in the fifth bullet that no usable TLSA records
for one target endpoint does not mean there are no usable TLSA records for
another target endpoint. The security considerations address this point
and the point in the first bullet above, but it seems worth reenforcing in
the body as well.
- Bullet 5 should reference RFC5280 alongside RFC6125 and/or reference
"non-DANE behavior" a la section 3.1 (but using the target server
hostname).

In Section 4.2
- Should this reference RFC6698 section 2.1 or section 4? Section 4 seems
like a better target to me.
- Replace reference to "expiration checks from RFC5280" with "validation
checks from RFC5280" unless you mean for some forms of 5280 checks to be
honored here. Current wording could create a misimpression that only
expiration checks need be performed.

In section 10.2
- In the last sentence, clients must also validate the certificate back to
the designated trust anchor, not just check the reference identifiers.



From nobody Mon Apr 13 11:57:28 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FF61ACE0D; Mon, 13 Apr 2015 11:57:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQds6ySO5cVB; Mon, 13 Apr 2015 11:57:13 -0700 (PDT)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4301B2A2B; Mon, 13 Apr 2015 11:57:13 -0700 (PDT)
Received: by iebmp1 with SMTP id mp1so73095353ieb.0; Mon, 13 Apr 2015 11:57:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ukgZXIaD0VoEDw75KUtXPJaExtentWggr7nHHaaKYOM=; b=Ip2zyvjLRkHqGP+cdKTEw1Oml0bbDHRenDAKYS7+n6kAcXYnvPHDm+WyvSQYTPoXl6 Japt8Qte/0bqKjt895NGXus5nG5mKxRAF55jTjbhpVP0piIvzMmHJn3+OeOi55Fd3+xr abpfVqZaMknQqlXYrQ7iRmNTLysZJ2Rk2Za5UnsOOVJ0APHtB+so9uY1Ftz8CPQuRIqg Wk2BexgLb1dKJKEuW3VjwzbP0dOq5kOjXzCFbiZPbHLKqudldZ2OVXBCqEKFvHEK/SCb LIq2WnQYGL0ksz8OWwndB8t6+2UIvz28LdE7Jhif5U3uFUgYg2F07isq5RwwguFRCzpM Mzmw==
X-Received: by 10.50.79.233 with SMTP id m9mr18958724igx.45.1428951432886; Mon, 13 Apr 2015 11:57:12 -0700 (PDT)
Received: from [192.168.1.135] (dsl-173-206-66-49.tor.primus.ca. [173.206.66.49]) by mx.google.com with ESMTPSA id kc1sm5535689igb.0.2015.04.13.11.57.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Apr 2015 11:57:12 -0700 (PDT)
Message-ID: <552C1186.1010702@gmail.com>
Date: Mon, 13 Apr 2015 14:57:10 -0400
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Takeshi Takahashi ,  draft-perrault-behave-natv2-mib.all@tools.ietf.org
References: <008201d07602$149a67e0$3dcf37a0$@nict.go.jp>
In-Reply-To: <008201d07602$149a67e0$3dcf37a0$@nict.go.jp>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: behave-chairs@tools.ietf.org, 'The IESG' , secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-perrault-behave-natv2-mib-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Apr 2015 18:57:20 -0000

Thank you very much for your review. Some responses below marked with [PTT].

Tom Taylor

On 13/04/2015 11:54 AM, Takeshi Takahashi 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.
>
> This document is ready for publication.
>
> [summary of this document]
>
> This draft defines a portion of the MIB for devices implementing the NAT
> function.
> The new MIB module defined in this document, NATv2-MIB is intended to
> replace module NAT-MIB (RFC 4008).
> The document claims that the version 2 has more focus on measurement, while
> the version 1 has more focus on configuration.
> This document begins with defining four types of content the NATv2-MIB
> module provides, followed by the outline of MIB module organization (OID
> map) and detailed explanation of MIB-related tables.
>
> [comment on security consideration]
>
> The biggest concern I had when reading this draft was the manipulation of
> the MIB by malicious parties.
> Access control and encryption need to be addressed.
> The current security consideration section raises adequate concerns on that,
> and I think the section is fine.
>
> [minor questions]
>
> Let me ask minor three questions to deepen my understanding on this draft.
> Note that these questions are purely for deepening my understanding, and I
> am not asking to change the sentences of the draft at all by these
> questions.
>
> 1. [Section 3.1.2 in page 7]
>     question on natv2NotificationPoolUsageHigh and
> natv2NotificationPoolUsageLow.
>
> It is easy to imagine the use of "natv2NotificationPoolUsageHigh", but I am
> not sure what kind of usage we have on the "natv2NotificationPoolUsageLow".
> The notification indicates that "usage equals or has fallen below a lower
> threshold".
> What kind of actions are we going to take by receiving the notification?
> Are we going to aggregate two rarely-used NAT modules into one based on this
> notification?
>
[PTT] The notification concerns address pools. Those are sets of 
addresses routable in a given address realm. If the addresses are in one 
pool they are inaccessible to users or services assigned to a different 
pool. The action taken would be to move some of the addresses from the 
underutilized pool to another one than has a high utilization.

[PTT] The need for a notification for this condition is something I 
questioned myself, but apparently someone sees it to be useful.

> The NATv2-MIB provides state information, as described in Section 3.1.3.
> I assume that administrators of NAT modules monitor the state information
> periodically in order to redesign NAT modules (if needed).
> If so, I do not think administrators rely on the
> natv2NotificationPoolUsageLow notification; I do not see the need to receive
> real-time notification of rarely-used NAT.
> I might have totally misunderstood; I would appreciate some guidance on
> this.
>
>
> 2. [Section 3.1.2 in page 7]
>     question on disabling notifications.
>
> "A given notification can be disabled by setting the threshold to 0
> (default)" with the exception of natv2PoolThresholdUsageLow, which uses "-1"
> to disable its notification.
> Having two different values on the same kind of issues is a bit confusing to
> me.
> I wonder whether we could have any problem if we use the value "-1" for all
> the threshold values to disable notifications.
> Are there any disadvantages using "-1" instead of using the mixture of "0"
> and "-1" for the threshold values?
>
[PTT] I pondered that one myself. There may be some slight effect on 
SNMP message size when conveying this data, but probably you're right, 
we should go for uniformity.
>
> 3. [Section 3.1.4 in page 10]
>     question on Statistics.
>
> This question is related to the counters "address/port map limit drops".
> According to the draft, the counters are incremented based on the threshold
> values for address/port mapping.
> Then, I would avoid setting a value that is more than the NAT module's
> capability.
> Do we have any means to check the appropriateness of the threshold value?
> (I am not sure whether it is possible to measure NAT's processing
> capabilities in advance.)
>
[PTT] I think typically a vendor will quote capacities, and an operator 
will confirm them in the lab before putting the equipment into service.

> Thank you.
>
> Take
>
>
>
>


From nobody Mon Apr 13 12:49:42 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37A91A0385; Mon, 13 Apr 2015 12:41:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SjLGpkh_GlO; Mon, 13 Apr 2015 12:41:45 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 003BA1A014E; Mon, 13 Apr 2015 12:41:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4868; q=dns/txt; s=iport; t=1428954105; x=1430163705; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wnCLhb/Lg+6d3CysMb+Swslop0X4hxLp5rnbMzKJTvo=; b=Hbn0J4LKltGwecP5E2AoZFdAkOTnd0Ns+etSkn5OUhocK6w13NaTjcVk AgYGO0VCFLt5G2Xe6SKdPJtsks7aW0aGmgZ3EhgJOoEczl0cQJSI5O+vZ rCllvSVGuSVPj5Jbr/51xvX7JLfqO5B9wVj2Z7NXfdQYBncDSVN/L1koG 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CUBQCiGyxV/5JdJa1cgwyBLgXEKIg+AoE8TAEBAQEBAX6EIAEBBHAJEAIBCEYyJQEBBAENBYgqzUABAQEBAQEBAQEBAQEBAQEBAQEBGYsrhCRYB4QtAQSKfIN2ghqGJYNqgR2DN5AYIoF+BRyBUG+BAgEfBB5/AQEB
X-IronPort-AV: E=Sophos;i="5.11,571,1422921600"; d="scan'208";a="411576095"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-4.cisco.com with ESMTP; 13 Apr 2015 19:41:18 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t3DJfI6n012407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Apr 2015 19:41:18 GMT
Received: from xmb-rcd-x15.cisco.com ([169.254.5.170]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Mon, 13 Apr 2015 14:41:18 -0500
From: "Senthil Sivakumar (ssenthil)" 
To: Takeshi Takahashi , "draft-perrault-behave-natv2-mib.all@tools.ietf.org" 
Thread-Topic: Secdir review of draft-perrault-behave-natv2-mib-03
Thread-Index: AdB111/h0yd7zQHoRkKk9EAsY4rZpwAUs+KA
Date: Mon, 13 Apr 2015 19:41:17 +0000
Message-ID: 
References: <008201d07602$149a67e0$3dcf37a0$@nict.go.jp>
In-Reply-To: <008201d07602$149a67e0$3dcf37a0$@nict.go.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-originating-ip: [10.150.2.11]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <7693EBD47B8DA94392EC63EFDCFDD595@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-Mailman-Approved-At: Mon, 13 Apr 2015 12:49:37 -0700
Cc: "behave-chairs@tools.ietf.org" , 'The IESG' , "secdir@ietf.org" 
Subject: Re: [secdir] Secdir review of draft-perrault-behave-natv2-mib-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Apr 2015 19:41:46 -0000

Please find some answers below.

On 4/13/15, 11:54 AM, "Takeshi Takahashi" 
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.
>
>This document is ready for publication.
>
>[summary of this document]
>
>This draft defines a portion of the MIB for devices implementing the NAT
>function.
>The new MIB module defined in this document, NATv2-MIB is intended to
>replace module NAT-MIB (RFC 4008).
>The document claims that the version 2 has more focus on measurement,
>while
>the version 1 has more focus on configuration.
>This document begins with defining four types of content the NATv2-MIB
>module provides, followed by the outline of MIB module organization (OID
>map) and detailed explanation of MIB-related tables.
>
>[comment on security consideration]
>
>The biggest concern I had when reading this draft was the manipulation of
>the MIB by malicious parties.
>Access control and encryption need to be addressed.
>The current security consideration section raises adequate concerns on
>that,
>and I think the section is fine.
>
>[minor questions]
>
>Let me ask minor three questions to deepen my understanding on this draft.
>Note that these questions are purely for deepening my understanding, and I
>am not asking to change the sentences of the draft at all by these
>questions.
>
>1. [Section 3.1.2 in page 7]
>   question on natv2NotificationPoolUsageHigh and
>natv2NotificationPoolUsageLow.
>
>It is easy to imagine the use of "natv2NotificationPoolUsageHigh", but I
>am
>not sure what kind of usage we have on the
>"natv2NotificationPoolUsageLow".
>The notification indicates that "usage equals or has fallen below a lower
>threshold".
>What kind of actions are we going to take by receiving the notification?
>Are we going to aggregate two rarely-used NAT modules into one based on
>this
>notification?

The usage of natv2NotificationPoolUsageHigh is to provision more addresses
and=20
natv2NotificationPoolUsageLow is to reclaim the addresses. Usually, the
high and=20

low notifications happen at the beginning of a deployment that helps the
network=20
operators to find a happy medium. Once the network is up and running, some
strange Ddos attacks would trigger the high and a temporary provisioning
of=20
more addresses and then once the attack is identified and averted, the
addresses=20
can be reclaimed (either with a low notification or otherwise). As to what
people
do with reclaiming the addresses is hard to say. With cloud deployments,
it is=20
possible to envision a scenario to dynamically use the addresses in an
efficient way to=20
reclaim addresses and use it for other NAT instances.

>
>The NATv2-MIB provides state information, as described in Section 3.1.3.
>I assume that administrators of NAT modules monitor the state information
>periodically in order to redesign NAT modules (if needed).
>If so, I do not think administrators rely on the
>natv2NotificationPoolUsageLow notification; I do not see the need to
>receive
>real-time notification of rarely-used NAT.
>I might have totally misunderstood; I would appreciate some guidance on
>this.
>
>
>2. [Section 3.1.2 in page 7]
>   question on disabling notifications.
>
>"A given notification can be disabled by setting the threshold to 0
>(default)" with the exception of natv2PoolThresholdUsageLow, which uses
>"-1"
>to disable its notification.
>Having two different values on the same kind of issues is a bit confusing
>to
>me.
>I wonder whether we could have any problem if we use the value "-1" for
>all
>the threshold values to disable notifications.
>Are there any disadvantages using "-1" instead of using the mixture of "0"
>and "-1" for the threshold values?

I don=B9t see a disadvantage of using -1 across the board to disable
thresholds,=20
however, it is easy to understand, the value of 0 to disable the
threshold.=20
(with just one exception).

Thanks
Senthil

>
>
>3. [Section 3.1.4 in page 10]
>   question on Statistics.
>
>This question is related to the counters "address/port map limit drops".
>According to the draft, the counters are incremented based on the
>threshold
>values for address/port mapping.
>Then, I would avoid setting a value that is more than the NAT module's
>capability.
>Do we have any means to check the appropriateness of the threshold value?
>(I am not sure whether it is possible to measure NAT's processing
>capabilities in advance.)
>
>Thank you.
>
>Take
>
>
>


From nobody Mon Apr 13 13:10:25 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406E71A1BA4 for ; Mon, 13 Apr 2015 13:10:24 -0700 (PDT)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdIqvkrPuUHb for ; Mon, 13 Apr 2015 13:10:22 -0700 (PDT)
Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (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 6FCD71A1BCF for ; Mon, 13 Apr 2015 13:10:06 -0700 (PDT)
Received: by iedfl3 with SMTP id fl3so85040326ied.1 for ; Mon, 13 Apr 2015 13:10:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JunaEgw6vSLGVgaDEpxxkXeOUJb7fHn4WquPZtxy1zY=; b=Xfj2QosuGnRRIwxtAeCQSZsWZJo2Du0yj6sKBILWjgMl6hxRH5ts1lSuLAfKjN+Sze nCGSRaKPlnYE1LZsljFTmV+rbt6No8ALV8ska261IbvP07FtQ0dldZUnshCl2v93/chI 0zZrGvHRxIqrjKi5Q6s6y5cHBmfAf35wjUPutQxv2tsuOpD9ch8bSanEQSvMrSL/pNI8 HUvHvqH9k4wO8xMRXrPP00yZsp7zx3oNmgK3l4dADdPTCtwA0joOliYncdoNBUFknsZP EMXb2YKzHVWoSAB8n/XzFspZ9auAy6Hjq0aQb/SfDVrV4JgxXb4EvmDrk1ILUfmTst3R 0cPQ==
X-Gm-Message-State: ALoCoQnkj3BSE7UiK4BpueEjszu7ACsAUo19oA4/8BFaxhVljRNLnJDp9qjS3ciR/IQco3DsPxl4
X-Received: by 10.42.226.69 with SMTP id iv5mr21361355icb.58.1428955805899; Mon, 13 Apr 2015 13:10:05 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id g187sm5510119ioe.30.2015.04.13.13.10.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Apr 2015 13:10:05 -0700 (PDT)
Message-ID: <552C229C.1030701@andyet.net>
Date: Mon, 13 Apr 2015 14:10:04 -0600
From: Peter Saint-Andre - &yet 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Carl Wallace , mamille2@cisco.com, dot@dotat.at
References:  
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] FW: secdir review of draft-ietf-dane-srv-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Apr 2015 20:10:24 -0000

Hi Carl,

Thanks for your review and sorry about the trouble with the email 
aliases. (Please note that I have not checked any of the proposed text 
with my co-authors, so this is all provisional.)

On 4/13/15 11:46 AM, Carl Wallace wrote:
> My attempt at using the tools address for all document authors failed,
> hence sending it directly. Please add secdir@ietf.org and iesg@ietf.org
> back to any reply.
>
> On 4/13/15, 1:43 PM, "Carl Wallace"  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 document is basically ready. A few minor nits are below. The primary
>> comment is that there are a few instances where abbreviated certificate
>> checks are cited and potentially mask a need to do full certification
>> path
>> validation.
>>
>> Therefore this document provides guidelines that enable protocols that
>> rely on SRV lookups to locate and use TLSA records.
>>
>> In section 1
>> - May be worth adding a note to the third bullet to clarify that multiple
>> target endpoints may be defined for a given service domain, including a
>> mix of endpoints that have and do not have TLSA records.

IMHO that's implicit, but maybe it would be clearer if we say something 
like this:

OLD
    o  When DNSSEC-validated TLSA records are published for a particular
       connection endpoint, clients always use TLS when connecting (even
       if the connection endpoint supports cleartext communication).

NEW
    o  When DNSSEC-validated TLSA records are published for a particular
       connection endpoint, clients always use TLS when connecting (even
       if the connection endpoint supports cleartext communication
       or some SRV records for the service domain map to connection
       endpoints that do not support TLS).

Is that what you had in mind? Do you feel it's helpful? I'm not so sure, 
myself. Instead, I wonder if the point would be better handled by adding 
another bullet point, such as:

    o  Although in accordance with [RFC2782] a service domain can
       advertise a number of SRV records (some of which might map to
       connection endpoints that do not support TLS), the intent of this
       specification is for an endpoint to securely discover connection
       endpoints that support TLS.

Does that capture your suggestion?

>> - Should the "always use" in the third bullet be "MUST use"?

There is no normative text in the introduction. All of the normative 
rules are contained in the body of the document. I'd prefer to keep it 
that way.

>> - May be worth clarifying in the fifth bullet that no usable TLSA records
>> for one target endpoint does not mean there are no usable TLSA records
>> for
>> another target endpoint. The security considerations address this point
>> and the point in the first bullet above, but it seems worth reenforcing
>> in
>> the body as well.
>>
>> - Bullet 5 should reference RFC5280 alongside RFC6125 and/or reference
>> "non-DANE behavior" a la section 3.1 (but using the target server
>> hostname).

Probably all of the bullet points in the introduction need to say 
"usable TLSA record *for a given connection endpoint*" and then have a 
bullet point at the end that says something like this:

    o  If there are no usable TLSA records for any connection endpoint
       (and thus the client cannot securely discover a connection
       endpoint that supports TLS), the client's behavior is a matter
       for the application protocol or client implementation; this might
       involve a fallback to non-DANE behavior using the public key
       infrastructure [RFC5280].

>> In Section 4.2
>> - Should this reference RFC6698 section 2.1 or section 4? Section 4 seems
>> like a better target to me.

That does seem better.

>> - Replace reference to "expiration checks from RFC5280" with "validation
>> checks from RFC5280" unless you mean for some forms of 5280 checks to be
>> honored here. Current wording could create a misimpression that only
>> expiration checks need be performed.

Good point.

>> In section 10.2
>> - In the last sentence, clients must also validate the certificate back
>> to
>> the designated trust anchor, not just check the reference identifiers.

In RFC 6125 we had this paragraph:

    This document does not supersede the rules for certificate issuance
    or validation provided in [PKIX].  Therefore, [PKIX] is authoritative
    on any point that might also be discussed in this document.
    Furthermore, [PKIX] also governs any certificate-related topic on
    which this document is silent, including but not limited to
    certificate syntax, certificate extensions such as name constraints
    and extended key usage, and handling of certification paths.

Even though there's no reason why anyone should expect this document to 
override RFC 5280 (and Section 10.2 is about matching of subject names 
only), it can't hurt to reinforce the point...

OLD
    Otherwise, while DNSSEC provides a secure binding between the server
    name and the TLSA record, and the TLSA record provides a binding to a
    certificate, this latter step can be indirect via a chain of
    certificates.  For example, a Certificate Usage "PKIX-TA" TLSA record
    only authenticates the CA that issued the certificate, and third
    parties can obtain certificates from the same CA.  Therefore, clients
    need to check whether the server's certificate matches one of the
    expected reference identifiers to ensure that the certificate was
    issued by the CA to the server the client expects.

NEW
    Otherwise, while DNSSEC provides a secure binding between the server
    name and the TLSA record, and the TLSA record provides a binding to a
    certificate, this latter step can be indirect via a chain of
    certificates.  For example, a Certificate Usage "PKIX-TA" TLSA record
    only authenticates the CA that issued the certificate, and third
    parties can obtain certificates from the same CA.  Therefore, clients
    need to check whether the server's certificate matches one of the
    expected reference identifiers to ensure that the certificate was
    issued by the CA to the server the client expects (naturally, this
    is in addition to standard certificate-related checks as specified
    in [RFC5280], including but not limited to certificate syntax,
    certificate extensions such as name constraints and extended key
    usage, and handling of certification paths).

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Mon Apr 13 13:17:22 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6246B1A1EF3; Mon, 13 Apr 2015 13:17:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.211
X-Spam-Level: 
X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DY1Y4KHplBCa; Mon, 13 Apr 2015 13:17:10 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FDB71A1E0F; Mon, 13 Apr 2015 13:17:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7735; q=dns/txt; s=iport; t=1428956230; x=1430165830; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=aS2zPXgKZJ6T+1Hm+WJ69M0+1VvPFc4LRD+c5GZG3TU=; b=Zqs4cJLjOmG8yU4BpgYy6yankTgEHl9DkHlH+tUtO08DKCQD8DrKaMt9 hk2eHo1tSqCX34PL2lO0EG81EkyYp/7jxNuHQm6na1sdAtFeVbdLhu615 6GPHRiZxZQvTfXiCjjUdlada/Ml2eanGnAaXDjw6w6PWPzr+2mE6xrDB0 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CmBAALIyxV/4UNJK1cgwxSXAWDEMF+CYFGhgkCgT04FAEBAQEBAQF9hB8BAQEDASNVAQULCxgCAgUWCwICCQMCAQIBNQcJBgEMAQUCAQGIHgi3IZYbAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIYoKhBkKBwEGGDMHgmiBRQEEiy6JV4YWgR2DN4JEigeDTSKCAh2Bb1CBAgIHFwYcfwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,571,1422921600"; d="scan'208";a="140763572"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP; 13 Apr 2015 20:17:09 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t3DKH9Gw018833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Apr 2015 20:17:09 GMT
Received: from [10.89.9.212] (10.89.9.212) by xhc-rcd-x12.cisco.com (173.37.183.86) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 13 Apr 2015 15:17:08 -0500
Message-ID: <552C2444.1070907@cisco.com>
Date: Mon, 13 Apr 2015 14:17:08 -0600
From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Peter Saint-Andre - &yet , Carl Wallace , 
References:   <552C229C.1030701@andyet.net>
In-Reply-To: <552C229C.1030701@andyet.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.89.9.212]
Archived-At: 
Cc: The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] FW: secdir review of draft-ietf-dane-srv-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Apr 2015 20:17:13 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 4/13/15 2:10 PM, Peter Saint-Andre - &yet wrote:
> Hi Carl,
> 
> Thanks for your review and sorry about the trouble with the email 
> aliases. (Please note that I have not checked any of the proposed
> text with my co-authors, so this is all provisional.)
> 

Thanks for the review, Carl.

I agree with my co-author's response and proposed changes.


- -- 
- - m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.

> On 4/13/15 11:46 AM, Carl Wallace wrote:
>> My attempt at using the tools address for all document authors
>> failed, hence sending it directly. Please add secdir@ietf.org and
>> iesg@ietf.org back to any reply.
>> 
>> On 4/13/15, 1:43 PM, "Carl Wallace" 
>> 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 document is basically ready. A few minor nits are below.
>>> The primary comment is that there are a few instances where
>>> abbreviated certificate checks are cited and potentially mask a
>>> need to do full certification path validation.
>>> 
>>> Therefore this document provides guidelines that enable
>>> protocols that rely on SRV lookups to locate and use TLSA
>>> records.
>>> 
>>> In section 1 - May be worth adding a note to the third bullet
>>> to clarify that multiple target endpoints may be defined for a
>>> given service domain, including a mix of endpoints that have
>>> and do not have TLSA records.
> 
> IMHO that's implicit, but maybe it would be clearer if we say
> something like this:
> 
> OLD o  When DNSSEC-validated TLSA records are published for a
> particular connection endpoint, clients always use TLS when
> connecting (even if the connection endpoint supports cleartext
> communication).
> 
> NEW o  When DNSSEC-validated TLSA records are published for a
> particular connection endpoint, clients always use TLS when
> connecting (even if the connection endpoint supports cleartext
> communication or some SRV records for the service domain map to
> connection endpoints that do not support TLS).
> 
> Is that what you had in mind? Do you feel it's helpful? I'm not so
> sure, myself. Instead, I wonder if the point would be better
> handled by adding another bullet point, such as:
> 
> o  Although in accordance with [RFC2782] a service domain can 
> advertise a number of SRV records (some of which might map to 
> connection endpoints that do not support TLS), the intent of this 
> specification is for an endpoint to securely discover connection 
> endpoints that support TLS.
> 
> Does that capture your suggestion?
> 
>>> - Should the "always use" in the third bullet be "MUST use"?
> 
> There is no normative text in the introduction. All of the
> normative rules are contained in the body of the document. I'd
> prefer to keep it that way.
> 
>>> - May be worth clarifying in the fifth bullet that no usable
>>> TLSA records for one target endpoint does not mean there are no
>>> usable TLSA records for another target endpoint. The security
>>> considerations address this point and the point in the first
>>> bullet above, but it seems worth reenforcing in the body as
>>> well.
>>> 
>>> - Bullet 5 should reference RFC5280 alongside RFC6125 and/or
>>> reference "non-DANE behavior" a la section 3.1 (but using the
>>> target server hostname).
> 
> Probably all of the bullet points in the introduction need to say 
> "usable TLSA record *for a given connection endpoint*" and then
> have a bullet point at the end that says something like this:
> 
> o  If there are no usable TLSA records for any connection endpoint 
> (and thus the client cannot securely discover a connection endpoint
> that supports TLS), the client's behavior is a matter for the
> application protocol or client implementation; this might involve a
> fallback to non-DANE behavior using the public key infrastructure
> [RFC5280].
> 
>>> In Section 4.2 - Should this reference RFC6698 section 2.1 or
>>> section 4? Section 4 seems like a better target to me.
> 
> That does seem better.
> 
>>> - Replace reference to "expiration checks from RFC5280" with
>>> "validation checks from RFC5280" unless you mean for some forms
>>> of 5280 checks to be honored here. Current wording could create
>>> a misimpression that only expiration checks need be performed.
> 
> Good point.
> 
>>> In section 10.2 - In the last sentence, clients must also
>>> validate the certificate back to the designated trust anchor,
>>> not just check the reference identifiers.
> 
> In RFC 6125 we had this paragraph:
> 
> This document does not supersede the rules for certificate
> issuance or validation provided in [PKIX].  Therefore, [PKIX] is
> authoritative on any point that might also be discussed in this
> document. Furthermore, [PKIX] also governs any certificate-related
> topic on which this document is silent, including but not limited
> to certificate syntax, certificate extensions such as name
> constraints and extended key usage, and handling of certification
> paths.
> 
> Even though there's no reason why anyone should expect this
> document to override RFC 5280 (and Section 10.2 is about matching
> of subject names only), it can't hurt to reinforce the point...
> 
> OLD Otherwise, while DNSSEC provides a secure binding between the
> server name and the TLSA record, and the TLSA record provides a
> binding to a certificate, this latter step can be indirect via a
> chain of certificates.  For example, a Certificate Usage "PKIX-TA"
> TLSA record only authenticates the CA that issued the certificate,
> and third parties can obtain certificates from the same CA.
> Therefore, clients need to check whether the server's certificate
> matches one of the expected reference identifiers to ensure that
> the certificate was issued by the CA to the server the client
> expects.
> 
> NEW Otherwise, while DNSSEC provides a secure binding between the
> server name and the TLSA record, and the TLSA record provides a
> binding to a certificate, this latter step can be indirect via a
> chain of certificates.  For example, a Certificate Usage "PKIX-TA"
> TLSA record only authenticates the CA that issued the certificate,
> and third parties can obtain certificates from the same CA.
> Therefore, clients need to check whether the server's certificate
> matches one of the expected reference identifiers to ensure that
> the certificate was issued by the CA to the server the client
> expects (naturally, this is in addition to standard
> certificate-related checks as specified in [RFC5280], including but
> not limited to certificate syntax, certificate extensions such as
> name constraints and extended key usage, and handling of
> certification paths).
> 
> Peter
> 

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

iQEcBAEBCgAGBQJVLCREAAoJEDWi+S0W7cO13tAH/25IN+jxGgB4FaxKYAiXlKfL
ZwQFRz5/NV8MlW5ZByIkj0baoy9QbfJQxobUe9OR+kUT+qt9/x4v2Zmhlpz+xpKx
xiOnh8dPJGa2112Ljnyc2MlbKdB6cBMYY85dvwtaD+YYtgDK2nNFy38hrebkLu8H
kn6prwxxci8+chIo6fE5hF0c0KoEJ7Q8zCGZqwKbr6eAvgoqxfu9Ey2Wzki0jBCO
Lq5A8ltRLyl0aUVNtBY3l+M1MSkDJ6RK35xqeYPNNamLz1XUN/A4uCpRRxzjc2Is
+q+h9jr8UZPw6rX+IuoospP3zoOQoLBb0b26Pbtmgpkp66jnW4wPWKcNmr+AWLA=
=SmS2
-----END PGP SIGNATURE-----


From nobody Mon Apr 13 13:21:40 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FFE1A3BA4 for ; Mon, 13 Apr 2015 13:21:38 -0700 (PDT)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7PxTQ2E6wN6 for ; Mon, 13 Apr 2015 13:21:36 -0700 (PDT)
Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (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 875171A3BA3 for ; Mon, 13 Apr 2015 13:21:36 -0700 (PDT)
Received: by igblo3 with SMTP id lo3so56641107igb.1 for ; Mon, 13 Apr 2015 13:21:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=umBa3aIJ4UzxmuziKh48cUzXSGLk3UbQ6d/oulwcF74=; b=Ea6m/gisGviGlKMl5BVR/9FYnHkIAsnumIh3qRJE8jxnOIXvPoEzbegFDdFMVPwqaH WfCaQQiWhyqyi5NW83yDoyojsiiuw1MHGu8Rk9cUpkasTQtH2QayS5wjk+OAiBj6T/so WjV8vrcyqMDacQbBugaJDzEHjlFXKZ7AlGFZzGdW+gNxdv7lcHPLGlac1XZQNat7BtdY mFtVcbNrkjZBLb33lY24ZyOshYz8hUmFiv/V+ymskOpc6WXVKJAKDWrNl+M4nTEc6iy8 oGnGrr/hsm0HWa5A+mtcrES9g9NuOfHzFSrb1twMVxLpEN46Ugih69jPNy/aqP9vUVkw vW8w==
X-Gm-Message-State: ALoCoQmwF2TbRzh3Ewe8KdMjXsTxd6MmhnaLDl8Vgswd6JnZUbcuO3UJNJ+7bW2c5hbXLKaKGx7U
X-Received: by 10.107.157.135 with SMTP id g129mr23974787ioe.72.1428956495877;  Mon, 13 Apr 2015 13:21:35 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id r39sm5546455ioi.2.2015.04.13.13.21.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Apr 2015 13:21:35 -0700 (PDT)
Message-ID: <552C254E.4080705@andyet.net>
Date: Mon, 13 Apr 2015 14:21:34 -0600
From: Peter Saint-Andre - &yet 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Carl Wallace , mamille2@cisco.com, dot@dotat.at
References:   <552C229C.1030701@andyet.net>
In-Reply-To: <552C229C.1030701@andyet.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] FW: secdir review of draft-ietf-dane-srv-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Apr 2015 20:21:38 -0000

On 4/13/15 2:10 PM, Peter Saint-Andre - &yet wrote:

>     o  Although in accordance with [RFC2782] a service domain can
>        advertise a number of SRV records (some of which might map to
>        connection endpoints that do not support TLS), the intent of this
>        specification is for an endpoint to securely discover connection
>        endpoints that support TLS.

That should be s/endpoint/client/ in the penultimate line, i.e.,

         specification is for a client to securely discover connection
         endpoints that support TLS.

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Tue Apr 14 05:59:22 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCCC1A908B for ; Tue, 14 Apr 2015 05:59:20 -0700 (PDT)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn5PLHF-Dx8O for ; Tue, 14 Apr 2015 05:59:18 -0700 (PDT)
Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com [209.85.220.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 83D511A907C for ; Tue, 14 Apr 2015 05:59:18 -0700 (PDT)
Received: by qku63 with SMTP id 63so17545047qku.3 for ; Tue, 14 Apr 2015 05:59:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=NSX82bEdXVILF9yjVVuhGa766ylDm/6z+flh/V9F8xI=; b=X96OqArTk5nYDTTXX2zmM/OWVBbE6RB/hsZibPU7Ua/7ToWQ1vpc+AlSqmYqPdhO80 qgjNwZ/GL8y4fv+Iq5OEHHZnTe+eKJE91GvkohFUeehAuJTbF9Cb/o1SGniU3AKQzac7 4EmqAB+f+RM/hBzYNgbTzyGwMqt1IMqv5lqnTr8ALCw5VahqHWU/j0v7XZBrwsl+v3DM 3k+/UCwkgLg8k2Fs+AwpPBDrYB9TeqNGWlVAV5nHdSPz35s+veTfOkhmGErz2YscysKt /LzjWwRPVKJB1ZGA4mLq21A054b8q0wseFiuVWF/A7+IWJJpaq/n9A5p8FMVXAEietn3 +iwQ==
X-Gm-Message-State: ALoCoQn/C7TwsdIoJQ4s98sdL0mC4+VmdO5fcbUWy26syicBhg/KW3/xOhBn+xgtEqjKQlbTXiRt
X-Received: by 10.55.31.137 with SMTP id n9mr39986970qkh.91.1429016337096; Tue, 14 Apr 2015 05:58:57 -0700 (PDT)
Received: from [192.168.2.27] (pool-96-241-148-223.washdc.fios.verizon.net. [96.241.148.223]) by mx.google.com with ESMTPSA id a6sm630595qgf.17.2015.04.14.05.58.54 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 14 Apr 2015 05:58:56 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.4.7.141117
Date: Tue, 14 Apr 2015 08:58:52 -0400
From: Carl Wallace 
To: Peter Saint-Andre - &yet , , 
Message-ID: 
Thread-Topic: secdir review of draft-ietf-dane-srv-12
References:   <552C229C.1030701@andyet.net>
In-Reply-To: <552C229C.1030701@andyet.net>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: 
Cc: The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] secdir review of draft-ietf-dane-srv-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Apr 2015 12:59:20 -0000

On 4/13/15, 4:10 PM, "Peter Saint-Andre - &yet"  wrote:

>>> In section 1
>>> - May be worth adding a note to the third bullet to clarify that
>>>multiple
>>> target endpoints may be defined for a given service domain, including a
>>> mix of endpoints that have and do not have TLSA records.
>
>IMHO that's implicit, but maybe it would be clearer if we say something
>like this:
>
>OLD
>    o  When DNSSEC-validated TLSA records are published for a particular
>       connection endpoint, clients always use TLS when connecting (even
>       if the connection endpoint supports cleartext communication).
>
>NEW
>    o  When DNSSEC-validated TLSA records are published for a particular
>       connection endpoint, clients always use TLS when connecting (even
>       if the connection endpoint supports cleartext communication
>       or some SRV records for the service domain map to connection
>       endpoints that do not support TLS).

I think you are right a second bullet is better but if changing this
maybe: When DNSSEC-validated TLSA records are published for a particular
connection endpoint, clients always use TLS when connecting to that
connection endpoint even if the endpoint supports cleartext communication.

>
>Is that what you had in mind? Do you feel it's helpful? I'm not so sure,
>myself. Instead, I wonder if the point would be better handled by adding
>another bullet point, such as:
>
>    o  Although in accordance with [RFC2782] a service domain can
>       advertise a number of SRV records (some of which might map to
>       connection endpoints that do not support TLS), the intent of this
>       specification is for an endpoint to securely discover connection
>       endpoints that support TLS.
>
>Does that capture your suggestion?

Mostly, though I was thinking of endpoints that supported TLS but did not
publish TLSA. The new bullet seems a little out of sync with the security
considerations w.r.t. the intent of the spec, which claims no special
effort is made to accommodate mixed results. Maybe: In accordance with
[RFC2782] a service domain can advertise a number of SRV records (some of
which might map to connection endpoints that do not support TLS or that
support TLS but do not publish TLSA records), this specification enables
clients to securely authenticate connection endpoints that support TLS and
publish TLSA records.

>
>>> - Should the "always use" in the third bullet be "MUST use"?
>
>There is no normative text in the introduction. All of the normative
>rules are contained in the body of the document. I'd prefer to keep it
>that way.

Right. That makes sense. I forgot that was introductory text.


>
>>> In section 10.2
>>> - In the last sentence, clients must also validate the certificate back
>>> to
>>> the designated trust anchor, not just check the reference identifiers.
>
>In RFC 6125 we had this paragraph:
>
>    This document does not supersede the rules for certificate issuance
>    or validation provided in [PKIX].  Therefore, [PKIX] is authoritative
>    on any point that might also be discussed in this document.
>    Furthermore, [PKIX] also governs any certificate-related topic on
>    which this document is silent, including but not limited to
>    certificate syntax, certificate extensions such as name constraints
>    and extended key usage, and handling of certification paths.
>
>Even though there's no reason why anyone should expect this document to
>override RFC 5280 (and Section 10.2 is about matching of subject names
>only), it can't hurt to reinforce the point...
>
>OLD
>    Otherwise, while DNSSEC provides a secure binding between the server
>    name and the TLSA record, and the TLSA record provides a binding to a
>    certificate, this latter step can be indirect via a chain of
>    certificates.  For example, a Certificate Usage "PKIX-TA" TLSA record
>    only authenticates the CA that issued the certificate, and third
>    parties can obtain certificates from the same CA.  Therefore, clients
>    need to check whether the server's certificate matches one of the
>    expected reference identifiers to ensure that the certificate was
>    issued by the CA to the server the client expects.
>
>NEW
>    Otherwise, while DNSSEC provides a secure binding between the server
>    name and the TLSA record, and the TLSA record provides a binding to a
>    certificate, this latter step can be indirect via a chain of
>    certificates.  For example, a Certificate Usage "PKIX-TA" TLSA record
>    only authenticates the CA that issued the certificate, and third
>    parties can obtain certificates from the same CA.  Therefore, clients
>    need to check whether the server's certificate matches one of the
>    expected reference identifiers to ensure that the certificate was
>    issued by the CA to the server the client expects (naturally, this
>    is in addition to standard certificate-related checks as specified
>    in [RFC5280], including but not limited to certificate syntax,
>    certificate extensions such as name constraints and extended key
>    usage, and handling of certification paths).

Seems fine.



From nobody Tue Apr 14 10:02:17 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9931B2EE9 for ; Tue, 14 Apr 2015 10:02:16 -0700 (PDT)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZSUs6ztPkLH for ; Tue, 14 Apr 2015 10:02:15 -0700 (PDT)
Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5301B2F36 for ; Tue, 14 Apr 2015 10:02:12 -0700 (PDT)
Received: by iedfl3 with SMTP id fl3so22753354ied.1 for ; Tue, 14 Apr 2015 10:02:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TGWsB3s020s9RPatNjN8wB8kQVqhhoswFRsJKfv9964=; b=RTaV49NlwGFDtEpeynEwEtg8abmbm9wnkVLpfs8GIzJquEnd5yEkboivL4I01NUepJ H8h0qe7BddK5+SppmJtnHIuaVY+FXg3hdQIk3bV5KJ4231PPgqzHgIvvvXE294uyrAMe VZ/XzIRzc+uIc+dGgrWW1VMQHxIANQRkRd19gvnVvuS99UW1hQ2wXJ/upnH0Bjgn7kQT m/qnZEJdk5UuZDtabRn96PSbkfHCuOCxWuvsadkjS4WBemm44l0F4/+gIXyY0OEiHJzB RznO3Ah1py71GnKat85ebvVSQWJN0Qk375d+lgieY1d3o4+pjr8N+fcUb5d6YeZoL4/R 15yQ==
X-Gm-Message-State: ALoCoQmvPPH7ZkESLe4vzq4EK1oEKFwhQPEmSnDvdxZGwOXaJoYVxog7QtJ44hWXGdxB4g4Ijgpq
X-Received: by 10.50.143.42 with SMTP id sb10mr25429834igb.49.1429030931433; Tue, 14 Apr 2015 10:02:11 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id l128sm780371iol.1.2015.04.14.10.02.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 10:02:10 -0700 (PDT)
Message-ID: <552D4811.7010507@andyet.net>
Date: Tue, 14 Apr 2015 11:02:09 -0600
From: Peter Saint-Andre - &yet 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Carl Wallace , mamille2@cisco.com, dot@dotat.at
References:   <552C229C.1030701@andyet.net> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] secdir review of draft-ietf-dane-srv-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Apr 2015 17:02:16 -0000

On 4/14/15 6:58 AM, Carl Wallace wrote:
>
>
> On 4/13/15, 4:10 PM, "Peter Saint-Andre - &yet"  wrote:
> 
>>>> In section 1
>>>> - May be worth adding a note to the third bullet to clarify that
>>>> multiple
>>>> target endpoints may be defined for a given service domain, including a
>>>> mix of endpoints that have and do not have TLSA records.
>>
>> IMHO that's implicit, but maybe it would be clearer if we say something
>> like this:
>>
>> OLD
>>     o  When DNSSEC-validated TLSA records are published for a particular
>>        connection endpoint, clients always use TLS when connecting (even
>>        if the connection endpoint supports cleartext communication).
>>
>> NEW
>>     o  When DNSSEC-validated TLSA records are published for a particular
>>        connection endpoint, clients always use TLS when connecting (even
>>        if the connection endpoint supports cleartext communication
>>        or some SRV records for the service domain map to connection
>>        endpoints that do not support TLS).
>
> I think you are right a second bullet is better but if changing this
> maybe: When DNSSEC-validated TLSA records are published for a particular
> connection endpoint, clients always use TLS when connecting to that
> connection endpoint even if the endpoint supports cleartext communication.
>
>>
>> Is that what you had in mind? Do you feel it's helpful? I'm not so sure,
>> myself. Instead, I wonder if the point would be better handled by adding
>> another bullet point, such as:
>>
>>     o  Although in accordance with [RFC2782] a service domain can
>>        advertise a number of SRV records (some of which might map to
>>        connection endpoints that do not support TLS), the intent of this
>>        specification is for an endpoint to securely discover connection
>>        endpoints that support TLS.
>>
>> Does that capture your suggestion?
>
> Mostly, though I was thinking of endpoints that supported TLS but did not
> publish TLSA.

Ah, thanks for the clarification - I had not understood your concern.

> The new bullet seems a little out of sync with the security
> considerations w.r.t. the intent of the spec, which claims no special
> effort is made to accommodate mixed results.

As I see it, the purpose of this spec is to document how SRV and TLSA 
records interact with the intent that a client can securely discover at 
least one connection endpoint that supports TLS, and then establish a 
TLS-protected connection to the service domain at that endpoint.

Although that is the focus here, of course we don't want to degrade 
security in any way, so it's important to mention appropriate caveats.

> Maybe: In accordance with
> [RFC2782] a service domain can advertise a number of SRV records (some of
> which might map to connection endpoints that do not support TLS or that
> support TLS but do not publish TLSA records), this specification enables
> clients to securely authenticate connection endpoints that support TLS and
> publish TLSA records.

Strictly speaking, a connection endpoint does not publish TLSA records, 
since that's the responsibility of the service domain.

     o  In accordance with [RFC2782] a service domain can advertise a
        variety of SRV records; some of these might map to connection
        endpoints that do not support TLS, and others might map to
        connection endpoints that support TLS but for which no TLSA
        records are available. This specification makes no special
        effort to accommodate such mixed results, since it is focused on
        enabling a client to securely discover at least one connection
        endpoint that supports TLS and then to establish a TLS-protected
        connection to the service domain.

Somehow that feels awfully wordy for an informational summary, but if it 
is accurate and causes no harm then we might as well include it...

Peter



From nobody Wed Apr 15 22:53:27 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265191A90D8; Wed, 15 Apr 2015 22:53:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7FTWLGZo4TE; Wed, 15 Apr 2015 22:53:20 -0700 (PDT)
Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368391A90D4; Wed, 15 Apr 2015 22:53:20 -0700 (PDT)
Received: by lagv1 with SMTP id v1so48765823lag.3; Wed, 15 Apr 2015 22:53:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=VL8OdO5aAqgq0ETCKr15cuNppSszaeCLT7Sp3jN/USg=; b=fUqQQHPZWcAHS70CYm5t34CAPYqOSDJ+i1UIi50P6FNDhfgBga+z5eOwL9v6ADY9Fn y6Z5tMnKxodZr9pfu96n+GQm+cQ4zaDJ0/61CLXqy60iTW9v+6UUMLJpS+U0j7kSwRe5 2AvDN7zxPZdGmszUJjhmLMAD19pvGTBevPgbhBHJfwY13HUrPLAM8ND0mtKULofQnNZV 521YSLB9mCfSXv/wVFbTM9mvluEGMsYEGGMTId7Z6UIhiaTxbqPvxZd88Qpq0W9rlGBf Jkk9JmgFEbGYJFyU33bwlYAjc4tL652opGuMF41iPaVz0XXqTWDKMua5iiPa1Yemwo19 Q5AQ==
MIME-Version: 1.0
X-Received: by 10.152.27.194 with SMTP id v2mr26562091lag.75.1429163598763; Wed, 15 Apr 2015 22:53:18 -0700 (PDT)
Received: by 10.112.133.68 with HTTP; Wed, 15 Apr 2015 22:53:18 -0700 (PDT)
Date: Wed, 15 Apr 2015 22:53:18 -0700
Message-ID: 
From: Radia Perlman 
To: "secdir@ietf.org" , The IESG ,  draft-ietf-tls-session-hash.all@tools.ietf.org
Content-Type: multipart/alternative; boundary=089e0158c2aca15e810513d1141d
Archived-At: 
Subject: [secdir] Secdir review of draft-ietf-tls-session-hash-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Apr 2015 05:53:23 -0000

--089e0158c2aca15e810513d1141d
Content-Type: text/plain; charset=UTF-8

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 proposes an extension and a small computation change to TLS to
mitigate the "triple handshake" (and perhaps other related
yet-to-be-discovered) vulnerabilities in TLS. For details of the attack,
see: Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, A., and P.
Strub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing
Authentication over TLS", IEEE Symposium on Security and Privacy
(Oakland'14) , 2014.

In my judgement, the proposed change does a fine job of addressing the
vulnerability. I assume this has gotten lots of other eyes as well.

I hope that someone has tested the major server implementations of TLS to
assure that they follow the spec and will ignore the new unrecognized
extension if a client presents it. The TLS spec clearly says that they MUST
do so, but there has been a history of hacks done by implementers to get
around bugs in legacy implementations. If there are a significant number of
implementations that get this wrong, it would be worth considering
implementing the extension in some different way (e.g. as an additional
proposed cipher-suite).

This vulnerability is subtle and would not affect the security of most uses
of TLS, though evaluating whether it does or does not in any particular case
is difficult so it makes sense to implement this change universally over
time. This spec, however, takes a hard line in the trade-off between
security and interoperability that I believe needs to be carefully
considered. In particular, I believe lots of implementers will *not* follow
this spec in implementing the feature in order to get greater
interoperability with deployed systems.

In particular, section 5.2 paragraph 4 & 5 say:

"If the server receives a ClientHello without the extension, it SHOULD abort
the handshake. If it chooses to continue, then it MUST NOT include the
extension in the ServerHello."

"If a client receives a ServerHello without the extension, it SHOULD abort
the handshake."

Implementations that follow these SHOULDs will not interoperate with any
existing implementation of TLS, making a phased deployment of the new
software impossible. I believe it would be preferable to say that
implementations of TLS SHOULD be configurable to reject peers that do not
implement the extension so that improved security at the expense of
interoperability can be enabled after a critical mass of deployments exist.

In section 5.3, there is similar language to disable session resumption when
the extension is not present. While this may be more acceptable because it
will not break interoperability, it *will* cause a significant performance
degradation in some important scenarios. I would again recommend that it be
a configuration parameter so that no one will refuse to deploy this change
because of performance concerns.

Section 5.4 also mandates breaking behavior (and here it is a MUST) in
scenarios where there is most likely to be a triple handshake vulnerability.
Given that there are cases with no such vulnerability and given that people
will be reluctant to deploy software that turns a subtle security
vulnerability into non-interoperability, I believe this should be a matter
of configuration.

Section 5.4 paragraph 4 seems to be undermining earlier requirements, saying
that it MAY be safe (to break rules stated earlier). Taking this to heart, I
would propose that the "MUST abort" clauses in sections 5.2 and 5.3 be
softened to at least allow - and perhaps recommend - implementations to
support this scenario.

-------

Nits:

In section 6.2, it is claimed that the security of TLS depends on the hash
function used being collision resistant, use of MD5 and SHA1 is NOT
RECOMMENDED. That would rule out use of TLS 1.0 and TLS 1.1. While a worthy
goal, I don't believe this enhancement makes migration away from TLS 1.0 and
TLS 1.1 any more urgent. I also don't believe that TLS depends on the hash
function being collision resistant (but only that it is second preimage
resistant).

P9: "each other identity" -> "each other's identities"
P10: "that where hence" -> "that were hence"
P11: "server/ Hence," -> "server. Hence,

--089e0158c2aca15e810513d1141d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I have review=
ed this document as part of the security directorate's ongoingeffort to review all IETF documents being processed by the IESG.=
 These
comments were written primarily for the benefit o=
f the security area
directors. Document editors and WG c=
hairs should treat these comments just
like any other la=
st call comments.

This document proposes an extension and a small computation change to =
TLS to
mitigate the "triple handshake" (and pe=
rhaps other related
yet-to-be-discovered) vulnerabilitie=
s in TLS. For details of the attack,
see: Bhargavan, K.,=
 Delignat-Lavaud, A., Fournet, C., Pironti, A., and P.
S=
trub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing
Authentication over TLS", IEEE Symposium on Security and=
 Privacy
(Oakland'14) , 2014.

In my judgement, the proposed chang=
e does a fine job of addressing the
vulnerability. I ass=
ume this has gotten lots of other eyes as well.

I hope that someone has tested the major=
 server implementations of TLS to
assure that they follo=
w the spec and will ignore the new unrecognized
extensio=
n if a client presents it. The TLS spec clearly says that they MUST<=
br style=3D"font-size:12.8000001907349px">do so, but there has been a history of hacks done by implemente=
rs to get
around bugs in legacy implementations. If ther=
e are a significant number of
implementations that get t=
his wrong, it would be worth considering
implementing th=
e extension in some different way (e.g. as an additional
proposed cipher-suite).
<=
br style=3D"font-size:12.8000001907349px">This vulnerability is subtle and would not affect the security =
of most uses
of TLS, though evaluating whether it does=
 or does not in any particular case
is difficult so it m=
akes sense to implement this change universally over
tim=
e. This spec, however, takes a hard line in the trade-off betweensecurity and interoperability that I believe needs to be carefull=
y
considered. In particular, I believe lots of implement=
ers will *not* follow
this spec in implementing the feat=
ure in order to get greater
interoperability with deploy=
ed systems.

I=
n particular, section 5.2 paragraph 4 & 5 say:

"If the server receives a Client=
Hello without the extension, it SHOULD abort
the handsha=
ke. If it chooses to continue, then it MUST NOT include the
extension in the ServerHello."

"If a client receives a ServerHello without=
 the extension, it SHOULD abort
the handshake."

Implementations =
that follow these SHOULDs will not interoperate with any
existing implementation of TLS, making a phased deployment of the new
software impossible. I believe it would be preferable to say=
 that
implementations of TLS SHOULD be configurable to r=
eject peers that do not
implement the extension so that =
improved security at the expense of
interoperability can=
 be enabled after a critical mass of deployments exist.

In section 5.3, there is similar=
 language to disable session resumption when
the extensi=
on is not present. While this may be more acceptable because it
will not break interoperability, it *will* cause a significant perf=
ormance
degradation in some important scenarios. I would=
 again recommend that it be
a configuration parameter so=
 that no one will refuse to deploy this change
because o=
f performance concerns.
Section 5.4 also mandates breaking behavior (and here it is a MU=
ST) in
scenarios where there is most likely to be a trip=
le handshake vulnerability.
Given that there are cases w=
ith no such vulnerability and given that people
will be =
reluctant to deploy software that turns a subtle security
vulnerability into non-interoperability, I believe this should be a mat=
ter
of configuration.

Section 5.4 paragraph 4 seems to be undermining=
 earlier requirements, saying
that it MAY be safe (to br=
eak rules stated earlier). Taking this to heart, I
would=
 propose that the "MUST abort" clauses in sections 5.2 and 5.3 be=

softened to at least allow - and perhaps recommend - im=
plementations to
support this scenario.

-------

Nits:

In section 6.2, it is claimed that the s=
ecurity of TLS depends on the hash
function used being c=
ollision resistant, use of MD5 and SHA1 is NOT
RECOMMEND=
ED. That would rule out use of TLS 1.0 and TLS 1.1. While a worthygoal, I don't believe this enhancement makes migration away =
from TLS 1.0 and
TLS 1.1 any more urgent. I also don'=
;t believe that TLS depends on the hash
function being c=
ollision resistant (but only that it is second preimage
=
resistant).

P=
9: "each other identity" -> "each other's identities&=
quot;
P10: "that where hence" -> "that=
 were hence"
P11: "server/ Hence," -> =
"server. Hence,


--089e0158c2aca15e810513d1141d--


From nobody Thu Apr 16 02:19:46 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02901B2AF2; Thu, 16 Apr 2015 00:07:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STCq-k1tZiTH; Thu, 16 Apr 2015 00:06:58 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D096B1B2AF7; Thu, 16 Apr 2015 00:06:54 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.11,586,1422918000"; d="scan'208";a="111699762"
Received: from 166.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.166]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 16 Apr 2015 09:06:43 +0200
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Karthikeyan Bhargavan 
In-Reply-To: 
Date: Thu, 16 Apr 2015 09:06:42 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Radia Perlman 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
X-Mailman-Approved-At: Thu, 16 Apr 2015 02:19:44 -0700
Cc: draft-ietf-tls-session-hash.all@tools.ietf.org, The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] Secdir review of draft-ietf-tls-session-hash-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Apr 2015 07:07:01 -0000

Hi Radia,

Thanks for the comments. I made many of the smaller changes, and have =
some
questions about the interop concerns.

> In particular, section 5.2 paragraph 4 & 5 say:
>=20
> "If the server receives a ClientHello without the extension, it SHOULD =
abort
> the handshake. If it chooses to continue, then it MUST NOT include the
> extension in the ServerHello."
>=20
> "If a client receives a ServerHello without the extension, it SHOULD =
abort
> the handshake.=94

The style we chose was to say that the client/server SHOULD abort the =
handshake,
but we also say in paragraph 7:=20

"If the client or server choose to continue a full handshake without the =
extension, they use the legacy master secret derivation for the new =
session. In this case, the considerations in section 5.4 apply.=94

That is, we do offer them the choice of opting out of this draft for =
interoperability, by following
the recommendations in 5.4.

We could make this forward pointer more explicit by saying instead:

=93In order to interoperate with legacy peers, some lients and servers =
may choose to=20
 to continue a full handshake without the extension. In this case, they =
use
 the  legacy master secret derivation for the new session, and the=20
 considerations in section 5.4 apply.=94

Would this assuage the security/interoperability concern?


> In section 5.3, there is similar language to disable session =
resumption when
> the extension is not present. While this may be more acceptable =
because it
> will not break interoperability, it *will* cause a significant =
performance
> degradation in some important scenarios. I would again recommend that =
it be
> a configuration parameter so that no one will refuse to deploy this =
change
> because of performance concerns.

During resumption we use similar language to point forward to section =
5.2
if the client or server chooses to continue without the extension.

> Section 5.4 also mandates breaking behavior (and here it is a MUST) in
> scenarios where there is most likely to be a triple handshake =
vulnerability.
> Given that there are cases with no such vulnerability and given that =
people
> will be reluctant to deploy software that turns a subtle security
> vulnerability into non-interoperability, I believe this should be a =
matter
> of configuration.

This case seems most difficult, because section 5.4 is the defense of=20
last resort. Weakening the MUST requirements here would, in our mind,
be tantamount to disabling the extension altogether.=20

Recall that in  the triple handshake attack, the man-in-the-middle is a =
valid peer
who is trying to fool both the client and the server. Hence, we cannot
rely on this man-in-the-middle sending the extension. If we allow
handshakes without the extension, the attack cannot be prevented, only =
mitigated.
The MUSTs in this section try to enforce these mitigations.

Best regards,
Karthik


>=20
> Section 5.4 paragraph 4 seems to be undermining earlier requirements, =
saying
> that it MAY be safe (to break rules stated earlier). Taking this to =
heart, I
> would propose that the "MUST abort" clauses in sections 5.2 and 5.3 be
> softened to at least allow - and perhaps recommend - implementations =
to
> support this scenario.
>=20
> -------
>=20
> Nits:
>=20
> In section 6.2, it is claimed that the security of TLS depends on the =
hash
> function used being collision resistant, use of MD5 and SHA1 is NOT
> RECOMMENDED. That would rule out use of TLS 1.0 and TLS 1.1. While a =
worthy
> goal, I don't believe this enhancement makes migration away from TLS =
1.0 and
> TLS 1.1 any more urgent. I also don't believe that TLS depends on the =
hash
> function being collision resistant (but only that it is second =
preimage
> resistant).
>=20
> P9: "each other identity" -> "each other's identities"
> P10: "that where hence" -> "that were hence"
> P11: "server/ Hence," -> "server. Hence,


From nobody Thu Apr 16 03:55:39 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F2B1A016C for ; Thu, 16 Apr 2015 03:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Level: 
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6HlDE5E22ms for ; Thu, 16 Apr 2015 03:55:35 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450361A0161 for ; Thu, 16 Apr 2015 03:55:35 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t3GAtUR2005205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 16 Apr 2015 13:55:30 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t3GAtUos026308; Thu, 16 Apr 2015 13:55:30 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21807.38177.837423.510312@fireball.kivinen.iki.fi>
Date: Thu, 16 Apr 2015 13:55:29 +0300
From: Tero Kivinen 
To: secdir@ietf.org
X-Edit-Time: 1 min
X-Total-Time: 1 min
Archived-At: 
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Apr 2015 10:55:37 -0000

Review instructions and related resources are at:
http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

Shaun Cooley is next in the rotation.

For special review for changes happened after telechat:

Reviewer                 LC end     Draft
Paul Wouters             2015-02-13 draft-ietf-idr-as-migration-04

Last calls and special requests:

Derek Atkins             2015-04-28 draft-ietf-precis-saslprepbis-15
John Bradley             2015-05-13 draft-jimenez-p2psip-coap-reload-08
Dan Harkins              2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14
Eric Osterweil           2015-04-29 draft-perrault-behave-deprecate-nat-mib-v1-01
Vincent Roca             2015-04-24 draft-hansen-scram-sha256-02
Joe Salowey              2015-04-16 draft-ietf-nfsv4-layout-types-03
Zach Shelby              2014-06-06 draft-housley-implementer-obligations-02
Tina TSOU                2015-05-05 draft-hallambaker-tlsfeature-09
Sean Turner              2015-04-20 draft-ietf-bmwg-traffic-management-04
David Waltermire         2015-04-20 draft-ietf-opsawg-hmac-sha-2-usm-snmp-05
Sam Weiler               2015-04-20 draft-ietf-scim-api-16
Brian Weis               2015-04-20 draft-ietf-scim-core-schema-17
Klaas Wierenga           2015-04-17 draft-ietf-tls-negotiated-ff-dhe-08
Paul Wouters             2015-04-20 draft-ietf-v6ops-cidr-prefix-01
Tom Yu                   2015-04-23 draft-ietf-intarea-gre-mtu-02
Dacheng Zhang            2015-04-28 draft-ietf-lisp-eid-block-mgmnt-04
-- 
kivinen@iki.fi


From nobody Thu Apr 16 08:34:54 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDF31A89BB; Thu, 16 Apr 2015 08:34:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awslpiJT2uO1; Thu, 16 Apr 2015 08:34:08 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE5C1A8A3A; Thu, 16 Apr 2015 08:33:10 -0700 (PDT)
Received: by wgin8 with SMTP id n8so84860568wgi.0; Thu, 16 Apr 2015 08:33:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=t5mvbI2/US9Pkr8lrV7I4jj+eqnwmUjFhRoS9aCD000=; b=hkNsITo8FpupbWJVCNE/H6NEZwNMseiAAgfeAidHqe6Av0A/TBNUCpNAvYaNRoVeV6 Jvv+nMeC2u+V2umgPpj0rXkMV5j7owytJGP60tOM3A9TN8U/63m5rbXuVWAaDMI/WINf xRnbiv+G85DNepPPYBOIqIIvVz1iNOJuPsxNcBUMCL44fxTyzaUstrn6kwyHxmYhaqmQ WQzaD8eqdqB3HH8ZLs7FGo/k57AbqJs23kpaFHhGcZ5B7ArllHN4JJksSmqUW7dUWj23 M4vsIGWW6iG7GqtrhJFhj+S4mGdGhkxxwaMcxTORFDRNcFJoZHfs/ZcPxtMLuGpWd4HN yqkQ==
MIME-Version: 1.0
X-Received: by 10.194.9.98 with SMTP id y2mr62745068wja.85.1429198389460; Thu, 16 Apr 2015 08:33:09 -0700 (PDT)
Received: by 10.194.136.233 with HTTP; Thu, 16 Apr 2015 08:33:09 -0700 (PDT)
In-Reply-To: 
References:  
Date: Thu, 16 Apr 2015 08:33:09 -0700
Message-ID: 
From: Watson Ladd 
To: Karthikeyan Bhargavan 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-Mailman-Approved-At: Thu, 16 Apr 2015 08:34:44 -0700
Cc: "secdir@ietf.org" , draft-ietf-tls-session-hash.all@tools.ietf.org, The IESG 
Subject: Re: [secdir] [TLS] Secdir review of draft-ietf-tls-session-hash-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Apr 2015 15:34:10 -0000

On Thu, Apr 16, 2015 at 12:06 AM, Karthikeyan Bhargavan
 wrote:
> Hi Radia,
>
> Thanks for the comments. I made many of the smaller changes, and have som=
e
> questions about the interop concerns.
>
>> In particular, section 5.2 paragraph 4 & 5 say:
>>
>> "If the server receives a ClientHello without the extension, it SHOULD a=
bort
>> the handshake. If it chooses to continue, then it MUST NOT include the
>> extension in the ServerHello."
>>
>> "If a client receives a ServerHello without the extension, it SHOULD abo=
rt
>> the handshake.=E2=80=9D
>
> The style we chose was to say that the client/server SHOULD abort the han=
dshake,
> but we also say in paragraph 7:
>
> "If the client or server choose to continue a full handshake without the =
extension, they use the legacy master secret derivation for the new session=
. In this case, the considerations in section 5.4 apply.=E2=80=9D
>
> That is, we do offer them the choice of opting out of this draft for inte=
roperability, by following
> the recommendations in 5.4.
>
> We could make this forward pointer more explicit by saying instead:
>
> =E2=80=9CIn order to interoperate with legacy peers, some lients and serv=
ers may choose to
>  to continue a full handshake without the extension. In this case, they u=
se
>  the  legacy master secret derivation for the new session, and the
>  considerations in section 5.4 apply.=E2=80=9D
>
> Would this assuage the security/interoperability concern?
>
>
>> In section 5.3, there is similar language to disable session resumption =
when
>> the extension is not present. While this may be more acceptable because =
it
>> will not break interoperability, it *will* cause a significant performan=
ce
>> degradation in some important scenarios. I would again recommend that it=
 be
>> a configuration parameter so that no one will refuse to deploy this chan=
ge
>> because of performance concerns.

I seem to recall a discussion about this, where my minority position
was that breaking renegotiation instead was more acceptable. We need
to break one, and renegotiation is not used nearly as commonly for
browsers.

>
> During resumption we use similar language to point forward to section 5.2
> if the client or server chooses to continue without the extension.
>
>> Section 5.4 also mandates breaking behavior (and here it is a MUST) in
>> scenarios where there is most likely to be a triple handshake vulnerabil=
ity.
>> Given that there are cases with no such vulnerability and given that peo=
ple
>> will be reluctant to deploy software that turns a subtle security
>> vulnerability into non-interoperability, I believe this should be a matt=
er
>> of configuration.
>
> This case seems most difficult, because section 5.4 is the defense of
> last resort. Weakening the MUST requirements here would, in our mind,
> be tantamount to disabling the extension altogether.

Web browsers have adopted a more minimal solution, namely not
permitting renegotiation to change certificates. I doubt that the
stricter defense in 5.4 will cause interoperability issues, and it may
have been adopted by some of them. Input from browser writers would be
greatly appreciated.

Sincerely,
Watson Ladd

>
> Recall that in  the triple handshake attack, the man-in-the-middle is a v=
alid peer
> who is trying to fool both the client and the server. Hence, we cannot
> rely on this man-in-the-middle sending the extension. If we allow
> handshakes without the extension, the attack cannot be prevented, only mi=
tigated.
> The MUSTs in this section try to enforce these mitigations.
>
> Best regards,
> Karthik
>
>
>>
>> Section 5.4 paragraph 4 seems to be undermining earlier requirements, sa=
ying
>> that it MAY be safe (to break rules stated earlier). Taking this to hear=
t, I
>> would propose that the "MUST abort" clauses in sections 5.2 and 5.3 be
>> softened to at least allow - and perhaps recommend - implementations to
>> support this scenario.
>>
>> -------
>>
>> Nits:
>>
>> In section 6.2, it is claimed that the security of TLS depends on the ha=
sh
>> function used being collision resistant, use of MD5 and SHA1 is NOT
>> RECOMMENDED. That would rule out use of TLS 1.0 and TLS 1.1. While a wor=
thy
>> goal, I don't believe this enhancement makes migration away from TLS 1.0=
 and
>> TLS 1.1 any more urgent. I also don't believe that TLS depends on the ha=
sh
>> function being collision resistant (but only that it is second preimage
>> resistant).
>>
>> P9: "each other identity" -> "each other's identities"
>> P10: "that where hence" -> "that were hence"
>> P11: "server/ Hence," -> "server. Hence,
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



--=20
"Man is born free, but everywhere he is in chains".
--Rousseau.


From nobody Thu Apr 16 16:31:38 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8591A8739 for ; Thu, 16 Apr 2015 16:31:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.578
X-Spam-Level: 
X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3Kg2CeJiZNh for ; Thu, 16 Apr 2015 16:31:33 -0700 (PDT)
Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com [209.85.220.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955681A8734 for ; Thu, 16 Apr 2015 16:31:33 -0700 (PDT)
Received: by qkhg7 with SMTP id g7so143083609qkh.2 for ; Thu, 16 Apr 2015 16:31:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=f6Jb0tP4RxdsFzB1wiWmvOhxNHRlMj10464r0yiS+Aw=; b=Li1TQmYUqMrWFfwAdL385b8PYrlMrZKzvfCN6G5QaSZYu7AW8XWJBeH/oLIhi8NBy5 wKxhAC2rhftNRfutsgMqGmNcHawRz99H20cW50zO6xR/YvGkxxEbdS9I9kGcZEt68T2+ X/hdPFsJ+nV89FpsmZ1VRFub+rgiKlPBqgP5oH+x8GL6V+RK7uPE+MYnHJsOncRYhfUi XkoM96VU+NXsSoY8ziYRoG7j2TK5SSNExlykmCstAtE2TpW5wfpcVwmq9NQz7V/F/KQ5 Lb1/9S+W5+kv8BV7QSsHFmaxT3ap9kuG3kjnc2MCMBf0tePNo363vgaqjDzhSLJHcPsH 1XNg==
X-Gm-Message-State: ALoCoQmJ7gLDd4xc2fIjlPnIKfDliQis76HriR3Or/w6I94PnlEAfBz8NA0XeVX+oBeX5LE3I+sX
MIME-Version: 1.0
X-Received: by 10.229.175.131 with SMTP id ba3mr294542qcb.3.1429227092889; Thu, 16 Apr 2015 16:31:32 -0700 (PDT)
Received: by 10.96.121.104 with HTTP; Thu, 16 Apr 2015 16:31:32 -0700 (PDT)
X-Originating-IP: [67.168.161.122]
Date: Thu, 16 Apr 2015 16:31:32 -0700
Message-ID: 
From: Joseph Salowey 
To: secdir , The IESG ,  draft-ietf-nfsv4-layout-types.all@tools.ietf.org
Content-Type: multipart/alternative; boundary=001a11c2875a2cecde0513dfdd04
Archived-At: 
Subject: [secdir] Sector review of draft-ietf-nfsv4-layout-types-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Apr 2015 23:31:35 -0000

--001a11c2875a2cecde0513dfdd04
Content-Type: text/plain; charset=UTF-8

Do not be alarmed, this document review is part of the security
directorate's ongoing effort to review all IETF documents being processed
by the IESG.  These comments were written for the benefit of the document
editors, WG chairs and the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

I believe this document is ready with issues.

The document discusses security requirements for pNFS layout types.  The
document has significant discussions of security considerations, however
I'm not sure its complete and I think it could be better organized.  The
main places that need work are the security considerations section and the
protocol requirements section.

I'm not sure how best to break up the information between the security
considerations and the rest of the document, but here are some suggestions.


Security considerations - Different Layout types have significantly
different security properties.  I think this should be emphasized in the
security considerations section:

"Different layout types have significantly different security properties
which need to be considered during their design and deployment.  For
example, some layouts, such as the block layout type, can only enforce
minimal security controls and require the client to be trusted to enforce
additional access controls. "

The current security considerations section discusses fencing
requirements.  Are there additional security considerations around the
control protocol used to revoke access at the storage device?  It would
seem that the integrity and availability of this channel is important.
Possibly the confidentiality of the channel is important as well.

It would probably be a good idea to discuss the security requirements of
the storage protocol as well.

It would probably be a good idea to reference section 12.9 and 13.12 of RFC
5661.

Are there cases where any contextual information needs to be communicated
over the control channel (access control information perhaps)?

This document does not include privacy considerations, but neither does RFC
5661, so I'm not sure it would be in scope.

I'm new to NFSv4 and pNFS so if some of this isn't clear let me know and I
can try to clarify.

Cheers,

Joe

--001a11c2875a2cecde0513dfdd04
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Do not be alarmed, this document review is part of the=C2=
=A0security directorate's=C2=A0on=
going effort to review all IETF documents being processed by the IESG.=C2=
=A0 These comments were written for the benefit of the document editors, WG=
 chairs and the security area directors.=C2=A0 Document editors and WG chai=
rs=C2=A0should treat these comments just like any other last call comments.

I believe this document is ready with issues. =C2=A0<=
/div>

The=C2=A0doc=
ument discusses security requirements for pNFS layout types.=C2=A0 The docu=
ment has significant discussions of security considerations, however I'=
m not sure its complete and I think it could be better organized.=C2=A0 The=
 main places that need work are the security considerations section and the=
 protocol requirements section. =C2=A0

I'm not=
 sure how best to break up the information between the security considerati=
ons and the rest of the document, but here are some suggestions. =C2=A0

Security considerations - Different Layout types have=
 significantly different security properties.=C2=A0 I think this should be =
emphasized in the security considerations section:

"Different layout types have significantly different security propert=
ies which need to be considered during their design and deployment.=C2=A0 F=
or example, some layouts, such as the block layout type, can only enforce m=
inimal security controls and require the client to be trusted to enforce ad=
ditional access controls. "

The current secur=
ity considerations section discusses fencing requirements.=C2=A0 Are there =
additional security considerations around the control protocol used to revo=
ke access at the storage device?=C2=A0 It would seem that the integrity and=
 availability of this channel is important. =C2=A0 Possibly the confidentia=
lity of the channel is important as well. =C2=A0

I=
t would probably be a good idea to discuss the security requirements of the=
 storage protocol as well.=C2=A0

It would probably=
 be a good idea to reference section 12.9 and 13.12 of RFC 5661. =C2=A0

Are there cases where any contextual information need=
s to be communicated over the control channel (access control information p=
erhaps)?=C2=A0

This document does not include priv=
acy considerations, but neither does RFC 5661, so I'm not sure it would=
 be in scope. =C2=A0

I'm new to NFSv4 and pNFS=
 so if some of this isn't clear let me know and I can try to clarify.

Cheers,

Joe

=



--001a11c2875a2cecde0513dfdd04--


From nobody Thu Apr 16 22:38:07 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95CE51ACE44; Thu, 16 Apr 2015 22:38:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wkn_t5Q9haom; Thu, 16 Apr 2015 22:37:58 -0700 (PDT)
Received: from BAY004-OMC2S1.hotmail.com (bay004-omc2s1.hotmail.com [65.54.190.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D322F1ACD37; Thu, 16 Apr 2015 22:37:58 -0700 (PDT)
Received: from BAY405-EAS211 ([65.54.190.124]) by BAY004-OMC2S1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);  Thu, 16 Apr 2015 22:37:58 -0700
X-TMN: [mtzEsnJqUbOdfWTmjRVXHku3aK3ma7WP]
X-Originating-Email: [charliekaufman@outlook.com]
Message-ID: 
From: Charlie Kaufman 
To: "'Watson Ladd'" , "'Karthikeyan Bhargavan'" 
References:   
In-Reply-To: 
Date: Thu, 16 Apr 2015 22:38:00 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQABAgMEOWnyltKQ8w0oTN5VCJ+wxaDvljJw
Content-Language: en-us
X-OriginalArrivalTime: 17 Apr 2015 05:37:58.0604 (UTC) FILETIME=[A98068C0:01D078D0]
Archived-At: 
Cc: draft-ietf-tls-session-hash.all@tools.ietf.org, 'The IESG' , secdir@ietf.org
Subject: Re: [secdir] [TLS] Secdir review of draft-ietf-tls-session-hash-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 05:38:01 -0000

Making a completely breaking change to a protocol - where no new =
implementation will interoperate with any existing implementation - =
seems like a bad idea under almost all circumstances. Am I reading the =
document correctly and that is the implication of implementing the =
features labelled "SHOULD"?

At the very least, if you are going to break interoperability, I would =
think you would introduce a new version number to the protocol rather =
than (and do I have this right?) make this change to all versions of TLS =
so that there will be a new TLS 1.0, TLS 1.1, and TLS 1.2 with this =
extension but none of them will interoperate with old implementations of =
any version of TLS?

And worst of all, if you are going to completely break interoperability =
without introducing a new version number, you should warn people about =
it in dramatic terms in the introduction to the RFC rather than have it =
be something that alert people will figure out when reading the spec and =
others will discover only when they try to deploy it.

The vulnerability that this extension addresses affects a tiny fraction =
of scenarios. I would expect that most people would decline to upgrade =
their implementation of TLS to fix that vulnerability if the cost were =
to break everything.

In the best case, people will ignore the fact that the step in the =
algorithm that breaks interoperability is labelled SHOULD and will =
instead deploy it such that the mitigation is effective only after both =
ends are upgraded, with a configuration switch allowing the mitigation =
to be required in scenarios where a single customer controls both ends =
of the connection. It would be reasonable to require the more secure =
behavior in TLS v1.3 (assuming that is the next version), since =
implementations not supporting it will negotiate down to a lower =
version.

But specifying a SHOULD behavior and hoping implementers will have the =
good sense to ignore it seems like we're looking for trouble.

	--Charlie

-----Original Message-----
From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Watson Ladd
Sent: Thursday, April 16, 2015 8:33 AM
To: Karthikeyan Bhargavan
Cc: secdir@ietf.org; draft-ietf-tls-session-hash.all@tools.ietf.org; The =
IESG
Subject: Re: [secdir] [TLS] Secdir review of =
draft-ietf-tls-session-hash-04

On Thu, Apr 16, 2015 at 12:06 AM, Karthikeyan Bhargavan =
 wrote:
> Hi Radia,
>
> Thanks for the comments. I made many of the smaller changes, and have=20
> some questions about the interop concerns.
>
>> In particular, section 5.2 paragraph 4 & 5 say:
>>
>> "If the server receives a ClientHello without the extension, it=20
>> SHOULD abort the handshake. If it chooses to continue, then it MUST=20
>> NOT include the extension in the ServerHello."
>>
>> "If a client receives a ServerHello without the extension, it SHOULD=20
>> abort the handshake.=E2=80=9D
>
> The style we chose was to say that the client/server SHOULD abort the=20
> handshake, but we also say in paragraph 7:
>
> "If the client or server choose to continue a full handshake without =
the extension, they use the legacy master secret derivation for the new =
session. In this case, the considerations in section 5.4 apply.=E2=80=9D
>
> That is, we do offer them the choice of opting out of this draft for=20
> interoperability, by following the recommendations in 5.4.
>
> We could make this forward pointer more explicit by saying instead:
>
> =E2=80=9CIn order to interoperate with legacy peers, some lients and =
servers=20
> may choose to  to continue a full handshake without the extension. In=20
> this case, they use  the  legacy master secret derivation for the new=20
> session, and the  considerations in section 5.4 apply.=E2=80=9D
>
> Would this assuage the security/interoperability concern?
>
>
>> In section 5.3, there is similar language to disable session=20
>> resumption when the extension is not present. While this may be more=20
>> acceptable because it will not break interoperability, it *will*=20
>> cause a significant performance degradation in some important=20
>> scenarios. I would again recommend that it be a configuration=20
>> parameter so that no one will refuse to deploy this change because of =
performance concerns.

I seem to recall a discussion about this, where my minority position was =
that breaking renegotiation instead was more acceptable. We need to =
break one, and renegotiation is not used nearly as commonly for =
browsers.

>
> During resumption we use similar language to point forward to section=20
> 5.2 if the client or server chooses to continue without the extension.
>
>> Section 5.4 also mandates breaking behavior (and here it is a MUST)=20
>> in scenarios where there is most likely to be a triple handshake =
vulnerability.
>> Given that there are cases with no such vulnerability and given that=20
>> people will be reluctant to deploy software that turns a subtle=20
>> security vulnerability into non-interoperability, I believe this=20
>> should be a matter of configuration.
>
> This case seems most difficult, because section 5.4 is the defense of=20
> last resort. Weakening the MUST requirements here would, in our mind,=20
> be tantamount to disabling the extension altogether.

Web browsers have adopted a more minimal solution, namely not permitting =
renegotiation to change certificates. I doubt that the stricter defense =
in 5.4 will cause interoperability issues, and it may have been adopted =
by some of them. Input from browser writers would be greatly =
appreciated.

Sincerely,
Watson Ladd

>
> Recall that in  the triple handshake attack, the man-in-the-middle is=20
> a valid peer who is trying to fool both the client and the server.=20
> Hence, we cannot rely on this man-in-the-middle sending the extension. =

> If we allow handshakes without the extension, the attack cannot be =
prevented, only mitigated.
> The MUSTs in this section try to enforce these mitigations.
>
> Best regards,
> Karthik
>
>
>>
>> Section 5.4 paragraph 4 seems to be undermining earlier requirements, =

>> saying that it MAY be safe (to break rules stated earlier). Taking=20
>> this to heart, I would propose that the "MUST abort" clauses in=20
>> sections 5.2 and 5.3 be softened to at least allow - and perhaps=20
>> recommend - implementations to support this scenario.
>>
>> -------
>>
>> Nits:
>>
>> In section 6.2, it is claimed that the security of TLS depends on the =

>> hash function used being collision resistant, use of MD5 and SHA1 is=20
>> NOT RECOMMENDED. That would rule out use of TLS 1.0 and TLS 1.1.=20
>> While a worthy goal, I don't believe this enhancement makes migration =

>> away from TLS 1.0 and TLS 1.1 any more urgent. I also don't believe=20
>> that TLS depends on the hash function being collision resistant (but=20
>> only that it is second preimage resistant).
>>
>> P9: "each other identity" -> "each other's identities"
>> P10: "that where hence" -> "that were hence"
>> P11: "server/ Hence," -> "server. Hence,
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



--
"Man is born free, but everywhere he is in chains".
--Rousseau.

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview


From nobody Fri Apr 17 04:38:28 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8391B3780; Thu, 16 Apr 2015 14:54:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UC6-4DtJwDtb; Thu, 16 Apr 2015 14:54:53 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297791B377C; Thu, 16 Apr 2015 14:54:53 -0700 (PDT)
Received: from BY2PR03MB554.namprd03.prod.outlook.com (10.141.141.156) by BY2PR03MB556.namprd03.prod.outlook.com (10.141.142.145) with Microsoft SMTP Server (TLS) id 15.1.118.21; Thu, 16 Apr 2015 21:54:32 +0000
Received: from BY2PR03MB554.namprd03.prod.outlook.com ([10.141.141.156]) by BY2PR03MB554.namprd03.prod.outlook.com ([10.141.141.156]) with mapi id 15.01.0118.029; Thu, 16 Apr 2015 21:54:31 +0000
From: Marsh Ray 
To: Watson Ladd , Karthikeyan Bhargavan 
Thread-Topic: [TLS] Secdir review of draft-ietf-tls-session-hash-04
Thread-Index: AQHQeAm2Xn7AfNfeP0+q3/GpYRs4wZ1PN7QAgACNgICAAGddsA==
Date: Thu, 16 Apr 2015 21:54:31 +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: [131.107.160.206]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=maray@microsoft.com; 
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB556;
x-o365ent-eop-header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(979002)(6009001)(13464003)(377454003)(51914003)(51704005)(24454002)(164054003)(77096005)(4001410100001)(74316001)(2656002)(87936001)(19580405001)(19580395003)(106116001)(15975445007)(92566002)(99286002)(102836002)(62966003)(77156002)(46102003)(86362001)(86612001)(122556002)(40100003)(50986999)(33656002)(76176999)(230783001)(76576001)(2950100001)(66066001)(2900100001)(54356999)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB556; H:BY2PR03MB554.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BY2PR03MB556; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB556; 
x-forefront-prvs: 0548586081
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2015 21:54:31.6608 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB556
Archived-At: 
X-Mailman-Approved-At: Fri, 17 Apr 2015 04:38:26 -0700
Cc: "secdir@ietf.org" , "draft-ietf-tls-session-hash.all@tools.ietf.org" , The IESG 
Subject: Re: [secdir] [TLS] Secdir review of draft-ietf-tls-session-hash-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Apr 2015 21:54:55 -0000

V2hpbGUgdGhlcmUgYXJlIGxpbWl0YXRpb25zIG9mIHRoaXMgYXBwcm9hY2gsIGF0IGxlYXN0IGZv
ciB0aGUgY3VycmVudCBUTFMgcHJvdG9jb2wgdmVyc2lvbnMgdXNlcnMgb2YgY2xpZW50IGNlcnRz
IG5lZWQgcmVuZWdvdGlhdGlvbiB0byBhdm9pZCBzZW5kaW5nIHRoZSBjbGllbnQgY2VydCBpbiB0
aGUgY2xlYXIuIEhvcGVmdWxseSBzb21ldGhpbmcgYmV0dGVyIHdpbGwgYmUgcG9zc2libGUgZm9y
IFRMUyAxLjMuDQoNCkFzIGEgZGF0YSBwb2ludCwgdGhlIDUgeWVhciBleHBlcmllbmNlIHdpdGgg
dGhlIFJlbmVnb3RpYXRpb24gSW5kaWNhdGlvbiBleHRlbnNpb24gW1JGQyA1NzQ2XSBzaG93cyB0
aGF0IHdlIGhhdmUgYWNoaWV2ZWQgc29tZXRoaW5nIGxpa2UgKDEwMC0yLjkpID0gOTcuMSUgY292
ZXJhZ2Ugb2Ygc2l0ZXMgdGhhdCByZWZ1c2UgaW5zZWN1cmUgcmVuZWdvdGlhdGlvbiwgdGhlIHZh
c3QgbWFqb3JpdHkgb2Ygd2hpY2ggc3VwcG9ydCBvZiB0aGUgbmV3IGV4dGVuc2lvbi4NCmh0dHBz
Oi8vd3d3LnRydXN0d29ydGh5aW50ZXJuZXQub3JnL3NzbC1wdWxzZS8NCg0KVGhhbmtzLA0KDQot
IE1hcnNoDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBXYXRzb24gTGFkZCBb
bWFpbHRvOndhdHNvbmJsYWRkQGdtYWlsLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTYs
IDIwMTUgODozMyBBTQ0KVG86IEthcnRoaWtleWFuIEJoYXJnYXZhbg0KQ2M6IFJhZGlhIFBlcmxt
YW47IGRyYWZ0LWlldGYtdGxzLXNlc3Npb24taGFzaC5hbGxAdG9vbHMuaWV0Zi5vcmc7IFRoZSBJ
RVNHOyBzZWNkaXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExTXSBTZWNkaXIgcmV2aWV3IG9m
IGRyYWZ0LWlldGYtdGxzLXNlc3Npb24taGFzaC0wNA0KDQpPbiBUaHUsIEFwciAxNiwgMjAxNSBh
dCAxMjowNiBBTSwgS2FydGhpa2V5YW4gQmhhcmdhdmFuIDxrYXJ0aGlrLmJoYXJnYXZhbkBnbWFp
bC5jb20+IHdyb3RlOg0KPiBIaSBSYWRpYSwNCj4NCj4gVGhhbmtzIGZvciB0aGUgY29tbWVudHMu
IEkgbWFkZSBtYW55IG9mIHRoZSBzbWFsbGVyIGNoYW5nZXMsIGFuZCBoYXZlIA0KPiBzb21lIHF1
ZXN0aW9ucyBhYm91dCB0aGUgaW50ZXJvcCBjb25jZXJucy4NCj4NCj4+IEluIHBhcnRpY3VsYXIs
IHNlY3Rpb24gNS4yIHBhcmFncmFwaCA0ICYgNSBzYXk6DQo+Pg0KPj4gIklmIHRoZSBzZXJ2ZXIg
cmVjZWl2ZXMgYSBDbGllbnRIZWxsbyB3aXRob3V0IHRoZSBleHRlbnNpb24sIGl0IA0KPj4gU0hP
VUxEIGFib3J0IHRoZSBoYW5kc2hha2UuIElmIGl0IGNob29zZXMgdG8gY29udGludWUsIHRoZW4g
aXQgTVVTVCANCj4+IE5PVCBpbmNsdWRlIHRoZSBleHRlbnNpb24gaW4gdGhlIFNlcnZlckhlbGxv
LiINCj4+DQo+PiAiSWYgYSBjbGllbnQgcmVjZWl2ZXMgYSBTZXJ2ZXJIZWxsbyB3aXRob3V0IHRo
ZSBleHRlbnNpb24sIGl0IFNIT1VMRCANCj4+IGFib3J0IHRoZSBoYW5kc2hha2Uu4oCdDQo+DQo+
IFRoZSBzdHlsZSB3ZSBjaG9zZSB3YXMgdG8gc2F5IHRoYXQgdGhlIGNsaWVudC9zZXJ2ZXIgU0hP
VUxEIGFib3J0IHRoZSANCj4gaGFuZHNoYWtlLCBidXQgd2UgYWxzbyBzYXkgaW4gcGFyYWdyYXBo
IDc6DQo+DQo+ICJJZiB0aGUgY2xpZW50IG9yIHNlcnZlciBjaG9vc2UgdG8gY29udGludWUgYSBm
dWxsIGhhbmRzaGFrZSB3aXRob3V0IHRoZSBleHRlbnNpb24sIHRoZXkgdXNlIHRoZSBsZWdhY3kg
bWFzdGVyIHNlY3JldCBkZXJpdmF0aW9uIGZvciB0aGUgbmV3IHNlc3Npb24uIEluIHRoaXMgY2Fz
ZSwgdGhlIGNvbnNpZGVyYXRpb25zIGluIHNlY3Rpb24gNS40IGFwcGx5LuKAnQ0KPg0KPiBUaGF0
IGlzLCB3ZSBkbyBvZmZlciB0aGVtIHRoZSBjaG9pY2Ugb2Ygb3B0aW5nIG91dCBvZiB0aGlzIGRy
YWZ0IGZvciANCj4gaW50ZXJvcGVyYWJpbGl0eSwgYnkgZm9sbG93aW5nIHRoZSByZWNvbW1lbmRh
dGlvbnMgaW4gNS40Lg0KPg0KPiBXZSBjb3VsZCBtYWtlIHRoaXMgZm9yd2FyZCBwb2ludGVyIG1v
cmUgZXhwbGljaXQgYnkgc2F5aW5nIGluc3RlYWQ6DQo+DQo+IOKAnEluIG9yZGVyIHRvIGludGVy
b3BlcmF0ZSB3aXRoIGxlZ2FjeSBwZWVycywgc29tZSBsaWVudHMgYW5kIHNlcnZlcnMgDQo+IG1h
eSBjaG9vc2UgdG8gIHRvIGNvbnRpbnVlIGEgZnVsbCBoYW5kc2hha2Ugd2l0aG91dCB0aGUgZXh0
ZW5zaW9uLiBJbiANCj4gdGhpcyBjYXNlLCB0aGV5IHVzZSAgdGhlICBsZWdhY3kgbWFzdGVyIHNl
Y3JldCBkZXJpdmF0aW9uIGZvciB0aGUgbmV3IA0KPiBzZXNzaW9uLCBhbmQgdGhlICBjb25zaWRl
cmF0aW9ucyBpbiBzZWN0aW9uIDUuNCBhcHBseS7igJ0NCj4NCj4gV291bGQgdGhpcyBhc3N1YWdl
IHRoZSBzZWN1cml0eS9pbnRlcm9wZXJhYmlsaXR5IGNvbmNlcm4/DQo+DQo+DQo+PiBJbiBzZWN0
aW9uIDUuMywgdGhlcmUgaXMgc2ltaWxhciBsYW5ndWFnZSB0byBkaXNhYmxlIHNlc3Npb24gDQo+
PiByZXN1bXB0aW9uIHdoZW4gdGhlIGV4dGVuc2lvbiBpcyBub3QgcHJlc2VudC4gV2hpbGUgdGhp
cyBtYXkgYmUgbW9yZSANCj4+IGFjY2VwdGFibGUgYmVjYXVzZSBpdCB3aWxsIG5vdCBicmVhayBp
bnRlcm9wZXJhYmlsaXR5LCBpdCAqd2lsbCogDQo+PiBjYXVzZSBhIHNpZ25pZmljYW50IHBlcmZv
cm1hbmNlIGRlZ3JhZGF0aW9uIGluIHNvbWUgaW1wb3J0YW50IA0KPj4gc2NlbmFyaW9zLiBJIHdv
dWxkIGFnYWluIHJlY29tbWVuZCB0aGF0IGl0IGJlIGEgY29uZmlndXJhdGlvbiANCj4+IHBhcmFt
ZXRlciBzbyB0aGF0IG5vIG9uZSB3aWxsIHJlZnVzZSB0byBkZXBsb3kgdGhpcyBjaGFuZ2UgYmVj
YXVzZSBvZiBwZXJmb3JtYW5jZSBjb25jZXJucy4NCg0KSSBzZWVtIHRvIHJlY2FsbCBhIGRpc2N1
c3Npb24gYWJvdXQgdGhpcywgd2hlcmUgbXkgbWlub3JpdHkgcG9zaXRpb24gd2FzIHRoYXQgYnJl
YWtpbmcgcmVuZWdvdGlhdGlvbiBpbnN0ZWFkIHdhcyBtb3JlIGFjY2VwdGFibGUuIFdlIG5lZWQg
dG8gYnJlYWsgb25lLCBhbmQgcmVuZWdvdGlhdGlvbiBpcyBub3QgdXNlZCBuZWFybHkgYXMgY29t
bW9ubHkgZm9yIGJyb3dzZXJzLg0KDQo+DQo+IER1cmluZyByZXN1bXB0aW9uIHdlIHVzZSBzaW1p
bGFyIGxhbmd1YWdlIHRvIHBvaW50IGZvcndhcmQgdG8gc2VjdGlvbiANCj4gNS4yIGlmIHRoZSBj
bGllbnQgb3Igc2VydmVyIGNob29zZXMgdG8gY29udGludWUgd2l0aG91dCB0aGUgZXh0ZW5zaW9u
Lg0KPg0KPj4gU2VjdGlvbiA1LjQgYWxzbyBtYW5kYXRlcyBicmVha2luZyBiZWhhdmlvciAoYW5k
IGhlcmUgaXQgaXMgYSBNVVNUKSANCj4+IGluIHNjZW5hcmlvcyB3aGVyZSB0aGVyZSBpcyBtb3N0
IGxpa2VseSB0byBiZSBhIHRyaXBsZSBoYW5kc2hha2UgdnVsbmVyYWJpbGl0eS4NCj4+IEdpdmVu
IHRoYXQgdGhlcmUgYXJlIGNhc2VzIHdpdGggbm8gc3VjaCB2dWxuZXJhYmlsaXR5IGFuZCBnaXZl
biB0aGF0IA0KPj4gcGVvcGxlIHdpbGwgYmUgcmVsdWN0YW50IHRvIGRlcGxveSBzb2Z0d2FyZSB0
aGF0IHR1cm5zIGEgc3VidGxlIA0KPj4gc2VjdXJpdHkgdnVsbmVyYWJpbGl0eSBpbnRvIG5vbi1p
bnRlcm9wZXJhYmlsaXR5LCBJIGJlbGlldmUgdGhpcyANCj4+IHNob3VsZCBiZSBhIG1hdHRlciBv
ZiBjb25maWd1cmF0aW9uLg0KPg0KPiBUaGlzIGNhc2Ugc2VlbXMgbW9zdCBkaWZmaWN1bHQsIGJl
Y2F1c2Ugc2VjdGlvbiA1LjQgaXMgdGhlIGRlZmVuc2Ugb2YgDQo+IGxhc3QgcmVzb3J0LiBXZWFr
ZW5pbmcgdGhlIE1VU1QgcmVxdWlyZW1lbnRzIGhlcmUgd291bGQsIGluIG91ciBtaW5kLCANCj4g
YmUgdGFudGFtb3VudCB0byBkaXNhYmxpbmcgdGhlIGV4dGVuc2lvbiBhbHRvZ2V0aGVyLg0KDQpX
ZWIgYnJvd3NlcnMgaGF2ZSBhZG9wdGVkIGEgbW9yZSBtaW5pbWFsIHNvbHV0aW9uLCBuYW1lbHkg
bm90IHBlcm1pdHRpbmcgcmVuZWdvdGlhdGlvbiB0byBjaGFuZ2UgY2VydGlmaWNhdGVzLiBJIGRv
dWJ0IHRoYXQgdGhlIHN0cmljdGVyIGRlZmVuc2UgaW4gNS40IHdpbGwgY2F1c2UgaW50ZXJvcGVy
YWJpbGl0eSBpc3N1ZXMsIGFuZCBpdCBtYXkgaGF2ZSBiZWVuIGFkb3B0ZWQgYnkgc29tZSBvZiB0
aGVtLiBJbnB1dCBmcm9tIGJyb3dzZXIgd3JpdGVycyB3b3VsZCBiZSBncmVhdGx5IGFwcHJlY2lh
dGVkLg0KDQpTaW5jZXJlbHksDQpXYXRzb24gTGFkZA0KDQo+DQo+IFJlY2FsbCB0aGF0IGluICB0
aGUgdHJpcGxlIGhhbmRzaGFrZSBhdHRhY2ssIHRoZSBtYW4taW4tdGhlLW1pZGRsZSBpcyANCj4g
YSB2YWxpZCBwZWVyIHdobyBpcyB0cnlpbmcgdG8gZm9vbCBib3RoIHRoZSBjbGllbnQgYW5kIHRo
ZSBzZXJ2ZXIuIA0KPiBIZW5jZSwgd2UgY2Fubm90IHJlbHkgb24gdGhpcyBtYW4taW4tdGhlLW1p
ZGRsZSBzZW5kaW5nIHRoZSBleHRlbnNpb24uIA0KPiBJZiB3ZSBhbGxvdyBoYW5kc2hha2VzIHdp
dGhvdXQgdGhlIGV4dGVuc2lvbiwgdGhlIGF0dGFjayBjYW5ub3QgYmUgcHJldmVudGVkLCBvbmx5
IG1pdGlnYXRlZC4NCj4gVGhlIE1VU1RzIGluIHRoaXMgc2VjdGlvbiB0cnkgdG8gZW5mb3JjZSB0
aGVzZSBtaXRpZ2F0aW9ucy4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPiBLYXJ0aGlrDQo+DQo+DQo+
Pg0KPj4gU2VjdGlvbiA1LjQgcGFyYWdyYXBoIDQgc2VlbXMgdG8gYmUgdW5kZXJtaW5pbmcgZWFy
bGllciByZXF1aXJlbWVudHMsIA0KPj4gc2F5aW5nIHRoYXQgaXQgTUFZIGJlIHNhZmUgKHRvIGJy
ZWFrIHJ1bGVzIHN0YXRlZCBlYXJsaWVyKS4gVGFraW5nIA0KPj4gdGhpcyB0byBoZWFydCwgSSB3
b3VsZCBwcm9wb3NlIHRoYXQgdGhlICJNVVNUIGFib3J0IiBjbGF1c2VzIGluIA0KPj4gc2VjdGlv
bnMgNS4yIGFuZCA1LjMgYmUgc29mdGVuZWQgdG8gYXQgbGVhc3QgYWxsb3cgLSBhbmQgcGVyaGFw
cyANCj4+IHJlY29tbWVuZCAtIGltcGxlbWVudGF0aW9ucyB0byBzdXBwb3J0IHRoaXMgc2NlbmFy
aW8uDQo+Pg0KPj4gLS0tLS0tLQ0KPj4NCj4+IE5pdHM6DQo+Pg0KPj4gSW4gc2VjdGlvbiA2LjIs
IGl0IGlzIGNsYWltZWQgdGhhdCB0aGUgc2VjdXJpdHkgb2YgVExTIGRlcGVuZHMgb24gdGhlIA0K
Pj4gaGFzaCBmdW5jdGlvbiB1c2VkIGJlaW5nIGNvbGxpc2lvbiByZXNpc3RhbnQsIHVzZSBvZiBN
RDUgYW5kIFNIQTEgaXMgDQo+PiBOT1QgUkVDT01NRU5ERUQuIFRoYXQgd291bGQgcnVsZSBvdXQg
dXNlIG9mIFRMUyAxLjAgYW5kIFRMUyAxLjEuIA0KPj4gV2hpbGUgYSB3b3J0aHkgZ29hbCwgSSBk
b24ndCBiZWxpZXZlIHRoaXMgZW5oYW5jZW1lbnQgbWFrZXMgbWlncmF0aW9uIA0KPj4gYXdheSBm
cm9tIFRMUyAxLjAgYW5kIFRMUyAxLjEgYW55IG1vcmUgdXJnZW50LiBJIGFsc28gZG9uJ3QgYmVs
aWV2ZSANCj4+IHRoYXQgVExTIGRlcGVuZHMgb24gdGhlIGhhc2ggZnVuY3Rpb24gYmVpbmcgY29s
bGlzaW9uIHJlc2lzdGFudCAoYnV0IA0KPj4gb25seSB0aGF0IGl0IGlzIHNlY29uZCBwcmVpbWFn
ZSByZXNpc3RhbnQpLg0KPj4NCj4+IFA5OiAiZWFjaCBvdGhlciBpZGVudGl0eSIgLT4gImVhY2gg
b3RoZXIncyBpZGVudGl0aWVzIg0KPj4gUDEwOiAidGhhdCB3aGVyZSBoZW5jZSIgLT4gInRoYXQg
d2VyZSBoZW5jZSINCj4+IFAxMTogInNlcnZlci8gSGVuY2UsIiAtPiAic2VydmVyLiBIZW5jZSwN
Cj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g
VExTIG1haWxpbmcgbGlzdA0KPiBUTFNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby90bHMNCg0KDQoNCi0tDQoiTWFuIGlzIGJvcm4gZnJlZSwgYnV0IGV2
ZXJ5d2hlcmUgaGUgaXMgaW4gY2hhaW5zIi4NCi0tUm91c3NlYXUuDQo=


From nobody Fri Apr 17 04:38:30 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC8B1B3826; Thu, 16 Apr 2015 15:42:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Level: 
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOnhS1XCcSHb; Thu, 16 Apr 2015 15:42:29 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E02A1B381E; Thu, 16 Apr 2015 15:42:28 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.11,590,1422918000";  d="asc'?scan'208";a="135475101"
Received: from 5ec2c015.skybroadband.com (HELO adminisatorsmbp.lan) ([94.194.192.21]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 17 Apr 2015 00:42:26 +0200
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_AC81B333-F0B3-43DF-B62F-F959B60394D2"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Karthikeyan Bhargavan 
In-Reply-To: 
Date: Thu, 16 Apr 2015 23:42:25 +0100
Message-Id: <39C61EC6-9487-436C-902E-86F73CA88988@inria.fr>
References:    
To: Marsh Ray 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
X-Mailman-Approved-At: Fri, 17 Apr 2015 04:38:26 -0700
Cc: Watson Ladd , "secdir@ietf.org" , "draft-ietf-tls-session-hash.all@tools.ietf.org" , The IESG 
Subject: Re: [secdir] [TLS] Secdir review of draft-ietf-tls-session-hash-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Apr 2015 22:42:35 -0000

--Apple-Mail=_AC81B333-F0B3-43DF-B62F-F959B60394D2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

We=92re running out of time on this revision, so I am submitting a new =
version with the changes
indicated before. That is, not making too many changes to support =
interoperability, but just making
the choice explicit.

-K.

On 16 Apr 2015, at 22:54, Marsh Ray  wrote:

> While there are limitations of this approach, at least for the current =
TLS protocol versions users of client certs need renegotiation to avoid =
sending the client cert in the clear. Hopefully something better will be =
possible for TLS 1.3.
>=20
> As a data point, the 5 year experience with the Renegotiation =
Indication extension [RFC 5746] shows that we have achieved something =
like (100-2.9) =3D 97.1% coverage of sites that refuse insecure =
renegotiation, the vast majority of which support of the new extension.
> https://www.trustworthyinternet.org/ssl-pulse/
>=20
> Thanks,
>=20
> - Marsh
>=20
> -----Original Message-----
> From: Watson Ladd [mailto:watsonbladd@gmail.com]
> Sent: Thursday, April 16, 2015 8:33 AM
> To: Karthikeyan Bhargavan
> Cc: Radia Perlman; draft-ietf-tls-session-hash.all@tools.ietf.org; The =
IESG; secdir@ietf.org
> Subject: Re: [TLS] Secdir review of draft-ietf-tls-session-hash-04
>=20
> On Thu, Apr 16, 2015 at 12:06 AM, Karthikeyan Bhargavan =
 wrote:
>> Hi Radia,
>>=20
>> Thanks for the comments. I made many of the smaller changes, and have
>> some questions about the interop concerns.
>>=20
>>> In particular, section 5.2 paragraph 4 & 5 say:
>>>=20
>>> "If the server receives a ClientHello without the extension, it
>>> SHOULD abort the handshake. If it chooses to continue, then it MUST
>>> NOT include the extension in the ServerHello."
>>>=20
>>> "If a client receives a ServerHello without the extension, it SHOULD
>>> abort the handshake.=94
>>=20
>> The style we chose was to say that the client/server SHOULD abort the
>> handshake, but we also say in paragraph 7:
>>=20
>> "If the client or server choose to continue a full handshake without =
the extension, they use the legacy master secret derivation for the new =
session. In this case, the considerations in section 5.4 apply.=94
>>=20
>> That is, we do offer them the choice of opting out of this draft for
>> interoperability, by following the recommendations in 5.4.
>>=20
>> We could make this forward pointer more explicit by saying instead:
>>=20
>> =93In order to interoperate with legacy peers, some lients and =
servers
>> may choose to  to continue a full handshake without the extension. In
>> this case, they use  the  legacy master secret derivation for the new
>> session, and the  considerations in section 5.4 apply.=94
>>=20
>> Would this assuage the security/interoperability concern?
>>=20
>>=20
>>> In section 5.3, there is similar language to disable session
>>> resumption when the extension is not present. While this may be more
>>> acceptable because it will not break interoperability, it *will*
>>> cause a significant performance degradation in some important
>>> scenarios. I would again recommend that it be a configuration
>>> parameter so that no one will refuse to deploy this change because =
of performance concerns.
>=20
> I seem to recall a discussion about this, where my minority position =
was that breaking renegotiation instead was more acceptable. We need to =
break one, and renegotiation is not used nearly as commonly for =
browsers.
>=20
>>=20
>> During resumption we use similar language to point forward to section
>> 5.2 if the client or server chooses to continue without the =
extension.
>>=20
>>> Section 5.4 also mandates breaking behavior (and here it is a MUST)
>>> in scenarios where there is most likely to be a triple handshake =
vulnerability.
>>> Given that there are cases with no such vulnerability and given that
>>> people will be reluctant to deploy software that turns a subtle
>>> security vulnerability into non-interoperability, I believe this
>>> should be a matter of configuration.
>>=20
>> This case seems most difficult, because section 5.4 is the defense of
>> last resort. Weakening the MUST requirements here would, in our mind,
>> be tantamount to disabling the extension altogether.
>=20
> Web browsers have adopted a more minimal solution, namely not =
permitting renegotiation to change certificates. I doubt that the =
stricter defense in 5.4 will cause interoperability issues, and it may =
have been adopted by some of them. Input from browser writers would be =
greatly appreciated.
>=20
> Sincerely,
> Watson Ladd
>=20
>>=20
>> Recall that in  the triple handshake attack, the man-in-the-middle is
>> a valid peer who is trying to fool both the client and the server.
>> Hence, we cannot rely on this man-in-the-middle sending the =
extension.
>> If we allow handshakes without the extension, the attack cannot be =
prevented, only mitigated.
>> The MUSTs in this section try to enforce these mitigations.
>>=20
>> Best regards,
>> Karthik
>>=20
>>=20
>>>=20
>>> Section 5.4 paragraph 4 seems to be undermining earlier =
requirements,
>>> saying that it MAY be safe (to break rules stated earlier). Taking
>>> this to heart, I would propose that the "MUST abort" clauses in
>>> sections 5.2 and 5.3 be softened to at least allow - and perhaps
>>> recommend - implementations to support this scenario.
>>>=20
>>> -------
>>>=20
>>> Nits:
>>>=20
>>> In section 6.2, it is claimed that the security of TLS depends on =
the
>>> hash function used being collision resistant, use of MD5 and SHA1 is
>>> NOT RECOMMENDED. That would rule out use of TLS 1.0 and TLS 1.1.
>>> While a worthy goal, I don't believe this enhancement makes =
migration
>>> away from TLS 1.0 and TLS 1.1 any more urgent. I also don't believe
>>> that TLS depends on the hash function being collision resistant (but
>>> only that it is second preimage resistant).
>>>=20
>>> P9: "each other identity" -> "each other's identities"
>>> P10: "that where hence" -> "that were hence"
>>> P11: "server/ Hence," -> "server. Hence,
>>=20
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>=20
>=20
>=20
> --
> "Man is born free, but everywhere he is in chains".
> --Rousseau.


--Apple-Mail=_AC81B333-F0B3-43DF-B62F-F959B60394D2
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJVMDrRAAoJEB/WSo9veuUKbiYH/jm8t2sosLtElEnMKtTI+MQt
RWsZUgHjM5e8RrT277JYh1BAXijkakP2VxPkvgQk7dSXyAhR/W/8nuyzwo/CJtB9
v5SYVQZ3dW6EYLw3NVbIX/1uMq5wN56giGonqNsy5pQdHqQkgTZ+muxke/v4k1Y7
Lv97Iz7l4IFEegmNkSozeigN8UBGj4xgeyjcEoEq6uGorBNGOUXzuSLf2Q9eqVt2
1MaY9aQqTdQm4zSBtt4GwcdAu8Wzrv/+HARz8VAtqm0MfhwTikrSr6jTOsJ2pbMo
FYbK7P2mvWPhR8SMJWT3xj4KazJYzs48RygCJHnxHppRS1CeAv3BLCiffguT1RE=
=2czy
-----END PGP SIGNATURE-----

--Apple-Mail=_AC81B333-F0B3-43DF-B62F-F959B60394D2--


From nobody Sun Apr 19 14:32:38 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C381A87C7; Sun, 19 Apr 2015 14:32:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jBU2BeRp2fQ; Sun, 19 Apr 2015 14:32:34 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788061A87C3; Sun, 19 Apr 2015 14:32:34 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lVPWf3Qg8z1Dv; Sun, 19 Apr 2015 23:32:30 +0200 (CEST)
Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=QUy0P1k3
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Xz3coS_LH2V2; Sun, 19 Apr 2015 23:32:29 +0200 (CEST)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 19 Apr 2015 23:32:29 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 681F0803E0; Sun, 19 Apr 2015 17:32:28 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1429479148; bh=unssnrDPvoHh4hw1bmQiQ2Uyx6NAgtugsqKdQjstEdE=; h=Date:From:To:Subject; b=QUy0P1k3YLBRAQcvfluikjoiYVAIhCD2ttJ7DrbJyQPPN76yih/UJzL1lhDyA2zZ4 tzlqxDlBtSROJ8p+3pNZxuU6t5FSWZsvrxXYeZLCOEKyc9kyoM2brK3GKTvjIlOwjH h8IKR7UZoIYp2iTkniiTHNBA2ju9oT9GUhtg3q4Q=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t3JLWQWJ004902; Sun, 19 Apr 2015 17:32:26 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Sun, 19 Apr 2015 17:32:26 -0400 (EDT)
From: Paul Wouters 
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-v6ops-cidr-prefix.all@tools.ietf.org
Message-ID: 
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: 
Subject: [secdir] Secdir review of draft-ietf-v6ops-cidr-prefix-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Apr 2015 21:32:36 -0000

Secdir review of draft-ietf-v6ops-cidr-prefix-01

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 clarifies IPv6 forwarders should support all IPv6 prefix
lengths and use longest-match-first on prefixes of any valid length.

This document does not introduce security issues in addition to what
is discussed in [RFC4291], which it references in its Security
Considerations section.

I think this draft is Ready.

Paul


From nobody Wed Apr 22 07:25:32 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348741A9302; Wed, 22 Apr 2015 07:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFDsFggeskoT; Wed, 22 Apr 2015 07:25:28 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549231AC3C2; Wed, 22 Apr 2015 07:24:43 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lX3tZ6Ww3z7YR; Wed, 22 Apr 2015 16:24:38 +0200 (CEST)
Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=BKskxb3r
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id D_IUWVyM-csK; Wed, 22 Apr 2015 16:24:38 +0200 (CEST)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 22 Apr 2015 16:24:38 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3D923809F8; Wed, 22 Apr 2015 10:24:37 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1429712677; bh=faUvmWTu6Z8oPh2nhbFl9b/WyqQtGBocZIm7qeqNrK8=; h=Date:From:To:Subject; b=BKskxb3rUz4qODslOfnb0ojWcXNeJ/SRWDgfe/slgH9Nl89Bm44nypBhVHwu4Jjm7 y61cSowWw9YdkuJV4puaNTTQKKtIM52JEdrMSGjNvyBvKTElmDrA6+rNtKek1iNdim D2k3yIdRCRNsy9oTaKSZxG+2V8Dk+sXabM9DB1kc=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t3MEOaTN004017; Wed, 22 Apr 2015 10:24:36 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Wed, 22 Apr 2015 10:24:36 -0400 (EDT)
From: Paul Wouters 
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-idr-as-migration.all@tools.ietf.org
Message-ID: 
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: 
Subject: [secdir] Secdir review of draft-ietf-idr-as-migration-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Apr 2015 14:25:30 -0000

Secdir review of draft-ietf-idr-as-migration-04

[Note: I am not a BGP expert]

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 describes a common AS migration deployment scenario, and
lists the features and practises that are used in an AS migration for
reference in future BGP work. Additionally, it is a useful document
for those BGP administrators that need to perform such an AS migration.

I think this draft is Ready.

My only suggestion would be to consider to emphasize the warning paragraph
at the end of section 3.2 on routing loops either by creating its own
sub-section or by mentioning this again in the Security Considerations.

(But I might be more sensitive to routing loops than real BGP administrators)

Paul


From nobody Thu Apr 23 02:04:49 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1971A8F3A for ; Thu, 23 Apr 2015 02:04:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Level: 
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEbVQoCFOkCj for ; Thu, 23 Apr 2015 02:04:45 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACF11A8AF2 for ; Thu, 23 Apr 2015 02:04:32 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t3N94SZh008881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 23 Apr 2015 12:04:29 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t3N94St0007783; Thu, 23 Apr 2015 12:04:28 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21816.46492.594722.722943@fireball.kivinen.iki.fi>
Date: Thu, 23 Apr 2015 12:04:28 +0300
From: Tero Kivinen 
To: secdir@ietf.org
X-Edit-Time: 0 min
X-Total-Time: 0 min
Archived-At: 
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Apr 2015 09:04:47 -0000

Review instructions and related resources are at:
http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

Tobias Gondrom is next in the rotation.

For telechat 2015-05-14

Reviewer                 LC end     Draft
Shaun Cooley           T 2015-05-05 draft-ietf-appsawg-rfc7001bis-07
Shawn Emery            T 2015-05-01 draft-ietf-manet-tlv-naming-01
Daniel Kahn Gillmor    T 2015-04-30 draft-ietf-rtgwg-mofrr-06
Sam Weiler             T 2015-04-20 draft-ietf-scim-api-16
Brian Weis             T 2015-04-20 draft-ietf-scim-core-schema-17

Last calls and special requests:

Derek Atkins             2015-04-28 draft-ietf-precis-saslprepbis-15
John Bradley             2015-05-13 draft-jimenez-p2psip-coap-reload-08
Dave Cridland            2015-05-06 draft-ietf-dhc-dynamic-shared-v4allocation-06
Alan DeKok               2015-05-01 draft-ietf-dprive-problem-statement-04
Donald Eastlake          2015-05-04 draft-ietf-ipsecme-ikev2-null-auth-06
Dan Harkins              2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-15
Eric Osterweil           2015-04-29 draft-perrault-behave-deprecate-nat-mib-v1-01
Vincent Roca             2015-04-24 draft-hansen-scram-sha256-02
Zach Shelby              2014-06-06 draft-housley-implementer-obligations-02
Tina TSOU                2015-05-05 draft-hallambaker-tlsfeature-09
Sean Turner              2015-04-20 draft-ietf-bmwg-traffic-management-04
David Waltermire         2015-04-20 draft-ietf-opsawg-hmac-sha-2-usm-snmp-06
Klaas Wierenga           2015-04-17 draft-ietf-tls-negotiated-ff-dhe-08
Tom Yu                   2015-04-23 draft-ietf-intarea-gre-mtu-02
Dacheng Zhang            2015-04-28 draft-ietf-lisp-eid-block-mgmnt-04
-- 
kivinen@iki.fi


From nobody Thu Apr 23 16:45:19 2015
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D1B1AD367; Thu, 23 Apr 2015 16:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWqxodoqhBor; Thu, 23 Apr 2015 16:45:14 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9EF1AD259; Thu, 23 Apr 2015 16:45:02 -0700 (PDT)
X-AuditID: 1209190e-f79a76d000000d1b-d8-553983fd945c
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id B5.2C.03355.DF389355; Thu, 23 Apr 2015 19:45:01 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t3NNj09X004552; Thu, 23 Apr 2015 19:45:00 -0400
Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t3NNiwJX002697; Thu, 23 Apr 2015 19:44:59 -0400
From: Tom Yu 
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-intarea-gre-mtu.all@tools.ietf.org
Date: Thu, 23 Apr 2015 19:44:57 -0400
Message-ID: 
Lines: 13
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixG6nrvu32TLUYNMlWYsl208yWsz4M5HZ 4sPChywOzB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV8aqnYsYC+azVry4uJa9gXEtSxcj J4eEgInEgedvmSBsMYkL99azdTFycQgJLGaSuPVtGSOEs5FR4lLDOyjnDaNEy/plbCAtbALS Escv7wJq5+AQEYiS6JgXDWIKC5hLbFooDVLBIqAqcej9O7BqXgFdictnXzGC2DwCnBJL+7Yy QcQFJU7OfAJ2ELOAlsSNfy+ZJjDyzkKSmoUktYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGu sV5uZoleakrpJkZQQHFK8u1g/HpQ6RCjAAejEg/vi2yLUCHWxLLiytxDjJIcTEqivEdiLEOF +JLyUyozEosz4otKc1KLDzFKcDArifDurgbK8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnN Tk0tSC2CycpwcChJ8AY3ATUKFqWmp1akZeaUIKSZODhBhvMADW8GqeEtLkjMLc5Mh8ifYtTl uDPl/yImIZa8/LxUKXHeNpAiAZCijNI8uDmwRPCKURzoLWHeLSBVPMAkAjfpFdASJqAlM5da gCwpSURISTUwhoYX8HFvu7H94ZYAx6DLq1ImVd1b4rqrf0vPok9vtnq18QnkM9kwuC8MXvVU KDypN/TQr8ydlYq+Wt3XeuPio7siTn5fKS7FN63n4vbLp9YfvxJ6X+aXkwgff+a9XMOlVeli 7Bcv7LtwJ+Oo608tZraJ0wu+326xVNBdLWNcmLTAYZ7G3G5pJZbijERDLeai4kQABMn1At8C AAA=
Archived-At: 
Subject: [secdir] secdir review of draft-ietf-intarea-gre-mtu-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Apr 2015 23:45:16 -0000

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.

Summary: ready

This document deals with fragmentation issues in the General Routing
Encapsulation (GRE).  Fragmentation naturally presents potential denial
of service and resource exhaustion vulnerabilities.  I think the
Security Considerations section of this document adequately addresses
these potential vulnerabilities.


From nobody Fri Apr 24 08:36:34 2015
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 D82A01B2DD0; Fri, 24 Apr 2015 08:28:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1429889299; bh=MCPEVOcx4JTjBr4uqodZ8DMDkG3cVf5YsumDfYGNl9s=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=yODHTNyJwX/JS75WkZROaAzYsIRjo3QAJS22rF89L4lFYj5BN3ToQv+kNuQXi70rk +AxFvXKkvZRDM4vqhgt/Cch7uCOY6g+pwnq1n94tdJxjvHNHx83F8HkZov6mhHq1v6 A1TTNOoCd9hytdsUfqB5gPKB0CN2cVz3m+d4NN6Y=
X-Original-To: new-work@ietfa.amsl.com
Delivered-To: new-work@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35611B2EFC; Fri, 24 Apr 2015 08:28:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_pQo3z9AEHO; Fri, 24 Apr 2015 08:28:10 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 715311ACE19; Fri, 24 Apr 2015 08:28:10 -0700 (PDT)
MIME-Version: 1.0
From: The IESG 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.1.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150424152810.16096.72536.idtracker@ietfa.amsl.com>
Date: Fri, 24 Apr 2015 08:28:10 -0700
Archived-At: 
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Apr 2015 08:36:33 -0700
Subject: [secdir] [new-work] WG Review: Internet Video Codec (netvc)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Apr 2015 15:28:20 -0000

A new IETF working group has been proposed in the Real-time Applications
and Infrastructure 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
at ietf.org) by 2015-05-04.

Internet Video Codec (netvc)
------------------------------------------------
Current Status: Proposed WG

Assigned Area Director:
  Alissa Cooper 

Mailing list
  Address: video-codec@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/video-codec
  Archive: http://www.ietf.org/mail-archive/web/video-codec/

Charter:

Objectives

This WG is chartered to produce a high-quality video codec that meets the
following conditions:

1. Is competitive with current video codecs in widespread use.

2. Is optimized for use in interactive web applications.

3. Is viewed as having IPR licensing terms that allow it to be widely
implemented and deployed.

To elaborate, this video codec will need to be commercially interesting
to implement by being competitive with the video codecs in widespread use
at the time it is finalized.

This video codec will need to be optimized for the real-world conditions
of the public, best-effort Internet. It should include, but may not be
limited to, the ability to support fast and flexible congestion control
and rate adaptation, the ability to quickly join broadcast streams and
the ability to be optimized for captures of content typically shared in
interactive communications.

The objective is to produce a video codec that can be implemented,
distributed, and deployed by open source and closed source software as
well as implemented in specialized hardware.

The working group shall heed the preference stated in BCP 79: "In
general, IETF working groups prefer technologies with no known IPR claims
or, for technologies with claims against them, an offer of royalty-free
licensing." In keeping with this BCP, the WG will prefer algorithms or
tools where there are verifiable reasons to believe they are available on
an RF basis. In developing the codec specification, the WG may consider
information concerning old prior art or the results of research
indicating royalty-free availability of particular techniques. Note that
the preference stated in BCP 79 cannot guarantee that the working group
will produce an IPR unencumbered codec.

Process

The core technical considerations for such a codec include, but are not
necessarily limited to, the following:

1. High compression efficiency that is competitive with existing popular
video codecs.

2. Reasonable computational complexity that permits real-time operation
on existing, popular hardware, including mobile devices, and efficient
implementation in new hardware designs.

3. Use in interactive real-time applications, such as point-to-point
video calls, multi-party video conferencing, telepresence, teleoperation,
and in-game video chat.

4. Resilient in the real-world transport conditions of the Internet, such
as the flexibility to rapidly respond to changing bandwidth availability
and loss rates, etc.

5. Integratable with common Internet applications and Web APIs (e.g., the
HTML5