Need for secured email delegation workflow

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Need for secured email delegation workflow

vaibhav singh
Hi,

First of all, I am kind of new and still learning how email infrastructure fits in, so please feel free to highlight any glaring issues with my logic.

I was working on implementing Email Delegation for my email server, and felt a need to highlight a couple of things.

1.) I could not find a place where this workflow is outlined. It seems like everyone, from Microsoft to Google, have an implementation for email delegation, and they are all kind of doing their own thing.

2.) As I could not find any RFC/Internet Draft covering this flow, I could, potentially, create a really bad email delegation implementation in which I could allow potentially anyone to send mails on behalf of anyone, and I will still be, say, RFC-2822 compatible (I may be incorrect here, but I could not really find any place which would restrict a user from sending an email on someone's behalf, by editing the "Sender" header before sending an IMAP request.)

Am I missing something here? Is this something which should be an Internet draft/RFC?

--

Regards,
Vaibhav Singh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

John Levine
In article <[hidden email]> you write:
>I was working on implementing Email Delegation for my email server, and
>felt a need to highlight a couple of things.

Email Delegation is not as far as I can tell a phrase that has ever
appeared in an RFC, and I have no idea what it means.

Can you tell us what you're trying to do?

R's,
John

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

Dave Crocker-2
In reply to this post by vaibhav singh
On 7/12/2017 12:03 AM, vaibhav singh wrote:
> 1.) I could not find a place where this workflow is outlined.


It's possible that Internet Mail Architecture (RFC 5598) will assist
your efforts, including use of common vocabulary.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

Viktor Dukhovni-2
In reply to this post by vaibhav singh

> On Jul 12, 2017, at 3:03 AM, vaibhav singh <[hidden email]> wrote:
>
> I was working on implementing Email Delegation for my email server, and felt a need to highlight a couple of things.
>
> 1.) I could not find a place where this workflow is outlined. It seems like everyone, from Microsoft to Google, have an implementation for email delegation, and they are all kind of doing their own thing.

I suspect this topic is not really appropriate for this list, so I'll keep this brief.

> Am I missing something here? Is this something which should be an Internet draft/RFC?

It seems you want to authorize a third party to send email on your behalf.
It is not clear that logistical guidance of how to do is proper subject
matter for an RFC.  The relevant technical standards are:

        * DKIM, allows you to delegate a keypair and a "selector" for a third
          party to send authenticated email with "d=<yourdomain.example>"

        * SPF, allows you designate a set of SMTP clients that are authorized
          to originate email with envelope sender addresses in your mail.

        * SMTP generally allows any client to send from any domain.  Any
          constraints that block third parties from sending on behalf of
          of your domain are "self inflicted" (restrictive SPF, abominable
          DMARC).  To the extent that you employ these, they provide the
          means to exempt third parties from your own restrictive policies.

Any process that the third party wants you to follow in order to register
with them to send on your behalf is I think outside the scope of IETF
standards.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

Andrew Sullivan-9
On Wed, Jul 12, 2017 at 12:56:56PM -0400, Viktor Dukhovni wrote:
> It seems you want to authorize a third party to send email on your behalf.
> It is not clear that logistical guidance of how to do is proper subject
> matter for an RFC.

Why?  We have a whole area dedicated to Management and Operations,
including one named DNSOP.

> Any process that the third party wants you to follow in order to register
> with them to send on your behalf is I think outside the scope of IETF
> standards.

The more general thing is that there is no way for a domain operator
to signal to a possible vendor its authority to allow said vendor to
operate $thing on the domain operator's behalf.  It would have been
nice if the protocol we stumbled into creating that was well-suited to
this (RDAP) didn't have a bootstrapping mechanism that was nailed to
the historical facts about whois, but some of us lost that fight in
the WG.  The way this is mostly done today is to put a bunch of TXT
records at the apex of the zone in question, thereby permanently
bloating DNS answers for large numbers of domains for no good reason
(and offering a useful amplification mechanism in passing).

