Subject: Re: [Acme] New Version Notification for draft-fieau-cdni-https-delegation-00.txt

From: [email-masked]
Date: Wed, 9 Nov 2016 16:50:19 +0000

Hi -- Just wanted to follow up to Fred's email. Our intent for this draft was to look at published drafts - OOB, Short-term certs, Session Key Interface (referred in the draft as LURK) and short-lived certificates as probable choices for applicability to CDNi, specifically, delegation of HTTPS content from an upstream CDN to a downstream CDN. 

Based on our understanding, we have attempted to summarize applicability and issues with above proposal and would like to hear feedback on our interpretation. Some of our findings:

On LURK (sec 6.1) we note following advantages: 
1) A LURK i/f may provide advantages to HTTPS delegation (for CDNi), such as, the origin of the information can be preserved (provided DNS is used to redirect a UA from an upstream CDN to a down-stream CDN)
2) Leakage of private key is considered safer (storing separately from the content)
3) Does not impact the UA or the TLS stack
4) Easy revocation by denying access to the key server

On the flip side though, we think, the RTT for UA is not guaranteed as session keys are fetched from the key server.

On OOB (sec 6.2), we note follow advantages:
1) CDNs don’t need keys and can stay agnostic to content
2) Client makes separate and authenticated contact with the secondary servers (ie dCDN)

On the flip side, we noted following issues:
1) How is origin preserved in case of OOB chaining n CDNi
2) How to improve performance in the E2E delegation, that is, from the Origin to dCDN within a single OOB resource map the UA receives.
3) E2E delegation using OOB with DNS redirect may raise an issue where the requested domain does not match the URI causing UI to issue a warning. Or, in different scenario, using 302 redirect initially followed by OOB may raise delegation issues where the origin of information is the uCDN and not the origin.
4) How to avoid circular redirection

Subcerts (sec 6.3)

RE subcerts, the analysis requires additional details, such as ability to cascade sub-certs. That is, in one scenario, we envisage, that when the Origin Server shares its key and certificate with the up-stream CDN, in this case, we expect uCDN to issue sub-certificate to the dCDN, however, in cases where the Origin (content owner) does not share the keys and the certificates with the up-stream CDN but allows the CDN to request sub-certs, it is not conclusive, whether a uCDN can then authorize dCDN with a sub-certificate off its own subcerts. Our draft did not cover pros and cons for various method as sub-certs draft have listed those within each sub-section.

Short-lived certificates (sec 6.3)
One of the draw-back we noted here was all parties would need to implement ACME (which can also be a benefit should the CDN, Content owner and CA support full automation and compliance to ACME protocol). Our draft did not review the most recent draft Yarron published.

Any guidance or comments to above are welcome and also we would be happy to provide a short-overview should there be any interest in the mailing list, though we realize, the chairs have published the agenda and there may not be availability of any time slot but we can ask if it will be useful.

Thanks
Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 31, 2016 2:48 PM
To: [email-masked]
Cc: STEPHAN Emile IMT/OLN; Mishra, Sanjay
Subject: [E] TR: New Version Notification for draft-fieau-cdni-https-delegation-00.txt

Hi All,

Just posted a new draft highlighting Out-of-Band "redirection", SubCerts and Short-Lived certs approaches for HTTPS delegation in CDNI.
Feel free to comment.

Best regards,
Frédéric

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] Envoyé : lundi 31 octobre 2016 19:41 À : FIEAU Frédéric IMT/OLN; STEPHAN Emile IMT/OLN; STEPHAN Emile IMT/OLN; Sanjay Mishra Objet : New Version Notification for draft-fieau-cdni-https-delegation-00.txt

A new version of I-D, draft-fieau-cdni-https-delegation-00.txt
has been successfully submitted by Frederic Fieau and posted to the IETF repository.

Name:		draft-fieau-cdni-https-delegation
Revision:	00
Title:		HTTPS delegation in CDNI
Document date:	2016-10-31
Group:		Individual Submission
Pages:		18
URL:            https://www.ietf.org/internet-drafts/draft-fieau-cdni-https-delegation-00.txt
Status:         https://datatracker.ietf.org/doc/draft-fieau-cdni-https-delegation/
Htmlized:       https://tools.ietf.org/html/draft-fieau-cdni-https-delegation-00

Abstract:
   This document examines probable solutions for delegating of encrypted
   content within the context of CDN interconnection.  HTTPS delegation
   allows a delivering party, e.g. a CDN, to deliver content for and on-
   behalf of an origin server.  The HTTPS delegation also expects
   delivering content without compromising security, integrity and
   privacy of the user.  This document examines Internet Drafts that
   have been submitted along with their implementation status.

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.

The IETF Secretariat

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 information 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 delete 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.