Subject: [CDNi] LURK: draft-fieau-cdni-https-delegation-02

From: Ori Finkelman <[email-masked]>
Date: Wed, 20 Dec 2017 10:20:31 +0200

Hi,
Currently this draft lists LURK as one the options for certificate
delegation, however, its complementary interface
draft draft-fieau-cdni-interfaces-https-delegation-02 does not provide an
interface for that.
>From discussions we had in the last SVA meeting we believe that LURK is the
best alternative for the open caching use case, where the dCDN is the ISP
and uCDN is a commercial CDN.
I also believe that LURK is a good candidate for CDNI in general.

Can CDNI help promote LURK so it can be adopted ?

Best regards,
Ori

-- 

*Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
[email-masked]

---

From: Kevin Ma <[email-masked]>
Date: Thu, 21 Dec 2017 17:55:59 -0500

Hi Ori,

  (As chair) LURK is beyond the scope of the CDNI charter.  The LURK BoF
held at IETF-96 did not lead to a WG.  As I recall, there were concerns
about signing oracles and privacy, and many leaned toward ACME.  The CDNI
use case was also not pushed, and there were additional security concerns
from the AD about the transitive use case. (
https://datatracker.ietf.org/meeting/96/materials/minutes-96-lurk/)

  From a CDNI perspective, we can define CDNI support for using existing
protocols (e.g., ACME or LURK if defined), but we are not chartered to
define a new protocol for LURK.  In general, the sec area is better suited
for defining security protocols than arts.  I have not seen much on the
lurk list recently (
https://www.ietf.org/mail-archive/web/lurk/current/maillist.html), but that
is possibly a better venue for pushing for the advancement of LURK.

thanx.

--  Kevin J. Ma

On Wed, Dec 20, 2017 at 3:20 AM, Ori Finkelman <[email-masked]> wrote:

> delegation, however, its complementary interface draft draft-fieau-cdni-interfaces-https-delegation-02
> does not provide an interface for that.
> From discussions we had in the last SVA meeting we believe that LURK is
> the best alternative for the open caching use case, where the dCDN is the
> ISP and uCDN is a commercial CDN.
> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <+972%2072-222-1647> |
> Mobile: +972-52-3832189 <+972%2052-383-2189> | [email-masked]
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>
>

---

From: Ori Finkelman <[email-masked]>
Date: Sun, 24 Dec 2017 09:49:34 +0200

Hi Kevin,
After several discussions in the SVA, LURK is currently the leading
alternative for DNS delegation, and in fact, I don't believe there is
another valid option. The ACME alternatives are best suited for the Origin
-> CDN delegation, where trust is already in place.
Delegating from a CDN who is trusted by an origin, to an ISP, crosses the
trust boundaries and I don't think short term certs, or sub-cert makes the
relationship any easier to manage.
Repeating here the reasons why I don't think LURK latency or performance
are an issue in Open Caching use case, and probably in other CDNI cases:

+ Latency - for a long ABR stream / session, getting some additional
latency for the first transaction only is not an issue, certainly when
considering the alternative to be HTTP 302 redirect, which induces latency
of the similar order.
+ Performance - unlike the domain owner to CDN delegation scenario, when a
commercial CDN delegates to an ISP, the CDN must have the capacity in place
for the original load, so being able to support TLS session key exchange
once per ABR session is not a real issue (this was confirmed in last SVA
meeting)
+ High availability - is not an issue from the same reason as performance.

I know there are people we need to convince about this, but I think this is
the right solution for the use case.
I understand the CDNI is not chartered to lead such a draft, but I wonder
how we can help promoting it within SEC ?

Happy holidays,
Ori

On Fri, Dec 22, 2017 at 12:55 AM, Kevin Ma <[email-masked]>
wrote:

> from the AD about the transitive use case. (https://datatracker.ietf.org/
> meeting/96/materials/minutes-96-lurk/)
>
> lurk list recently (https://www.ietf.org/mail-arc
> hive/web/lurk/current/maillist.html), but that is possibly a better venue
> for pushing for the advancement of LURK.
>
> thanx.
>
> --  Kevin J. Ma
>
>> draft draft-fieau-cdni-interfaces-https-delegation-02 does not provide
>> an interface for that.

-- 

*Ori Finkelman*Qwilt | Work: +972-72-2221647 <072-222-1647> | Mobile:
+972-52-3832189 <052-383-2189> | [email-masked]