From nobody Fri May 2 00:11:24 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FB51A0A6E for ; Fri, 2 May 2014 00:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] 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 jGD-XSWsSRla for ; Fri, 2 May 2014 00:11:18 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5521A0A3E for ; Fri, 2 May 2014 00:11:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,971,1389740400"; d="scan'208";a="25024543" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 02 May 2014 09:11:15 +0200 Received: from EXC-MBX03.tsn.tno.nl ([fe80::e969:1300:fb9f:7e12]) by EXC-CASHUB01.tsn.tno.nl ([fe80::b855:be6:1aa8:4d0f%13]) with mapi id 14.03.0174.001; Fri, 2 May 2014 09:11:15 +0200 From: "Brandenburg, R. (Ray) van" To: Ben Niven-Jenkins , "flefauch@cisco.com" Thread-Topic: [CDNi] URI Signing for CDNI Working Group Draft Thread-Index: AQHPSBomVjXoux+3r0uy5ywq9SFIlJstFjTQ Date: Fri, 2 May 2014 07:11:14 +0000 Message-ID: References: <147CBB6C-9F42-4758-909C-2FD9B96DB289@niven-jenkins.co.uk> In-Reply-To: <147CBB6C-9F42-4758-909C-2FD9B96DB289@niven-jenkins.co.uk> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/NC0BO_S2NNaiNXryMMCGQUbSB7g Cc: "cdni@ietf.org" Subject: Re: [CDNi] URI Signing for CDNI Working Group Draft X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 07:11:24 -0000 Hi Ben, Thanks for you review. Sorry for taking so long to respond to your comments= . = > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins > Sent: dinsdag 25 maart 2014 12:03 > To: Daryl Malas > Cc: cdni@ietf.org > Subject: Re: [CDNi] URI Signing for CDNI Working Group Draft > = > Daryl, Authors, > = > I gave the draft a quick read. It seems a reasonable starting point. > = > While I was reading the draft I noticed a couple of things in it that I t= hink are > worth raising: > = > 1) In section 2 the draft says "Any attributes appended in such way after= the > URI Signature has been calculated are not validated for the purpose of > content access authorization." > = > If additional query parameters can be appended to the URI which are not > validated, could a UA obtain content that it isn't authorised to obtain by > adding additional query parameters? It seems like something that could be > worth discussing in the security considerations section? > = I'm not sure I understand you correctly. Any parameters added by the UA aft= er the URI Signature are not taken into account during the signing process.= As such, there is no way for these parameters to affect the outcome of the= validation process. The only way for the UA to affect the validation outco= me would be to change the IR Signing Package Attribute, however, this would= cause the signature to be invalid. = > 2) Section 2.2 allows the KeyID to be included in the Signed URI. This al= so > seems like it might open a security hole as a malicious UA could strip the > original URISigningPackage attribute, sign the URI with a Key under its c= ontrol > (possibly altering other things like the actual URI or expiry time) and i= nclude > the appropriate KeyID for that new Key in the new URISigningPackage. > = > Is there a use case for signalling the KeyID within the Signed URI itself? The use case for signaling the KeyID is the uCDN allowing multiple keys to = be used in the metadata. In order to signal the used Key to the dCDN, the K= eyID field is used. Let's assume that for a given content item, the uCDN allows five different = keys to be used (as announced in the metadata). You're right that if the UA= would somehow have access to one of these five keys, and the associated ke= yID, it could recalculate the URISigningPackage attribute. However, I don't= think this problem stems from the use of the KeyID field. Even if there wo= uld be only one key, and this key would be leaked, then the UA could also r= esign the UA. So the question is, is the chance of a given key leaking bigg= er if it is part of a set of allowed keys instead of the only allowed key? > = > 3) Regarding hash functions & digital signature algorithms, the draft hin= ts at > allowing several options for each and defines a default in case a particu= lar > algorithm is not specified in the URISigningPackage. > = > This seems a bit overkill to me. To aid inter-operability, I think it wou= ld be > better to specify a single algorithm for each unless there are use cases = for > requiring support for more than one algorithm in the first version define= d in > the draft? > = Are you saying you would prefer to keep the HF and DSA fields but only defi= ne one possible value for them in this document, or are you saying you woul= d prefer to remove these fields and just specify a single mandatory hash fu= nction and DS algorithm? Personally, I think it is useful to have the optio= n of signaling different hash functions or DS algorithms. = Thanks, Ray > Regards > Ben > = > = > On 6 Mar 2014, at 15:34, Daryl Malas wrote: > = > > All, > > > > During today's working group meeting, we agreed the latest draft revisi= on > of this draft (http://tools.ietf.org/html/draft-leung-cdni-uri-signing-05= ) is > substantial for us to adopt it as a working group item. However, Francoi= s and > I did not feel comfortable conducting a "Hum," since there were not a lot= of > people present who had read the draft. This draft was proposed in respon= se > to the following charter item: > > > > A specification for "CDNI URI Signing". This document will specify a > > mechanism that allows interconnected CDNs to support access control by > > signing content URIs. This may involve extensions to the CDNI > > interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). > > > > In addition, the working group has the following milestone: > > > > Sep 2014 - Submit specification of URI Signing for CDNI to IESG as > > Proposed Standard > > > > With this in mind, we are requesting people read the draft in preparati= on > for this draft to be accepted as a working group item, which will occur on > March 21st. If anyone has any major concerns with this, please post > comments and concerns to the list. > > > > Regards, > > > > Daryl & Francois > > > > > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni > = > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten. = This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. From nobody Mon May 5 08:48:15 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE95E1A00C6 for ; Mon, 5 May 2014 08:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.651] 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 gOWo3NoNJ6t9 for ; Mon, 5 May 2014 08:48:11 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3A40F1A0087 for ; Mon, 5 May 2014 08:48:11 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s45Fm3x5023138; Mon, 5 May 2014 09:48:03 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 05 May 2014 09:48:02 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0174.001; Mon, 5 May 2014 09:48:02 -0600 From: Daryl Malas To: "cdni@ietf.org" Thread-Topic: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a WG document Thread-Index: AQHPaHllHEVLXIIwS0KJeBpi0p3GNA== Date: Mon, 5 May 2014 15:48:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/Bl5CV19GH7Khw9t0X8YcuM6aofI Subject: Re: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 15:48:13 -0000 Taking off my chair hat, I have no issues with this draft becoming a working group item. URI Signing is discussed in the framework as a method for establishing trust (Section 6) and for controlling access (Section 8). The text in this draft elaborates on these two concepts. The figures also do a good job of extending the representation and usage of the CDNI framework. =8BDaryl On 4/25/14, 8:30 AM, "Francois Le Faucheur (flefauch)" wrote: >Folks, > >During the London meeting: > * authors confirmed that they believe the latest version of >draft-leung-cdni-uri-signing resolved the issue related to >draft-ietf-appsawg-uri-get-off-my-lawn-04.txt. > * WG chairs agreed to take to the list the question of adopting >draft-leung-cdni-uri-signing-05 as a WG document to ensure it gets >sufficient review. > >This message is to encourage review of draft-leung-cdni-uri-signing-05 >(http://tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and >sollicite feedback on adopting it as a WG document to address the >corresponding milestone on our charter. >Please do so by end of 12 May (ie within the next 2 weeks). > >Francois & Daryl, CDNI WG Chairs > > > >For convenience, quote from IETF-89 CDNI WG meeting minutes : >" >Daryl (as chair): This is a deliverable on our charter, but not many >people have read the draft yet, so will take question for WG adoption to >the list to give people time to read it. >=B3 > > >For convenience, relevant excerpt from the CDNI WG charter >(http://tools.ietf.org/wg/cdni/charters): >=B3 >The working group will focus on the following items: ><=8A> > - A specification for "CDNI URI Signing". This document will specify a > mechanism that allows interconnected CDNs to support access control > by signing content URIs. This may involve extensions to the CDNI > interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). > ><=8A> > >Goals and Milestones: ><=8A> > Sep 2014 - Submit specification of URI Signing for CDNI to IESG as >Proposed Standard >" >_______________________________________________ >CDNi mailing list >CDNi@ietf.org >https://www.ietf.org/mailman/listinfo/cdni From nobody Mon May 5 09:56:30 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1D31A017E; Mon, 5 May 2014 09:56: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 DX_E21pba1Gu; Mon, 5 May 2014 09:56:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B851A03A5; Mon, 5 May 2014 09:56:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140505165621.17506.511.idtracker@ietfa.amsl.com> Date: Mon, 05 May 2014 09:56:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/9eHWWovCn1oTrwcQaVs1qYxMneU Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-framework-11.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 16:56:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF. Title : Framework for CDN Interconnection Authors : Larry Peterson Bruce Davie Ray van Brandenburg Filename : draft-ietf-cdni-framework-11.txt Pages : 56 Date : 2014-05-05 Abstract: This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDN Interconnection requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. This document, in combination with RFC 6707, obsoletes RFC 3466. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-framework-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-framework-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 6 15:15:47 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E661A0636 for ; Tue, 6 May 2014 15:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Z0NkgA5bgEZ for ; Tue, 6 May 2014 15:15:42 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B174D1A049F for ; Tue, 6 May 2014 15:15:42 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-95-536910104153 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 4C.A6.07420.01019635; Tue, 6 May 2014 18:38:41 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Tue, 6 May 2014 18:15:38 -0400 From: Kevin Ma J To: "cdni@ietf.org" Thread-Topic: Review of draft-ietf-cdni-control-triggers-02 Thread-Index: Ac9peI0LAh6Z9mxCSYyIvRUaFcFOXQ== Date: Tue, 6 May 2014 22:15:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyuXRPrK6gQGawwemNXBZPZ/9hdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvYTn1gLJrhVzNx5ha2B8Zl+FyMnh4SAicTNI8+ZIWwxiQv3 1rN1MXJxCAkcZZRoWvqRGcJZxijx6/IfRpAqNgEticdf/zJ1MXJwiAgoS/w85AgSFhYwkziy 4w47iC0iYC3xcM0pVogSPYkXfRUgJouAisS8yYEgFbwC3hLbL39mBbEZgdZ+P7WGCcRmFhCX uPVkPhPEOQISS/achzpNVOLl43+sELaSxJzX15gh6nUkFuz+xAZha0ssW/iaGWK+oMTJmU9Y JjAKz0IydhaSlllIWmYhaVnAyLKKkaO0OLUsN93IYBMjMIiPSbDp7mDc89LyEKMAB6MSD++C TRnBQqyJZcWVuYcYpTlYlMR5C77EBgsJpCeWpGanphakFsUXleakFh9iZOLglGpgzIz9ytS9 74dkiq/In8dtmUp72ldGL3Wf0FW3NzCnVNi+OmL/kszERzmMSYKaTz1WGjiv4trbLHQ141C/ tan7nr9xlTaCjKp+zDaLcua+qtn+YeF1Afc9z1YJ2llpPn5dPSP90N4pG75VmoSIXXxSebb8 +8+vvt473V6lHVwuOeHF8kbuJ0evKrEUZyQaajEXFScCAL9cFPNDAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/ubGRH2Rd29C54SC3zvpcWzAAHEk Subject: [CDNi] Review of draft-ietf-cdni-control-triggers-02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 22:15:45 -0000 Hi All, Per the chairs' request for a detailed review of the triggers draft, I've compiled a list of comments below. thanx. -- Kevin J. Ma comments: - General: imo, an article in front of uCDN/dCDN (i.e., the uCDN/dCDN) makes for easier reading. - General: There are quite a few lower case "must"s (17), "shall"s (14), "should"s (7), and "may"s (36) in the document. Are they all intentionally non-normative?=20 - section 2: Should cancelling a trigger and removing a trigger status be separated in some way? Using DELETE for both means that if I wanted to cancel a trigger, I would have no way to get status on the cancelled trigger, since the status resource would be removed at the same time, and delete does not return a status, per the example in section 7.2.5 - section 2/4.1: In step 2 of figure 1, it mentions authentication as does section 4.1, but section 7 and 9 provide no guidance on either the authentication mechanism or what precisely is being authenticated. Presumably we are authenticating that it is a known uCDN making the request for metadata/content that is known to be owned by that uCDN? Should we state that? Do we have a suggestion (e.g., SSL client auth, HTTP basic/digest auth, etc.) for authentication method? - section 2.1: I found the wording of this sentance a little confusing. "If uCDN wishes to invalidate or purge content, then immediately preposition replacement content at the same URLs, it must ensure the dCDN has completed the invalidate/purge before initiating the prepositioning. If it fails to do that and the requests overlap, and dCDN passes the triggers on to a further dCDN in a cascade, that CDN may preposition content that has not yet been invalidated/purged in its uCDN." Perhaps something like: "If uCDN wishes to invalidate or purge content, then immediately preposition replacement content at the same URLs, it must ensure the dCDN and all cascaded dCDNs have completed the invalidate/purge before initiating the prepositioning, otherwise, a cascaded dCDN may attempt to preposition content that has not yet been invalidated/purge= d in its uCDN." - section 3: I would break this into two sentances: "The dCDN must present a different set of Trigger Status Resources to each interconnected uCDN, only Trigger Status Resources belonging to a uCDN shall be visible to it." i.e.: "The dCDN must present a different set of Trigger Status Resources to each interconnected uCDN. Only Trigger Status Resources belonging to a uCDN shall be visible to it." - section 3: This is the first mention of expiry. Perhaps a reference to Section 4.4? "This collection lists all uCDN triggers that have been accepted by dCDN, and have not yet been deleted by uCDN or expired and removed by dCDN." - section 4.1: These are the first mention of etime and mtime, perhaps there should be a reference to Section 5.2, or some type of explaination on what etime > mtime means. I am not sure about using of etime > mtime as an indicator. If mtime < now and etime < now, but still etime > mtime, it would seem to imply that the activity may be complete, but I don't think that is the intent? Should there be some normative language stating that if etime > mtime, the uCDN must update the status, and the dCDN must update mtime =3D now and etime > mtime? "If dCDN is not able to track triggered activity, it MAY indicate that it has undertaken to complete the activity but will not report completion or any further errors. To do this, it must set the trigger status to "complete", with an estimated completion time in the future ("etime" greater than "mtime")." - section 4.4: Why 24 hours? Seems fast? "It is recommended that Trigger Status Resources are automatically deleted 24 hours after they become completed or failed." - section 4.4: comma after: "If any part of the trigger request fails, " comma before: ", if the trigger is still running for some URLs or Patterns in the trigger request." perhaps clarify "cascaded" dCDNs: "pass a trigger request on to any of its affected cascaded dCDNs" - section 5.2: AbsoluteTime is a Unix Epoch, so should be UTC. I found the phrase "Time is local to dCDN" confusing as I first assumed "local" was referencing timezone, but I think "local" is just related to unsynchronized clocks? Perhaps: "Time is determined by the dCDN"? - section 5.4: links is a "List of Relationships". Why not just URLs? If the trigger collection can only reference trigger statuses, then why does it need typed relationships? The use of a relationship here seems overly complex? Is relationship standard JSON terminology? Should there be a reference to the acknowledged work of Mike Kelly? - section 6: There is a note about MI dependency. Is it just for PatternMatch? - section 6.1.6: "ralationship" -> "relationship" - section 6.1.6/6.1.7: I think it would be helpful to define the Relationship and Link objects the same way as all the other JSON objects, e.g.: How are the keys in the _links dictionary determined? And how is their meaning known? The key "self" seems to have a specific meaning? It is essentially a reserved keyword? Are there other reserved keywords (e.g., "Trigger"), and do they have to be registered somewhere? Relationship: Key: _links Description: List of related objects? Type: Array of LinkUnions Mandatory: Yes LinkUnion: Key: ??? Description: List of related objects? Type: Array of LinkUnions Mandatory: No. Key: ??? Description: related objects? Type: Link Mandatory: No. Link: Key: href Description: URI of the addressable object being referenced Type: URL Mandatory: Yes =20 Key: type Description: Type of the referenced object Type: MIME Media Type Mandatory: No - section 7: There are no examples with "base" or "links". I have an idea of how "base" might be used, but I don't know what the purpoes of "links" is. Can we add an example? "URLs are under control" -> "URLs are under the control" - section 7.2.1/7.2.2: I don't know where the key "Trigger" came from? Is it derived from some known object, or is it randomly selected (and somehow registered)? - section 7.2.5: Would there be value in returning the status on delete? - section 9: In the first sentance below, I interpret "access" as the ability to read (GET) a status object or collection. It does not necessarily imply to me who can issue a new trigger request? In the second sentance, it says it can only "affect" it's own content, which I guess implies that only it can affect it's own content, as another uCDN affecting it's content would violate this rule? Should we make that more explicit? "The dCDN must ensure that each uCDN only has access to its own Trigger Status Resources." "The dCDN must ensure that activity triggered by uCDN only affects metadata or content originating from that uCDN." e.g., update the second sentance to something like: "The dCDN must ensure that activity triggered by uCDN only affects metadata or content originating from that uCDN, and that no other uCDN may trigger activity that affects another uCDN's metadata or content." - random: The mention of only affecting a uCDN's own content made me think of the DNS diamond scenario. Do we believe that the Content URLs described in section 5.1.1 are sufficient to ensure this, or is there a caveat for the diamond case? "The dCDN must ensure that activity triggered by uCDN only affects metadata or content originating from that uCDN." From nobody Wed May 7 06:31:48 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128581A02C5 for ; Wed, 7 May 2014 06:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 SSRDY1jDkcqI for ; Wed, 7 May 2014 06:31:44 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id E2D831A0072 for ; Wed, 7 May 2014 06:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9692; q=dns/txt; s=iport; t=1399469500; x=1400679100; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ic0CWHUb6N0DA8Y991yWtlUWjfNK26UATeTt9MVV+yI=; b=KUnurI6Xi5Qf+qNiuCcXnS9UPuC0WfiAnmg0uJfU7satGqLL/76l/kKj qn1EgLnPdj6b+Z4HfRqAl7bmbbp75XH3uBmq1UVqbOhPj+FvDcFNIN3C3 m4B/lHaYktvWiIW9MNIquExFmNsthhLBGu7M+8PgX+TfBdmWe3yopjKXF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAOk0alOtJA2D/2dsb2JhbABagwZPWL1chzwBgRsWdIIlAQEBAwEBAQEkRwQHBQsCAQhGJwslAQEEDgWIOQgNz0UTBI4fMweDKoEVAQOZN4YtjE6DNG2BAAQ+ X-IronPort-AV: E=Sophos;i="4.97,1003,1389744000"; d="scan'208";a="41750690" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP; 07 May 2014 13:31:38 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s47DVcYh012759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 13:31:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Wed, 7 May 2014 08:31:38 -0500 From: "Francois Le Faucheur (flefauch)" To: Ma Kevin Thread-Topic: [CDNi] Review of draft-ietf-cdni-control-triggers-02 Thread-Index: Ac9peI0LAh6Z9mxCSYyIvRUaFcFOXQAqggMA Date: Wed, 7 May 2014 13:31:36 +0000 Message-ID: <956183FA-FD38-446D-8425-EA09B8E0A339@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.197] Content-Type: text/plain; charset="Windows-1252" Content-ID: <976495D034DE03409DB16B4AE3037D62@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/p5y5ohAXeRLWXyYw-TJkWFalWZI Cc: "cdni@ietf.org" Subject: Re: [CDNi] Review of draft-ietf-cdni-control-triggers-02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 13:31:46 -0000 Hi Kevin, Thanks much for the review. Let=92s hear from the editors on how to address your comments. Francois On 7 May 2014, at 00:15, Kevin Ma J wrote: > Hi All, >=20 > Per the chairs' request for a detailed review of the triggers draft, > I've compiled a list of comments below. >=20 > thanx. >=20 > -- Kevin J. Ma >=20 > comments: >=20 > - General: imo, an article in front of uCDN/dCDN (i.e., the uCDN/dCDN) > makes for easier reading. >=20 > - General: There are quite a few lower case "must"s (17), "shall"s (14), > "should"s (7), and "may"s (36) in the document. Are they all > intentionally non-normative?=20 >=20 > - section 2: Should cancelling a trigger and removing a trigger status > be separated in some way? Using DELETE for both means > that if I wanted to cancel a trigger, I would have no way > to get status on the cancelled trigger, since the status > resource would be removed at the same time, and delete > does not return a status, per the example in section 7.2.5 >=20 > - section 2/4.1: In step 2 of figure 1, it mentions authentication as > does section 4.1, but section 7 and 9 provide no > guidance on either the authentication mechanism or > what precisely is being authenticated. Presumably we > are authenticating that it is a known uCDN making the > request for metadata/content that is known to be owned > by that uCDN? Should we state that? >=20 > Do we have a suggestion (e.g., SSL client auth, HTTP > basic/digest auth, etc.) for authentication method? >=20 > - section 2.1: I found the wording of this sentance a little confusing. >=20 > "If uCDN wishes to invalidate or purge content, then immediately > preposition replacement content at the same URLs, it must ensure the > dCDN has completed the invalidate/purge before initiating the > prepositioning. If it fails to do that and the requests overlap, and > dCDN passes the triggers on to a further dCDN in a cascade, that CDN > may preposition content that has not yet been invalidated/purged in > its uCDN." >=20 > Perhaps something like: >=20 > "If uCDN wishes to invalidate or purge content, then immediately > preposition replacement content at the same URLs, it must ensure the > dCDN and all cascaded dCDNs have completed the invalidate/purge > before initiating the prepositioning, otherwise, a cascaded dCDN may > attempt to preposition content that has not yet been invalidated/purg= ed > in its uCDN." >=20 > - section 3: I would break this into two sentances: >=20 > "The dCDN must present a different set of Trigger Status Resources to > each interconnected uCDN, only Trigger Status Resources belonging to > a uCDN shall be visible to it." >=20 > i.e.: >=20 > "The dCDN must present a different set of Trigger Status Resources to > each interconnected uCDN. Only Trigger Status Resources belonging to > a uCDN shall be visible to it." >=20 > - section 3: This is the first mention of expiry. Perhaps a reference > to Section 4.4? >=20 > "This collection lists all > uCDN triggers that have been accepted by dCDN, and have not yet been > deleted by uCDN or expired and removed by dCDN." >=20 > - section 4.1: These are the first mention of etime and mtime, perhaps > there should be a reference to Section 5.2, or some > type of explaination on what etime > mtime means. >=20 > I am not sure about using of etime > mtime as an indicator. > If mtime < now and etime < now, but still etime > mtime, > it would seem to imply that the activity may be complete, > but I don't think that is the intent? >=20 > Should there be some normative language stating that if > etime > mtime, the uCDN must update the status, and the > dCDN must update mtime =3D now and etime > mtime? >=20 > "If dCDN is not able to track triggered activity, it MAY indicate that > it has undertaken to complete the activity but will not report > completion or any further errors. To do this, it must set the > trigger status to "complete", with an estimated completion time in > the future ("etime" greater than "mtime")." >=20 > - section 4.4: Why 24 hours? Seems fast? >=20 > "It > is recommended that Trigger Status Resources are automatically > deleted 24 hours after they become completed or failed." >=20 > - section 4.4: comma after: >=20 > "If any part of the trigger request fails, " >=20 > comma before: >=20 > ", if the trigger is still running for some URLs > or Patterns in the trigger request." >=20 > perhaps clarify "cascaded" dCDNs: >=20 > "pass a trigger request on to any of its affected cascaded dCDNs" >=20 > - section 5.2: AbsoluteTime is a Unix Epoch, so should be UTC. > I found the phrase "Time is local to dCDN" confusing as > I first assumed "local" was referencing timezone, but I > think "local" is just related to unsynchronized clocks? > Perhaps: "Time is determined by the dCDN"? >=20 > - section 5.4: links is a "List of Relationships". Why not just URLs? > If the trigger collection can only reference trigger > statuses, then why does it need typed relationships? > The use of a relationship here seems overly complex? >=20 > Is relationship standard JSON terminology? Should there > be a reference to the acknowledged work of Mike Kelly? >=20 > - section 6: There is a note about MI dependency. > Is it just for PatternMatch? >=20 > - section 6.1.6: "ralationship" -> "relationship" >=20 > - section 6.1.6/6.1.7: I think it would be helpful to define the > Relationship and Link objects the same way as > all the other JSON objects, e.g.: >=20 > How are the keys in the _links dictionary > determined? And how is their meaning known? > The key "self" seems to have a specific meaning? > It is essentially a reserved keyword? Are there > other reserved keywords (e.g., "Trigger"), and > do they have to be registered somewhere? >=20 > Relationship: > Key: _links > Description: List of related objects? > Type: Array of LinkUnions > Mandatory: Yes >=20 > LinkUnion: > Key: ??? > Description: List of related objects? > Type: Array of LinkUnions > Mandatory: No. >=20 > Key: ??? > Description: related objects? > Type: Link > Mandatory: No. >=20 > Link: > Key: href > Description: URI of the addressable object being referenced > Type: URL > Mandatory: Yes >=20 > Key: type > Description: Type of the referenced object > Type: MIME Media Type > Mandatory: No >=20 > - section 7: There are no examples with "base" or "links". I have an > idea of how "base" might be used, but I don't know what > the purpoes of "links" is. Can we add an example? >=20 > "URLs are under control" -> "URLs are under the control" >=20 > - section 7.2.1/7.2.2: I don't know where the key "Trigger" came from? > Is it derived from some known object, or is it > randomly selected (and somehow registered)? >=20 > - section 7.2.5: Would there be value in returning the status on delete? >=20 > - section 9: In the first sentance below, I interpret "access" as the > ability to read (GET) a status object or collection. It > does not necessarily imply to me who can issue a new > trigger request? In the second sentance, it says it can > only "affect" it's own content, which I guess implies > that only it can affect it's own content, as another uCDN > affecting it's content would violate this rule? Should > we make that more explicit? >=20 > "The dCDN must ensure that each uCDN only has access to its own > Trigger Status Resources." >=20 > "The dCDN must ensure that activity triggered by uCDN only affects > metadata or content originating from that uCDN." >=20 > e.g., update the second sentance to something like: >=20 > "The dCDN must ensure that activity triggered by uCDN only affects > metadata or content originating from that uCDN, and that no other > uCDN may trigger activity that affects another uCDN's metadata or > content." >=20 > - random: The mention of only affecting a uCDN's own content made me > think of the DNS diamond scenario. Do we believe that the > Content URLs described in section 5.1.1 are sufficient to > ensure this, or is there a caveat for the diamond case? >=20 > "The dCDN must ensure that activity triggered by uCDN only affects > metadata or content originating from that uCDN." >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Wed May 7 06:42:57 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CC11A02C5 for ; Wed, 7 May 2014 06:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 B1Jrp0nU9uMA for ; Wed, 7 May 2014 06:42:52 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id EEC511A0072 for ; Wed, 7 May 2014 06:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9621; q=dns/txt; s=iport; t=1399470168; x=1400679768; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ztdKDP9ZHPmVidFpvJzWios6UOqSdY1FjfEUHKrU/kc=; b=RVrjltx5TIrxfuWrwLqYpmwlV/INeqcyYrwpG+gQKSlShd0OO/Il5iDp NpDIGpPAjFNasKTa9Ps3rI5zevO4/Ni6p6DYgHXpp9Tg6M5RNHsMO3a0D Z3ja+U7kMXJQz/k8ZqlNm7o0OrsztWq+1eTVIMDq8ZNqdeJw/3GpvyNGS I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FAAw3alOtJA2N/2dsb2JhbABagwZPWLwagUIBhzsBgRsWdIIlAQEBBAEBAWsbAgEZAwECKAcnCxQJCAIEARIJiDgNz0YXjX4DAQE+DQoBBoMkgRUEmTeBPJE/gzRtgQk5 X-IronPort-AV: E=Sophos;i="4.97,1003,1389744000"; d="scan'208,217";a="41753796" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP; 07 May 2014 13:42:47 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s47DglUA012889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 13:42:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Wed, 7 May 2014 08:42:47 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" , "draft-leung-cdni-uri-signing@tools.ietf.org" Thread-Topic: Adoption of draft-leung-cdni-uri-signing as a WG document Thread-Index: AQHPafo7Fm/bsUFZ3ka0x9geqEbs1Q== Date: Wed, 7 May 2014 13:42:46 +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: [10.55.161.197] Content-Type: multipart/alternative; boundary="_000_D0F7064DD0744098AF9D61E4BDFE3ABBciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/kkyUl6Oba5kvWi80fUFuRXwG-Nw Subject: [CDNi] Adoption of draft-leung-cdni-uri-signing as a WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 13:42:54 -0000 --_000_D0F7064DD0744098AF9D61E4BDFE3ABBciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Folks, In addition to the support expressed in London, we=92ve heard as a result o= f the list poll: * statements of strong support (Kevin, Matt, Scott, Daryl) * a statement of conditional support (Ben) * no objection/concern. So we (WG Chairs) confirm adoption of draft-leung-cdni-uri-signing as a WG = document, conditioned to resolution of Ben=92s comments. To draft authors, Please continue the discussion (on the WG mailer) with Ben to converge on h= ow to best address his comments, and then post a new version of the draft a= s draft-ietf-cdni-uri-signing-00. Cheers Francois On 25 Apr 2014, at 16:51, Francois Le Faucheur (flefauch) > wrote: Folks, Just to be clear, this is a follow up from Daryl=92s earlier message of 25 = April (http://www.ietf.org/mail-archive/web/cdni/current/msg01837.html), wh= ich issued a similar request. We did not received much feedback so would li= ke to give another opportunity for more feedback. Francois Begin forwarded message: From: "Francois Le Faucheur (flefauch)" > Subject: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a W= G document Date: 25 April 2014 16:30:08 CEST To: "cdni@ietf.org" > Folks, During the London meeting: * authors confirmed that they believe the latest version of draft-leung-cdn= i-uri-signing resolved the issue related to draft-ietf-appsawg-uri-get-off-= my-lawn-04.txt. * WG chairs agreed to take to the list the question of adopting draft-leung= -cdni-uri-signing-05 as a WG document to ensure it gets sufficient review. This message is to encourage review of draft-leung-cdni-uri-signing-05 (htt= p://tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and sollicite fe= edback on adopting it as a WG document to address the corresponding milesto= ne on our charter. Please do so by end of 12 May (ie within the next 2 weeks). Francois & Daryl, CDNI WG Chairs For convenience, quote from IETF-89 CDNI WG meeting minutes : " Daryl (as chair): This is a deliverable on our charter, but not many people= have read the draft yet, so will take question for WG adoption to the list= to give people time to read it. =93 For convenience, relevant excerpt from the CDNI WG charter (http://tools.ie= tf.org/wg/cdni/charters): =93 The working group will focus on the following items: <=85> - A specification for "CDNI URI Signing". This document will specify a mechanism that allows interconnected CDNs to support access control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). <=85> Goals and Milestones: <=85> Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Propose= d Standard " _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_D0F7064DD0744098AF9D61E4BDFE3ABBciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6BB4E0DD0C9A69429B0D892C7F44B40B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Folks,
In addition to the support expressed in London, we=92ve heard as a res= ult of the list poll:
* = ;statements of strong support (Kevin, Matt, Scott, Daryl)
* a st= atement of conditional support (Ben)
* no o= bjection/concern.
So we (WG Chairs) confirm adoption of draft-leung-cdni-uri-signin= g as a WG document, conditioned to resolution of Ben=92s comments.

