[Cfrg] MAC tags with unauthenticated keys provide a service called what? [was [saag] better ** terminology]

[Dan Brown <[e-mail]>]

Dear CFRG list,

Being a terminology question, this is more of a mole hill than a mountain.  Anyway, for those mountain climbers still interested in this stuff, here is a little mountain on the matter.

Stephen Kent wrote a nice I-D on pervasive encryption, which is being discussed on the SAAG list.  One of the proposals concerns using encryption despite encryption keys being unauthenticated.   One of the issues discussed in the I-D is terminology regarding this practice, both in terms of encryption and in terms of authentication.  The I-D already alludes to authentication in case of the store-and-forward context, citing the "murky" distinction between integrity and authentication.  To me, the authentication terminology issue also seems in other contexts, including TLS and SSH.  So, I think that this raises a more general terminology issue: what to call symmetric message authentication with unauthenticated shared keys?  I wouldn't want terminology debates to distract from any proposed actions, but terminology can sometimes help avoid mistakes.

Of course, this would also apply to the "authenticated" term in authenticated encryption modes (e.g. CCM, GCM, OCB), or not just to the A in MAC.

In case cryptographers have already satisfactorily resolved this minor terminology issue, I've brought the discussion to CFRG.

Most of the current terminology reduce the term authentication (e.g. the A in MAC) with something weaker when the MAC keys is unauthenticated.  So, it is not at all a problem of understanding for experts, as far as I can tell.  Nevertheless, a consistent terminology might be helpful for expository reasons, as comparison between comparable protocols.  Some examples:

1. Client-anonymous TLS has a client applying a MAC.  So, the protocol does the terminology downgrade, by using the term "anonymous".  I'm not sure if TLS says anywhere the term "anonymous authentication".

2. The encryption schemes DHIES or ECIES approach: use a MAC, but then call the result "integrated".

3. Shoup, in ISO 18033-2, introduced DEM, where encapsulation replaces authentication, at an even lower level than TLS or ECIES: symmetric key.

4. In a reversal Shoup's terminology DEM, the essentially equivalent class of symmetric authenticated encryption, added back the term "authentication" even though it is well-known (e.g. TLS) that shared symmetric keys are sometimes unauthenticated.

5. S/MIME's AuthenticatedData has not really downgraded the term, but maybe idea the shared keys here are required to be authenticated?

6. TOFU and LoF refers to the practice of just trusting a key, but perhaps that seems to something deeper than just terminology.

7. Some key agreement and certificate schemes use the term implicit (key) authentication, but that refers to something quite different, that authentication is pending some proof-of-knowledge, and usually an identity is included with an assurance that only the identified could possibly know the shared secret (but accepting the possibility that nobody (or at least just an authority) knows the shared secret).

8. In the MAC layer, crypto MACs get called MIC.  This is lowest level primitive of my examples, in which the term "authentication" is avoided. Unfortunately, this may fail to convey the idea that a MIC can provide authentication if the shared symmetric keys are authenticated.

9. MACs and authenticated encryption modes clearly assume authenticated keys, but also provide some value of the keys are unauthenticated.  One argument for using the term "authentication" is that is relative to whoever knows the shared keys.  But that conflicts with the term "unauthenticated" when applies to the keys.

10. In public-key encryption, the relevant security properties (that something a MAC built-in the scheme provides), are called non-malleability or chosen-ciphertext security.

Ten or more may be too many approaches for nearly the same thing.  Of course, it's hard to break with precedents.

I wonder if the heart of the problem is the lack of separation between the tool and the task.  Encryption provides confidentiality (or some might say privacy).  Authentication provides authentication.  If signatures provide authentication, then it perhaps it is the just tool that need renaming.  We already have MAC tag, so maybe tag as a verb would do.  So, tagging provides authentication, provide the tag keys are authenticated.  (Maybe mark instead of tag would be nice too, because of its similarity to MAC, but that requires breaking new terminological ground.)

The term tagging does not completely resolve what service tagging with unauthenticated keys provides, but the separation of terms may still be enough to avoid a novice's potential mistake of thinking that a MAC always provides authentication.  It does unable us to talk about anonymous tagging, unauthenticated tagging, and so on.  I'd suggest one of the existing terms for this service provided, either integrity or non-malleability.

Best regards,

Dan

> -----Original Message-----
> From: saag [mailto:[e-mail]] On Behalf Of Stephen Kent
> Sent: Tuesday, March 18, 2014 6:05 PM
> To: saag
> Subject: [saag] better ** terminology
>
> I have just posted an I-D that does a few things:
>
>      - it proposes yet another term for the subject of our protracted terminology
> discussion
>      - it defines what that term means, based on a STRINT workshop breakout
> group
>      - it argues why "opportunistic encryption" is a poor terminology choice
>        for what we want to describe
>      - it examines some other aspects of terminology for key management
>        that yields authenticated, anonymous, or pseudonymous communications
>
> I extracted this text form a bigger document, and made changes based on the
> debate that has been taking place on SAAG, replacing my preferred
> "opportunistic keying"
> with a term that seems tailor made to the problem we're addressing :-).
>
> https://datatracker.ietf.org/doc/draft-kent-pervasive-encryption/
>
> Steve
>
>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag