Re: [Teas-ns-dt] Security, and especially encryption.

[Jeff Tantsura <[e-mail]>]

Eric,

Users are not just asking “random stuff”, end2end encryption is a basic feature of a SSLA (secure SLA).
This is not about user observability (user can’t observe disjoined paths or similar features either) but a capability of expressing particular logic in an NBI and ability of the provider to deliver it, there’s also no “confidence factor” it is binary, the service is either provided or it is not.
The service (TS in our case) as defined by a provider and as consumed by a consumer is a combination (logical AND) of a set of features, all of which has to be true is order for the service fulfillment to be successful.

Provider “doesn’t just want” to provide encryption as a service (it costs in OPEX and CAPEX) it is a value add service that could be delivered to a consumer as a distinct advantage ( in a competitive market) or against additional payment.

Note - end2end encryption for compliance reasons (e.g PCI, HIPAA, similar) if required is not optional

Cheers,
Jeff
On May 14, 2020, 10:42 AM -0700, Eric Gray <[e-mail]>, wrote:
> Jeff,
>
> I agree that a user may ask (or, if they are big enough, insist) that a provider encrypts their data.
>
> However, as I said during the meeting, either a user encrypts their own data, or they have no way to determine that it is not encrypted – other than through some failure scenario where their data appears (in unencrypted form, or “plain text”) somewhere where it should not have.
>
> If we allow that “detection” of non-performance on some service objective may occur in any failure scenario, then we cannot immediately distinguish the case where the provider intended to meet the criteria and the mechanism used (e.g. – encryption) failed, from a case where the provider did not take any steps to meet the criteria (again, encryption of the data) and this was only discoverable as a result of some other uncommon failure (e.g. - the unencrypted data was intercepted by some third party, or was stored in unencrypted format in some location which was subsequently accessed by an unauthorized entity).
>
> If the data is “leaked” in unencrypted form in some extremely uncommon cases, it is not actually possible to determine if that was because it was never encrypted, or if it was only exceptionally unencrypted.
>
> In this sense, a user requesting encryption is essentially saying “if the service can do so, I would like my data encrypted.”  That is, while I agree that we may want to include this as a parameter in the NBI (I suggest that is a bad idea), it would be unenforceable (except via legal recourse, and auditing).
>
> And it is not actually the best way to represent what the customer really wants.
>
> It is far more useful for the consumer to indicate their preference that their data is protected (in some way), with some degree of confidence (up to and including 100%) from exposure to unauthorized parties.
>
> As a separate, out of scope in this work, issue – legal documents (e.g. – an SLA) may explicitly stipulate remedies and recourses.  IETF does not specify these
>
> Many providers may find it simply easier to allow customers to request their data is encrypted – especially if their network equipment includes the capability at a relatively low cost (e.g. – no perceptible impact on traffic handling).  But that does not mean this is the only (or even necessarily the best) way to provide the data protection that a user requested.
>
> Encryption, by the way, does not (by itself) ensure that a customer’s data is completely protected (which is another reason for the customers to ask for what they really want), because – if the provider is doing the encryption and decryption themselves, there are two (or more) points at which the data exists in the provider’s network equipment in an unencrypted form.
>
> Note that – if a provider really wants to use encryption to meet the data protection requirement – there is actually no reason why a “higher layer” controller cannot translate a request for data protection at some (possibly variable) level of confidence into an explicit request to an NBI.
>
> Another reason to list this as distinct “protection” and “confidence” factors (as opposed to a simple “encrypt my data” factor) is that additional degrees of confidence are achievable.  For instance, a provider  might choose to deploy a more expensive device on a customer’s premises that does whatever it is that the provider chooses to use for protecting the customer’s data (e.g. – encryption) using a platform that is explicitly hardened against unauthorized access and/or hacking (possibly using more sophisticated algorithms).
>
> As it is, the current “Security” objective conflates multiple security aspects – of which data protection is but one.
>
> --
> Eric