I can think of more than one existing IETF standard that might be good
for this, but I can't think of one that solves the use case today.  It
might be a useful thing for some of us to discuss in the halls in
Prague.  If anyone is interested in having that conversation, please
contact me off-list.  I hear there is beer in Prague.  Maybe we can
arrange for various birds to get together in a bar rather than a hall.

A

--
Andrew Sullivan
[hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

Michael Richardson-11
In reply to this post by vaibhav singh

vaibhav singh <[hidden email]> wrote:
    > First of all, I am kind of new and still learning how email
    > infrastructure fits in, so please feel free to highlight any glaring
    > issues with my logic.

    > I was working on implementing Email Delegation for my email server, and
    > felt a need to highlight a couple of things.

    > 1.) I could not find a place where this workflow is outlined. It seems
    > like everyone, from Microsoft to Google, have an implementation for
    > email delegation, and they are all kind of doing their own thing.

I think that when you say "email delegation", you mean where a manager
(or other person) authorizes their "PA" (personal assistant, formerly known
as "secretary") to send email on their behalf.  Back in the days of BNR COCOS
it was very common thing for middle management, but even in those dark days
of mainframe based email, it was usually accomplished by having the PA log in
with the manager's email.

It's good that microsoft(outlook) and google(gmail) have realized that
sharing passwords is a dumb thing.  I think that in the walled gardens of
those systems, that the email delegation is accomplished entirely within
their MUA/MTA.

    > 2.) As I could not find any RFC/Internet Draft covering this flow, I
    > could, potentially, create a really bad email delegation implementation
    > in which I could allow potentially anyone to send mails on behalf of
    > anyone, and I will still be, say, RFC-2822 compatible (I may be

RFC2822 (and 822 before it, and the one for that) always let anyone send any
email claiming to be from anyway.  That was both a strength ("permissionless
innovation"), and led to our spam disaster.  So as others in this thread
have mentioned, we have SPF to give clues as to which IP addresses are
authorized to speak authoritative for a domain, and DKIM to make sure that
the headers are authentic (and optionally body). Neither provides for content
signing that is reachable by end users at this time.
I don't think you are looking for SPF or DKIM, unless you are trying
to seperate the PA and the manager into different (submission) mail systems.

All of this is MTA to MTA protocol, not MUA to MTA.

    > incorrect here, but I could not really find any place which would
    > restrict a user from sending an email on someone's behalf, by editing
    > the "Sender" header before sending an IMAP request.)

Since you speak about IMAP, you are clearly not in the MTA business, but
I suspect in the MUA side of things.  Maybe I'm wrong and you are building
IMAP servers.  I didn't think that IMAP included email submission, but I'm
sure I'm not up to speed... (30 years since I wrote that MTA for AmigaOS...)
So let me speak about email submission protocol (rfc4409) and you can
substitute IMAP if that is in fact appropriate.

It seems to me that a mail server that has an authorized user SHOULD force
the SMTP From (aka "Sender") to the authorized user.  Perhaps it MAY also
force the body From: to a specific value, but I haven't encountered an
open source one that does.  It seems that you are asking how a MUA could
indicate (and provide proof) that it is authorized to set the From:
order Sender: to another value.  (I really think, btw, you want to set
the From: to the manager, and leave the Sender: as the PA)

This seems like it might be the space for a SAML assertion.
I believe that many IMAP servers use small subsets of SAML to provide mailbox
ACLs, and it would fit right in there.  I suspect that there is space for
an RFC about how to do this in a standard way.

--
Michael Richardson <[hidden email]>, Sandelman Software Works
 -= IPv6 IoT consulting =-




signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

vaibhav singh
In reply to this post by John Levine
Hi John,

First of all, sorry for not defining things properly. I will be adding this glossary to all Email Delegation threads:

Definition: Email Delegation will be the workflow in which a user is able to send emails on behalf of another user. A general example will be a secretary replying back to emails which his/her boss received.

Couple of terms:

manager
= The user who wants to delegate some other user to manage his account on his behalf.

delegate = The user who has to get access to the manager's account.

Please note that email delegation could also cover cases like creating folders, deleting folders etc in the manager's account.


So, I was working on a similar workflow and looking around to see how others have implemented this workflow, and felt that a proper document describing this workflow would really help, as the Email Delegation behavior did not seem consistent and sometimes, not secure.


On Wed, Jul 12, 2017 at 9:59 PM, John Levine <[hidden email]> wrote:
In article <[hidden email]> you write:
>I was working on implementing Email Delegation for my email server, and
>felt a need to highlight a couple of things.

Email Delegation is not as far as I can tell a phrase that has ever
appeared in an RFC, and I have no idea what it means.

Can you tell us what you're trying to do?

R's,
John



--

Regards,
Vaibhav Singh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

John Levine
> Definition: Email Delegation will be the workflow in which a user is able
> to send emails on behalf of another user. A general example will be a
> secretary replying back to emails which his/her boss received.

Oh, OK.  This is rather outside the scope of IETF standards.  Historically
(like more than a decade ago) mail programs let anyone put any address on
the From: line.  These days we have some designs like SPF and DMARC that
limit sending mail as other domains (e.g., as [hidden email] if
your regular address is [hidden email]) but we've never said anything
about how a system decides who's allowed to send mail from various
addresses in the same domain.

We do have standards for logging into mail systems both to send and to
pick up mail.  A widely used convention (not a standard) is that you can
send mail with an address on the From: line if you have the credentials to
pick up mail sent to that address.  If that's your local convention, we do
have designs like oauth which allow access delegation.  That might be a
useful place to look.

Regards,
John Levine, [hidden email], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

vaibhav singh
In reply to this post by Michael Richardson-11


On Thu, Jul 13, 2017 at 12:42 AM, Michael Richardson <[hidden email]> wrote:

vaibhav singh <[hidden email]> wrote:
    > First of all, I am kind of new and still learning how email
    > infrastructure fits in, so please feel free to highlight any glaring
    > issues with my logic.

    > I was working on implementing Email Delegation for my email server, and
    > felt a need to highlight a couple of things.

    > 1.) I could not find a place where this workflow is outlined. It seems
    > like everyone, from Microsoft to Google, have an implementation for
    > email delegation, and they are all kind of doing their own thing.

