ADK's
Jacob Bachmeyer
jcb62281 at gmail.com
Tue May 2 04:43:57 CEST 2023
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
More information about the Gnupg-users
mailing list