Subject: [Lurk] FW: New Version Notification for draft-mglt-lurk-tls-abstract-api-00.txt

From: Daniel Migault <[email-masked]>
Date: Fri, 19 Feb 2016 14:46:53 +0000

Hi, 

Please find an abstract description for an API between Edge and Content Provider. It is far from being finalized, but I believe early comment would be valuable to make the work progress.

I hope it will be helpful, and that a more complete version will be provided before next IETF meeting.

BR, 
Daniel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 19, 2016 9:42 AM
To: Daniel Migault
Subject: New Version Notification for draft-mglt-lurk-tls-abstract-api-00.txt

A new version of I-D, draft-mglt-lurk-tls-abstract-api-00.txt
has been successfully submitted by Daniel Migault and posted to the IETF repository.

Name:		draft-mglt-lurk-tls-abstract-api
Revision:	00
Title:		TLS/DTLS Content Provider Edge Server Abstract API
Document date:	2016-02-19
Group:		Individual Submission
Pages:		14
URL:            https://www.ietf.org/internet-drafts/draft-mglt-lurk-tls-abstract-api-00.txt
Status:         https://datatracker.ietf.org/doc/draft-mglt-lurk-tls-abstract-api/
Htmlized:       https://tools.ietf.org/html/draft-mglt-lurk-tls-abstract-api-00

Abstract:
   This document describes the interactions between the Edge Server and
   the Content Provider in a split authentication scenario.

   This document provides an abstract description of the information
   exchanged between an Edge Server and a Content Provider.

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

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 19 Feb 2016 18:19:43 +0200

Hi Daniel,

Thanks for writing the draft! Here are some initial comments.

  * Many of the authentication methods you mention are deprecated,
    rarely used, or rarely used for the relevant use case. Examples
    include dh_anon, anything with dss, and anything with psk. I would
    suggest to concentrate on the very few that are in actual use with
    CDNs. This would enable us to simplify the (future) protocol and its
    implementations.
  * The only exception to the above is *_ecdsa which is still rare, but
    expected to grow.
  * At a higher level, I'm not clear about the value of an abstract API.
    Once we settle on use cases, I suppose we will want to create a
    concrete protocol between the Edge Server and Content Provider. This
    would solve the problem in an interoperable way. Why would we want
    an abstract API in addition to the protocol? That is, unless you
    look at the abstract API as a sort of high-level design for the
    protocol.
  * Sec. 4.3.1 demonstrates issues that are typically not discussed with
    abstract APIs but are important here. Specifically, resistance to
    timing attacks.
  * Typo: RFC 2546.

Best,

     Yaron

On 02/19/2016 04:46 PM, Daniel Migault wrote:
> _______________________________________________
> Lurk mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lurk

---

From: Daniel Migault <[email-masked]>
Date: Fri, 19 Feb 2016 19:34:24 +0000

Hi Yaron,

Thanks for the feed backs. Please see inline my responses.

BR,
Daniel

From: Yaron Sheffer [mailto:[email-masked]]
Sent: Friday, February 19, 2016 11:20 AM
To: Daniel Migault; LURK BoF
Subject: Re: [Lurk] FW: New Version Notification for draft-mglt-lurk-tls-abstract-api-00.txt

Hi Daniel,

  *   Many of the authentication methods you mention are deprecated, rarely used, or rarely used for the relevant use case. Examples include dh_anon, anything with dss, and anything with psk. I would suggest to concentrate on the very few that are in actual use with CDNs. This would enable us to simplify the (future) protocol and its implementations.
MGLT: Agree. I think we should limit ourselves to a limited number of authentication methods. I would like to propose to restrict ourselves to focus on DHE / ECDHE authentications.
MGLT: Similarly, I also think we could also restrict the scope to TLS/DTLS 1.2 and 1.3.

  *   The only exception to the above is *_ecdsa which is still rare, but expected to grow.
MGLT: hopefully ;-)

  *   At a higher level, I'm not clear about the value of an abstract API. Once we settle on use cases, I suppose we will want to create a concrete protocol between the Edge Server and Content Provider. This would solve the problem in an interoperable way. Why would we want an abstract API in addition to the protocol? That is, unless you look at the abstract API as a sort of high-level design for the protocol.
MGLT: I see the abstract API as a high level view of the protocol. The reason for writing an abstract API was to describe the interactions needed between the Edge Server and the Content Provider, with the expected input / outputs, no matter on whether JSON or CBOR or whatever format is used for these parameters or which transport protocol is used.

  *   Sec. 4.3.1 demonstrates issues that are typically not discussed with abstract APIs but are important here. Specifically, resistance to timing attacks.
MGLT: OK then, maybe it is not an abstract API.

  *   Typo: RFC 2546.

Best,

    Yaron

Hi,

BR,

Daniel

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

To: Daniel Migault

Revision: 00

Pages:           14

Abstract:

The IETF Secretariat

Lurk mailing list

[email-masked]<mailto:[email-masked]>

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 19 Feb 2016 22:28:44 +0200

Similarly to what Andrei said, we (unfortunately) cannot exclude TLS 1.0 
at the moment. See https://www.trustworthyinternet.org/ssl-pulse/. 
Though I don't think that should have any real implications on the protocol.

Thanks,
     Yaron

On 02/19/2016 09:34 PM, Daniel Migault wrote:
> *From:*Yaron Sheffer [mailto:[email-masked]]
> *Sent:* Friday, February 19, 2016 11:20 AM
> *To:* Daniel Migault; LURK BoF
> *Subject:* Re: [Lurk] FW: New Version Notification for 
> draft-mglt-lurk-tls-abstract-api-00.txt
>
> Hi Daniel,
>
>     CDNs. This would enable us to simplify the (future) protocol and
>     its implementations.
>
> MGLT: Agree. I think we should limit ourselves to a limited number of 
> authentication methods. I would like to propose to restrict ourselves 
> to focus on DHE / ECDHE authentications.
>
>   * At a higher level, I'm not clear about the value of an abstract
>     API. Once we settle on use cases, I suppose we will want to create
>     a concrete protocol between the Edge Server and Content Provider.
>     This would solve the problem in an interoperable way. Why would we
>     want an abstract API in addition to the protocol? That is, unless
>     you look at the abstract API as a sort of high-level design for
>     the protocol.
>
> MGLT: I see the abstract API as a high level view of the protocol. The 
> reason for writing an abstract API was to describe the interactions 
> needed between the Edge Server and the Content Provider, with the 
> expected input / outputs, no matter on whether JSON or CBOR or 
> whatever format is used for these parameters or which transport 
> protocol is used.
>
>   * Sec. 4.3.1 demonstrates issues that are typically not discussed
>     with abstract APIs but are important here. Specifically,
>     resistance to timing attacks.
>
>     From:[email-masked] <mailto:[email-masked]>  [mailto:[email-masked]]
>
>     URL:https://www.ietf.org/internet-drafts/draft-mglt-lurk-tls-abstract-api-00.txt
>
>     Status:https://datatracker.ietf.org/doc/draft-mglt-lurk-tls-abstract-api/
>
>     Htmlized:https://tools.ietf.org/html/draft-mglt-lurk-tls-abstract-api-00
>
>     Abstract:
>
>     [email-masked] <mailto:[email-masked]>
>