ADK's

[Jacob Bachmeyer]

Michael Richardson wrote:
> Jacob Bachmeyer <jcb62281 at gmail.com> wrote:
>     >> I'm unclear if this is a new feature (I think so), and if so what happens if
>     >> the sender hasn't upgraded yet?
>     >>
>
>     > My understanding:  ADKs are new and do not work without support on the
>     > sender's side.  The ADK is a request to also encrypt any message to the
>     > subkey to the ADK.  If the sender's software does not understand that
>     > request, it does not happen.  If the sender rejects that request, either
>     > by setting an option or by patching their software to ignore the request, it
>     > does not happen.
>
> Does it still (by default) encrypt to the main key?
>   

My understanding:  Yes, if ADKs are not supported, the message is 
encrypted only for the main key.

> [...]
>
>     >> > I would also note that, for a work email system in an environment where there
>     >> > is a legal or quasi-legal requirement (not uncommon in finance) to archive
>     >> > messages, simply dropping any incoming message not decryptable with the
>     >> > archive ADK as spam would be reasonable.  Since the primary concern
>     >> > motivating message archival in this example is deterring insider trading,
>     >> > simply not allowing unreadable messages to be delivered accomplishes the same
>     >> > objective.
>     >>
>     >> Yes, reasonable.
>     >> OTH, the emails investigating the insider trading by the HR people might need
>     >> to avoid the ADK.
>
>     > If we are talking about investigating HR malfeasance, those messages would
>     > not be going to the traders' regular inboxes in the first place.  You are
>     > right that an HR ADK could be a very bad idea in this example, since it could
>     > allow HR to front-run their own employer.  The expected solution would be to
>     > give the trading archives only to the audit or legal departments, and only
>     > after some period of time has passed.  That still leaves potential auditor or
>     > lawyer malfeasance, but that is an existing risk such businesses already
>     > handle.
>
> It's the initial investigation of an irregularity where there could be a problem.
> There is also an issue with 2FA and password reset emails: it's something
> that may be a vulnerability to archive.  Okay, few are encrypted today, but
> we can hope.   Many companies with forced proxis are starting to realize that
> they become liable when they store banking login cookies.
>   

Really, the banks should be recognizing those networks and denying 
logins.  Perhaps corporate forced proxies should be required to insert 
an additional header reporting that the connection is not actually 
point-to-point encrypted, which banks and other sensitive services could 
use to reject sessions.

The main problem here seems to be a work-life balance issue.  People 
should not be conducting personal business on the company network, and, 
in turn, companies need to understand that personal time outside of work 
is /personal/ /time/ /outside/ /of/ /work/.  I am not sure in which 
direction this first broke down, but it is the root cause of a wide 
variety of problems.

> Anyway, I think senders need to be made mildly aware that it's occuring, and
> I think they should be allowed to pick a specific ADK or suppress them all in
> certain circumstances best decided by them.
>   

I believe that is substantially what I proposed, so at least two of us 
agree.


-- Jacob