Ingest Security

[KevinCJohns]

I would like to propose we add a section that discusses Ingest security, including Authentication. It is important that we define how Encoders can both securely delivery content and authenticate themselves with each PUT/POST request.

I would propose we start with supporting HTTPS with a modern security profile w/SNI support. Authentication could be done via basic auth (yea I know its bad but HTTP does not offer much beyond basic and digest and no one gets digest right...). Basic auth shouldn't be allowed without HTTPS.

If folks agree I can draft up some text.

I agree however I would also suggest that TLS client certificates also be suggested as a means of authentication, as they are more robust than HTTP basic authentication.

We agree on HTTPS + Basic auth or alternatively TLS client certificates, I will incorporate this in the next version of the next draft then you can check if this reflects your view. Note the details of how the encryption is handled will be pretty much outside the scope of the spec, but yes HTTPS usage should be emphasized and authentication aswell with basic auth as a minimum and TLS client Certificates as another option. Could you please check the current revision if it fits your requirement, thanks

Let me know if you agree with the change and if this issue can be closed, thanks

[KevinCJohns]

The revised text is confusing. I would propose we create a section on Ingest Security and gather the requirements there. The section would read along the following lines (this is a strawman and is expected to be revised/refined once we have a section in place to edit):

Authentication

In order to provide some level of protection and track who is connecting to a given publication point, the Live Encoder and Media Processing Entity MUST support the use of HTTP Basic Authentication over HTTPS. Optionally the Live Encoder and Media Processing Entity MAY support the use of TLS Mutual Authentication.

When Basic Ingest Authentication is Enabled, the Live Encoder MUST include the Username/Password in each request. If Basic Ingest Authentication is Enabled and the Media Processing Entity receives a request without the HTTP Authorization header, it MUST respond to the request with a 401 and include the WWW-Authenticate header. If Basic Ingest Authentication is Enabled and the Media Processing Entity receives a request with an invalid Username and/or Password, it MUST respond to the request with a 403.

Transport Security

If Ingest Security is desired, HTTPS MUST be used. For best performance, modern profiles should be used. At a minimum the Live Encoder and Media Processing Entity MUST support TLS1.1 or greater, Elliptic-curve Diffie–Hellman (ECDH), and AESGCM.

The Live Encoder and Media Processing Entity MUST support TLS1.3 when reasonable (e.g., 6-months after the RFC is issued).

To reduce the overhead associated with negotiating session keys, HTTP 1.1 with keepalives MUST be used.

To facility reconnecting, the Live Encoder and Media Processing Entity SHOULD support the use of session resumption.

Both the Live Encoder and Media Processing Entities MUST support the Server Name Indication TLS extension along with ALPN (for HTTP/2 Support).

I'm unsure why you're stating TLS 1.1 - I would suggest that TLS 1.2 at minimum be used, it's the most robust version presently and has quite good support amongst existing user agents. I think the "...MUST support TLS 1.3" is better off being "SHOULD", or be dropped entirely under the assumption TLS 1.3 RFC be published before this specification is.

As for cipher modes, this language should be adjusted to perhaps indicate either exactly which are either SHOULD or SHOULD NOT be used, the reader may not understand the cipher mode "hierarchy". I would vote the following be SHOULD:

• Use ECDHE
• Either RSA or ECDSA
• CHACHA20 or AES128 at minimum, larger key sizes preferred
• POLY1305 or SHA256 at minimum, larger digests preferred

This clearly defines all current best practice cipher modes, as most TLS libraries represent them:

• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES128-SHA256
• ECDHE-RSA-AES128-SHA256
• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA384
• ECDHE-ECDSA-CHACHA20-POLY1305
• ECDHE-RSA-CHACHA20-POLY1305

SNI/ALPN could be better written as:
Both the Live Encoder and Media Processing Entities MUST support the TLS Server Name Indication extension, and MUST support Application-Layer Protocol Negotiation when using HTTP/2.

[KevinCJohns]

Am ok with the proposed edits but would prefer we clearly specify use of GCM as modern processors are highly optimized to handle this encryption method vs. CBC. I don't have much data on the efficiency of Poly Chipher and understand it to be used more in the mobile domain so not sure how applicable it would be here.

GCM is not available on all hardware, and the above recommended ciphers are not mine - they are considered a set recommended by Mozilla.

Probably the most straightfoward answer I can provide over Poly performance is a blog post by CloudFlare:

ChaCha20-Poly1305 allows for highly efficient implementation using SIMD instructions. Most of our servers are based on Intel CPUs with 256-bit SIMD extensions called AVX2. We utilize those to get the maximal performance.
...
AES-128-GCM and AES-256-GCM both still beat ChaCha20-Poly1305 in pure performance for records larger than 320 bytes, but getting below 2 cycles/byte is a major performance achievement. Not many modes can beat this performance. It is also important to note that AES-GCM uses two dedicated CPU instructions (AESENC and CLMULQDQ), whereas both ChaCha and Poly only use the generic SIMD instructions.

Keep in mind that we are running implementations with lots of CPU power (encoder), there should not be much special requirements with regard to the use of encryption here compared to other protocols, I feel being to restrictive is not good. Otherwise a reference to a best practice of related protocols or browsers could help and be referenced. The main topic of this specification is the media stream content and the usage of the POST to transmit this, for encryption a best practice should be followed, preferably a reference to a solid source, for example commonly HTTPS implementation used in browsers. Also we don't want this spec to date quickly. I think as Kevin is ok with tiger toes proposal i think we can settle with this text for now, reference would be good though to have

[KevinCJohns]

As for references, the Mozilla server side TLS recommendations for Intermediate compatibility is a good reference (https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28default.29).

Thank you for the reference I added it to the spec and a line with a recommendation to use this profile