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

[Brandon Long <[e-mail]>]

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

On Mon, Mar 23, 2020 at 5:54 AM Eric Rescorla <[e-mail]> wrote:

> 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 <[e-mail]>
> wrote:
>
>> 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
>>
>>
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>