To draft authors,
Please continue the discussion (on the WG mailer) with Ben to converge= on how to best address his comments, and then post a new version of the dr= aft as draft-ietf-cdni-uri-signing-00.

Cheers

Francois

On 25 Apr 2014, at 16:51, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:

Folks,

Just to be clear, this is a follow up from Daryl=92s earlier message o= f 25 April (http://www.ietf.org/mail-archive/web/cdni/current/msg01837.htm= l), which issued a similar request. We did not received much feedback so would like to give another opportunit= y for more feedback.

Francois

Begin forwarded message:

From: "Francois Le Faucheur (flefauch)" <<= a href=3D"mailto:flefauch@cisco.com">flefauch@cisco.com>
Subject: [CDNi] Poll for adoption of draft-leung-cd= ni-uri-signing-05 as a WG document
Date: 25 April 2014 16:30:08 CEST

Folks,

During the London meeting:
* authors c= onfirmed that they believe the latest version of draft-leung-cdni-uri-signi= ng resolved the issue related to draft-ietf-appsawg-uri-get-off-my-lawn-04.= txt.
* WG chairs= agreed to take to the list the question of adopting draft-leung-cdni-uri-s= igning-05 as a WG document to ensure it gets sufficient review.

This message is to encourage review of draft-leung-cdni-uri-signing-05 (http:= //tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and sollicite = feedback on adopting it as a WG document to address the corresponding milestone on our charter.
Please do so by end of 12 May (ie within the next 2 weeks).

Francois & Daryl, CDNI WG Chairs



For convenience, quote from IETF-89 CDNI WG meeting minutes :
"
Daryl (as chair): This is a deliverable on our charter, but not many people= have read the draft yet, so will take question for WG adoption to the list= to give people time to read it.
=93


For convenience, relevant excerpt from the CDNI WG charter (http://tools.ietf.org/wg/cdni/charters<= /a>):
=93
The working group will focus on the following items:
<=85>
 - A specification for "CDNI URI Signing". This document wil= l specify a
   mechanism that allows interconnected CDNs to support acce= ss control
   by signing content URIs. This may involve extensions to t= he CDNI
   interfaces (e.g. CDNI Metadata interface, CDNI Logging in= terface).

<=85>

Goals and Milestones:
<=85>
 Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Pr= oposed Standard
"
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni

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

--_000_D0F7064DD0744098AF9D61E4BDFE3ABBciscocom_-- From nobody Wed May 7 06:53:16 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1DB1A0302 for ; Wed, 7 May 2014 06:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 J3Kij6ScXfgR for ; Wed, 7 May 2014 06:53:11 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id F330C1A0771 for ; Wed, 7 May 2014 06:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11491; q=dns/txt; s=iport; t=1399470787; x=1400680387; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=/J/sGIN8R1qQNgAc1gku6i9aqgYQBKlG1gaUDHH4dJ4=; b=DVAhIMgy0CccxSz37mja51/dJvaDnaXPUS47J2FyvidBANP2L1mqIssC EmUz9pUQ06BMS6g5QVJzSSpsuljFAqmawaVPtqpz95d7/8k5VGtRI+CYw UwliIpmFr/I+jDiploutM/vBSQ4QI7wOXJ+o6peY/ugMAlgvnFOZlUqCj 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FAFY6alOtJA2E/2dsb2JhbABagwZPWLwagUIBhzsBgRsWdIIlAQEBBAEBAWsbAgEIEQMBAigHJwsUCQgCBAESCYg4Dc9PF41+AwEBPg0KAQaDJIEVBJk3gTyRP4M0bYEJOQ X-IronPort-AV: E=Sophos;i="4.97,1003,1389744000"; d="scan'208,217";a="323056227" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP; 07 May 2014 13:52:56 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s47Dqukn017807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 13:52:56 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Wed, 7 May 2014 08:52:55 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" , "draft-leung-cdni-uri-signing@tools.ietf.org" Thread-Topic: [CDNi] Adoption of draft-leung-cdni-uri-signing as a WG document Thread-Index: AQHPafo7Fm/bsUFZ3ka0x9geqEbs1Zs1dykA Date: Wed, 7 May 2014 13:52:54 +0000 Message-ID: <0DB89F92-A961-4EF9-B94C-2787B0E4BDAA@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.197] Content-Type: multipart/alternative; boundary="_000_0DB89F92A9614EF9B94C2787B0E4BDAAciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/Xzmow1phsNHJ5eRxAEYtuZYBGNk Subject: Re: [CDNi] Adoption of draft-leung-cdni-uri-signing as a WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 13:53:13 -0000 --_000_0DB89F92A9614EF9B94C2787B0E4BDAAciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, I incorrectly thought the poll deadline was May 5th, but it was set to May = 12th in my poll message below. So just to make sure we are not preventing a= nyone from posting their feedback, let=92s hold off on the announcement bel= ow until May 12th. We=92ll revaluate the decision then based on additional = feedback. Cheers Francois PS: I guess going on holidays can make one lose the notion of time ... On 7 May 2014, at 15:42, Francois Le Faucheur (flefauch) > wrote: Folks, In addition to the support expressed in London, we=92ve heard as a result o= f the list poll: * statements of strong support (Kevin, Matt, Scott, Daryl) * a statement of conditional support (Ben) * no objection/concern. So we (WG Chairs) confirm adoption of draft-leung-cdni-uri-signing as a WG = document, conditioned to resolution of Ben=92s comments. To draft authors, Please continue the discussion (on the WG mailer) with Ben to converge on h= ow to best address his comments, and then post a new version of the draft a= s draft-ietf-cdni-uri-signing-00. Cheers Francois On 25 Apr 2014, at 16:51, Francois Le Faucheur (flefauch) > wrote: Folks, Just to be clear, this is a follow up from Daryl=92s earlier message of 25 = April (http://www.ietf.org/mail-archive/web/cdni/current/msg01837.html), wh= ich issued a similar request. We did not received much feedback so would li= ke to give another opportunity for more feedback. Francois Begin forwarded message: From: "Francois Le Faucheur (flefauch)" > Subject: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a W= G document Date: 25 April 2014 16:30:08 CEST To: "cdni@ietf.org" > Folks, During the London meeting: * authors confirmed that they believe the latest version of draft-leung-cdn= i-uri-signing resolved the issue related to draft-ietf-appsawg-uri-get-off-= my-lawn-04.txt. * WG chairs agreed to take to the list the question of adopting draft-leung= -cdni-uri-signing-05 as a WG document to ensure it gets sufficient review. This message is to encourage review of draft-leung-cdni-uri-signing-05 (htt= p://tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and sollicite fe= edback on adopting it as a WG document to address the corresponding milesto= ne on our charter. Please do so by end of 12 May (ie within the next 2 weeks). Francois & Daryl, CDNI WG Chairs For convenience, quote from IETF-89 CDNI WG meeting minutes : " Daryl (as chair): This is a deliverable on our charter, but not many people= have read the draft yet, so will take question for WG adoption to the list= to give people time to read it. =93 For convenience, relevant excerpt from the CDNI WG charter (http://tools.ie= tf.org/wg/cdni/charters): =93 The working group will focus on the following items: <=85> - A specification for "CDNI URI Signing". This document will specify a mechanism that allows interconnected CDNs to support access control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). <=85> Goals and Milestones: <=85> Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Propose= d Standard " _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_0DB89F92A9614EF9B94C2787B0E4BDAAciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable All,

I incorrectly thought the poll deadline was May 5th, but it was set to= May 12th in my poll message below. So just to make sure we are not prevent= ing anyone from posting their feedback, let=92s hold off on the announcemen= t below until May 12th. We=92ll revaluate the decision then based on additional feedback.

Cheers

Francois

PS: I guess going on holidays can make one lose the notion of time ...=

On 7 May 2014, at 15:42, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:

Folks,
In addition to the support expressed in London, we=92ve heard as a res= ult of the list poll:
* = ;statements of strong support (Kevin, Matt, Scott, Daryl)
* a st= atement of conditional support (Ben)
* no o= bjection/concern.
So we (WG Chairs) confirm adoption of draft-leung-cdni-uri-signin= g as a WG document, conditioned to resolution of Ben=92s comments.

To draft authors,
Please continue the discussion (on the WG mailer) with Ben to converge= on how to best address his comments, and then post a new version of the dr= aft as draft-ietf-cdni-uri-signing-00.

Cheers

Francois

On 25 Apr 2014, at 16:51, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:

Folks,

Just to be clear, this is a follow up from Daryl=92s earlier message o= f 25 April (http://www.ietf.org/mail-archive/web/cdni/current/msg01837.htm= l), which issued a similar request. We did not received much feedback so would like to give another opportunit= y for more feedback.

Francois

Begin forwarded message:

From: "Francois Le Faucheur (flefauch)" <<= a href=3D"mailto:flefauch@cisco.com">flefauch@cisco.com>
Subject: [CDNi] Poll for adoption of draft-leung-cd= ni-uri-signing-05 as a WG document
Date: 25 April 2014 16:30:08 CEST

Folks,

During the London meeting:
* authors c= onfirmed that they believe the latest version of draft-leung-cdni-uri-signi= ng resolved the issue related to draft-ietf-appsawg-uri-get-off-my-lawn-04.= txt.
* WG chairs= agreed to take to the list the question of adopting draft-leung-cdni-uri-s= igning-05 as a WG document to ensure it gets sufficient review.

This message is to encourage review of draft-leung-cdni-uri-signing-05 (http:= //tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and sollicite = feedback on adopting it as a WG document to address the corresponding milestone on our charter.
Please do so by end of 12 May (ie within the next 2 weeks).

Francois & Daryl, CDNI WG Chairs



For convenience, quote from IETF-89 CDNI WG meeting minutes :
"
Daryl (as chair): This is a deliverable on our charter, but not many people= have read the draft yet, so will take question for WG adoption to the list= to give people time to read it.
=93


For convenience, relevant excerpt from the CDNI WG charter (http://tools.ietf.org/wg/cdni/charters<= /a>):
=93
The working group will focus on the following items:
<=85>
 - A specification for "CDNI URI Signing". This document wil= l specify a
   mechanism that allows interconnected CDNs to support acce= ss control
   by signing content URIs. This may involve extensions to t= he CDNI
   interfaces (e.g. CDNI Metadata interface, CDNI Logging in= terface).

<=85>

Goals and Milestones:
<=85>
 Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Pr= oposed Standard
"
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni

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

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

--_000_0DB89F92A9614EF9B94C2787B0E4BDAAciscocom_-- From nobody Mon May 12 03:10:55 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C07C1A0667 for ; Mon, 12 May 2014 03:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 JPKdooOtOQBs for ; Mon, 12 May 2014 03:10:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 78C971A0665 for ; Mon, 12 May 2014 03:10:46 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id BA4432AC720; Mon, 12 May 2014 12:10:38 +0200 (CEST) Received: from pmexch31.intranet-paris.francetelecom.fr (unknown [10.100.76.21]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id A2BF9384061; Mon, 12 May 2014 12:10:38 +0200 (CEST) Received: from PMEXCB1D.intranet-paris.francetelecom.fr ([10.100.76.13]) by pmexch31.intranet-paris.francetelecom.fr ([10.100.76.21]) with mapi; Mon, 12 May 2014 12:10:38 +0200 From: To: "Francois Le Faucheur (flefauch)" , "cdni@ietf.org" , "draft-leung-cdni-uri-signing@tools.ietf.org" Date: Mon, 12 May 2014 12:10:37 +0200 Thread-Topic: [CDNi] Adoption of draft-leung-cdni-uri-signing as a WG document Thread-Index: AQHPafo7Fm/bsUFZ3ka0x9geqEbs1Zs1dykAgAdD7yA= Message-ID: <28257_1399889438_53709E1E_28257_9427_13_8F0D2F5E4AAB7249BC7339A3E944DEDD2284B99CB5@PMEXCB1D.intranet-paris.francetelecom.fr> References: <0DB89F92-A961-4EF9-B94C-2787B0E4BDAA@cisco.com> In-Reply-To: <0DB89F92-A961-4EF9-B94C-2787B0E4BDAA@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_8F0D2F5E4AAB7249BC7339A3E944DEDD2284B99CB5PMEXCB1Dintra_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.5.12.2118 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/LkmyIhA884YDlOsyqTHCjLRE_Ms Subject: Re: [CDNi] Adoption of draft-leung-cdni-uri-signing as a WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 10:10:51 -0000 --_000_8F0D2F5E4AAB7249BC7339A3E944DEDD2284B99CB5PMEXCB1Dintra_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello IETF-ers, As previously stated, the current version of the draft is a good starting p= oint. After a quick chat with one of my colleagues, there are a few aspects that = we'd like to mention: 1. It seems that all CSPs share the same format of the URI signing, w= hich might be a disadvantage as they often seem to have various specific me= thods. I know we are trying to achieve interoperability, but maybe it would= be worth adding another parameter to give more flexibility in the choice o= f signing method (other than VER that doesn't seem well suited for this pur= pose). 2. For the objects presented in Section 5.4, I am not sure of my unde= rstanding of the set of dCDNs sharing a symmetric key with the uCDN. Can th= at be a security issue where a dCDN can spoof another dCDN that's using the= same key? 3. There seems to be a need to include the scenario in which there ar= e several users on a home LAN that are behind a box that does NAT. It would= be good to have a way to differentiate each individual request coming from= the devices on the same network. To be picky, maybe the example used in the draft could use an IP address th= at is in line with RFC 6761 instead of the classic private 10.0.0.1. -- iuniana De : CDNi [mailto:cdni-bounces@ietf.org] De la part de Francois Le Faucheur= (flefauch) Envoy=E9 : mercredi 7 mai 2014 15:53 =C0 : cdni@ietf.org; draft-leung-cdni-uri-signing@tools.ietf.org Objet : Re: [CDNi] Adoption of draft-leung-cdni-uri-signing as a WG document All, I incorrectly thought the poll deadline was May 5th, but it was set to May = 12th in my poll message below. So just to make sure we are not preventing a= nyone from posting their feedback, let's hold off on the announcement below= until May 12th. We'll revaluate the decision then based on additional feed= back. Cheers Francois PS: I guess going on holidays can make one lose the notion of time ... On 7 May 2014, at 15:42, Francois Le Faucheur (flefauch) > wrote: Folks, In addition to the support expressed in London, we've heard as a result of = the list poll: * statements of strong support (Kevin, Matt, Scott, Daryl) * a statement of conditional support (Ben) * no objection/concern. So we (WG Chairs) confirm adoption of draft-leung-cdni-uri-signing as a WG = document, conditioned to resolution of Ben's comments. To draft authors, Please continue the discussion (on the WG mailer) with Ben to converge on h= ow to best address his comments, and then post a new version of the draft a= s draft-ietf-cdni-uri-signing-00. Cheers Francois On 25 Apr 2014, at 16:51, Francois Le Faucheur (flefauch) > wrote: Folks, Just to be clear, this is a follow up from Daryl's earlier message of 25 Ap= ril (http://www.ietf.org/mail-archive/web/cdni/current/msg01837.html), whic= h issued a similar request. We did not received much feedback so would like= to give another opportunity for more feedback. Francois Begin forwarded message: From: "Francois Le Faucheur (flefauch)" > Subject: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a W= G document Date: 25 April 2014 16:30:08 CEST To: "cdni@ietf.org" > Folks, During the London meeting: * authors confirmed that they believe the latest version of draft-leung-cdn= i-uri-signing resolved the issue related to draft-ietf-appsawg-uri-get-off-= my-lawn-04.txt. * WG chairs agreed to take to the list the question of adopting draft-leung= -cdni-uri-signing-05 as a WG document to ensure it gets sufficient review. This message is to encourage review of draft-leung-cdni-uri-signing-05 (htt= p://tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and sollicite fe= edback on adopting it as a WG document to address the corresponding milesto= ne on our charter. Please do so by end of 12 May (ie within the next 2 weeks). Francois & Daryl, CDNI WG Chairs For convenience, quote from IETF-89 CDNI WG meeting minutes : " Daryl (as chair): This is a deliverable on our charter, but not many people= have read the draft yet, so will take question for WG adoption to the list= to give people time to read it. " For convenience, relevant excerpt from the CDNI WG charter (http://tools.ie= tf.org/wg/cdni/charters): " The working group will focus on the following items: <...> - A specification for "CDNI URI Signing". This document will specify a mechanism that allows interconnected CDNs to support access control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). <...> Goals and Milestones: <...> Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Propose= d Standard " _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8F0D2F5E4AAB7249BC7339A3E944DEDD2284B99CB5PMEXCB1Dintra_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello IETF-= ers,

 

As previously stated, the c= urrent version of the draft is a good starting point.

 

After a quick chat with one of my colle= agues, there are a few aspects that we’d like to mention:<= /span>

 =

1.   &= nbsp;   It s= eems that all CSPs share the same format of the URI signing, which might be= a disadvantage as they often seem to have various specific methods. I know= we are trying to achieve interoperability, but maybe it would be worth add= ing another parameter to give more flexibility in the choice of signing met= hod (other than VER that doesn’t seem well suited for this purpose).<= o:p>

2.=        For the objects presented in Section 5.4, I am not sure of my = understanding of the set of dCDNs sharing a symmetric key with the uCDN. Ca= n that be a security issue where a dCDN can spoof another dCDN that’s= using the same key?

3.       There seems to be a need to include the sce= nario in which there are several users on a home LAN that are behind a box = that does NAT. It would be good to have a way to differentiate each individ= ual request coming from the devices on the same network.<= /p>

 

To be picky, maybe the example used i= n the draft could use an IP address that is in line with RFC 6761 instead o= f the classic private 10.0.0.1.

<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser= if";color:#CC3399'> 

-- iuniana

 

 

De : CDNi [mailto:cdni-bounces@ietf.org] De l= a part de Francois Le Faucheur (flefauch)
Envoy=E9 : mer= credi 7 mai 2014 15:53
=C0 : cdni@ietf.org; draft-leung-cdni= -uri-signing@tools.ietf.org
Objet : Re: [CDNi] Adoption of d= raft-leung-cdni-uri-signing as a WG document

 

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>All,

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'> 

I incorrectly thoug= ht the poll deadline was May 5th, but it was set to May 12th in my poll mes= sage below. So just to make sure we are not preventing anyone from posting = their feedback, let’s hold off on the announcement below until May 12= th. We’ll revaluate the decision then based on additional feedback.

<= o:p> 

Cheers

 

Francois

 

PS: I guess going on holidays can make = one lose the notion of time ...

 

On 7 May 2014, at 15:42, Francois Le = Faucheur (flefauch) <flefauch@cisc= o.com> wrote:



Folks,

In addition to the support expressed in London, weR= 17;ve heard as a result of the list poll:

* statements of strong suppo= rt (Kevin, Matt, Scott, Daryl)

* a statement of conditional support (Ben)

*= no objection/concern.

So we (WG Chairs) confirm adoption of draft-le= ung-cdni-uri-signing as a WG document, conditioned to resolution of BenR= 17;s comments.

 

To draft authors,

Please continue the discussion (o= n the WG mailer) with Ben to converge on how to best address his comments, = and then post a new version of the draft as draft-ietf-cdni-uri-signing-00.=

 

Cheers

 

Francois

 

On 25 Apr 2014, at 16:51, Francois L= e Faucheur (flefauch) <flefauch@ci= sco.com> wrote:



Folks,

 

Just to be clear, this is a follo= w up from Daryl’s earlier message of 25 April (http://www.ietf.org/m= ail-archive/web/cdni/current/msg01837.html), which issued a similar req= uest. We did not received much feedback so would like to give another oppor= tunity for more feedback.

 

Francois

 

Begin forwarded message:



From: "Francois Le Faucheur (flefa= uch)" <flefauch@cisco.com= >

Subject= : [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a WG docum= ent

Date= : 25 April = 2014 16:30:08 CEST

=

 

Folks,

During the= London meeting:
* authors confirmed that they believe the latest versio= n of draft-leung-cdni-uri-signing resolved the issue related to draft-ietf-= appsawg-uri-get-off-my-lawn-04.txt.
* WG chairs agreed to take to the li= st the question of adopting draft-leung-cdni-uri-signing-05 as a WG documen= t to ensure it gets sufficient review.

This message is to encourage = review of draft-leung-cdni-uri-signing-05 (http://tools.ietf.org/id/draft-leu= ng-cdni-uri-signing-05.txt) and sollicite feedback on adopting it as a = WG document to address the corresponding milestone on our charter.
Pleas= e do so by end of 12 May (ie within the next 2 weeks).

Francois &= ; Daryl, CDNI WG Chairs



For convenience, quote from IETF-89 = CDNI WG meeting minutes :
"
Daryl (as chair): This is a delivera= ble on our charter, but not many people have read the draft yet, so will ta= ke question for WG adoption to the list to give people time to read it. “


For convenience, relevant excerpt from the CDNI WG char= ter (http://tools.ietf.o= rg/wg/cdni/charters):
“
The working group will focus on the= following items:
<…>
 - A specification for "C= DNI URI Signing". This document will specify a
   me= chanism that allows interconnected CDNs to support access control
 =   by signing content URIs. This may involve extensions to the CDN= I
   interfaces (e.g. CDNI Metadata interface, CDNI Loggi= ng interface).

<…>

Goals and Milestones:
<&= #8230;>
 Sep 2014 - Submit specification of URI Signing for CDNI= to IESG as Proposed Standard
"
________________________________= _______________
CDNi mailing list
CD= Ni@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/cdni

 

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>__________________________= _____________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

 

<= /div>

____________________= ___________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

 

<= /div>
___________________________________________________________=
______________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_8F0D2F5E4AAB7249BC7339A3E944DEDD2284B99CB5PMEXCB1Dintra_-- From nobody Mon May 12 04:42:47 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0141A0675 for ; Mon, 12 May 2014 04:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 2wVsg8T3vhMI for ; Mon, 12 May 2014 04:42:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2C24F1A069B for ; Mon, 12 May 2014 04:42:33 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 47E773743AB; Mon, 12 May 2014 13:42:26 +0200 (CEST) Received: from PMEXCH41.intranet-paris.francetelecom.fr (unknown [10.100.76.22]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 2B3AE180053; Mon, 12 May 2014 13:42:26 +0200 (CEST) Received: from PMEXCB1D.intranet-paris.francetelecom.fr ([10.100.76.13]) by PMEXCH41.intranet-paris.francetelecom.fr ([10.100.76.22]) with mapi; Mon, 12 May 2014 13:42:25 +0200 From: To: "Francois Le Faucheur (flefauch)" , "cdni@ietf.org" , "draft-leung-cdni-uri-signing@tools.ietf.org" Date: Mon, 12 May 2014 13:42:24 +0200 Thread-Topic: Adoption of draft-leung-cdni-uri-signing as a WG document Thread-Index: AQHPafo7Fm/bsUFZ3ka0x9geqEbs1Zs82iRw Message-ID: <28917_1399894946_5370B3A2_28917_4019_1_8F0D2F5E4AAB7249BC7339A3E944DEDD2284B99D21@PMEXCB1D.intranet-paris.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_8F0D2F5E4AAB7249BC7339A3E944DEDD2284B99D21PMEXCB1Dintra_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.5.12.2118 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/je5meS621CUNBjjC7YhBQrsKiHo Subject: Re: [CDNi] Adoption of draft-leung-cdni-uri-signing as a WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 11:42:44 -0000 --_000_8F0D2F5E4AAB7249BC7339A3E944DEDD2284B99D21PMEXCB1Dintra_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Someone pointed out it should have been RFC 6890 for documentation IP range= s. My humble excuses, -- iuniana De : CDNi [mailto:cdni-bounces@ietf.org] De la part de Francois Le Faucheur= (flefauch) Envoy=E9 : mercredi 7 mai 2014 15:43 =C0 : cdni@ietf.org; draft-leung-cdni-uri-signing@tools.ietf.org Objet : [CDNi] Adoption of draft-leung-cdni-uri-signing as a WG document Folks, In addition to the support expressed in London, we've heard as a result of = the list poll: * statements of strong support (Kevin, Matt, Scott, Daryl) * a statement of conditional support (Ben) * no objection/concern. So we (WG Chairs) confirm adoption of draft-leung-cdni-uri-signing as a WG = document, conditioned to resolution of Ben's comments. To draft authors, Please continue the discussion (on the WG mailer) with Ben to converge on h= ow to best address his comments, and then post a new version of the draft a= s draft-ietf-cdni-uri-signing-00. Cheers Francois On 25 Apr 2014, at 16:51, Francois Le Faucheur (flefauch) > wrote: Folks, Just to be clear, this is a follow up from Daryl's earlier message of 25 Ap= ril (http://www.ietf.org/mail-archive/web/cdni/current/msg01837.html), whic= h issued a similar request. We did not received much feedback so would like= to give another opportunity for more feedback. Francois Begin forwarded message: From: "Francois Le Faucheur (flefauch)" > Subject: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a W= G document Date: 25 April 2014 16:30:08 CEST To: "cdni@ietf.org" > Folks, During the London meeting: * authors confirmed that they believe the latest version of draft-leung-cdn= i-uri-signing resolved the issue related to draft-ietf-appsawg-uri-get-off-= my-lawn-04.txt. * WG chairs agreed to take to the list the question of adopting draft-leung= -cdni-uri-signing-05 as a WG document to ensure it gets sufficient review. This message is to encourage review of draft-leung-cdni-uri-signing-05 (htt= p://tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and sollicite fe= edback on adopting it as a WG document to address the corresponding milesto= ne on our charter. Please do so by end of 12 May (ie within the next 2 weeks). Francois & Daryl, CDNI WG Chairs For convenience, quote from IETF-89 CDNI WG meeting minutes : " Daryl (as chair): This is a deliverable on our charter, but not many people= have read the draft yet, so will take question for WG adoption to the list= to give people time to read it. " For convenience, relevant excerpt from the CDNI WG charter (http://tools.ie= tf.org/wg/cdni/charters): " The working group will focus on the following items: <...> - A specification for "CDNI URI Signing". This document will specify a mechanism that allows interconnected CDNs to support access control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). <...> Goals and Milestones: <...> Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Propose= d Standard " _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8F0D2F5E4AAB7249BC7339A3E944DEDD2284B99D21PMEXCB1Dintra_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Someone pointed out it should have been RFC 6890 for documentation IP ran= ges.

&nb= sp;

My humble excu= ses,

-- iunia= na

 = ;

De : CDNi [mailto:cdni-bounces@ietf.org] De la part de Fra= ncois Le Faucheur (flefauch)
Envoy=E9 : mercredi 7 mai 2014 = 15:43
=C0 : cdni@ietf.org; draft-leung-cdni-uri-signing@tool= s.ietf.org
Objet : [CDNi] Adoption of draft-leung-cdni-uri-s= igning as a WG document

 

Folks,

In addition to the support expressed in Londo= n, we’ve heard as a result of the list poll:

* statements of str= ong support (Kevin, Matt, Scott, Daryl)

* a statement of conditional supp= ort (Ben)

* no objection/concern.

So we (WG Chairs) confirm adoption of&nbs= p;draft-leung-cdni-uri-signing as a WG document, conditioned to resolution = of Ben’s comments.

 

To draft authors,

=

Please continue the discu= ssion (on the WG mailer) with Ben to converge on how to best address his co= mments, and then post a new version of the draft as draft-ietf-cdni-uri-sig= ning-00.

 

Cheers

 

Francois

 

On 25 Apr 2014, at 16:51, F= rancois Le Faucheur (flefauch) <fl= efauch@cisco.com> wrote:



Folks,

 

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>Just to be clear, this is = a follow up from Daryl’s earlier message of 25 April (http://www.iet= f.org/mail-archive/web/cdni/current/msg01837.html), which issued a simi= lar request. We did not received much feedback so would like to give anothe= r opportunity for more feedback.

 

Francois

 

Begin forwarded message= :


= From: "Francois Le Fauche= ur (flefauch)" <flefauch@cisc= o.com>

Subject: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a= WG document

Date: = 25 April 2014 16:30:08 CEST

 =

Folks,

Du= ring the London meeting:
* authors confirmed that they believe the lates= t version of draft-leung-cdni-uri-signing resolved the issue related to dra= ft-ietf-appsawg-uri-get-off-my-lawn-04.txt.
* WG chairs agreed to take t= o the list the question of adopting draft-leung-cdni-uri-signing-05 as a WG= document to ensure it gets sufficient review.

This message is to en= courage review of draft-leung-cdni-uri-signing-05 (http://tools.ietf.org/id/d= raft-leung-cdni-uri-signing-05.txt) and sollicite feedback on adopting = it as a WG document to address the corresponding milestone on our charter.<= br>Please do so by end of 12 May (ie within the next 2 weeks).

Franc= ois & Daryl, CDNI WG Chairs



For convenience, quote from = IETF-89 CDNI WG meeting minutes :
"
Daryl (as chair): This is a = deliverable on our charter, but not many people have read the draft yet, so= will take question for WG adoption to the list to give people time to read= it.
“


For convenience, relevant excerpt from the CDNI= WG charter (http://tool= s.ietf.org/wg/cdni/charters):
“
The working group will focu= s on the following items:
<…>
 - A specification for= "CDNI URI Signing". This document will specify a
  =  mechanism that allows interconnected CDNs to support access control   by signing content URIs. This may involve extensions to= the CDNI
   interfaces (e.g. CDNI Metadata interface, CD= NI Logging interface).

<…>

Goals and Milestones:<= br><…>
 Sep 2014 - Submit specification of URI Signing = for CDNI to IESG as Proposed Standard
"
________________________= _______________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

<= /div>

 

__________________= _____________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

<= /div>

 

_________________________________________________________=
________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_8F0D2F5E4AAB7249BC7339A3E944DEDD2284B99D21PMEXCB1Dintra_-- From nobody Mon May 12 06:11:40 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86C31A0706 for ; Mon, 12 May 2014 06:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.551 X-Spam-Level: X-Spam-Status: No, score=-9.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 cAR0Ia5CUACg for ; Mon, 12 May 2014 06:11:29 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF441A031E for ; Mon, 12 May 2014 06:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30606; q=dns/txt; s=iport; t=1399900282; x=1401109882; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iEirt5FwtnbOICVRljjt7y3M9MdMfje+vMgTgYjqDHE=; b=RV4mP2G7Q2aPaIxQOzoVJ0sTzLP2Uj8ph3xjkppHWY6yuyNvuBpDjCgd B8Msn8dTbbHwVruTj9BGWMfDy7ntrI29UnYh/oMgXK2wlX9Paa6+h4ZPL 3rV+ttelMfB61ciG+HNlIhUuFYLJNOlemsLy/PsGZWxClvzm35vAmw2nd Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUFAL3HcFOtJV2Y/2dsb2JhbABZgkJET1iFSbckgUIBhzsBgRYWdIIlAQEBBAEBASpBCxACAQgRAwECIQEGBycLFAkIAgQOBQmIOA3OfBeNcA4CAgE+DAEEBgEGgyWBFQSBV5dxgTyRS4FCgXRtgUI X-IronPort-AV: E=Sophos;i="4.97,1035,1389744000"; d="scan'208,217";a="43049431" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 12 May 2014 13:11:21 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s4CDBLoj024191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 May 2014 13:11:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 12 May 2014 08:11:21 -0500 From: "Francois Le Faucheur (flefauch)" To: "iuniana.oprescu@orange.com" Thread-Topic: [CDNi] Adoption of draft-leung-cdni-uri-signing as a WG document Thread-Index: AQHPafo7Fm/bsUFZ3ka0x9geqEbs1Zs1dykAgAdD7yCAAIwZAA== Date: Mon, 12 May 2014 13:11:20 +0000 Message-ID: <0F9E0105-612C-4360-930A-1DCB8E03C97E@cisco.com> References: <0DB89F92-A961-4EF9-B94C-2787B0E4BDAA@cisco.com> <28257_1399889438_53709E1E_28257_9427_13_8F0D2F5E4AAB7249BC7339A3E944DEDD2284B99CB5@PMEXCB1D.intranet-paris.francetelecom.fr> In-Reply-To: <28257_1399889438_53709E1E_28257_9427_13_8F0D2F5E4AAB7249BC7339A3E944DEDD2284B99CB5@PMEXCB1D.intranet-paris.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.200] Content-Type: multipart/alternative; boundary="_000_0F9E0105612C4360930A1DCB8E03C97Eciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/7L2mPyor4oCvbg7d8pMxygXCxKQ Cc: "draft-leung-cdni-uri-signing@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] Adoption of draft-leung-cdni-uri-signing as a WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 13:11:36 -0000 --_000_0F9E0105612C4360930A1DCB8E03C97Eciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 12 May 2014, at 12:10, > > wrote: Hello IETF-ers, As previously stated, the current version of the draft is a good starting p= oint. After a quick chat with one of my colleagues, there are a few aspects that = we=92d like to mention: 1. It seems that all CSPs share the same format of the URI signing, w= hich might be a disadvantage as they often seem to have various specific me= thods. I know we are trying to achieve interoperability, but maybe it would= be worth adding another parameter to give more flexibility in the choice o= f signing method (other than VER that doesn=92t seem well suited for this p= urpose). If DNS redirection is used, then the dCDNs will see the initial signature a= pplied by the CSP. So the URI signature spec defined by CDNI has to be used= by the CSP themselves. I agree that every CSP have their own way to do tha= t today. But to me it means we don;t have much chance of including in our s= pec the necessary flavors to avid change at the CSP. Given that situation, = I think our best bet to maximise interoperability is to define one simple m= andatory approach to implement and that all CDNs would support. If HTTP redirection is used, then the uCDN woudl perform URI resigning. So = each CSP can use its own URI signing algorithm (as long as they agree with = the uCDN) and then the CDNI URI signing scheme is applied when redirecting = to dCDN. 2. For the objects presented in Section 5.4, I am not sure of my unde= rstanding of the set of dCDNs sharing a symmetric key with the uCDN. Can th= at be a security issue where a dCDN can spoof another dCDN that=92s using t= he same key? If DNS redirection is used, then all dCDNs need to understand the original = signature. If the signature uses symmetric keys , then all dCDNs need to us= e that same shared key. This is a property of that deployment scenario (ie = DNS/symmetric). But yes the security implications need to be discussed. If HTTP redirection is used, then the expected mode of operator will be tha= t the uCDN performs re-signing after URI rewrite, in which case a different= a different symmetric key can be used for each dCDN. 3. There seems to be a need to include the scenario in which there ar= e several users on a home LAN that are behind a box that does NAT. It would= be good to have a way to differentiate each individual request coming from= the devices on the same network. To be picky, maybe the example used in the draft could use an IP address th= at is in line with RFC 6761 instead of the classic private 10.0.0.1. Agreed, Thanks for the review and comments. Francois -- iuniana De : CDNi [mailto:cdni-bounces@ietf.org] De la part de Francois Le Faucheur= (flefauch) Envoy=E9 : mercredi 7 mai 2014 15:53 =C0 : cdni@ietf.org; draft-leung-cdni-uri-signing@too= ls.ietf.org Objet : Re: [CDNi] Adoption of draft-leung-cdni-uri-signing as a WG documen= t All, I incorrectly thought the poll deadline was May 5th, but it was set to May = 12th in my poll message below. So just to make sure we are not preventing a= nyone from posting their feedback, let=92s hold off on the announcement bel= ow until May 12th. We=92ll revaluate the decision then based on additional = feedback. Cheers Francois PS: I guess going on holidays can make one lose the notion of time ... On 7 May 2014, at 15:42, Francois Le Faucheur (flefauch) > wrote: Folks, In addition to the support expressed in London, we=92ve heard as a result o= f the list poll: * statements of strong support (Kevin, Matt, Scott, Daryl) * a statement of conditional support (Ben) * no objection/concern. So we (WG Chairs) confirm adoption of draft-leung-cdni-uri-signing as a WG = document, conditioned to resolution of Ben=92s comments. To draft authors, Please continue the discussion (on the WG mailer) with Ben to converge on h= ow to best address his comments, and then post a new version of the draft a= s draft-ietf-cdni-uri-signing-00. Cheers Francois On 25 Apr 2014, at 16:51, Francois Le Faucheur (flefauch) > wrote: Folks, Just to be clear, this is a follow up from Daryl=92s earlier message of 25 = April (http://www.ietf.org/mail-archive/web/cdni/current/msg01837.html), wh= ich issued a similar request. We did not received much feedback so would li= ke to give another opportunity for more feedback. Francois Begin forwarded message: From: "Francois Le Faucheur (flefauch)" > Subject: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a W= G document Date: 25 April 2014 16:30:08 CEST To: "cdni@ietf.org" > Folks, During the London meeting: * authors confirmed that they believe the latest version of draft-leung-cdn= i-uri-signing resolved the issue related to draft-ietf-appsawg-uri-get-off-= my-lawn-04.txt. * WG chairs agreed to take to the list the question of adopting draft-leung= -cdni-uri-signing-05 as a WG document to ensure it gets sufficient review. This message is to encourage review of draft-leung-cdni-uri-signing-05 (htt= p://tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and sollicite fe= edback on adopting it as a WG document to address the corresponding milesto= ne on our charter. Please do so by end of 12 May (ie within the next 2 weeks). Francois & Daryl, CDNI WG Chairs For convenience, quote from IETF-89 CDNI WG meeting minutes : " Daryl (as chair): This is a deliverable on our charter, but not many people= have read the draft yet, so will take question for WG adoption to the list= to give people time to read it. =93 For convenience, relevant excerpt from the CDNI WG charter (http://tools.ie= tf.org/wg/cdni/charters): =93 The working group will focus on the following items: <=85> - A specification for "CDNI URI Signing". This document will specify a mechanism that allows interconnected CDNs to support access control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). <=85> Goals and Milestones: <=85> Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Propose= d Standard " _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_0F9E0105612C4360930A1DCB8E03C97Eciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7FA9D44868972F479A128C5D7A489CE4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 12 May 2014, at 12:10, <iuniana.oprescu@orange.com> <iuniana.oprescu@orange.com> wrote:

Hello IETF-ers,

 

As previou= sly stated, the current version of the draft is a good starting point.

 

After a qu= ick chat with one of my colleagues, there are a few aspects that we=92d lik= e to mention:

 

1.      

2.      

= 3.       There se= ems to be a need to include the scenario in which there are several users o= n a home LAN that are behind a box that does NAT. It would be good to have a way to differentiate each individual = request coming from the devices on the same network.

 

To be pick= y, maybe the example used in the draft could use an IP address that is in l= ine with RFC 6761 instead of the classic private 10.0.0.1.


Agreed,

Thanks for the review and comments.

Francois

 

-- iuniana=

 

 

De = : CDNi [mai= lto:cdni-bounces@ietf.org] De la part de Francois Le Faucheur (flefauch)
Envoy=E9 : mercredi 7 mai 2014 15:53
=C0 : cdni@ietf.org; draft-leung-cdni-uri-signing@tools.ietf.org
Objet : Re: [CDNi] Adoption of draft-leung-cdni-uri-signing as = a WG document

 

All,

 

I incorrectly thought t= he poll deadline was May 5th, but it was set to May 12th in my poll message= below. So just to make sure we are not preventing anyone from posting thei= r feedback, let=92s hold off on the announcement below until May 12th. We=92ll revaluate the decision then based on additio= nal feedback.

 

Cheers

 

Francois

 

PS: I guess going on ho= lidays can make one lose the notion of time ...

 

On 7 May 2014, at 15:42= , Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:



Folks,

In addition to the supp= ort expressed in London, we=92ve heard as a result of the list poll:

* statements of st= rong support (Kevin, Matt, Scott, Daryl)

* a statement of condit= ional support (Ben)

* no objection/concern.=

So we (WG Chairs) confi= rm adoption of draft-leung-cdni-uri-signing as a WG document, conditio= ned to resolution of Ben=92s comments.

 

To draft authors,<= /o:p>

Please continue the dis= cussion (on the WG mailer) with Ben to converge on how to best address his = comments, and then post a new version of the draft as draft-ietf-cdni-uri-s= igning-00.

 

Cheers

 

Francois

 

On 25 Apr 2014, at 16:5= 1, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:



Folks,

 

Just to be clear, this = is a follow up from Daryl=92s earlier message of 25 April (http://www.ietf= .org/mail-archive/web/cdni/current/msg01837.html), which issued a similar request. We did not received much feedback so would= like to give another opportunity for more feedback.

 

Francois

 

Begin forwarded message= :



From: "Francois Le Faucheur (flefauch)" <flefauch@cisco.com>

Subject: [CDNi] Poll f= or adoption of draft-leung-cdni-uri-signing-05 as a WG document<= o:p>

Date: 25 April 2014 16:30:08 CEST

 

Folks,

During the London meeting:
* authors confirmed that they believe the latest version of draft-leung-cdn= i-uri-signing resolved the issue related to draft-ietf-appsawg-uri-get-off-= my-lawn-04.txt.
* WG chairs agreed to take to the list the question of adopting draft-leung= -cdni-uri-signing-05 as a WG document to ensure it gets sufficient review.<= br>
This message is to encourage review of draft-leung-cdni-uri-signing-05 (http:= //tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and sollicite = feedback on adopting it as a WG document to address the corresponding milestone on our charter.
Please do so by end of 12 May (ie within the next 2 weeks).

Francois & Daryl, CDNI WG Chairs



For convenience, quote from IETF-89 CDNI WG meeting minutes :
"
Daryl (as chair): This is a deliverable on our charter, but not many people= have read the draft yet, so will take question for WG adoption to the list= to give people time to read it.
=93


For convenience, relevant excerpt from the CDNI WG charter (http://tools.ietf.org/wg/cdni/charters<= /a>):
=93
The working group will focus on the following items:
<=85>
 - A specification for "CDNI URI Signing". This document wil= l specify a
   mechanism that allows interconnected CDNs to support acce= ss control
   by signing content URIs. This may involve extensions to t= he CDNI
   interfaces (e.g. CDNI Metadata interface, CDNI Logging in= terface).

<=85>

Goals and Milestones:
<=85>
 Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Pr= oposed Standard
"
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni

 

_______________________= ________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni

 

_______________________= ________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

--_000_0F9E0105612C4360930A1DCB8E03C97Eciscocom_-- From nobody Mon May 12 09:55:47 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AB41A076D for ; Mon, 12 May 2014 09:55:45 -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 7b7QGXWjFKzi for ; Mon, 12 May 2014 09:55:42 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 656681A0761 for ; Mon, 12 May 2014 09:55:42 -0700 (PDT) Received: from host4.velocix.com ([81.134.152.4] helo=xxx.corp.velocix.com) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1WjtVm-0000hn-KP; Mon, 12 May 2014 17:55:35 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Niven-Jenkins In-Reply-To: Date: Mon, 12 May 2014 17:55:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <00E86C22-E72B-40DA-BC5D-49DEB4CB28B2@niven-jenkins.co.uk> References: <147CBB6C-9F42-4758-909C-2FD9B96DB289@niven-jenkins.co.uk> To: "Brandenburg, R. (Ray) van" X-Mailer: Apple Mail (2.1874) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/X018ti4ttJe66CQgQcFR8SAPMPQ Cc: "cdni@ietf.org" Subject: Re: [CDNi] URI Signing for CDNI Working Group Draft X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 16:55:46 -0000 Ray, See inline. On 2 May 2014, at 08:11, Brandenburg, R. (Ray) van = wrote: > Hi Ben, >=20 > Thanks for you review. Sorry for taking so long to respond to your = comments.=20 >=20 >> -----Original Message----- >> From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Ben = Niven-Jenkins >> Sent: dinsdag 25 maart 2014 12:03 >> To: Daryl Malas >> Cc: cdni@ietf.org >> Subject: Re: [CDNi] URI Signing for CDNI Working Group Draft >>=20 >> Daryl, Authors, >>=20 >> I gave the draft a quick read. It seems a reasonable starting point. >>=20 >> While I was reading the draft I noticed a couple of things in it that = I think are >> worth raising: >>=20 >> 1) In section 2 the draft says "Any attributes appended in such way = after the >> URI Signature has been calculated are not validated for the purpose = of >> content access authorization." >>=20 >> If additional query parameters can be appended to the URI which are = not >> validated, could a UA obtain content that it isn't authorised to = obtain by >> adding additional query parameters? It seems like something that = could be >> worth discussing in the security considerations section? >>=20 >=20 > I'm not sure I understand you correctly. Any parameters added by the = UA after the URI Signature are not taken into account during the signing = process. As such, there is no way for these parameters to affect the = outcome of the validation process. The only way for the UA to affect the = validation outcome would be to change the IR Signing Package Attribute, = however, this would cause the signature to be invalid.=20 Section 3 of the draft states "The entire URI except the "scheme name" = part is protected by the URI signature.=94 But if someone can append = additional query parameters to a signed URI and still have it be = considered =93correctly signed=94 by a dCDN then the proposed mechanism = is not protecting =93the entire URI=94. That aside, as it stands, as specified in the draft I believe it is = possible to do the following: Take a URI, e.g. http://videos.example/videos?title=3Dbatman and sign it to get something like http://videos.example/videos?title=3Dbatman& then present to a dCDN the following URI http://videos.example/videos?title=3Dbatman&&quality=3DHD which will correctly validate but lead to a dCDN acquiring/delivering http://videos.example/videos?title=3Dbatman&quality=3DHD which, even though it passes URI signing validation, is a different = URI/resource to the one that was originally signed. >> 2) Section 2.2 allows the KeyID to be included in the Signed URI. = This also >> seems like it might open a security hole as a malicious UA could = strip the >> original URISigningPackage attribute, sign the URI with a Key under = its control >> (possibly altering other things like the actual URI or expiry time) = and include >> the appropriate KeyID for that new Key in the new URISigningPackage. >>=20 >> Is there a use case for signalling the KeyID within the Signed URI = itself? >=20 > The use case for signaling the KeyID is the uCDN allowing multiple = keys to be used in the metadata. In order to signal the used Key to the = dCDN, the KeyID field is used. >=20 > Let's assume that for a given content item, the uCDN allows five = different keys to be used (as announced in the metadata). You're right = that if the UA would somehow have access to one of these five keys, and = the associated keyID, it could recalculate the URISigningPackage = attribute. However, I don't think this problem stems from the use of the = KeyID field. Even if there would be only one key, and this key would be = leaked, then the UA could also resign the UA. So the question is, is the = chance of a given key leaking bigger if it is part of a set of allowed = keys instead of the only allowed key? The attack surface could be larger than leaked keys. E.g. if the 5 keys = the uCDN says are allowed came from different content providers, then = the key does=92t have to leak anywhere, an enterprising individual with = legitimate knowledge of CSP1=92s key could use CSP1=92s key to sign = URIs and get hold of content from CSP2. For the use case presented I think there is a better/easier way to solve = it rather than have each UA->dCDN request include which key to use. What I=92d propose is: - Within CDNI Metadata the URI signing keys are associated with the = content to which they apply. - The CDNI Metadata can contain >1 key for a given piece of content. - If any of the keys included in the relevant CDNI Metadata correctly = validate the URI, then it is valid. That way a CSP can provide/use multiple keys if they want, there is no = need to signal the keyID to be used in the URI itself (so absolutely no = ability for a User Agent to affect it in any way), and you can do = key-rollover without having to co-ordinate KeyIDs between the party = responsible for signing the URI (the uCDN/CSP probably) and the party = responsible for validating them (the dCDN). >> 3) Regarding hash functions & digital signature algorithms, the draft = hints at >> allowing several options for each and defines a default in case a = particular >> algorithm is not specified in the URISigningPackage. >>=20 >> This seems a bit overkill to me. To aid inter-operability, I think it = would be >> better to specify a single algorithm for each unless there are use = cases for >> requiring support for more than one algorithm in the first version = defined in >> the draft? >>=20 >=20 > Are you saying you would prefer to keep the HF and DSA fields but only = define one possible value for them in this document, or are you saying = you would prefer to remove these fields and just specify a single = mandatory hash function and DS algorithm? Personally, I think it is = useful to have the option of signaling different hash functions or DS = algorithms.=20 I am OK with leaving in the hooks for extensibility. I don=92t like the idea of specifying >1 hash function/digital signature = algorithm in this document. This document is defining a new URI signing algorithm for CDNI, there=92s = no reason IMO why we can=92t start with a single Hash function & Digital = Signature Algorithm for baseline interoperability and if folks need = something else in future they can specify it. Several CDNs support >1 HF/DSA because things have evolved over time, = some newer functions are considered more secure or whatever and = backwards compatibility needs to be maintained. We=92re not in that position, the document is describing a new signing = mechanism that everyone will need to implement, we have no backwards = compatibility to maintain so let=92s not carry any historical baggage = resulting from CDN-proprietary URI signing schemes along with us. Ben >=20 > Thanks, >=20 > Ray >=20 >> Regards >> Ben >>=20 >>=20 >> On 6 Mar 2014, at 15:34, Daryl Malas wrote: >>=20 >>> All, >>>=20 >>> During today's working group meeting, we agreed the latest draft = revision >> of this draft = (http://tools.ietf.org/html/draft-leung-cdni-uri-signing-05) is >> substantial for us to adopt it as a working group item. However, = Francois and >> I did not feel comfortable conducting a "Hum," since there were not a = lot of >> people present who had read the draft. This draft was proposed in = response >> to the following charter item: >>>=20 >>> A specification for "CDNI URI Signing". This document will specify a >>> mechanism that allows interconnected CDNs to support access control = by >>> signing content URIs. This may involve extensions to the CDNI >>> interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). >>>=20 >>> In addition, the working group has the following milestone: >>>=20 >>> Sep 2014 - Submit specification of URI Signing for CDNI to IESG as >>> Proposed Standard >>>=20 >>> With this in mind, we are requesting people read the draft in = preparation >> for this draft to be accepted as a working group item, which will = occur on >> March 21st. If anyone has any major concerns with this, please post >> comments and concerns to the list. >>>=20 >>> Regards, >>>=20 >>> Daryl & Francois >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 >=20 >=20 > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien = u niet de geadresseerde bent of dit bericht abusievelijk aan u is = toegezonden, wordt u verzocht dat aan de afzender te melden en het = bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de = inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor schade, = van welke aard ook, die verband houdt met risico's verbonden aan het = elektronisch verzenden van berichten. >=20 >=20 >=20 > This message may contain information that is not intended for you. If = you are not the addressee or if this message was sent to you by mistake, = you are requested to inform the sender and delete the message. TNO = accepts no liability for the content of this e-mail, for the manner in = which you use it and for damage of any kind resulting from the risks = inherent to the electronic transmission of messages. From nobody Tue May 13 00:58:40 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82A01A0852 for ; Tue, 13 May 2014 00:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 q-bboFbysw04 for ; Tue, 13 May 2014 00:58:34 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id F25571A0847 for ; Tue, 13 May 2014 00:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11484; q=dns/txt; s=iport; t=1399967908; x=1401177508; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NvaJQeWfPUEASv4kK36FQzA392vERRGsHQ/xQUIQAI8=; b=l3yyCZZI/1babc9LfJaH6yC4TNTSVTHLLJ803p6IKQhV0CHmpCy6XDea 29EYIUBPNP8ez7/nkM4YDWDH3M65ayMYN5uePXBymxfatnHjbzO72mffP WFV6QgALW0jp7lhsr13ByAT0Gz1jcHNGcrciDXI+RU85G8mvnBey3HsXY w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAGTPcVOtJV2a/2dsb2JhbABZgwZPWL46hzsBgRoWdIIlAQEBAwEBAQEkRwsQAgEIGBUZJwslAgQOBYg5CA3QcheOHwgrBwIIgyGBFQSVUIN4gTyRS4M2gW8kHA X-IronPort-AV: E=Sophos;i="4.97,1042,1389744000"; d="scan'208";a="324434249" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 13 May 2014 07:58:27 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4D7wRot024272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 07:58:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 13 May 2014 02:58:27 -0500 From: "Francois Le Faucheur (flefauch)" To: Niven-Jenkins Ben Thread-Topic: [CDNi] URI Signing for CDNI Working Group Draft Thread-Index: AQHPbgMASoGYsdn+T0K5glDGAe/RFZs+eggA Date: Tue, 13 May 2014 07:58:26 +0000 Message-ID: References: <147CBB6C-9F42-4758-909C-2FD9B96DB289@niven-jenkins.co.uk> <00E86C22-E72B-40DA-BC5D-49DEB4CB28B2@niven-jenkins.co.uk> In-Reply-To: <00E86C22-E72B-40DA-BC5D-49DEB4CB28B2@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.248] Content-Type: text/plain; charset="Windows-1252" Content-ID: <27A1BED4A7D32D43BEC5286D64953932@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/lVcMA30okRL4Xgc5n6LE7Zl_cww Cc: "cdni@ietf.org" Subject: Re: [CDNi] URI Signing for CDNI Working Group Draft X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 07:58:38 -0000 All, On 12 May 2014, at 18:55, Ben Niven-Jenkins wrote= : >>>=20 >>>=20 >>> 1) In section 2 the draft says "Any attributes appended in such way aft= er the >>> URI Signature has been calculated are not validated for the purpose of >>> content access authorization." >>>=20 >>> If additional query parameters can be appended to the URI which are not >>> validated, could a UA obtain content that it isn't authorised to obtain= by >>> adding additional query parameters? It seems like something that could = be >>> worth discussing in the security considerations section? >>>=20 >>=20 >> I'm not sure I understand you correctly. Any parameters added by the UA = after the URI Signature are not taken into account during the signing proce= ss. As such, there is no way for these parameters to affect the outcome of = the validation process. The only way for the UA to affect the validation ou= tcome would be to change the IR Signing Package Attribute, however, this wo= uld cause the signature to be invalid.=20 >=20 >=20 > Section 3 of the draft states "The entire URI except the "scheme name" pa= rt is protected by the URI signature.=94 But if someone can append addition= al query parameters to a signed URI and still have it be considered =93corr= ectly signed=94 by a dCDN then the proposed mechanism is not protecting =93= the entire URI=94. >=20 > That aside, as it stands, as specified in the draft I believe it is possi= ble to do the following: >=20 > Take a URI, e.g. > http://videos.example/videos?title=3Dbatman >=20 > and sign it to get something like >=20 > http://videos.example/videos?title=3Dbatman& >=20 > then present to a dCDN the following URI >=20 > http://videos.example/videos?title=3Dbatman&&quality= =3DHD >=20 > which will correctly validate but lead to a dCDN acquiring/delivering >=20 > http://videos.example/videos?title=3Dbatman&quality=3DHD >=20 > which, even though it passes URI signing validation, is a different URI/r= esource to the one that was originally signed. That seems like a valid concern is some situations. At teh same time, I bel= ieve there are valid situations where the CSP wants to allow un-signed quer= y strings (because they can only affect things that need not be authorised)= . So how about adding one piece of metadata to CDNI Metadata that says: * allow query string to be extended after signature, which means (using th= e above example): - if the signature protecting "http://videos.example/videos?title=3Dbatma= n=94 is valid, then authorize "http://videos.example/videos?title=3Dbatman&= &quality=3DHD=94=20 - if the signature protecting "http://videos.example/videos?title=3Dbatma= n=94 is NOT valid, then block "http://videos.example/videos?title=3Dbatman&= &quality=3DHD=94=20 * disallow query string to be extended after signature, which means (using= the above example): - regardless of URI signature validity, block "http://videos.example/vide= os?title=3Dbatman&&quality=3DHD=94=20 >=20 >=20 >>> 2) Section 2.2 allows the KeyID to be included in the Signed URI. This = also >>> seems like it might open a security hole as a malicious UA could strip = the >>> original URISigningPackage attribute, sign the URI with a Key under its= control >>> (possibly altering other things like the actual URI or expiry time) and= include >>> the appropriate KeyID for that new Key in the new URISigningPackage. >>>=20 >>> Is there a use case for signalling the KeyID within the Signed URI itse= lf? >>=20 >> The use case for signaling the KeyID is the uCDN allowing multiple keys = to be used in the metadata. In order to signal the used Key to the dCDN, th= e KeyID field is used. >>=20 >> Let's assume that for a given content item, the uCDN allows five differe= nt keys to be used (as announced in the metadata). You're right that if the= UA would somehow have access to one of these five keys, and the associated= keyID, it could recalculate the URISigningPackage attribute. However, I do= n't think this problem stems from the use of the KeyID field. Even if there= would be only one key, and this key would be leaked, then the UA could als= o resign the UA. So the question is, is the chance of a given key leaking b= igger if it is part of a set of allowed keys instead of the only allowed ke= y? >=20 > The attack surface could be larger than leaked keys. E.g. if the 5 keys t= he uCDN says are allowed came from different content providers, then the ke= y does=92t have to leak anywhere, an enterprising individual with legitimat= e knowledge of CSP1=92s key could use CSP1=92s key to sign URIs and get ho= ld of content from CSP2. In that situation, the uCDN woudl not advertise the 5 key IDs for all conte= nts. It would only advertise key-ID 1 for CSP1. So an individual knowing CS= P1=92s key woudl not be able to access CSP2 content.=20 >=20 > For the use case presented I think there is a better/easier way to solve = it rather than have each UA->dCDN request include which key to use. >=20 > What I=92d propose is: > - Within CDNI Metadata the URI signing keys are associated with the conte= nt to which they apply. I believe that is already the case: " o Allowable Key ID set that the Signed URI's Key ID information element can reference " >=20 > - The CDNI Metadata can contain >1 key for a given piece of content. I believe that is already the case (what is signaled is Key ID and not the = key itself of course): " o Allowable Key ID set that the Signed URI's Key ID information element can reference " > - If any of the keys included in the relevant CDNI Metadata correctly val= idate the URI, then it is valid. I believe this is effectively already teh case. The difference is that the = key-ID can optionally be included in the URI, so that the CDN does not need= to successively try ecah and every Key from the set of authorized keys for= that content. >=20 > That way a CSP can provide/use multiple keys if they want, there is no ne= ed to signal the keyID to be used in the URI itself (so absolutely no abili= ty for a User Agent to affect it in any way), and you can do key-rollover w= ithout having to co-ordinate KeyIDs between the party responsible for signi= ng the URI (the uCDN/CSP probably) and the party responsible for validating= them (the dCDN). I don=92t see that includeing the key-ID in the URI increases the security = risk in any ways (since the set of allowed key-ID is conveyed in metadata a= lways). And it has a benefit in avoiding to systematically have to try with= every possible key. Am I missing something? >=20 >=20 >>> 3) Regarding hash functions & digital signature algorithms, the draft h= ints at >>> allowing several options for each and defines a default in case a parti= cular >>> algorithm is not specified in the URISigningPackage. >>>=20 >>> This seems a bit overkill to me. To aid inter-operability, I think it w= ould be >>> better to specify a single algorithm for each unless there are use case= s for >>> requiring support for more than one algorithm in the first version defi= ned in >>> the draft? >>>=20 >>=20 >> Are you saying you would prefer to keep the HF and DSA fields but only d= efine one possible value for them in this document, or are you saying you w= ould prefer to remove these fields and just specify a single mandatory hash= function and DS algorithm? Personally, I think it is useful to have the op= tion of signaling different hash functions or DS algorithms.=20 >=20 > I am OK with leaving in the hooks for extensibility. >=20 > I don=92t like the idea of specifying >1 hash function/digital signature = algorithm in this document. >=20 > This document is defining a new URI signing algorithm for CDNI, there=92s= no reason IMO why we can=92t start with a single Hash function & Digital S= ignature Algorithm for baseline interoperability and if folks need somethin= g else in future they can specify it. >=20 > Several CDNs support >1 HF/DSA because things have evolved over time, som= e newer functions are considered more secure or whatever and backwards comp= atibility needs to be maintained. >=20 > We=92re not in that position, the document is describing a new signing me= chanism that everyone will need to implement, we have no backwards compatib= ility to maintain so let=92s not carry any historical baggage resulting fro= m CDN-proprietary URI signing schemes along with us. That sounds right to me. Francois >=20 > Ben >=20 >=20 >>=20 >> Thanks, >>=20 >> Ray >>=20 >>> Regards >>> Ben >>>=20 >>>=20 >>> On 6 Mar 2014, at 15:34, Daryl Malas wrote: >>>=20 >>>> All, >>>>=20 >>>> During today's working group meeting, we agreed the latest draft revis= ion >>> of this draft (http://tools.ietf.org/html/draft-leung-cdni-uri-signing-= 05) is >>> substantial for us to adopt it as a working group item. However, Franc= ois and >>> I did not feel comfortable conducting a "Hum," since there were not a l= ot of >>> people present who had read the draft. This draft was proposed in resp= onse >>> to the following charter item: >>>>=20 >>>> A specification for "CDNI URI Signing". This document will specify a >>>> mechanism that allows interconnected CDNs to support access control by >>>> signing content URIs. This may involve extensions to the CDNI >>>> interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). >>>>=20 >>>> In addition, the working group has the following milestone: >>>>=20 >>>> Sep 2014 - Submit specification of URI Signing for CDNI to IESG as >>>> Proposed Standard >>>>=20 >>>> With this in mind, we are requesting people read the draft in preparat= ion >>> for this draft to be accepted as a working group item, which will occur= on >>> March 21st. If anyone has any major concerns with this, please post >>> comments and concerns to the list. >>>>=20 >>>> Regards, >>>>=20 >>>> Daryl & Francois >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >>=20 >>=20 >> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u= niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonde= n, wordt u verzocht dat aan de afzender te melden en het bericht te verwijd= eren. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, = de wijze waarop u deze gebruikt en voor schade, van welke aard ook, die ver= band houdt met risico's verbonden aan het elektronisch verzenden van berich= ten. >>=20 >>=20 >>=20 >> This message may contain information that is not intended for you. If yo= u are not the addressee or if this message was sent to you by mistake, you = are requested to inform the sender and delete the message. TNO accepts no l= iability for the content of this e-mail, for the manner in which you use it= and for damage of any kind resulting from the risks inherent to the electr= onic transmission of messages. >=20 From nobody Tue May 13 01:01:38 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7C31A0857 for ; Tue, 13 May 2014 01:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 KcgXRs23v2lY for ; Tue, 13 May 2014 01:01:26 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD681A0847 for ; Tue, 13 May 2014 01:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13814; q=dns/txt; s=iport; t=1399968080; x=1401177680; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=JMmyLE4pgrNdGkeKLX0UMsss2BjZ4Yh8dytnFCvUxy0=; b=kWkuyaaWPiAgSLKf7+AS9MHErYdj+kvXR0jxLYa+FP9R8wJMt7aoScEb IuW+0x78as8RySyDYqBnoLhmqFh5Hw1NuKQLOa1Rt273m36U4LBNn5tJQ z2NlqQoPNUCpAqCERPq6JTC+MRThyaMBpjSFc8BeRigx2nVl7/aEOoOQj A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAOTPcVOtJV2P/2dsb2JhbABZgwZPWLx4gUIBhzoBgRoWdIIlAQEBBAEBAWsbAgEZAwECKAcnCxQJCAIEARIJiDgN0G8XjX4DAQE+DQoBBoMlgRUEmUiBPJFLgzZtgQk5 X-IronPort-AV: E=Sophos;i="4.97,1042,1389744000"; d="scan'208,217";a="324460980" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP; 13 May 2014 08:01:19 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s4D81J6R001033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 08:01:19 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Tue, 13 May 2014 03:01:19 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" , "draft-leung-cdni-uri-signing@tools.ietf.org" Thread-Topic: Adoption of draft-leung-cdni-uri-signing as a WG document Thread-Index: AQHPboGFXGmGI0bgMEy2r9GxkEN+Qg== Date: Tue, 13 May 2014 08:01:19 +0000 Message-ID: <0B679634-94BC-48FB-8F4A-3CC1E1E6AB80@cisco.com> References: <0DB89F92-A961-4EF9-B94C-2787B0E4BDAA@cisco.com> In-Reply-To: <0DB89F92-A961-4EF9-B94C-2787B0E4BDAA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.248] Content-Type: multipart/alternative; boundary="_000_0B67963494BC48FB8F4A3CC1E1E6AB80ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/ddqwWFDB8_b74GAFa3U8BgYf3yc Subject: [CDNi] Adoption of draft-leung-cdni-uri-signing as a WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 08:01:34 -0000 --_000_0B67963494BC48FB8F4A3CC1E1E6AB80ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Folks, So, in addition to the support expressed in London, we=92ve heard as a resu= lt of the list poll: * statements of strong support (Kevin, Matt, Scott, Daryl) * 2 statement of support with comments (Ben, Inuniana) * no objection/concern. So we (WG Chairs) confirm adoption of draft-leung-cdni-uri-signing as a WG = document, conditioned to resolution of Ben=92s and Iuniana's comments. To draft authors, Please continue the discussion (on the WG mailer) with Ben & Iuniana to con= verge on how to best address their comments, and then post a new version of= the draft as draft-ietf-cdni-uri-signing-00. Cheers Francois & Daryl On 7 May 2014, at 15:52, Francois Le Faucheur (flefauch) > wrote: All, I incorrectly thought the poll deadline was May 5th, but it was set to May = 12th in my poll message below. So just to make sure we are not preventing a= nyone from posting their feedback, let=92s hold off on the announcement bel= ow until May 12th. We=92ll revaluate the decision then based on additional = feedback. Cheers Francois PS: I guess going on holidays can make one lose the notion of time ... On 7 May 2014, at 15:42, Francois Le Faucheur (flefauch) > wrote: Folks, In addition to the support expressed in London, we=92ve heard as a result o= f the list poll: * statements of strong support (Kevin, Matt, Scott, Daryl) * a statement of conditional support (Ben) * no objection/concern. So we (WG Chairs) confirm adoption of draft-leung-cdni-uri-signing as a WG = document, conditioned to resolution of Ben=92s comments. To draft authors, Please continue the discussion (on the WG mailer) with Ben to converge on h= ow to best address his comments, and then post a new version of the draft a= s draft-ietf-cdni-uri-signing-00. Cheers Francois On 25 Apr 2014, at 16:51, Francois Le Faucheur (flefauch) > wrote: Folks, Just to be clear, this is a follow up from Daryl=92s earlier message of 25 = April (http://www.ietf.org/mail-archive/web/cdni/current/msg01837.html), wh= ich issued a similar request. We did not received much feedback so would li= ke to give another opportunity for more feedback. Francois Begin forwarded message: From: "Francois Le Faucheur (flefauch)" > Subject: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a W= G document Date: 25 April 2014 16:30:08 CEST To: "cdni@ietf.org" > Folks, During the London meeting: * authors confirmed that they believe the latest version of draft-leung-cdn= i-uri-signing resolved the issue related to draft-ietf-appsawg-uri-get-off-= my-lawn-04.txt. * WG chairs agreed to take to the list the question of adopting draft-leung= -cdni-uri-signing-05 as a WG document to ensure it gets sufficient review. This message is to encourage review of draft-leung-cdni-uri-signing-05 (htt= p://tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and sollicite fe= edback on adopting it as a WG document to address the corresponding milesto= ne on our charter. Please do so by end of 12 May (ie within the next 2 weeks). Francois & Daryl, CDNI WG Chairs For convenience, quote from IETF-89 CDNI WG meeting minutes : " Daryl (as chair): This is a deliverable on our charter, but not many people= have read the draft yet, so will take question for WG adoption to the list= to give people time to read it. =93 For convenience, relevant excerpt from the CDNI WG charter (http://tools.ie= tf.org/wg/cdni/charters): =93 The working group will focus on the following items: <=85> - A specification for "CDNI URI Signing". This document will specify a mechanism that allows interconnected CDNs to support access control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). <=85> Goals and Milestones: <=85> Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Propose= d Standard " _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_0B67963494BC48FB8F4A3CC1E1E6AB80ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Folks,

So, in addition to the support expressed in London, we=92ve heard as a= result of the list poll:
* statements of strong support (Kevin, Matt, Scott, Daryl)
* 2 statement of support with comments (Ben, Inuniana)
* no objection/concern.

So we (WG Chairs) confirm adoption of draft-leung-cdni-uri-signing as = a WG document, conditioned to resolution of Ben=92s and Iuniana's comments.=

To draft authors,
Please continue the discussion (on the WG mailer) with Ben & Iuniana to= converge on how to best address their comments, and then post a new versio= n of the draft as draft-ietf-cdni-uri-signing-00.

Cheers

Francois & Daryl

On 7 May 2014, at 15:52, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:

All,

I incorrectly thought the poll deadline was May 5th, but it was set to= May 12th in my poll message below. So just to make sure we are not prevent= ing anyone from posting their feedback, let=92s hold off on the announcemen= t below until May 12th. We=92ll revaluate the decision then based on additional feedback.

Cheers

Francois

PS: I guess going on holidays can make one lose the notion of time ...=

On 7 May 2014, at 15:42, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:

Folks,
In addition to the support expressed in London, we=92ve heard as a res= ult of the list poll:
* = ;statements of strong support (Kevin, Matt, Scott, Daryl)
* a st= atement of conditional support (Ben)
* no o= bjection/concern.
So we (WG Chairs) confirm adoption of draft-leung-cdni-uri-signin= g as a WG document, conditioned to resolution of Ben=92s comments.

To draft authors,
Please continue the discussion (on the WG mailer) with Ben to converge= on how to best address his comments, and then post a new version of the dr= aft as draft-ietf-cdni-uri-signing-00.

Cheers

Francois

On 25 Apr 2014, at 16:51, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:

Folks,

Just to be clear, this is a follow up from Daryl=92s earlier message o= f 25 April (http://www.ietf.org/mail-archive/web/cdni/current/msg01837.htm= l), which issued a similar request. We did not received much feedback so would like to give another opportunit= y for more feedback.

Francois

Begin forwarded message:

From: "Francois Le Faucheur (flefauch)" <<= a href=3D"mailto:flefauch@cisco.com">flefauch@cisco.com>
Subject: [CDNi] Poll for adoption of draft-leung-cd= ni-uri-signing-05 as a WG document
Date: 25 April 2014 16:30:08 CEST

Folks,

During the London meeting:
* authors c= onfirmed that they believe the latest version of draft-leung-cdni-uri-signi= ng resolved the issue related to draft-ietf-appsawg-uri-get-off-my-lawn-04.= txt.
* WG chairs= agreed to take to the list the question of adopting draft-leung-cdni-uri-s= igning-05 as a WG document to ensure it gets sufficient review.

This message is to encourage review of draft-leung-cdni-uri-signing-05 (http:= //tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and sollicite = feedback on adopting it as a WG document to address the corresponding milestone on our charter.
Please do so by end of 12 May (ie within the next 2 weeks).

Francois & Daryl, CDNI WG Chairs



For convenience, quote from IETF-89 CDNI WG meeting minutes :
"
Daryl (as chair): This is a deliverable on our charter, but not many people= have read the draft yet, so will take question for WG adoption to the list= to give people time to read it.
=93


For convenience, relevant excerpt from the CDNI WG charter (http://tools.ietf.org/wg/cdni/charters<= /a>):
=93
The working group will focus on the following items:
<=85>
 - A specification for "CDNI URI Signing". This document wil= l specify a
   mechanism that allows interconnected CDNs to support acce= ss control
   by signing content URIs. This may involve extensions to t= he CDNI
   interfaces (e.g. CDNI Metadata interface, CDNI Logging in= terface).

<=85>

Goals and Milestones:
<=85>
 Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Pr= oposed Standard
"
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni

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

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

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

--_000_0B67963494BC48FB8F4A3CC1E1E6AB80ciscocom_-- From nobody Thu May 15 00:06:00 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2E21A03EE for ; Thu, 15 May 2014 00:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.443 X-Spam-Level: * X-Spam-Status: No, score=1.443 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] 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 7dUOTF7vZbyq for ; Thu, 15 May 2014 00:05:54 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 512A91A03EA for ; Thu, 15 May 2014 00:05:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,1057,1389740400"; d="scan'208";a="4124936" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 15 May 2014 09:05:45 +0200 Received: from EXC-MBX03.tsn.tno.nl ([fe80::e969:1300:fb9f:7e12]) by EXC-CASHUB02.tsn.tno.nl ([fe80::8c02:de2a:3094:171%14]) with mapi id 14.03.0174.001; Thu, 15 May 2014 09:05:44 +0200 From: "Brandenburg, R. (Ray) van" To: "Francois Le Faucheur (flefauch)" , Niven-Jenkins Ben Thread-Topic: [CDNi] URI Signing for CDNI Working Group Draft Thread-Index: AQHPSBomVjXoux+3r0uy5ywq9SFIlJstFjTQgBA+CoCAAPxDAIADLuzA Date: Thu, 15 May 2014 07:05:43 +0000 Message-ID: References: <147CBB6C-9F42-4758-909C-2FD9B96DB289@niven-jenkins.co.uk> <00E86C22-E72B-40DA-BC5D-49DEB4CB28B2@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/CpX6vifcDt6s-wXFiVR0lcUpbqY Cc: "cdni@ietf.org" Subject: Re: [CDNi] URI Signing for CDNI Working Group Draft X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 07:05:57 -0000 Hi Ben, Francois, > -----Original Message----- > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Sent: dinsdag 13 mei 2014 9:58 > To: Niven-Jenkins Ben > Cc: Francois Le Faucheur (flefauch); Brandenburg, R. (Ray) van; > cdni@ietf.org; Kent Leung (kleung) > Subject: Re: [CDNi] URI Signing for CDNI Working Group Draft >=20 > All, >=20 > On 12 May 2014, at 18:55, Ben Niven-Jenkins > wrote: > >>> > >>> > >>> 1) In section 2 the draft says "Any attributes appended in such way > >>> after the URI Signature has been calculated are not validated for > >>> the purpose of content access authorization." > >>> > >>> If additional query parameters can be appended to the URI which are > >>> not validated, could a UA obtain content that it isn't authorised to > >>> obtain by adding additional query parameters? It seems like > >>> something that could be worth discussing in the security consideratio= ns > section? > >>> > >> > >> I'm not sure I understand you correctly. Any parameters added by the U= A > after the URI Signature are not taken into account during the signing pro= cess. > As such, there is no way for these parameters to affect the outcome of th= e > validation process. The only way for the UA to affect the validation outc= ome > would be to change the IR Signing Package Attribute, however, this would > cause the signature to be invalid. > > > > > > Section 3 of the draft states "The entire URI except the "scheme name" > part is protected by the URI signature." But if someone can append > additional query parameters to a signed URI and still have it be consider= ed > "correctly signed" by a dCDN then the proposed mechanism is not protectin= g > "the entire URI". > > > > That aside, as it stands, as specified in the draft I believe it is pos= sible to do > the following: > > > > Take a URI, e.g. > > http://videos.example/videos?title=3Dbatman > > > > and sign it to get something like > > > > http://videos.example/videos?title=3Dbatman& > > > > then present to a dCDN the following URI > > > > http://videos.example/videos?title=3Dbatman& > stuff>&quality=3DHD > > > > which will correctly validate but lead to a dCDN acquiring/delivering > > > > http://videos.example/videos?title=3Dbatman&quality=3DHD > > > > which, even though it passes URI signing validation, is a different > URI/resource to the one that was originally signed. >=20 >=20 > That seems like a valid concern is some situations. At teh same time, I b= elieve > there are valid situations where the CSP wants to allow un-signed query > strings (because they can only affect things that need not be authorised)= . So > how about adding one piece of metadata to CDNI Metadata that says: > * allow query string to be extended after signature, which means > (using the above example): > - if the signature protecting > "http://videos.example/videos?title=3Dbatman" is valid, then authorize > "http://videos.example/videos?title=3Dbatman& stuff>&quality=3DHD" > - if the signature protecting > "http://videos.example/videos?title=3Dbatman" is NOT valid, then block > "http://videos.example/videos?title=3Dbatman& stuff>&quality=3DHD" > * disallow query string to be extended after signature, which means > (using the above example): > - regardless of URI signature validity, block > "http://videos.example/videos?title=3Dbatman& stuff>&quality=3DHD" >=20 I see Ben's point. That said, such behavior would be easily detectable at t= he dCDN. The dCDN knows that any parameters in the query string to the righ= t of the URI Signing Attribute have been added by the UA instead of the uCD= N. It would be fairly easy for a dCDN to ignore any such parameters for the= purposes of selecting a content item (e.g. only using it for purposes of l= ogging). I agree that we need to explicitly point out this potential vulner= ability in the draft, and maybe even add some recommendations for the dCDN.= Francois' proposal of adding an extra metadata field could indeed add some= further flexibility to such behavior, although I don't think it's strictly= necessary. > > > > > >>> 2) Section 2.2 allows the KeyID to be included in the Signed URI. > >>> This also seems like it might open a security hole as a malicious UA > >>> could strip the original URISigningPackage attribute, sign the URI > >>> with a Key under its control (possibly altering other things like > >>> the actual URI or expiry time) and include the appropriate KeyID for = that > new Key in the new URISigningPackage. > >>> > >>> Is there a use case for signalling the KeyID within the Signed URI it= self? > >> > >> The use case for signaling the KeyID is the uCDN allowing multiple key= s to > be used in the metadata. In order to signal the used Key to the dCDN, the > KeyID field is used. > >> > >> Let's assume that for a given content item, the uCDN allows five diffe= rent > keys to be used (as announced in the metadata). You're right that if the = UA > would somehow have access to one of these five keys, and the associated > keyID, it could recalculate the URISigningPackage attribute. However, I d= on't > think this problem stems from the use of the KeyID field. Even if there w= ould > be only one key, and this key would be leaked, then the UA could also res= ign > the UA. So the question is, is the chance of a given key leaking bigger i= f it is > part of a set of allowed keys instead of the only allowed key? > > > > The attack surface could be larger than leaked keys. E.g. if the 5 keys= the > uCDN says are allowed came from different content providers, then the key > does't have to leak anywhere, an enterprising individual with legitimate > knowledge of CSP1's key could use CSP1's key to sign URIs and get hold o= f > content from CSP2. >=20 > In that situation, the uCDN woudl not advertise the 5 key IDs for all con= tents. > It would only advertise key-ID 1 for CSP1. So an individual knowing CSP1'= s key > woudl not be able to access CSP2 content. >=20 > > > > For the use case presented I think there is a better/easier way to solv= e it > rather than have each UA->dCDN request include which key to use. > > > > What I'd propose is: > > - Within CDNI Metadata the URI signing keys are associated with the > content to which they apply. >=20 > I believe that is already the case: > " o Allowable Key ID set that the Signed URI's Key ID information > element can reference > " >=20 > > > > - The CDNI Metadata can contain >1 key for a given piece of content. >=20 > I believe that is already the case (what is signaled is Key ID and not th= e key > itself of course): > " o Allowable Key ID set that the Signed URI's Key ID information > element can reference > " >=20 > > - If any of the keys included in the relevant CDNI Metadata correctly > validate the URI, then it is valid. >=20 > I believe this is effectively already teh case. The difference is that th= e key-ID > can optionally be included in the URI, so that the CDN does not need to > successively try ecah and every Key from the set of authorized keys for t= hat > content. >=20 > > > > That way a CSP can provide/use multiple keys if they want, there is no > need to signal the keyID to be used in the URI itself (so absolutely no a= bility > for a User Agent to affect it in any way), and you can do key-rollover wi= thout > having to co-ordinate KeyIDs between the party responsible for signing th= e > URI (the uCDN/CSP probably) and the party responsible for validating them > (the dCDN). >=20 > I don't see that includeing the key-ID in the URI increases the security = risk in > any ways (since the set of allowed key-ID is conveyed in metadata always)= . > And it has a benefit in avoiding to systematically have to try with every > possible key. > Am I missing something? >=20 Agree with Francois. As long as the CDNI Metadata Interface can be used to = convey the set of allowed keys per uCDN/dCDN combination, I don't see a ris= k.=20 > > > > > >>> 3) Regarding hash functions & digital signature algorithms, the > >>> draft hints at allowing several options for each and defines a > >>> default in case a particular algorithm is not specified in the > URISigningPackage. > >>> > >>> This seems a bit overkill to me. To aid inter-operability, I think > >>> it would be better to specify a single algorithm for each unless > >>> there are use cases for requiring support for more than one > >>> algorithm in the first version defined in the draft? > >>> > >> > >> Are you saying you would prefer to keep the HF and DSA fields but only > define one possible value for them in this document, or are you saying yo= u > would prefer to remove these fields and just specify a single mandatory h= ash > function and DS algorithm? Personally, I think it is useful to have the o= ption > of signaling different hash functions or DS algorithms. > > > > I am OK with leaving in the hooks for extensibility. > > > > I don't like the idea of specifying >1 hash function/digital signature > algorithm in this document. > > > > This document is defining a new URI signing algorithm for CDNI, there's= no > reason IMO why we can't start with a single Hash function & Digital Signa= ture > Algorithm for baseline interoperability and if folks need something else = in > future they can specify it. > > > > Several CDNs support >1 HF/DSA because things have evolved over time, > some newer functions are considered more secure or whatever and > backwards compatibility needs to be maintained. > > > > We're not in that position, the document is describing a new signing > mechanism that everyone will need to implement, we have no backwards > compatibility to maintain so let's not carry any historical baggage resul= ting > from CDN-proprietary URI signing schemes along with us. >=20 > That sounds right to me. Agree.=20 >=20 > Francois >=20 > > > > Ben > > > > > >> > >> Thanks, > >> > >> Ray > >> > >>> Regards > >>> Ben > >>> > >>> > >>> On 6 Mar 2014, at 15:34, Daryl Malas wrote: > >>> > >>>> All, > >>>> > >>>> During today's working group meeting, we agreed the latest draft > >>>> revision > >>> of this draft > >>> (http://tools.ietf.org/html/draft-leung-cdni-uri-signing-05) is > >>> substantial for us to adopt it as a working group item. However, > >>> Francois and I did not feel comfortable conducting a "Hum," since > >>> there were not a lot of people present who had read the draft. This > draft was proposed in response to the following charter item: > >>>> > >>>> A specification for "CDNI URI Signing". This document will specify > >>>> a mechanism that allows interconnected CDNs to support access > >>>> control by signing content URIs. This may involve extensions to the > >>>> CDNI interfaces (e.g. CDNI Metadata interface, CDNI Logging interfac= e). > >>>> > >>>> In addition, the working group has the following milestone: > >>>> > >>>> Sep 2014 - Submit specification of URI Signing for CDNI to IESG as > >>>> Proposed Standard > >>>> > >>>> With this in mind, we are requesting people read the draft in > >>>> preparation > >>> for this draft to be accepted as a working group item, which will > >>> occur on March 21st. If anyone has any major concerns with this, > >>> please post comments and concerns to the list. > >>>> > >>>> Regards, > >>>> > >>>> Daryl & Francois > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> CDNi mailing list > >>>> CDNi@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/cdni > >>> > >>> _______________________________________________ > >>> CDNi mailing list > >>> CDNi@ietf.org > >>> https://www.ietf.org/mailman/listinfo/cdni > >> > >> > >> > >> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien= u > niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezond= en, > wordt u verzocht dat aan de afzender te melden en het bericht te > verwijderen. TNO aanvaardt geen aansprakelijkheid voor de inhoud van > deze e-mail, de wijze waarop u deze gebruikt en voor schade, van welke > aard ook, die verband houdt met risico's verbonden aan het elektronisch > verzenden van berichten. > >> > >> > >> > >> This message may contain information that is not intended for you. If = you > are not the addressee or if this message was sent to you by mistake, you = are > requested to inform the sender and delete the message. TNO accepts no > liability for the content of this e-mail, for the manner in which you use= it and > for damage of any kind resulting from the risks inherent to the electroni= c > transmission of messages. > > From nobody Thu May 15 00:22:04 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244771A01F3 for ; Thu, 15 May 2014 00:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.145 X-Spam-Level: X-Spam-Status: No, score=0.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.651] 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 CDXTs6GxSBpT for ; Thu, 15 May 2014 00:21:56 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 45D331A020F for ; Thu, 15 May 2014 00:21:55 -0700 (PDT) X-IronPort-AV: E=Sophos; i="4.97,1057,1389740400"; d="scan'208,217"; a="4125103" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 15 May 2014 09:21:47 +0200 Received: from EXC-MBX03.tsn.tno.nl ([fe80::e969:1300:fb9f:7e12]) by EXC-CASHUB02.tsn.tno.nl ([fe80::8c02:de2a:3094:171%14]) with mapi id 14.03.0174.001; Thu, 15 May 2014 09:21:47 +0200 From: "Brandenburg, R. (Ray) van" To: "Francois Le Faucheur (flefauch)" , "iuniana.oprescu@orange.com" Thread-Topic: [CDNi] Adoption of draft-leung-cdni-uri-signing as a WG document Thread-Index: AQHPafpBYJrcjdvkTkej5lldhp9PpJs1Ac4AgAedjYCAADJ+AIAEc86Q Date: Thu, 15 May 2014 07:21:46 +0000 Message-ID: References: <0DB89F92-A961-4EF9-B94C-2787B0E4BDAA@cisco.com> <28257_1399889438_53709E1E_28257_9427_13_8F0D2F5E4AAB7249BC7339A3E944DEDD2284B99CB5@PMEXCB1D.intranet-paris.francetelecom.fr> <0F9E0105-612C-4360-930A-1DCB8E03C97E@cisco.com> In-Reply-To: <0F9E0105-612C-4360-930A-1DCB8E03C97E@cisco.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA15820053C41EXCMBX03tsntnon_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/B9kTajZOnFFjua3k9AmMtDZmjJE Cc: "draft-leung-cdni-uri-signing@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] Adoption of draft-leung-cdni-uri-signing as a WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 07:22:02 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA15820053C41EXCMBX03tsntnon_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Iuniana, Francois, From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: maandag 12 mei 2014 15:11 To: iuniana.oprescu@orange.com Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; draft-leung-cdni-uri-si= gning@tools.ietf.org Subject: Re: [CDNi] Adoption of draft-leung-cdni-uri-signing as a WG docume= nt On 12 May 2014, at 12:10, > > wrote: Hello IETF-ers, As previously stated, the current version of the draft is a good starting p= oint. After a quick chat with one of my colleagues, there are a few aspects that = we'd like to mention: 1. It seems that all CSPs share the same format of the URI signing, wh= ich might be a disadvantage as they often seem to have various specific met= hods. I know we are trying to achieve interoperability, but maybe it would = be worth adding another parameter to give more flexibility in the choice of= signing method (other than VER that doesn't seem well suited for this purp= ose). If DNS redirection is used, then the dCDNs will see the initial signature a= pplied by the CSP. So the URI signature spec defined by CDNI has to be used= by the CSP themselves. I agree that every CSP have their own way to do tha= t today. But to me it means we don;t have much chance of including in our s= pec the necessary flavors to avid change at the CSP. Given that situation, = I think our best bet to maximise interoperability is to define one simple m= andatory approach to implement and that all CDNs would support. If HTTP redirection is used, then the uCDN woudl perform URI resigning. So = each CSP can use its own URI signing algorithm (as long as they agree with = the uCDN) and then the CDNI URI signing scheme is applied when redirecting = to dCDN. Agree that in the DNS case CSP might have to adjust. At the same time, I se= e this fact having a benefit to CSP as well, even outside the context of CD= NI. Since there is currently no standardized method for conducting URI Sign= ing, (small) CSPs currently have the problem of having to maintain differen= t (CDN-mandated) URI Signing mechanism for each CDN they work with. Having = a well standardized method that is supported among CDNs might benefit such = CSPs. 2. For the objects presented in Section 5.4, I am not sure of my under= standing of the set of dCDNs sharing a symmetric key with the uCDN. Can tha= t be a security issue where a dCDN can spoof another dCDN that's using the = same key? If DNS redirection is used, then all dCDNs need to understand the original = signature. If the signature uses symmetric keys , then all dCDNs need to us= e that same shared key. This is a property of that deployment scenario (ie = DNS/symmetric). But yes the security implications need to be discussed. That's an interesting attack vector that I didn't consider before. I agree = we need to discuss this in the draft. If HTTP redirection is used, then the expected mode of operator will be tha= t the uCDN performs re-signing after URI rewrite, in which case a different= a different symmetric key can be used for each dCDN. 3. There seems to be a need to include the scenario in which there ar= e several users on a home LAN that are behind a box that does NAT. It would= be good to have a way to differentiate each individual request coming from= the devices on the same network. Of course it would be great if we could differentiate between users behind = a NAT. At the same time, I currently don't see a way to do that in a standa= rdized manner within the IETF. I'm aware of various proprietary mechanisms = for doing this, but they all rely (partly) on client-side behavior, which i= s out-of-scope here. Do you see any possibilities that I am missing? The be= st option I see is to work together with other SDOs, notable MPEG (DASH), t= o fix this. To be picky, maybe the example used in the draft could use an IP address th= at is in line with RFC 6761 instead of the classic private 10.0.0.1. Agreed, Yes. Will fix this. Thanks, Ray Thanks for the review and comments. Francois -- iuniana De : CDNi [mailto:cdni-bounces@ietf.org] De la part de Francois Le Faucheur= (flefauch) Envoy=E9 : mercredi 7 mai 2014 15:53 =C0 : cdni@ietf.org; draft-leung-cdni-uri-signing@too= ls.ietf.org Objet : Re: [CDNi] Adoption of draft-leung-cdni-uri-signing as a WG document All, I incorrectly thought the poll deadline was May 5th, but it was set to May = 12th in my poll message below. So just to make sure we are not preventing a= nyone from posting their feedback, let's hold off on the announcement below= until May 12th. We'll revaluate the decision then based on additional feed= back. Cheers Francois PS: I guess going on holidays can make one lose the notion of time ... On 7 May 2014, at 15:42, Francois Le Faucheur (flefauch) > wrote: Folks, In addition to the support expressed in London, we've heard as a result of = the list poll: * statements of strong support (Kevin, Matt, Scott, Daryl) * a statement of conditional support (Ben) * no objection/concern. So we (WG Chairs) confirm adoption of draft-leung-cdni-uri-signing as a WG = document, conditioned to resolution of Ben's comments. To draft authors, Please continue the discussion (on the WG mailer) with Ben to converge on h= ow to best address his comments, and then post a new version of the draft a= s draft-ietf-cdni-uri-signing-00. Cheers Francois On 25 Apr 2014, at 16:51, Francois Le Faucheur (flefauch) > wrote: Folks, Just to be clear, this is a follow up from Daryl's earlier message of 25 Ap= ril (http://www.ietf.org/mail-archive/web/cdni/current/msg01837.html), whic= h issued a similar request. We did not received much feedback so would like= to give another opportunity for more feedback. Francois Begin forwarded message: From: "Francois Le Faucheur (flefauch)" > Subject: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a W= G document Date: 25 April 2014 16:30:08 CEST To: "cdni@ietf.org" > Folks, During the London meeting: * authors confirmed that they believe the latest version of draft-leung-cdn= i-uri-signing resolved the issue related to draft-ietf-appsawg-uri-get-off-= my-lawn-04.txt. * WG chairs agreed to take to the list the question of adopting draft-leung= -cdni-uri-signing-05 as a WG document to ensure it gets sufficient review. This message is to encourage review of draft-leung-cdni-uri-signing-05 (htt= p://tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and sollicite fe= edback on adopting it as a WG document to address the corresponding milesto= ne on our charter. Please do so by end of 12 May (ie within the next 2 weeks). Francois & Daryl, CDNI WG Chairs For convenience, quote from IETF-89 CDNI WG meeting minutes : " Daryl (as chair): This is a deliverable on our charter, but not many people= have read the draft yet, so will take question for WG adoption to the list= to give people time to read it. " For convenience, relevant excerpt from the CDNI WG charter (http://tools.ie= tf.org/wg/cdni/charters): " The working group will focus on the following items: <...> - A specification for "CDNI URI Signing". This document will specify a mechanism that allows interconnected CDNs to support access control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). <...> Goals and Milestones: <...> Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Propose= d Standard " _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten. = This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. --_000_FCC100FC8D6B034CB88CD8173B2DA15820053C41EXCMBX03tsntnon_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Iuniana, Francois,

 <= /p>

 <= /p>

From: Francois Le Faucheur (flefauch= ) [mailto:flefauch@cisco.com]
Sent: maandag 12 mei 2014 15:11
To: iuniana.oprescu@orange.com
Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; draft-leung-cdni= -uri-signing@tools.ietf.org
Subject: Re: [CDNi] Adoption of draft-leung-cdni-uri-signing as a WG= document

=  

=  

On 12 May 2014, at 12:1= 0, <iuniana.oprescu@orange= .com> <iuniana.opre= scu@orange.com> wrote:



Hello IETF-ers,<= /p>

 

As previously stated, the current version of the draft i= s a good starting point.

 

After a quick chat with one of my colleagues, there are = a few aspects that we’d like to mention:

 

1.   &nbs= p;  It= seems that all CSPs share the same format of the URI signing, which might = be a disadvantage as they often seem to have various specific methods. I know we are trying to achieve interoperability, but maybe it wo= uld be worth adding another parameter to give more flexibility in the choic= e of signing method (other than VER that doesn’t seem well suited for= this purpose).

 

If DNS redirection is u= sed, then the dCDNs will see the initial signature applied by the CSP. So t= he URI signature spec defined by CDNI has to be used by the CSP themselves.= I agree that every CSP have their own way to do that today. But to me it means we don;t have much chance of incl= uding in our spec the necessary flavors to avid change at the CSP. Given th= at situation, I think our best bet to maximise interoperability is to defin= e one simple mandatory approach to implement and that all CDNs would support. 

 

If HTTP redirection is = used, then the uCDN woudl perform URI resigning. So each CSP can use its ow= n URI signing algorithm (as long as they agree with the uCDN) and then the = CDNI URI signing scheme is applied when redirecting to dCDN.

 

Agree that= in the DNS case CSP might have to adjust. At the same time, I see this fac= t having a benefit to CSP as well, even outside the context of CDNI. Since there is currently no standardized method for conducting UR= I Signing, (small) CSPs currently have the problem of having to maintain di= fferent (CDN-mandated) URI Signing mechanism for each CDN they work with. H= aving a well standardized method that is supported among CDNs might benefit such CSPs.

 

2.   &nbs= p;  Fo= r the objects presented in Section 5.4, I am not sure of my understanding o= f the set of dCDNs sharing a symmetric key with the uCDN. Can that be a security issue where a dCDN can spoof another dCDN that̵= 7;s using the same key?

 

If DNS redirection is u= sed, then all dCDNs need to understand the original signature. If the signa= ture uses symmetric keys , then all dCDNs need to use that same shared key.= This is a property of that deployment scenario (ie DNS/symmetric). But yes the security implications need to be = discussed.

 <= /p>

That’= ;s an interesting attack vector that I didn’t consider before. I agre= e we need to discuss this in the draft.

 

If= HTTP redirection is used, then the expected mode of operator will be that = the uCDN performs re-signing after URI rewrite, in which case a different a= different symmetric key can be used for each dCDN. 

 

3.=  &= nbsp;     There seems to be a need t= o include the scenario in which there are several users on a home LAN that = are behind a box that does NAT. It would be good to have a way to differentiate each individual request coming from the devices on = the same network.

 

Of course = it would be great if we could differentiate between users behind a NAT. At = the same time, I currently don’t see a way to do that in a standardized manner within the IETF. I’m aware of various proprietar= y mechanisms for doing this, but they all rely (partly) on client-side beha= vior, which is out-of-scope here. Do you see any possibilities that I am mi= ssing? The best option I see is to work together with other SDOs, notable MPEG (DASH), to fix this.

 = ;

To be picky, maybe the example used in the draft could u= se an IP address that is in line with RFC 6761 instead of the classic private 10.0.0.1.

 

Agreed,

 

Yes. Will fix this.

 <= /p>

Thanks,=


Ray

 <= /p>

Thanks for the review a= nd comments.

 

Francois



 

-- iuniana

 

 

De : CDNi [mailto:cdni-bounces@ietf.org] De la part de Francois Le Faucheur (flefauch)
Envoy=E9 : mercredi 7 mai 2014 15:53
=C0 : cdni@ietf.org; draft-leung-cdni-uri-signing@tools.ietf.org
Objet : Re: [CDNi] Adoption of draft-leung-cdni-uri-signing as = a WG document

 = ;

All, =

 = ;

I inc= orrectly thought the poll deadline was May 5th, but it was set to May 12th = in my poll message below. So just to make sure we are not preventing anyone= from posting their feedback, let’s hold off on the announcement below until May 12th. We’ll revaluate the de= cision then based on additional feedback.

 = ;

Cheer= s

 = ;

Franc= ois

 = ;

PS: I= guess going on holidays can make one lose the notion of time ...

 = ;

On 7 = May 2014, at 15:42, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:




Folks= ,

In ad= dition to the support expressed in London, we’ve heard as a result of= the list poll:

*&nbs= p;statements of strong support (Kevin, Matt, Scott, Daryl)

* a s= tatement of conditional support (Ben)

* no = objection/concern.

So we= (WG Chairs) confirm adoption of draft-leung-cdni-uri-signing as a WG = document, conditioned to resolution of Ben’s comments.

 = ;

To dr= aft authors,

Pleas= e continue the discussion (on the WG mailer) with Ben to converge on how to= best address his comments, and then post a new version of the draft as dra= ft-ietf-cdni-uri-signing-00.

 = ;

Cheer= s

 = ;

Franc= ois

 = ;

On 25= Apr 2014, at 16:51, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:




Folks= ,

 = ;

Just = to be clear, this is a follow up from Daryl’s earlier message of 25 A= pril (http://www.ietf.org/mail-archive/web/cdni/current/msg01837.html), which issued a similar request. We did not received much feedback so would= like to give another opportunity for more feedback.

 = ;

Franc= ois

 = ;

Begin= forwarded message:




From: "Francois Le Faucheur (flefauch)" <flefauch@cisco.com>

Subject: [= CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a WG document=

Date: 25 April 2014 16:30:08 CEST

To: "cdni@ietf.org" <cdni@ietf.org><= span lang=3D"FR">

 = ;

Folks= ,

During the London meeting:
* authors confirmed that they believe the latest version of draft-leung-cdn= i-uri-signing resolved the issue related to draft-ietf-appsawg-uri-get-off-= my-lawn-04.txt.
* WG chairs agreed to take to the list the question of adopting draft-leung= -cdni-uri-signing-05 as a WG document to ensure it gets sufficient review.<= br>
This message is to encourage review of draft-leung-cdni-uri-signing-05 (http:= //tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and sollicite = feedback on adopting it as a WG document to address the corresponding milestone on our charter.
Please do so by end of 12 May (ie within the next 2 weeks).

Francois & Daryl, CDNI WG Chairs



For convenience, quote from IETF-89 CDNI WG meeting minutes :
"
Daryl (as chair): This is a deliverable on our charter, but not many people= have read the draft yet, so will take question for WG adoption to the list= to give people time to read it.
“


For convenience, relevant excerpt from the CDNI WG charter (http://tools.ietf.org/wg/cdni/charters<= /a>):
“
The working group will focus on the following items:
<…>
 - A specification for "CDNI URI Signing". This document wil= l specify a
   mechanism that allows interconnected CDNs to support acce= ss control
   by signing content URIs. This may involve extensions to t= he CDNI
   interfaces (e.g. CDNI Metadata interface, CDNI Logging in= terface).

<…>

Goals and Milestones:
<…>
 Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Pr= oposed Standard
"
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni

 = ;

_____= __________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni

 = ;

_____= __________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni

 = ;

_______________________=
___________________________________________________________________________=
_______________________
 
Ce message et ses piece=
s jointes peuvent contenir des informations confidentielles ou privilegiees=
 et ne doivent donc
pas etre diffuses, expl=
oites ou copies sans autorisation. Si vous avez recu ce message par erreur,=
 veuillez le signaler
a l'expediteur et le de=
truire ainsi que les pieces jointes. Les messages electroniques etant susce=
ptibles d'alteration,
Orange decline toute re=
sponsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its at=
tachments may contain confidential or privileged information that may be pr=
otected by law;
they should not be dist=
ributed, used or copied without authorisation.
If you have received th=
is email in error, please notify the sender and delete this message and its=
 attachments.
As emails may be altere=
d, Orange is not liable for messages that have been modified, changed or fa=
lsified.
Thank you.

 




Dit b= ericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de= geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt= u verzocht dat aan de afzender te melden en het bericht te verwijderen. TN= O aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze= waarop u deze gebruikt en voor schade, van welke aard ook, die verband hou= dt met risico's verbonden aan het elektronisch verzenden van berichten.
=

 

This m= essage may contain information that is not intended for you. If you are not= the addressee or if this message was sent to you by mistake, you are reque= sted to inform the sender and delete the message. TNO accepts no liability = for the content of this e-mail, for the manner in which you use it and for = damage of any kind resulting from the risks inherent to the electronic tran= smission of messages.

--_000_FCC100FC8D6B034CB88CD8173B2DA15820053C41EXCMBX03tsntnon_-- From nobody Thu May 15 00:38:51 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F631A0411 for ; Thu, 15 May 2014 00:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 e2wn3fzSIWg5 for ; Thu, 15 May 2014 00:38:39 -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 C97FF1A026B for ; Thu, 15 May 2014 00:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3662; q=dns/txt; s=iport; t=1400139512; x=1401349112; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oe4e3g47vvHjJ4or9a7ThgvYV1vxI3+ddMfwKjfERy4=; b=YrwWduOlypdnfSd3yy0RJEwUL9SpPbaN0ZyVBx52CbO2INzlszw7plNw A0eKHHGBZNh2eRdsd6vLI4WG8Qz0rlZGy4RlXIbRyuh+zxUp6UHlX2ZVx nbGYohk/oGJjFYK+B06yzTBWV753wL27p8PUZ+R4y0y8IiWEbStqfrYRf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFALltdFOtJA2I/2dsb2JhbABZgwZPWMU8AYEUFnSCJQEBAQR5EAIBCBgVGTIlAgQOBYhB0TYXjhszBwqDIYEVBJlRkxSDNoFwJBw X-IronPort-AV: E=Sophos;i="4.97,1057,1389744000"; d="scan'208";a="325153342" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP; 15 May 2014 07:38:31 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4F7cVKn013155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 May 2014 07:38:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 15 May 2014 02:38:31 -0500 From: "Francois Le Faucheur (flefauch)" To: "Brandenburg, R. (Ray) van" Thread-Topic: [CDNi] URI Signing for CDNI Working Group Draft Thread-Index: AQHPbgMASoGYsdn+T0K5glDGAe/RFZs+eggAgAMV74CAAAkogA== Date: Thu, 15 May 2014 07:38:30 +0000 Message-ID: References: <147CBB6C-9F42-4758-909C-2FD9B96DB289@niven-jenkins.co.uk> <00E86C22-E72B-40DA-BC5D-49DEB4CB28B2@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.200] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/-0Iq0ylsxndggoYgKOZTN1am18o Cc: "cdni@ietf.org" Subject: Re: [CDNi] URI Signing for CDNI Working Group Draft X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 07:38:45 -0000 Hi Ray, On 15 May 2014, at 09:05, Brandenburg, R. (Ray) van wrote: >>=20 >>>=20 >>>=20 >>> Section 3 of the draft states "The entire URI except the "scheme name" >> part is protected by the URI signature." But if someone can append >> additional query parameters to a signed URI and still have it be conside= red >> "correctly signed" by a dCDN then the proposed mechanism is not protecti= ng >> "the entire URI". >>>=20 >>> That aside, as it stands, as specified in the draft I believe it is pos= sible to do >> the following: >>>=20 >>> Take a URI, e.g. >>> http://videos.example/videos?title=3Dbatman >>>=20 >>> and sign it to get something like >>>=20 >>> http://videos.example/videos?title=3Dbatman& >>>=20 >>> then present to a dCDN the following URI >>>=20 >>> http://videos.example/videos?title=3Dbatman&>> stuff>&quality=3DHD >>>=20 >>> which will correctly validate but lead to a dCDN acquiring/delivering >>>=20 >>> http://videos.example/videos?title=3Dbatman&quality=3DHD >>>=20 >>> which, even though it passes URI signing validation, is a different >> URI/resource to the one that was originally signed. >>=20 >>=20 >> That seems like a valid concern is some situations. At teh same time, I = believe >> there are valid situations where the CSP wants to allow un-signed query >> strings (because they can only affect things that need not be authorised= ). So >> how about adding one piece of metadata to CDNI Metadata that says: >> * allow query string to be extended after signature, which means >> (using the above example): >> - if the signature protecting >> "http://videos.example/videos?title=3Dbatman" is valid, then authorize >> "http://videos.example/videos?title=3Dbatman&> stuff>&quality=3DHD" >> - if the signature protecting >> "http://videos.example/videos?title=3Dbatman" is NOT valid, then block >> "http://videos.example/videos?title=3Dbatman&> stuff>&quality=3DHD" >> * disallow query string to be extended after signature, which means >> (using the above example): >> - regardless of URI signature validity, block >> "http://videos.example/videos?title=3Dbatman&> stuff>&quality=3DHD" >>=20 >=20 > I see Ben's point. That said, such behavior would be easily detectable at= the dCDN. The dCDN knows that any parameters in the query string to the ri= ght of the URI Signing Attribute have been added by the UA instead of the u= CDN. It would be fairly easy for a dCDN to ignore any such parameters for t= he purposes of selecting a content item The CDNI-Metadata interface includes an =93ignore-query-string=94 that cont= rols when the query-string is to be taken into account and when its not to = be taken into account for caching. So we cannot assume that the dCDN would = just always ignore query strings for content selection in the cache. " Property: ignore-query-string Description: Allows a cache to ignore URI query string parameters while comparing URIs for equivalence. Each query parameter to ignore is specified in the list. If all query parameters should be ignored, then the list MUST be empty. =93 Francois > (e.g. only using it for purposes of logging). I agree that we need to exp= licitly point out this potential vulnerability in the draft, and maybe even= add some recommendations for the dCDN. Francois' proposal of adding an ext= ra metadata field could indeed add some further flexibility to such behavio= r, although I don't think it's strictly necessary. From nobody Thu May 15 00:55:57 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37A01A040A for ; Thu, 15 May 2014 00:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] 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 VcDPvmEG9rko for ; Thu, 15 May 2014 00:55:54 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id BA81B1A0403 for ; Thu, 15 May 2014 00:55:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,1057,1389740400"; d="scan'208";a="25589158" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 15 May 2014 09:55:46 +0200 Received: from EXC-MBX03.tsn.tno.nl ([fe80::e969:1300:fb9f:7e12]) by EXC-CASHUB02.tsn.tno.nl ([fe80::8c02:de2a:3094:171%14]) with mapi id 14.03.0174.001; Thu, 15 May 2014 09:55:45 +0200 From: "Brandenburg, R. (Ray) van" To: "Francois Le Faucheur (flefauch)" Thread-Topic: [CDNi] URI Signing for CDNI Working Group Draft Thread-Index: AQHPSBomVjXoux+3r0uy5ywq9SFIlJstFjTQgBA+CoCAAPxDAIADLuzA///wLACAACXO0A== Date: Thu, 15 May 2014 07:55:44 +0000 Message-ID: References: <147CBB6C-9F42-4758-909C-2FD9B96DB289@niven-jenkins.co.uk> <00E86C22-E72B-40DA-BC5D-49DEB4CB28B2@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/2O78gDfgC1xdoM_me9cpdjx32EM Cc: "cdni@ietf.org" Subject: Re: [CDNi] URI Signing for CDNI Working Group Draft X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 07:55:55 -0000 Hi Francois, > -----Original Message----- > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Sent: donderdag 15 mei 2014 9:39 > To: Brandenburg, R. (Ray) van > Cc: Francois Le Faucheur (flefauch); Niven-Jenkins Ben; cdni@ietf.org; Ke= nt > Leung (kleung) > Subject: Re: [CDNi] URI Signing for CDNI Working Group Draft > = > Hi Ray, > = > On 15 May 2014, at 09:05, Brandenburg, R. (Ray) van > wrote: > >> > >>> > >>> > >>> Section 3 of the draft states "The entire URI except the "scheme name" > >> part is protected by the URI signature." But if someone can append > >> additional query parameters to a signed URI and still have it be > >> considered "correctly signed" by a dCDN then the proposed mechanism > >> is not protecting "the entire URI". > >>> > >>> That aside, as it stands, as specified in the draft I believe it is > >>> possible to do > >> the following: > >>> > >>> Take a URI, e.g. > >>> http://videos.example/videos?title=3Dbatman > >>> > >>> and sign it to get something like > >>> > >>> http://videos.example/videos?title=3Dbatman& > >>> > >>> then present to a dCDN the following URI > >>> > >>> http://videos.example/videos?title=3Dbatman& >>> stuff>&quality=3DHD > >>> > >>> which will correctly validate but lead to a dCDN > >>> acquiring/delivering > >>> > >>> http://videos.example/videos?title=3Dbatman&quality=3DHD > >>> > >>> which, even though it passes URI signing validation, is a different > >> URI/resource to the one that was originally signed. > >> > >> > >> That seems like a valid concern is some situations. At teh same time, > >> I believe there are valid situations where the CSP wants to allow > >> un-signed query strings (because they can only affect things that > >> need not be authorised). So how about adding one piece of metadata to > CDNI Metadata that says: > >> * allow query string to be extended after signature, which means > >> (using the above example): > >> - if the signature protecting > >> "http://videos.example/videos?title=3Dbatman" is valid, then authorize > >> "http://videos.example/videos?title=3Dbatman& >> stuff>&quality=3DHD" > >> - if the signature protecting > >> "http://videos.example/videos?title=3Dbatman" is NOT valid, then block > >> "http://videos.example/videos?title=3Dbatman& >> stuff>&quality=3DHD" > >> * disallow query string to be extended after signature, which means > >> (using the above example): > >> - regardless of URI signature validity, block > >> "http://videos.example/videos?title=3Dbatman& >> stuff>&quality=3DHD" > >> > > > > I see Ben's point. That said, such behavior would be easily detectable > > at the dCDN. The dCDN knows that any parameters in the query string to > > the right of the URI Signing Attribute have been added by the UA > > instead of the uCDN. It would be fairly easy for a dCDN to ignore any > > such parameters for the purposes of selecting a content item > = > The CDNI-Metadata interface includes an "ignore-query-string" that contro= ls > when the query-string is to be taken into account and when its not to be > taken into account for caching. So we cannot assume that the dCDN would > just always ignore query strings for content selection in the cache. > = I'm not suggesting that the dCDN ignore all query strings. I'm suggesting t= hat it ignores any query strings that are to the right of the URI Signing A= ttribute. Are you saying that any such text in the URI Signing draft might = conflict with text in the Metadata draft? In that case, we might need to fi= x this in both drafts. = Ray > " > Property: ignore-query-string > = > Description: Allows a cache to ignore URI query string > parameters while comparing URIs for equivalence. Each query > parameter to ignore is specified in the list. If all query > parameters should be ignored, then the list MUST be empty. > " > = > Francois > = > = > > (e.g. only using it for purposes of logging). I agree that we need to e= xplicitly > point out this potential vulnerability in the draft, and maybe even add s= ome > recommendations for the dCDN. Francois' proposal of adding an extra > metadata field could indeed add some further flexibility to such behavior, > although I don't think it's strictly necessary. > = > = > = Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten. = This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. From nobody Thu May 15 01:36:43 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCBA1A0425 for ; Thu, 15 May 2014 01:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fF6iDtr2Up1o for ; Thu, 15 May 2014 01:36:37 -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 242481A0424 for ; Thu, 15 May 2014 01:36:37 -0700 (PDT) X-AuditID: c6180641-f799b6d000000b0f-51-53742aae29da Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 82.BF.02831.EAA24735; Thu, 15 May 2014 04:47:11 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Thu, 15 May 2014 04:36:22 -0400 From: Kevin Ma J To: "Brandenburg, R. (Ray) van" Thread-Topic: [CDNi] URI Signing for CDNI Working Group Draft Thread-Index: AQHPSBomVjXoux+3r0uy5ywq9SFIlJstFjTQgBCin4CAAPxEAIADFe+AgAAJKACAAATRAIAABPaA Date: Thu, 15 May 2014 08:36:22 +0000 Message-ID: <0C233AB7-730E-49F8-B387-81A42D380ED6@ericsson.com> References: <147CBB6C-9F42-4758-909C-2FD9B96DB289@niven-jenkins.co.uk> <00E86C22-E72B-40DA-BC5D-49DEB4CB28B2@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXSPn+56rZJgg9NdQhZPZ/9htfi34DST xbfN1xkdmD2m/N7I6rFkyU8mj4PrLjAHMEdx2aSk5mSWpRbp2yVwZRxe8I2t4Jl+xcxnuxgb GB+pdTFyckgImEgsW7aQEcIWk7hwbz1bFyMXh5DAUUaJG1++s0I4yxkl1jacZgOpYhPQknj8 9S8TiC0iYC1x5XIXM4jNLBAr8eTFNCCbg0NYwEbi15R0iBJbic6GM+wQdpTEy+4rYGNYBFQl Pvw/CLaYV8Be4v71D+wQu24wS0yY+QmsgVPAR2LTwxlg8xmBrvt+ag0TxC5xiVtP5jNBXC0g sWTPeWYIW1Ti5eN/rBA1OhILdn9ig7CtJXbNPsgOYWtLLFv4mhlisaDEyZlPWCYwis1CMnYW kvZZSNpnIWmfhaR9ASPrKkaO0uLUstx0I8NNjMCYOibB5riDccEny0OMAhyMSjy8D8qKg4VY E8uKK3MPMUpzsCiJ834VLwkWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLjJgsPjdYr6Ar6A mnrLB+4ZZ7c864r8uuv7vQ8tpxJVHTjDP2+MXr4y/2WQGjNLy2b2CXs2y6zPPd35mHODxIrC jJcfN0SIP3Q6nDK9dc+ZaRFM111mfrOUu8nLd8Bxwr1aHSNNuduNUZyz45eKKis8O7/37N2O wE7lTzv77U4zfpeQbrvsu06JpTgj0VCLuag4EQA4xiHtigIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/sziT46Ee7LWFBaHkVoHEzkln-k4 Cc: "cdni@ietf.org" Subject: Re: [CDNi] URI Signing for CDNI Working Group Draft X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 08:36:41 -0000 Hi all, Does the signing token not contain all of the attributes (including non-C= DNI attributes) of the signed query string (note: there is a known size con= cern with this approach)? The dCDN should probably only rely on those in t= he token, if it is concerned about tampering? -- Kevin J. Ma Sent from my iPhone > On May 15, 2014, at 8:55 AM, "Brandenburg, R. (Ray) van" wrote: >=20 > Hi Francois, >=20 >> -----Original Message----- >> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] >> Sent: donderdag 15 mei 2014 9:39 >> To: Brandenburg, R. (Ray) van >> Cc: Francois Le Faucheur (flefauch); Niven-Jenkins Ben; cdni@ietf.org; K= ent >> Leung (kleung) >> Subject: Re: [CDNi] URI Signing for CDNI Working Group Draft >>=20 >> Hi Ray, >>=20 >> On 15 May 2014, at 09:05, Brandenburg, R. (Ray) van >> wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>> Section 3 of the draft states "The entire URI except the "scheme name= " >>>> part is protected by the URI signature." But if someone can append >>>> additional query parameters to a signed URI and still have it be >>>> considered "correctly signed" by a dCDN then the proposed mechanism >>>> is not protecting "the entire URI". >>>>>=20 >>>>> That aside, as it stands, as specified in the draft I believe it is >>>>> possible to do >>>> the following: >>>>>=20 >>>>> Take a URI, e.g. >>>>> http://videos.example/videos?title=3Dbatman >>>>>=20 >>>>> and sign it to get something like >>>>>=20 >>>>> http://videos.example/videos?title=3Dbatman& >>>>>=20 >>>>> then present to a dCDN the following URI >>>>>=20 >>>>> http://videos.example/videos?title=3Dbatman&>>>> stuff>&quality=3DHD >>>>>=20 >>>>> which will correctly validate but lead to a dCDN >>>>> acquiring/delivering >>>>>=20 >>>>> http://videos.example/videos?title=3Dbatman&quality=3DHD >>>>>=20 >>>>> which, even though it passes URI signing validation, is a different >>>> URI/resource to the one that was originally signed. >>>>=20 >>>>=20 >>>> That seems like a valid concern is some situations. At teh same time, >>>> I believe there are valid situations where the CSP wants to allow >>>> un-signed query strings (because they can only affect things that >>>> need not be authorised). So how about adding one piece of metadata to >> CDNI Metadata that says: >>>> * allow query string to be extended after signature, which means >>>> (using the above example): >>>> - if the signature protecting >>>> "http://videos.example/videos?title=3Dbatman" is valid, then authorize >>>> "http://videos.example/videos?title=3Dbatman&>>> stuff>&quality=3DHD" >>>> - if the signature protecting >>>> "http://videos.example/videos?title=3Dbatman" is NOT valid, then block >>>> "http://videos.example/videos?title=3Dbatman&>>> stuff>&quality=3DHD" >>>> * disallow query string to be extended after signature, which means >>>> (using the above example): >>>> - regardless of URI signature validity, block >>>> "http://videos.example/videos?title=3Dbatman&>>> stuff>&quality=3DHD" >>>=20 >>> I see Ben's point. That said, such behavior would be easily detectable >>> at the dCDN. The dCDN knows that any parameters in the query string to >>> the right of the URI Signing Attribute have been added by the UA >>> instead of the uCDN. It would be fairly easy for a dCDN to ignore any >>> such parameters for the purposes of selecting a content item >>=20 >> The CDNI-Metadata interface includes an "ignore-query-string" that contr= ols >> when the query-string is to be taken into account and when its not to be >> taken into account for caching. So we cannot assume that the dCDN would >> just always ignore query strings for content selection in the cache. >=20 > I'm not suggesting that the dCDN ignore all query strings. I'm suggesting= that it ignores any query strings that are to the right of the URI Signing= Attribute. Are you saying that any such text in the URI Signing draft migh= t conflict with text in the Metadata draft? In that case, we might need to = fix this in both drafts.=20 >=20 > Ray >=20 >> " >> Property: ignore-query-string >>=20 >> Description: Allows a cache to ignore URI query string >> parameters while comparing URIs for equivalence. Each query >> parameter to ignore is specified in the list. If all query >> parameters should be ignored, then the list MUST be empty. >> " >>=20 >> Francois >>=20 >>=20 >>> (e.g. only using it for purposes of logging). I agree that we need to e= xplicitly >> point out this potential vulnerability in the draft, and maybe even add = some >> recommendations for the dCDN. Francois' proposal of adding an extra >> metadata field could indeed add some further flexibility to such behavio= r, >> although I don't think it's strictly necessary. >=20 >=20 >=20 >=20 > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u = niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden= , wordt u verzocht dat aan de afzender te melden en het bericht te verwijde= ren. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, d= e wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verb= and houdt met risico's verbonden aan het elektronisch verzenden van bericht= en. >=20 >=20 >=20 > This message may contain information that is not intended for you. If you= are not the addressee or if this message was sent to you by mistake, you a= re requested to inform the sender and delete the message. TNO accepts no li= ability for the content of this e-mail, for the manner in which you use it = and for damage of any kind resulting from the risks inherent to the electro= nic transmission of messages. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Mon May 19 01:31:04 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B811A029F for ; Mon, 19 May 2014 01:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.244 X-Spam-Level: ** X-Spam-Status: No, score=2.244 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] 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 S7WREK2szOr0 for ; Mon, 19 May 2014 01:30:59 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC1B1A0162 for ; Mon, 19 May 2014 01:30:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,865,1392159600"; d="scan'208";a="4151679" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 19 May 2014 10:30:58 +0200 Received: from EXC-MBX03.tsn.tno.nl ([fe80::e969:1300:fb9f:7e12]) by EXC-CASHUB03.tsn.tno.nl ([fe80::6d39:f277:173e:a926%13]) with mapi id 14.03.0174.001; Mon, 19 May 2014 10:30:58 +0200 From: "Brandenburg, R. (Ray) van" To: Kevin Ma J Thread-Topic: [CDNi] URI Signing for CDNI Working Group Draft Thread-Index: AQHPSBomVjXoux+3r0uy5ywq9SFIlJstFjTQgBA+CoCAAPxDAIADLuzA///wLACAACXO0P//6l0AgAZpUQA= Date: Mon, 19 May 2014 08:30:57 +0000 Message-ID: References: <147CBB6C-9F42-4758-909C-2FD9B96DB289@niven-jenkins.co.uk> <00E86C22-E72B-40DA-BC5D-49DEB4CB28B2@niven-jenkins.co.uk> <0C233AB7-730E-49F8-B387-81A42D380ED6@ericsson.com> In-Reply-To: <0C233AB7-730E-49F8-B387-81A42D380ED6@ericsson.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" Content-ID: <111CE812DEC03249AD8E99F019BF7765@tno.nl> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/hvmXSGGygoU4ITJ7BzeQRzcNVqw Cc: "cdni@ietf.org" Subject: Re: [CDNi] URI Signing for CDNI Working Group Draft X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 08:31:01 -0000 Correct. I will add such a note to the next iteration. Thanks, Ray On 15/05/14 10:36, "Kevin Ma J" wrote: >Hi all, > > Does the signing token not contain all of the attributes (including >non-CDNI attributes) of the signed query string (note: there is a known >size concern with this approach)? The dCDN should probably only rely on >those in the token, if it is concerned about tampering? > >-- Kevin J. Ma > >Sent from my iPhone > >> On May 15, 2014, at 8:55 AM, "Brandenburg, R. (Ray) van" >> wrote: >> = >> Hi Francois, >> = >>> -----Original Message----- >>> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] >>> Sent: donderdag 15 mei 2014 9:39 >>> To: Brandenburg, R. (Ray) van >>> Cc: Francois Le Faucheur (flefauch); Niven-Jenkins Ben; cdni@ietf.org; >>>Kent >>> Leung (kleung) >>> Subject: Re: [CDNi] URI Signing for CDNI Working Group Draft >>> = >>> Hi Ray, >>> = >>> On 15 May 2014, at 09:05, Brandenburg, R. (Ray) van >>> wrote: >>>>> = >>>>>> = >>>>>> = >>>>>> Section 3 of the draft states "The entire URI except the "scheme >>>>>>name" >>>>> part is protected by the URI signature." But if someone can append >>>>> additional query parameters to a signed URI and still have it be >>>>> considered "correctly signed" by a dCDN then the proposed mechanism >>>>> is not protecting "the entire URI". >>>>>> = >>>>>> That aside, as it stands, as specified in the draft I believe it is >>>>>> possible to do >>>>> the following: >>>>>> = >>>>>> Take a URI, e.g. >>>>>> http://videos.example/videos?title=3Dbatman >>>>>> = >>>>>> and sign it to get something like >>>>>> = >>>>>> http://videos.example/videos?title=3Dbatman& >>>>>> = >>>>>> then present to a dCDN the following URI >>>>>> = >>>>>> http://videos.example/videos?title=3Dbatman&>>>>> stuff>&quality=3DHD >>>>>> = >>>>>> which will correctly validate but lead to a dCDN >>>>>> acquiring/delivering >>>>>> = >>>>>> http://videos.example/videos?title=3Dbatman&quality=3DHD >>>>>> = >>>>>> which, even though it passes URI signing validation, is a different >>>>> URI/resource to the one that was originally signed. >>>>> = >>>>> = >>>>> That seems like a valid concern is some situations. At teh same time, >>>>> I believe there are valid situations where the CSP wants to allow >>>>> un-signed query strings (because they can only affect things that >>>>> need not be authorised). So how about adding one piece of metadata to >>> CDNI Metadata that says: >>>>> * allow query string to be extended after signature, which means >>>>> (using the above example): >>>>> - if the signature protecting >>>>> "http://videos.example/videos?title=3Dbatman" is valid, then authorize >>>>> "http://videos.example/videos?title=3Dbatman&>>>> stuff>&quality=3DHD" >>>>> - if the signature protecting >>>>> "http://videos.example/videos?title=3Dbatman" is NOT valid, then block >>>>> "http://videos.example/videos?title=3Dbatman&>>>> stuff>&quality=3DHD" >>>>> * disallow query string to be extended after signature, which >>>>>means >>>>> (using the above example): >>>>> - regardless of URI signature validity, block >>>>> "http://videos.example/videos?title=3Dbatman&>>>> stuff>&quality=3DHD" >>>> = >>>> I see Ben's point. That said, such behavior would be easily detectable >>>> at the dCDN. The dCDN knows that any parameters in the query string to >>>> the right of the URI Signing Attribute have been added by the UA >>>> instead of the uCDN. It would be fairly easy for a dCDN to ignore any >>>> such parameters for the purposes of selecting a content item >>> = >>> The CDNI-Metadata interface includes an "ignore-query-string" that >>>controls >>> when the query-string is to be taken into account and when its not to >>>be >>> taken into account for caching. So we cannot assume that the dCDN would >>> just always ignore query strings for content selection in the cache. >> = >> I'm not suggesting that the dCDN ignore all query strings. I'm >>suggesting that it ignores any query strings that are to the right of >>the URI Signing Attribute. Are you saying that any such text in the URI >>Signing draft might conflict with text in the Metadata draft? In that >>case, we might need to fix this in both drafts. >> = >> Ray >> = >>> " >>> Property: ignore-query-string >>> = >>> Description: Allows a cache to ignore URI query string >>> parameters while comparing URIs for equivalence. Each query >>> parameter to ignore is specified in the list. If all query >>> parameters should be ignored, then the list MUST be empty. >>> " >>> = >>> Francois >>> = >>> = >>>> (e.g. only using it for purposes of logging). I agree that we need to >>>>explicitly >>> point out this potential vulnerability in the draft, and maybe even >>>add some >>> recommendations for the dCDN. Francois' proposal of adding an extra >>> metadata field could indeed add some further flexibility to such >>>behavior, >>> although I don't think it's strictly necessary. >> = >> = >> = >> = >> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien >>u niet de geadresseerde bent of dit bericht abusievelijk aan u is >>toegezonden, wordt u verzocht dat aan de afzender te melden en het >>bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de >>inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor schade, >>van welke aard ook, die verband houdt met risico's verbonden aan het >>elektronisch verzenden van berichten. >> = >> = >> = >> This message may contain information that is not intended for you. If >>you are not the addressee or if this message was sent to you by mistake, >>you are requested to inform the sender and delete the message. TNO >>accepts no liability for the content of this e-mail, for the manner in >>which you use it and for damage of any kind resulting from the risks >>inherent to the electronic transmission of messages. >> = >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten. = This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. From nobody Mon May 19 01:48:54 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19701A02BA for ; Mon, 19 May 2014 01:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 YZE3YJFZlf0T for ; Mon, 19 May 2014 01:48:50 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 734E81A0162 for ; Mon, 19 May 2014 01:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3996; q=dns/txt; s=iport; t=1400489330; x=1401698930; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=kQoCgTPPOZ6I9zaiCX5TH6rULw6OgauYD9cESLhUfW4=; b=JVo1VPmjKshdGJTuic9nkz/+4e7ma/cYTyc1VKvx4wz7kzOkQp/Euzgi MJJZaeCDfBnK++yiTVeRSr2UO9OJSg2jhbBjkuZEJNbTLv15MgbYk2nSN gojGUktJcLSL97lQHtd2orD+PbtbusghIdNkmFdSfZrF3I6PvLfQ+vqF0 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYGAF3EeVOtJA2E/2dsb2JhbABZgkJEUVi7CIFCAYc8AYEPFnSCJgEBBAEBAWsbAgEIBDsHJwsUEQIEE4hBDdE+F45XgyuBFQSZWoE9kV2DN4Iw X-IronPort-AV: E=Sophos;i="4.98,865,1392163200"; d="scan'208,217";a="325999424" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP; 19 May 2014 08:48:35 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s4J8mYi7018879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 19 May 2014 08:48:35 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Mon, 19 May 2014 03:48:34 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] CDNI Logging WGLC Thread-Index: AQHPcz8e92tIH6PPrEOjIVU/Y4kOyg== Date: Mon, 19 May 2014 08:48:34 +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: [10.55.161.204] Content-Type: multipart/alternative; boundary="_000_BF1B9B74ED974B0AAC1BB643B94BFF12ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/pIFLB55xa8LcY4HM_B7KppkyGLE Subject: Re: [CDNi] CDNI Logging WGLC X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 08:48:52 -0000 --_000_BF1B9B74ED974B0AAC1BB643B94BFF12ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone, The WG chairs received a private query about the status of cdni-logging. So= just to make sure it is clear to everyone: * the WG Last Call is complete * we kindly received a very thorough early OPSDIR review (in view of making= the document better prepared for IESG review later). The authors are in th= e process of addressing these comments (with the most significant ones bein= g discussed on the list). Cheers Francois & Daryl On 29 Mar 2014, at 17:09, Daryl Malas > wrote: All, As we discussed in the last IETF meeting, after the remaining issues were a= ddressed per the meeting minutes, we are going to WGLC for the CDNI logging= draft (http://tools.ietf.org/html/draft-ietf-cdni-logging-11). These issu= es were addressed in rev 11 of the logging draft, so we are beginning a las= t call on this draft. This last call will take place starting today throug= h April 11th. If there are any remaining questions, concerns or issues, pl= ease send them to the mailing list during this time frame. Regards, Daryl & Francois _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_BF1B9B74ED974B0AAC1BB643B94BFF12ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi everyone,

The WG chairs received a private query about the status of cdni-loggin= g. So just to make sure it is clear to everyone:
* the = WG Last Call is complete
* we k= indly received a very thorough early OPSDIR review (in view of making the d= ocument better prepared for IESG review later). The authors are in the proc= ess of addressing these comments (with the most significant ones being discussed on the list).

Cheers

Francois & Daryl

On 29 Mar 2014, at 17:09, Daryl Malas <D.Malas@cablelabs.com> wrote:

All,

As we discussed in the last IETF meeting, after the remaining issues w= ere addressed per the meeting minutes, we are going to WGLC for the CDNI lo= gging draft (http://tools.ietf.org/html/draft-ietf-cdni-logging-11).  These issues were addressed in rev 11 of the logging draft, so we ar= e beginning a last call on this draft.  This last call will take place= starting today through April 11th.  If there are any remaining questi= ons, concerns or issues, please send them to the mailing list during this time frame.

Regards,

Daryl & Francois
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

--_000_BF1B9B74ED974B0AAC1BB643B94BFF12ciscocom_-- From nobody Mon May 26 08:33:14 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316581A019B; Mon, 26 May 2014 08:33:11 -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 jj0egS_JSV93; Mon, 26 May 2014 08:33:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDA51A01A6; Mon, 26 May 2014 08:33:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140526153303.16358.68136.idtracker@ietfa.amsl.com> Date: Mon, 26 May 2014 08:33:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/QHrdtZ8lCctEmP4_yJnpeg5BBkE Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-framework-12.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 15:33:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF. Title : Framework for CDN Interconnection Authors : Larry Peterson Bruce Davie Ray van Brandenburg Filename : draft-ietf-cdni-framework-12.txt Pages : 56 Date : 2014-05-26 Abstract: This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDN Interconnection requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. This document, in combination with RFC 6707, obsoletes RFC 3466. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-framework-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-framework-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 30 23:21:51 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF19B1A06F7; Fri, 30 May 2014 23:21:45 -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 Dd0gfq3M9T8e; Fri, 30 May 2014 23:21:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5931A0730; Fri, 30 May 2014 23:21:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140531062141.15474.46095.idtracker@ietfa.amsl.com> Date: Fri, 30 May 2014 23:21:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/U9e0hHv38ih63g5uN-mKnIh8hxA Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-framework-13.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 06:21:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF. Title : Framework for CDN Interconnection Authors : Larry Peterson Bruce Davie Ray van Brandenburg Filename : draft-ietf-cdni-framework-13.txt Pages : 56 Date : 2014-05-30 Abstract: This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDN Interconnection requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. This document, in combination with RFC 6707, obsoletes RFC 3466. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-framework-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-framework-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/