Subject: [dispatch] draft-storey-smtp-client-id-08.txt - privacy considerations

From: Harald Alvestrand <[email-masked]>
Date: Mon, 23 Mar 2020 12:50:25 +0100

I've scanned this draft:

draft-storey-smtp-client-id-08.txt

9.  Security Considerations

    As this extension provides an additional means of communicating
    information from a client to a server it is clear there is additional
    information divulged to the server.  This may have privacy
    considerations depending on the client identity type or its contents.
    For example, it may reveal a MAC address of the device used to
    communicate with a server that would not previously have been
    revealed.  While it has been useful to use identifier such as email
    address for authentication it is easy for these authetication tokens
    to be shared and/or reused and/or be publically available for other
    purposes.  An SMTP server and or its operators SHOULD not share
    any CLIENTID information presented with a third party as it may
    represent or be linked to an individual and SHOULD never be shared in
    association with authentication tokens.

Together with this section:

    Some examples of identity type might be UUID, LICENSE,
    DEVICE_ID, MAC and/or COOKIE.  It is expected that the most common
    types might be related to distinct UUID, LICENSEKEY, or HARDWAREID.

    2. LICENSE

       An SMTP client may find it useful to identify the license key of
       software it is using.  Such licenses are typically crafted such
       that they are unique and useful to identify a software
       installation.  This is more normally suited for a software
       designed for a single-user.  While LICENSE could be standard type
       again, it might more more helpful to specify a vendor specific
       type such as BBLICENSEKEY.

    3. DEVICE_ID

       Many hardware devices are designed to be used by a single
       individual and already have an associated hardware device id.
       While a standard type might be defined, it also might be more
       helpful to use a vendor specific type, such as ATOM-DEVICEID.

    4. MAC

       The MAC address traditionally was used as a worldwide identifier
       both of the unique device, as well as it's vendor and product
       category, however this is not always the case anymore, in the case
       of it's usage in 'virtual' devices.  But for many hardware devices
       which are required to access a defined SMTP resource, the MAC
       address may still be a simple unique identifier.  MAC should NOT
       be used, unless this is a MAC address that can be associated to a
       vendor using standard MAC registration information as defined or
       set by the IEEE Standards Association and is meant to represent a
       unique device.

I will note that all these categories reveal privacy sensitive information.

My preference would be that the draft take a strong stance that the 
CLIENTID MUST NOT reveal information that can be cross-correlated with 
any other persionally identifiable information (we have the authorized 
identity for that, thank you very much); if suggestions are to remain in 
the draft that indicate that CLIENTID may be used to reveal personally 
sensitive information, the Security Considerations need to spell this 
out, and describe what mechanisms (such as client verifying the 
certificate of the server in STARTTLS and using CLIENTID only with 
servers with which one has a preexisting trust relationshiop) are used 
to safeguard such information against harvesting.

(I remain doubtful about the usefulness of the extension. This critique 
is not to be perceived as any form of endorsement of the rest of the 
document.)

Harald

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Mar 2020 05:53:22 -0700

I have also skimmed the draft and have a different security concern.

In this context, the CLIENT_ID appears to be a bearer token which can, if
recovered, be replayable transplanted onto a new  connection. We have quite
a bit of experience with this kind of token in HTTP (cookies) and it's bad.
Why isn't the CLIENT_ID cryptographically bound to the connection? Of
course, this will only be effective if the ID is high entropy, but that
should be the case as well.

-Ekr

On Mon, Mar 23, 2020 at 4:50 AM Harald Alvestrand <[email-masked]>
wrote:

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "John Levine" <[email-masked]>
Date: 23 Mar 2020 11:22:09 -0400

>should be the case as well.

I can't tell whether this draft is supposed to be like OAUTH or TOTP
or something else.

POP and IMAP can certainly use something better than passwords but this strikes
me as a not terribly round reinvented wheel.

R's,
John

---

From: Brandon Long <[email-masked]>
Date: Mon, 23 Mar 2020 13:42:46 -0700

A random clientid generated by the client and only sent to the server with
login information over an encrypted connection doesn't seem quite the same.

Currently, login credentials are often reused and can be stolen in that
way, so the risk of clientid theft is different.  It does not benefit if
the mechanism of theft is MITM or the client device itself is compromised.

Risk evaluation at login should not ignore the possibility of clientid
compromise.

Short of a cryptographic exchange involving ondevice secure elements, I'm
not sure what level of binding you think would work.. but I fully admit to
not knowing much about it.

Brandon