I think that when you say "email delegation", you mean where a manager
(or other person) authorizes their "PA" (personal assistant, formerly known
as "secretary") to send email on their behalf.  Back in the days of BNR COCOS
it was very common thing for middle management, but even in those dark days
of mainframe based email, it was usually accomplished by having the PA log in
with the manager's email.

It's good that microsoft(outlook) and google(gmail) have realized that
sharing passwords is a dumb thing.  I think that in the walled gardens of
those systems, that the email delegation is accomplished entirely within
their MUA/MTA.

Exactly!! That is the workflow I am talking about. However, I feel that this could be something which could be used for other things as well, for example, in the place where I work, we have some automated tools where a user can input certain data and the tool will send mails to our group email address on behalf of the user.

Couple of terms:

manager
= The user who wants to delegate some other user to manage his account on his behalf.

delegate = The user who has to get access to the manager's account. 

entity = Any email user.

Please note that email delegation could also cover cases like creating folders, deleting folders etc in the manager's account.


This concept, in my opinion, could be generalized to include "entities" which could request permission to send mails on behalf of some other "entity". Sort of like OAUTH with emails, if you will. I am still hazy with all the details and not sure about how useful this could be, but it seems promising to me.

Another question which I was not clear about was how S/MIME would be integrated with delegation. For example, suppose the delegate were to create a signed email on behalf of the manager, in which case the manager would have to share his private key with the delegate. This would definitely not be secure.


    > 2.) As I could not find any RFC/Internet Draft covering this flow, I
    > could, potentially, create a really bad email delegation implementation
    > in which I could allow potentially anyone to send mails on behalf of
    > anyone, and I will still be, say, RFC-2822 compatible (I may be

RFC2822 (and 822 before it, and the one for that) always let anyone send any
email claiming to be from anyway.  That was both a strength ("permissionless
innovation"), and led to our spam disaster.  So as others in this thread
have mentioned, we have SPF to give clues as to which IP addresses are
authorized to speak authoritative for a domain, and DKIM to make sure that
the headers are authentic (and optionally body). Neither provides for content
signing that is reachable by end users at this time.
I don't think you are looking for SPF or DKIM, unless you are trying
to seperate the PA and the manager into different (submission) mail systems.

All of this is MTA to MTA protocol, not MUA to MTA.

    > incorrect here, but I could not really find any place which would
    > restrict a user from sending an email on someone's behalf, by editing
    > the "Sender" header before sending an IMAP request.)

Since you speak about IMAP, you are clearly not in the MTA business, but
I suspect in the MUA side of things.  Maybe I'm wrong and you are building
IMAP servers.  I didn't think that IMAP included email submission, but I'm
sure I'm not up to speed... (30 years since I wrote that MTA for AmigaOS...)
So let me speak about email submission protocol (rfc4409) and you can
substitute IMAP if that is in fact appropriate.
 
It seems to me that a mail server that has an authorized user SHOULD force
the SMTP From (aka "Sender") to the authorized user.  Perhaps it MAY also
force the body From: to a specific value, but I haven't encountered an
open source one that does.  It seems that you are asking how a MUA could
indicate (and provide proof) that it is authorized to set the From:
order Sender: to another value.  (I really think, btw, you want to set
the From: to the manager, and leave the Sender: as the PA)

This seems like it might be the space for a SAML assertion.
I believe that many IMAP servers use small subsets of SAML to provide mailbox
ACLs, and it would fit right in there.  I suspect that there is space for
an RFC about how to do this in a standard way.

--
Michael Richardson <[hidden email]>, Sandelman Software Works
 -= IPv6 IoT consulting =-






--

Regards,
Vaibhav Singh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

Dave Crocker-2
In reply to this post by John Levine
On 7/13/2017 9:24 PM, John R Levine wrote:
>> Definition: Email Delegation will be the workflow in which a user is able
>> to send emails on behalf of another user. A general example will be a
>> secretary replying back to emails which his/her boss received.
>
> Oh, OK.  This is rather outside the scope of IETF standards.


Except that that scenario was exactly the reason for the rfc5322.Sender
(originally rfc733.Sender) distinction from the rfc5322.From field. See
Section 3.6.2, which still has this explained in those terms.

So it hasn't been specified with authentication protections -- and it's
not clear that we now how to provide that granularity at scale, or
rather there is pretty strong operational demonstration that we do /not/
know how -- but it has already been done as a semantic.  40 years ago,
this year, with periodic renewals...

The problem now is that the construct has mostly been moved to the 'via'
hack in the <display-name> field.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

Michael Richardson-11
In reply to this post by vaibhav singh

vaibhav singh <[hidden email]> wrote:
    > Another question which I was not clear about was how S/MIME would be
    > integrated with delegation. For example, suppose the delegate were to
    > create a signed email on behalf of the manager, in which case the
    > manager would have to share his private key with the delegate. This
    > would definitely not be secure.

It is possible to have more than one certificate issued for a given DN,
but usually we try to avoid such things.   Some variation of this is probably
the right answer.  You'll have to talk to an enterprise CA provider to
understand if they do anything.  I suspect that if you can make contact
with the microsoft certificate authority people (I don't know them), they
will know if they have solved this problem.

I'm not sure if you read this part:

    mcr> This seems like it might be the space for a SAML assertion.
    mcr> I believe that many IMAP servers use small subsets of SAML to provide
    mcr> mailbox
    mcr> ACLs, and it would fit right in there. I suspect that there is space
    mcr> for
    mcr> an RFC about how to do this in a standard way.


--
Michael Richardson <[hidden email]>, Sandelman Software Works
 -= IPv6 IoT consulting =-




signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

Yoav Nir-4
In reply to this post by vaibhav singh

On 14 Jul 2017, at 7:30, vaibhav singh <[hidden email]> wrote:



On Thu, Jul 13, 2017 at 12:42 AM, Michael Richardson <[hidden email]> wrote:

vaibhav singh <[hidden email]> wrote:
    > First of all, I am kind of new and still learning how email
    > infrastructure fits in, so please feel free to highlight any glaring
    > issues with my logic.

    > I was working on implementing Email Delegation for my email server, and
    > felt a need to highlight a couple of things.

    > 1.) I could not find a place where this workflow is outlined. It seems
    > like everyone, from Microsoft to Google, have an implementation for
    > email delegation, and they are all kind of doing their own thing.

I think that when you say "email delegation", you mean where a manager
(or other person) authorizes their "PA" (personal assistant, formerly known
as "secretary") to send email on their behalf.  Back in the days of BNR COCOS
it was very common thing for middle management, but even in those dark days
of mainframe based email, it was usually accomplished by having the PA log in
with the manager's email.

It's good that microsoft(outlook) and google(gmail) have realized that
sharing passwords is a dumb thing.  I think that in the walled gardens of
those systems, that the email delegation is accomplished entirely within
their MUA/MTA.

Exactly!! That is the workflow I am talking about. However, I feel that this could be something which could be used for other things as well, for example, in the place where I work, we have some automated tools where a user can input certain data and the tool will send mails to our group email address on behalf of the user.

Couple of terms:

manager
 = The user who wants to delegate some other user to manage his account on his behalf.

I think “principal” is a better term. I would expect “manager” to authorize b to manage on behalf of c.

delegate = The user who has to get access to the manager's account. 

entity = Any email user.

Please note that email delegation could also cover cases like creating folders, deleting folders etc in the manager's account.


This concept, in my opinion, could be generalized to include "entities" which could request permission to send mails on behalf of some other "entity". Sort of like OAUTH with emails, if you will. I am still hazy with all the details and not sure about how useful this could be, but it seems promising to me.

Another question which I was not clear about was how S/MIME would be integrated with delegation. For example, suppose the delegate were to create a signed email on behalf of the manager, in which case the manager would have to share his private key with the delegate. This would definitely not be secure.

This is part of a wider issue. Even without delegation, if I use my own email account with several MUAs (say, my laptop and my phone), where is the private key stored?  Is it shared between laptop and phone?

You end up reading encrypted mail only using one MUA, which is one more thing dragging the use of S/Mime down.

While it may be OK to share a key with my phone (but too difficult to do securely in practice), sharing with a delegate is hairy on many different layers. But still it’s the same issue.

Yoav

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

Michael Richardson-11

Yoav Nir <[hidden email]> wrote:
    > This is part of a wider issue. Even without delegation, if I use my own
    > email account with several MUAs (say, my laptop and my phone), where is
    > the private key stored? Is it shared between laptop and phone?

I think that simple delegation would be a better tool to delegate email
access from my desktop to my phone and/or laptop.  That way the server
knows it's an anciliary device, it could be revoked easier, and a more
suspicious profile could be applied by servers.   Google has tried to
do this with the "App passwords", but my understanding is that they still
not restricted to specific apps.  Just additional passwords that have
most access, but not password resetting access.

OpenPGP format permits a (public) key blog on contain many signing (sub)keys,
and so distributing a public key with a set of subkeys where the private
keys are stored into laptops and phones, etc. would work.

    > You end up reading encrypted mail only using one MUA, which is one more
    > thing dragging the use of S/Mime down.

Agreed; I'm not sure if PKIX has a subkey concept.  I suspect it's in a
standard, but I'm unclear if it was ever deployed.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [
       


signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

S Moonesamy
In reply to this post by vaibhav singh
Hi Vaibhav,
At 21:08 13-07-2017, vaibhav singh wrote:
>First of all, sorry for not defining things properly. I will be
>adding this glossary to all Email Delegation threads:
>
>Definition: Email Delegation will be the workflow in which a user is
>able to send emails on behalf of another user. A general example
>will be a secretary replying back to emails which his/her boss received.

Please see Section 3.6.2 of RFC 5322

Regards,
S. Moonesamy

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

Yoav Nir-4
In reply to this post by Michael Richardson-11

> On 15 Jul 2017, at 1:36, Michael Richardson <[hidden email]> wrote:
>
>
> Yoav Nir <[hidden email]> wrote:
>> This is part of a wider issue. Even without delegation, if I use my own
>> email account with several MUAs (say, my laptop and my phone), where is
>> the private key stored? Is it shared between laptop and phone?
>
> I think that simple delegation would be a better tool to delegate email
> access from my desktop to my phone and/or laptop.  That way the server
> knows it's an anciliary device, it could be revoked easier, and a more
> suspicious profile could be applied by servers.   Google has tried to
> do this with the "App passwords", but my understanding is that they still
> not restricted to specific apps.  Just additional passwords that have
> most access, but not password resetting access.
>
> OpenPGP format permits a (public) key blog on contain many signing (sub)keys,
> and so distributing a public key with a set of subkeys where the private
> keys are stored into laptops and phones, etc. would work.
>
>> You end up reading encrypted mail only using one MUA, which is one more
>> thing dragging the use of S/Mime down.
>
> Agreed; I'm not sure if PKIX has a subkey concept.  I suspect it's in a
> standard, but I'm unclear if it was ever deployed.
That works OK for signatures, but for encryption?  You’d have to encrypt the message with each subkey.  Yeah, I know only the symmetric key gets encrypted but it’s still ugly.

And we haven’t even mentioned the web MUA and where it stores the private keys.

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

Michael Richardson-11

Yoav Nir <[hidden email]> wrote:
    >> OpenPGP format permits a (public) key blog on contain many signing
    >> (sub)keys, and so distributing a public key with a set of subkeys
    >> where the private keys are stored into laptops and phones, etc. would
    >> work.

    >>> You end up reading encrypted mail only using one MUA, which is one
    >>> more thing dragging the use of S/Mime down.

    >> Agreed; I'm not sure if PKIX has a subkey concept.  I suspect it's in
    >> a standard, but I'm unclear if it was ever deployed.

    > That works OK for signatures, but for encryption?  You’d have to
    > encrypt the message with each subkey.  Yeah, I know only the symmetric
    > key gets encrypted but it’s still ugly.

I'm pretty sure that the spec already says to do that.

    > And we haven’t even mentioned the web MUA and where it stores the
    > private keys.

There are existing S/MIME and PGP plugins and extensions for browsers that do
this.  I'm aware of one that has received significant commercial success in
some quarters.  I think that they can use the javascript local storage for
private keys, but I suspect that they also have options to store them
encrypted elsewhere.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [



--
Michael Richardson <[hidden email]>, Sandelman Software Works
 -= IPv6 IoT consulting =-




signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

Dave Cridland
In reply to this post by Yoav Nir-4
On 14 July 2017 at 15:42, Yoav Nir <[hidden email]> wrote:
> While it may be OK to share a key with my phone (but too difficult to do
> securely in practice), sharing with a delegate is hairy on many different
> layers. But still it’s the same issue.

I think it's all solvable using Proxy Re[en]cryption, but that seems
to be a little fraught with patents at the moment.

Dave.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

vaibhav singh


On Tue, Aug 8, 2017 at 8:56 PM, Dave Cridland <[hidden email]> wrote:
On 14 July 2017 at 15:42, Yoav Nir <[hidden email]> wrote:
> While it may be OK to share a key with my phone (but too difficult to do
> securely in practice), sharing with a delegate is hairy on many different
> layers. But still it’s the same issue.

I think it's all solvable using Proxy Re[en]cryption, but that seems
to be a little fraught with patents at the moment.

I am not comfortable with sharing my private key with anyone, be it the proxy user itself. I believe that is a requirement for Proxy Reencryption, please correct me if I may have interpreted it wrongly.

The root problem:

How will S/MIME work with delegation?

For sending emails on behalf of the principal/manager:

The delegate will have access to his private key, plus all the receiver's public keys. Encryption here is trivial, encrypting the mail can be done only with the delegates' private key. On the other side, the receivers will be verifying the delegates' signature, and as the delegate is authorized to act on behalf of his manager, the receivers may not have issues trusting the delegate. The only thing that has to be ensured here is that there has to be a provision for all the receivers to know that this delegate is acting and signing mails on behalf of his manager, as in, the list of *all* delegates and managers has to be openly accessible by any user within the network.

For receiving mails on behalf of the principal/manager:

Here lies the main issue of the delegate not able to decrypt any encrypted messages coming for the Manager. Reason: The delegate will not have the manager's private key.

However, given that the list of every manager and delegate is openly available in the network, what can happen is while creating a message, the MUA could use the delegate's public key while encrypting the message, or, in case of multiple delegates for that manager, could generate a one time use key which could be used to encrypt the message, copy the key n number of times(where 'n' is the number of delegates), encrypt all new key copies with the public key of the delegates and bundle them along with the encrypted message. This is how key-encryption-key (KEK) works while sending an encrypted S/MIME message to multiple receivers; we can use the same logic with multiple delegates here.

The only issue here is that I feel the concept of public-private keys is getting diluted here; when a person is getting a signed mail, he is not getting the mail from the manager as such, he is getting the mail signed by his delegate/PA. Similar is the case when creating the mail on the other side.

The other issue is the MIME could get really big, but then again, most people would not have multiple delegates/PA.

Atleast, I am not sharing my private key with anyone here. This would definitely make me sleep better at night.


Regards,
Vaibhav Singh


Dave.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

Dave Cridland
On 8 August 2017 at 18:25, vaibhav singh <[hidden email]> wrote:

>
>
> On Tue, Aug 8, 2017 at 8:56 PM, Dave Cridland <[hidden email]> wrote:
>>
>> On 14 July 2017 at 15:42, Yoav Nir <[hidden email]> wrote:
>> > While it may be OK to share a key with my phone (but too difficult to do
>> > securely in practice), sharing with a delegate is hairy on many
>> > different
>> > layers. But still it’s the same issue.
>>
>> I think it's all solvable using Proxy Re[en]cryption, but that seems
>> to be a little fraught with patents at the moment.
>
>
> I am not comfortable with sharing my private key with anyone, be it the
> proxy user itself. I believe that is a requirement for Proxy Reencryption,
> please correct me if I may have interpreted it wrongly.
>

You have interpreted it incorrectly.

The proxy holds a key that will change a message encrypted to its
proxy key into a message encrypted for an authorized key. It cannot
decrypt the message to plaintext itself.

All quite bleeding edge, all quite patent-encumbered, but look at
Mathew Green's work for details - he's been researching very heavily
in this field.

Dave.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for secured email delegation workflow

Phillip Hallam-Baker-2


On Tue, Aug 8, 2017 at 4:57 PM, Dave Cridland <[hidden email]> wrote:
On 8 August 2017 at 18:25, vaibhav singh <[hidden email]> wrote:
>
>
> On Tue, Aug 8, 2017 at 8:56 PM, Dave Cridland <[hidden email]> wrote:
>>
>> On 14 July 2017 at 15:42, Yoav Nir <[hidden email]> wrote:
>> > While it may be OK to share a key with my phone (but too difficult to do
>> > securely in practice), sharing with a delegate is hairy on many
>> > different
>> > layers. But still it’s the same issue.
>>
>> I think it's all solvable using Proxy Re[en]cryption, but that seems
>> to be a little fraught with patents at the moment.
>
>
> I am not comfortable with sharing my private key with anyone, be it the
> proxy user itself. I believe that is a requirement for Proxy Reencryption,
> please correct me if I may have interpreted it wrongly.
>

You have interpreted it incorrectly.

The proxy holds a key that will change a message encrypted to its
proxy key into a message encrypted for an authorized key. It cannot
decrypt the message to plaintext itself.

All quite bleeding edge, all quite patent-encumbered, but look at
Mathew Green's work for details - he's been researching very heavily
in this field.

​Proxy re-encryption has been around for 25 years. It is hardly cutting edge.

There is a patent on the DRM use expiring soon. But the original Blaze scheme does everything I need. It certainly isn't 'all' encumbered.

It seems to me that the cryptographers got a particular mathematical property into their head as 'essential' which really isn't if you design protocols. So I don't need the paired stuff.

I wrote some stuff on this:

If you know of patent claims on the DH based scheme I describe, please let me know.

12
Loading...