Subject: Scope for self-destructing email?

From: vaibhav singh <[email-masked]>
Date: Tue, 15 Aug 2017 00:31:52 +0530

Hi,

As some of you may already know, General Data Protection Regulation (GDPR),
about to be enforced in the EU within months, and calls for strict
regulations for Right to rectify communications, Right to be forgotten ,
Pseudonymisation and Data portability.

With regards to this, me and my friends were thinking about the idea of a
self-destructing email, wherein the sender will mark the mail to be
destroyed (expunged from the server) once the receiver(s) have finished
reading it/after a time period chosen by the sender.

Another enhancement to this idea was a notification which will be sent from
some (Exploding email RFC) compliant MUA, in case the receiver refuses to
delete the email from the client. (I know Snapchat is a poor example here,
but they apparently send notifications to the originator of the snap in
case any receiver tries to capture the screenshot of the snap. This is, in
theory, what we are trying to do here).

I would also like to know about things (working groups, internet drafts
etc) which are being done to enforce GDPR to
email and Instant Messaging especially.

-- 

Regards,
Vaibhav Singh

---

From: Matthias Merkel <[email-masked]>
Date: Mon, 14 Aug 2017 21:13:54 +0200

I really like your idea and basically I'm in. My company owns an email provider (we will release soon) and we'd love to implement this and help you work on it. If you need help writing some technical standard for it just email me!

On Aug 14, 2017 9:01 PM, vaibhav singh <[email-masked]> wrote:

Hi,

As some of you may already know, General Data Protection Regulation (GDPR), about to be enforced in the EU within months, and calls for strict regulations for Right to rectify communications, Right to be forgotten , Pseudonymisation and Data portability.

With regards to this, me and my friends were thinking about the idea of a self-destructing email, wherein the sender will mark the mail to be destroyed (expunged from the server) once the receiver(s) have finished reading it/after a time period chosen by the sender.

Another enhancement to this idea was a notification which will be sent from some (Exploding email RFC) compliant MUA, in case the receiver refuses to delete the email from the client. (I know Snapchat is a poor example here, but they apparently send notifications to the originator of the snap in case any receiver tries to capture the screenshot of the snap. This is, in theory, what we are trying to do here).

I would also like to know about things (working groups, internet drafts etc) which are being done to enforce GDPR to

--

Regards,
Vaibhav Singh

---

From: Dave Cridland <[email-masked]>
Date: Mon, 14 Aug 2017 20:16:12 +0100

On 14 August 2017 at 20:01, vaibhav singh <[email-masked]> wrote:
> but they apparently send notifications to the originator of the snap in case
> any receiver tries to capture the screenshot of the snap. This is, in

It's pretty much unenforceable. It is, however, theoretically possible
to build a mechanism to request the later deletion of a message using
MSGTRACK (RFC 3885) as a basis - but that's likely to be merely a
means to let others know you made an error rather than a real way to
delete a message.

> email and Instant Messaging especially.

In Instant Messaging, things are slightly different.

Because there's an online, synchronous communications path, then
protocols like XMPP can use "Perfect Forward Secrecy" techniques to
limit access to the original message, and protocols such as OTR, "The
Signal Protocol", and OMEMO all deliberately prevent non-repudiation
post-facto.

Therefore after a conversation, it is difficult to decrypt the
messages (you'd need to persistently store ephemeral keys) and
impossible to strictly prove that the message as captured was not
simply a forged log (although since computer logs are usually
admissible evidence, this is of debatable use).

In terms of Pseudonymity, XMPP builds this into chatrooms (XEP-0045)
and is making this slightly better in its replacement, MIX (XEP-0369).

However, all of these still boil down to keeping honest users honest -
the GDPR applies to people and organisations, and not to computer
systems per se. It means we (system and protocol developers) are
required to consider these use-cases to remain relevant, certainly,
but the actual compliance to these laws is a matter for the end user.

Dave.

---

From: Matthias Merkel <[email-masked]>
Date: Mon, 14 Aug 2017 21:24:42 +0200

How about adding a way to tell if a SMTP server supports self-destructing emails and if it doesn't tell the user it doesn't and if they want to send it without self destruction

---

From: Matthew Pounsett <[email-masked]>
Date: Mon, 14 Aug 2017 15:40:58 -0400

On 14 August 2017 at 15:24, Matthias Merkel <[email-masked]> wrote:

> How about adding a way to tell if a SMTP server supports self-destructing
> emails and if it doesn't tell the user it doesn't and if they want to send
> it without self destruction
>

You have the same enforceability problem.   In the first case the request
is basically, "you MUST delete this message on the date requested, but if
you don't you MUST send a notice saying you didn't do that, but if you
don't... nothing happens."   Just as nothing stops the receiving server
from never deleting the message and never telling you, there's nom way to
force the receiving server to tell you the truth about what features it
implements.

As a simple advisory feature I'd probably ignore it.  Since there's never
any way to know whether the receiving server will live up to its promise,
you can never trust that it will, and so why send the info in the first
place?

---

From: Warren Kumari <[email-masked]>
Date: Mon, 14 Aug 2017 15:48:26 -0400

http://www.owl-stretching-time.com/because-you-dont-contol-the-recipient.png

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Matthias Merkel <[email-masked]>
Date: Mon, 14 Aug 2017 21:53:16 +0200

I think however that this system would mostly find use in systems like governments or maybe communication between whistleblowers and news outlets. In these cases you can trust the receipient server to delete the message when being told to do so.

On Aug 14, 2017 9:40 PM, Matthew Pounsett <[email-masked]> wrote:

You have the same enforceability problem.   In the first case the request is basically, "you MUST delete this message on the date requested, but if you don't you MUST send a notice saying you didn't do that, but if you don't... nothing happens."   Just as nothing stops the receiving server from never deleting the message and never telling you, there's nom way to force the receiving server to tell you the truth about what features it implements.

As a simple advisory feature I'd probably ignore it.  Since there's never any way to know whether the receiving server will live up to its promise, you can never trust that it will, and so why send the info in the first place?

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 14 Aug 2017 13:05:37 -0700

Hi -

On 8/14/2017 12:53 PM, Matthias Merkel wrote:
> I think however that this system would mostly find use in systems like 
> governments or maybe communication between whistleblowers and news 
> outlets. In these cases you can trust the receipient server to delete 
> the message when being told to do so.

Which governments can actually be trusted to this extent?

More seriously, how could you have any confidence at all that
unauthorized (or even "lawful intercept") copies of the message
would be deleted?

Randy

---

From: [email-masked] (Martin Rex)
Date: Mon, 14 Aug 2017 22:35:38 +0200 (CEST)

> Pseudonymisation and Data portability.

I believe you have seriously misunderstood the parts of GDPR about
"the right to be forgotten", because it does regularly not apply to IETF
mailing list posting -- only in very exceptional situations -- and
for those exceptional situations, there is a procedure in place where
you can submit a request to delete an indivdual submission from
the public archives (mailing list archives and I-D repository)
if you have a valid reason why this submission should be deleted.

The "Right to be forgotton" primarily applies to

 - terminated contracts -- so that a seller or service provider
   deletes data about you after termination of contract / subscription

 - that stories in the news (media outlets) about you, which you often
   didn't publish yourself (but some reporter about you) and with little
   public interest, will at some point disappear from online public archives
   (and internet search engines).  The information may remain available
   in offline archives (such as microfiche) as in the past.

-Martin

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Aug 2017 13:32:40 +1200

> unauthorized (or even "lawful intercept") copies of the message

You can't. I have destroyed Message-ID: <CACZ1GipivEf31iHchaM1OPFQF4QkfVRGVNsY_vVx=[email-masked]>.
Is that true? How do you know it's true?

    Brian

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Aug 2017 21:38:16 -0400

--On Tuesday, August 15, 2017 13:32 +1200 Brian E Carpenter
<[email-masked]> wrote:

>> unauthorized (or even "lawful intercept") copies of the
>> message would be deleted?
> 
> You can't. I have destroyed Message-ID:
> <CACZ1GipivEf31iHchaM1OPFQF4QkfVRGVNsY_vVx=[email-masked]
> l.com>. Is that true? How do you know it's true?

Even if I had some way to verify that your statement about your
actions were true and that what you meant by "destroyed"
included any backup copies you might have kept as a side-effect
of other operations or procedures, there is no way that you can
guarantee that Google has destroyed it too.   Indeed, prior to
the recent change in Gmail policy, I one could infer that they
had not and would not until whatever information it was
contained were deemed of no relevance.

   john

---

From: "John Levine" <[email-masked]>
Date: 15 Aug 2017 01:44:05 -0000

>reading it/after a time period chosen by the sender.

This can never work, for both technical and policy reasons.

The technical reason, as others have explained, is that recipient
systems can do anything they want with mail they receieve.  If I got
mail with a "must delete" flag I would probably reply that it's been
deleted and then archive it forever.  (I live in the United States,
where that is quite legal.)

The other is that there are organizations that for good policy reasons archive
all of their incoming and outgoing mail, such as banks and other financial
institutions.  Imagine if you sent a message to your broker saying "sell
all of my stocks" with the delete flag.  Whether or not a broker would
act on it, no broker I know would delete it.

R's,
John

---

From: joel jaeggli <[email-masked]>
Date: Mon, 14 Aug 2017 20:12:01 -0700

On 8/14/17 12:01, vaibhav singh wrote:
> Hi,
> 
> As some of you may already know, General Data Protection Regulation
> (GDPR), about to be enforced in the EU within months, and calls for
> strict regulations for Right to rectify communications, Right to be
> forgotten , Pseudonymisation and Data portability.
> 
> With regards to this, me and my friends were thinking about the idea of
> a self-destructing email, wherein the sender will mark the mail to be
> Another enhancement to this idea was a notification which will be sent
> from some (Exploding email RFC) compliant MUA, in case the receiver
> refuses to delete the email from the client. (I know Snapchat is a poor
> example here, but they apparently send notifications to the originator
> of the snap in case any receiver tries to capture the screenshot of the
> snap. This is, in theory, what we are trying to do here).
> 

In order that you have some assurance that the demands provided at the
input side are honored on the receipt side you need effectively
end-to-end control over the system, that is the sender, receiver, and
any intermediate hops are part of the same administrative domain such
that any control imposed is actually implemented. That might be
practical for an email system but not generally for the email system.

---

From: Michel Py <[email-masked]>
Date: Tue, 15 Aug 2017 03:25:12 +0000

Good evening, Mr. Phelps.

Your mission, should you choose/decide to accept it, would be to solve the recurrent problems of world
hunger, peace in the Middle East, USA / Russia relationships, global warming, and deployment of IPv6.

As always, should you or any of your I.M. Force be caught or killed, the Secretary will disavow
any knowledge of your actions. This email will self-destruct in ten seconds. Good luck.

---

From: Theodore V Faber <[email-masked]>
Date: Tue, 15 Aug 2017 16:47:13 +0000

________________________________________
> From: ietf <[email-masked]> on behalf of John C Klensin <[email-masked]>

>contained were deemed of no relevance.

As an aside, that passive voice matters, too.  The entity making the judgment (state agent, intelligence service, advertiser) will evaluate relevance differently.

To the main point: I do know lots of people on this list know these issues and are channeling Socrates, but to be explicit:  I think that once bits are out in the net, provably erasing them is impossible.   I'll channel Franklin (or whoever he's quoting): "Three can keep a secret, if two of them are dead."

--
Ted Faber <[email-masked]>
Engineering Specialist
Computer Systems Research Department
The Aerospace Corporation
310-336-7373
   john

---

From: vaibhav singh <[email-masked]>
Date: Wed, 16 Aug 2017 10:20:50 +0530

> practical for an email system but not generally for the email system.
We found an archived thread of a similar proposal for XMPP being made in
XMPP Standards list as well. There were a couple of neat outcomes from that
discussion, which I would like to present here as well.

There were a couple of improvements/compromises we were thinking:

1.) The popular opinion is that this will be unenforceable on the client;
we can actually drop the idea of clients being forced to clean up those
messages altogether. Our initial plan to propose this was to let the sender
of the email decide whether he wants to store his emails on the server or
not; that would be what we will be focusing on then.

2.) Matthias suggested a way to implement feature discovery for this:

*Have a central list (possibly mentioned in the documentation of this) of
IPs and domains that really support this feature (a central registry that
maintains the list would test if it really works; I'd offer that my company
can do this but that would have to be decided by the public). If a SMTP
server advertises the feature and it is on the list send the mail without
any warnings, if it advertises it but is not on the list warn the user that
the server might potentionally fake the ability to do this. If it does not
advertise the feature but is on the list warn the user that the server may
not have the ability. If it neither is on the list nor advertise the
feature ask the user if they want to send the email without
self-destruction enabled.*

This seems to work for me. Any problems which could come up with having a
central authority for this feature?

3.) We may have to assume that the sender and receiver of the mail are
trusted; this would mean that the mail may have to be encrypted prior to
sending:

*Encryption would allow you to establish a level of trust with the
recipient. I.e. you encrypt the message and mark it for ‘self destruct’.
You then have to trust the recipient to destroy it (but at least you don’t
have to trust every server along the way). This gives you some level of
reassurance that the message will be destroyed, assuming the recipient is
trustworthy (and runs trustworthy clients).*

4.) A really boiled down version of ephemeral mails could just mark the
mail "outdated" if the information provided in the mail is not expected to
hold good after some time, instead of actually expunging the mail.

*why not try to accommodate both realitys and define a feature which is
called "Invalidation of Messages" or similar instead of "Destructible
Messages". The goal of this feature should be to mark messages in a way,
that the client somehow can mark the message as "not being relevant
anymore" or something like that. So it could still be displayed but grayed
out for example telling the receiver that the message can be ignored.
Additionally there could then be added an attribute "deletionrequest" which
can be set for clients which really want to have destructible messages like
Signal does.*

Any thoughts?

-- 

Regards,
Vaibhav Singh

---

From: Ted Hardie <[email-masked]>
Date: Wed, 16 Aug 2017 09:49:11 -0700

> can be set for clients which really want to have destructible messages like
I think there are two potential lines of development here, though I confess
I am skeptical of the value of either.

The first is providing a facility that declares a particular message to be
automatically overcome by events at a particular time, leaving it
completely up to the recipient how to process the message based on that
metadata.  There are simple message types (today's weather, lunch
availability, etc.) that could be thus set to be marked OBE when no longer
relevant.  Some clients might choose to auto-delete them or auto-archive
them when the time is reached, but this would be because of their preferred
handling and not a guarantee to the sender that the sender's intent is
being honored.  A message header like OBE-At: could be registered
provisionally without much hassle, and you could see if it saw
implementation and use.

The second is a trickier question:  is it possible to construct a message
such that it is cryptographically non-repudiable within a set time frame
but repudiable thereafter?  I think the answer to this is yes, but it
relies on a carefully crafted interaction among the use of limited validity
certificates, requirements to confirm validity with a CA, and CA behavior.
You could deploy that in a limited environment, in other words, and see if
it was useful enough to make the behavior standard.  It's less clear to me,
though, why it would be useful.  The one scenario I can construct is
financial, as part of the flow for placing a time limited order, but the
flow seems strictly worse that a simpler flow that includes the time limit
for the order within a message which is permanently non-repudiable.

regards,

Ted

---

From: Matthias Merkel <[email-masked]>
Date: Wed, 16 Aug 2017 19:30:23 +0200

Well. The problem with a central authority is that it has to be trusted.

In case my company will serve as central authority we would provide public audits which everyone could use to verify we followed the rules.

In case some other organisation would serve as central authority I'd suggest to require it to provide these audits as well.

On Aug 16, 2017 6:50 AM, vaibhav singh <[email-masked]> wrote:

We found an archived thread of a similar proposal for XMPP being made in XMPP Standards list as well. There were a couple of neat outcomes from that discussion, which I would like to present here as well.

1.) The popular opinion is that this will be unenforceable on the client; we can actually drop the idea of clients being forced to clean up those messages altogether. Our initial plan to propose this was to let the sender of the email decide whether he wants to store his emails on the server or not; that would be what we will be focusing on then.

Have
a central list (possibly mentioned in the documentation of this) of IPs
and domains that really support this feature (a central registry that
maintains the list would test if it really works; I'd offer that my
company can do this but that would have to be decided by the public). If
a SMTP server advertises the feature and it is on the list send the
mail without any warnings, if it advertises it but is not on the list
warn the user that the server might potentionally fake the ability to do
this. If it does not advertise the feature but is on the list warn the
user that the server may not have the ability. If it neither is on the
list nor advertise the feature ask the user if they want to send the
email without self-destruction enabled.

This seems to work for me. Any problems which could come up with having a central authority for this feature?

3.) We may have to assume that the sender and receiver of the mail are trusted; this would mean that the mail may have to be encrypted prior to sending:

Encryption would allow you to establish a level of trust with the recipient. I.e. you encrypt the message and mark it for ‘self destruct’.
You then have to trust the recipient to destroy it (but at least you
don’t have to trust every server along the way). This gives you some
level of reassurance that the message will be destroyed, assuming the recipient is trustworthy (and runs trustworthy clients).

4.) A really boiled down version of ephemeral mails could just mark the mail "outdated" if the information provided in the mail is not expected to hold good after some time, instead of actually expunging the mail.

why not try to accommodate both realitys and define a feature which is called "Invalidation of Messages" or similar instead of "Destructible
Messages". The goal of this feature should be to mark messages in a way,

that the client somehow can mark the message as "not being relevant anymore" or something like that. So it could still be displayed but

grayed out for example telling the receiver that the message can be ignored. Additionally there could then be added an attribute "deletionrequest" which can be set for clients which really want to have destructible messages like Signal does.

Any thoughts?

--

Regards,
Vaibhav Singh

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Aug 2017 14:05:31 -0400

--On Wednesday, August 16, 2017 09:49 -0700 Ted Hardie
<[email-masked]> wrote:

> On Tue, Aug 15, 2017 at 9:50 PM, vaibhav singh
>...
>> *why not try to accommodate both realitys and define a
>> feature which is called "Invalidation of Messages" or similar
>> instead of "Destructible Messages". The goal of this feature
>> should be to mark messages in a way, that the client somehow
>> can mark the message as "not being relevant anymore" or
>> something like that.
>...

> I think there are two potential lines of development here,
> though I confess I am skeptical of the value of either.

> The first is providing a facility that declares a particular
> message to be automatically overcome by events at a particular
> time, leaving it completely up to the recipient how to process
> the message based on that metadata.  There are simple message
> types (today's weather, lunch availability, etc.) that could
> be thus set to be marked OBE when no longer relevant.  Some
> clients might choose to auto-delete them or auto-archive them
> when the time is reached, but this would be because of their
> preferred handling and not a guarantee to the sender that the
> sender's intent is being honored.  A message header like
> OBE-At: could be registered provisionally without much hassle,
> and you could see if it saw implementation and use.

Ted,

Do you consider the above significantly different from the
X.400-derived Expiry-Date (RFC 1327) or Expires (RFC 2156)?
While both are identified as obsolete in RFC 4021 and the IANA
Message Header registry, they provide a date and leave it up to
the recipient how those metadata are processed.

While RFC 1327 and 2156 primarily define those fields by
reference to X.400 (1988 and 1992), my recollection of the
CCITT/ISO documents is that the expiration date-time is defined
in a way that is quite consistent with "Invalidation of
Messages" as described above, with the receiving system free to
warn about obsolescence or even to discard copies.

While I don't think it has much of a future --for reasons that
many of us have given and that I assume are consistent with your
skepticism -- I'd like to propose what I think would be a far
more constructive approach for Vaibhav and colleagues than
continued iterations on the IETF list:  They could write an I-D
in the form of an Experimental document that would actually pin
down what they are proposing.  That I-D could propose changing
the "obsolete" status for "Expires" in the registry to something
more active if the experiment succeeds, eliminating the need for
any IANA or Expert action at this point and potentially taking
advantage of any MUAs or MTAs that haven't bothered to get rid
of support for those old headers.   Then, with the feature and
any needed protocol bits specified, they see if they can get any
real traction.  Under more usual circumstances, we'd publish an
experimental spec without implementations and demonstration of
usefulness and usability, but, since "Expires" was implemented
and deployed in the past, after which the IETF decided it was
obsolete, it seems to me that pursuing this further should
require proof of utility and/or a clear explanation of why this
time is different.

best,
    john

---

From: Matthias Merkel <[email-masked]>
Date: Wed, 16 Aug 2017 20:10:35 +0200

The difference seems to be that Expires is a pre-set email header. The command for this can be sent after the email was already sent.

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Aug 2017 14:43:59 -0400

--On Wednesday, August 16, 2017 20:10 +0200 Matthias Merkel
<[email-masked]> wrote:

> The difference seems to be that Expires is a pre-set email
> header. The command for this can be sent after the email was
> already sent.

But, if an MUA is going to process it, which is implied by
"Invalidation of Messages... mark messages in a way, that the
client somehow can mark the message as "not being relevant
anymore"..., then it needs to make it into the headers of the
message that is seen by the receiving MUA.  Probably we have
enough mechanisms in message management protocols to signal the
delivery MTA or message store to insert that header field.
While I think any of us could devise some new mechanism that
would not require new header fields, such a mechanism would
imply inventing and deploying more machinery and make adoption
of this mechanism even less likely.

But I think the above (both your comment and my response)
demonstrate my main point -- it is time to get to an I-D that
specifies the details rather than continuing an on-list
discussion that is mostly about generalities (as a striking
example, note "...or something like that) and which each of us
is hearing a little differently as to what are, and are not, key
elements of the proposal.

best,
    john

---

From: "John Levine" <[email-masked]>
Date: 16 Aug 2017 22:56:37 -0000

>central authority for this feature?

Many.  What if I tell the central authority that I implement
self-destructive e-mail but I'm lying?  How could the central
authority tell?  I'm pretty sure I can pass whatever audits they make
since they have no way to tell what data I'm hiding in places they
can't see.

>hold good after some time, instead of actually expunging the mail.

As others have said, that feature has come and gone many times in the past.  In
netnews, which is similar in some ways to mail, there's an Expires: header which
works reasonably well, typically used to mark messages that stop being interesting
after some point like weather forecasts or event reminders.  There's no guarantee
that anyone will follow the advice, and you certainly can't use it to force stuff
to disappear, but it's been occasionally useful.

R's,
John

---

From: Warren Kumari <[email-masked]>
Date: Wed, 16 Aug 2017 20:43:29 -0400

> since they have no way to tell what data I'm hiding in places they

I suspect that one of my previous responses here might have been both
too subtle, and also quite likely to have been ignored as spam.
All of these sorts of solutions will always be subject to the issue
that you don't control the recipient system -- there is noting (well,
very little) that stops the recipient from taking a screen capture of
the message as it is displayed, or even whipping out their smartphone
and taking a picture of the screen.
See: http://www.owl-stretching-time.com/because-you-dont-contol-the-recipient.png
There is nothing that the sender can include which will make a image
of the message go "Boom" later.

> to disappear, but it's been occasionally useful.

Yup - I think that an advisory note (Expire:) saying "This mail might
not be relevant anymore (it was an invitation to a party last week)"
has some (limited) value, but a: relying on something like this to
actually expunge information is unworkable and b: rude. I might want
to search my mail to see what the weather forecast said last Thursday,
or search event reminders to know where I was last Tuesday. Once
you've sent me the mail, it's mine!

W

---

From: Ted Hardie <[email-masked]>
Date: Wed, 16 Aug 2017 17:58:40 -0700

On Aug 16, 2017 11:05 AM, "John C Klensin" <[email-masked]> wrote:

Ted,

Honestly, I had forgotten about both, so it is entirely possible that they
match the meta data semantics of much of this.

Ted

best,
    john

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Aug 2017 13:24:30 +1200

> to disappear, but it's been occasionally useful.

I thought of changing the title to "Scope for self-destructing web pages?"

After I heard an early internal presentation of the design of the World-Wide Web
from my CERN colleague Tim Berners-Lee, probably in 1993, I asked him why he didn't
make an expiry date a mandatory feature of every HTML document. Being a man of some
foresight, he explained exactly why it wouldn't work in practice, despite being
a wonderful idea in theory.

And yes, according to RFC 1866 (and for all I know, more recent definitions
of HTML) you can include things like
    <META HTTP-EQUIV="Expires" CONTENT="Tue, 04 Dec 1993 21:29:02 GMT">
and the server may then include "Expires: Tue, 04 Dec 1993 21:29:02 GMT"
in the reply to an HTTP GET.

Only, have you noticed any web pages expiring recently? Maybe there are
browsers that annoy their users by not displaying expired pages?

Bits don't expire.

    Brian

---

From: Lyndon Nerenberg <[email-masked]>
Date: Wed, 16 Aug 2017 18:47:41 -0700

> On Aug 16, 2017, at 6:24 PM, Brian E Carpenter <[email-masked]> wrote:
> 

They do.  Is there a single web site on the planet these days that *doesn't* set the page cache time to 0? 

Then again, my Customer Experience is Enhanced by waiting for that 20 second reload, every time I press the "back" button in my phone's web browser.  It gives me time to flip to another tab and buy something for Instant Delivery from Amazon.  The package usually arrives before the other tab finishes reloading.

--lyndon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Aug 2017 23:21:52 -0400

This is a problem I have been considering for some time. And everyone in
this thread is right. Right on the facts at least. Most are wrong on the
implications.

When the Web was launched in 1992, it was dismissed by the network
hypertext crowd because it did not solve the problem of referential
transparency that Ted Nelson insisted was really really important. It was
not, the Web worked fine with 404 not found. In fact it didn't work fine,
it worked *better*.

It was this insight that led me to propose Confidential Document Control
(CDC) as a subset of the Digital Rights Management (DRM) Problem. I have a
draft if you are interested in the math or just like looking at the pretty
SVG pictures we can use in HTML:

http://prismproof.org/Documents/draft-hallambaker-mesh-recrypt.html

​What I realized was that there are two difficult problems in the DRM
problem:

1) Restricting initial distribution of confidential data ​to the set of
authorized parties.

2) Preventing disclosure by authorized parties to others.

These are both challenging technical problems that cannot be solved with
the cryptographic toolset used in OpenPGP and S/MIME. Mesh/Recrypt
addresses the first. It uses cryptography that can be understood by high
school students but it is cryptography that nobody had worked out how to
apply in practice that way until now[1].

​Solving the first problem really wasn't impossible. I am pretty sure that
many others could have done what I have. But I rather suspect the reason
they did not is that the whole field of DRM has been poisoned by two facts:

1) ​ Preventing disclosure by authorized parties to others requires the use
of trustworthy hardware and no hardware is 100% trustworthy.

2) The whole field of DRM has been poisoned by anti-copyright enforcement
ideology.

​The problem that began this thread, 'burn after 24 hours' is simply
another type of attribute ​describing a restriction we wish to enforce on
the use of the document.

​At the moment, Mesh/Recrypt is deliberately limited to solving only the
first part of the CRM problem. It only addresses the initial distribution
of the documents. This is the subset I call Confidential Document Control.
One reason for this limitation is that authorization policy languages is a
whole different patent minefield to navigate. But the other is that I get
95% of the ​value of a full DRM system with just my CDC component.

Consider recent US government breaches:

* Did Snowden need to read any of the Powerpoint files?
* Did Chelsea Manning need to have access to 250,000 cables?
* Did everyone working in the CIA need access to the website with the
malware tools?
* Should the Secretary of State have reasonably considered the GSA mail
services secure when it is likely thousands of personnel and contractors
had access to them?

​When we drill down, the number of leaks by a person with a need to know
the material in question is a tiny ​fraction of the people who have access
today. Without a practical, standards based means of performing data level
encryption, the leaks are going to continue.

It is the same in the enterprise. While it is possible that the criminal
gangs that attacked HBO to leak Game of Thrones did so by suborning an
insider, it is vastly more likely that they compromised a machine on the
corporate network and leveraged it. CDC rather than full DRM would almost
certainly have been sufficient.

So what then of DRM? Am I saying it has absolutely no use? Absolutely not.
Because security is risk control, not risk elimination. It is not necessary
to provide an absolute guarantee that the data will not leak in any
possible circumstance to provide value. Trustworthy hardware does not need
to be 100% trustworthy to provide useful risk control in the enterprise.

In fact, there is only one area in which DRM has to be 100% and that is
copyright enforcement and that is because it is break once run anywhere. So
I can certainly help HBO stop their shows leaking before show date but I am
not going to promise anything after they have shared their secret with ten
million of their closest friends.

For early adopter purposes, the hardware used to distribute material need
not be any more trustworthy than an iPad Pro. Of course you or I or any
number of folk could probably work out how to bypass that level of security
given physical access to the device. But the fact is that what most people
want is for the machine to help them not leak stuff accidentally. They have
absolutely no intention of jailbreaking their corporate phone or tablet.

So here is what I propose. Let us start this journey by working on a
solution to the CDC part of the problem. Which will take us some time.
Solving the CDC problem is a subset of the enterprise DRM problem.

And if we win, then its like pinball - you win, you get to play again.
Adding a security policy language to describe permitted uses is a trivial
engineering task. The hard part would be the prior art search.

​PHB​

​[1] Well I hope this is the case as I am going to be doing just that later
this year.​

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Thu, 17 Aug 2017 03:47:35 +0000

The key issue is that no method currently in existence can defeat a camera taking a picture of the screen.  That will always let an authorized receiver make a permanent copy of the email and do what they want with it.  Yes, you may be throwing away repudiation and signature information, but they will have the contents of the mail.

-glenn

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 17 Aug 2017 00:43:16 -0400

On Wed, Aug 16, 2017 at 11:47 PM, Deen, Glenn (NBCUniversal) <
[email-masked]> wrote:

> The key issue is that no method currently in existence can defeat a camera
> taking a picture of the screen.  That will always let an authorized
> receiver make a permanent copy of the email and do what they want with it.
> Yes, you may be throwing away repudiation and signature information, but
> they will have the contents of the mail.
>

​Absolutely true. And really serious for some applications. But consider
the Game of Thrones hack, a screen capture would be serious, yes. But
nowhere near as serious as having the final cut leak in HD.

​The kids are using snapchat because their principle security concern is
that the receiver will forget to delete the pics they send and they will
end up with the parents. They understand full well that they can photograph
the screen of one phone with another.

The perfect is the enemy of the good.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 16 Aug 2017 23:28:25 -0700

On 8/16/2017 9:43 PM, Phillip Hallam-Baker wrote:

> On Wed, Aug 16, 2017 at 11:47 PM, Deen, Glenn (NBCUniversal)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     The key issue is that no method currently in existence can defeat
>     a camera taking a picture of the screen.  That will always let an
>     authorized receiver make a permanent copy of the email and do what
>     they want with it.  Yes, you may be throwing away repudiation and
>     signature information, but they will have the contents of the mail.
>
>
> ​ Absolutely true. And really serious for some applications. But
> consider the Game of Thrones hack, a screen capture would be serious,
> yes. But nowhere near as serious as having the final cut leak in HD.
>
> ​ The kids are using snapchat because their principle security concern
> is that the receiver will forget to delete the pics they send and they
> will end up with the parents. They understand full well that they can
> photograph the screen of one phone with another.
>
Yes. The threat model here is not that the recipient will somehow
divulge the message. Of course they can. The problem is that copies of
the message are kept in multiple places.

If the recipient is cooperating, that is not an unsolvable problem.
Suppose that the recipient's copy is encrypted with a short lived public
key, and that the recipient voluntarily discards the corresponding
private key after some time. There may well be copies of the bits around
in many places, but nobody would be able to decrypt them. Of course,
this requires that the sender acquires an ephemeral key from the
recipient before sending the message. That may be hard to do in
practice. But it is certainly doable.

-- 
Christian Huitema

---

From: "Gary E. Miller" <[email-masked]>
Date: Wed, 16 Aug 2017 23:56:37 -0700

Yo Christian!

On Wed, 16 Aug 2017 23:28:25 -0700

> If the recipient is cooperating, that is not an unsolvable problem.

It is unsolvable.  Nothing to prevent anyone from taking a screen shot,
cut/pasting, or taking a photo of the email.

Robert Redford had it right: No More Secrets

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	[email-masked]  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Aug 2017 08:25:32 -0400

Ted Hardie <[email-masked]> wrote:
    > automatically overcome by events at a particular time, leaving it completely
    > up to the recipient how to process the message based on that metadata. There
    > are simple message types (today's weather, lunch availability, etc.) that
    > could be thus set to be marked OBE when no longer relevant. Some
    > clients

This is an interesting idea.  For those of us who deal with many emails,
(particularly upon return from vacation), not having to deal with lunch plans
that have expired would in fact be nice.

Some of us still deal with cron job output.  An hourly job that fails all
weekend generates a lot of email, and often only the most recent failure is
at all useful to know about.  That's a job for good-old-Usenet Supercedes:,
but that's one email overcoming another, and the whole thing needs
some cryptographic support.  Note that a merkle hash (a la s/key) would
probably suffice.

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 17 Aug 2017 09:23:06 -0400

Folks,

It seems to me that three things are emerging on this thread.

(1) The original proposal and problem to be solved, at least as
most of us understood it, was to allow a sender to send some
sort of notification that would cause all copies of a message to
be  automagically destroyed.  We appear to have unanimity that
problem is unsolvable, at least in the general case and/or in
the absence of universal trust.

(2) We have considerable experience (in both email and netnew)
with putting out messages with expiry dates as information for
the recipient (whether expected to be acted on automatically or
not).  While there are important exceptions, they have never
been as useful as was apparently assumed when they were
adopted... to the point that the IANA registry entries for the
relevant email header fields identify them as obsolete.  We have
less experience with the originator of an already-sent message
as expired or obsolete, but no evidence has been offered so far
that such a facility would be appreciably more useful than the
"Expires:" header field.

(3) We have now reached the stage in which people seem to be
discussing alternate problems that can be solved.  That isn't
very hard, but those alternate problems are not the original one
and little or no case is being made that the new problems are
worth solving or that solutions would be useful, even if they
are feasible.

It seems to me that, if people believe there is a problem worth
solving and if they think they have a feasible solution, we need
to see an I-D that explains both, rather than continuing to
circle around an ever-expanding collection of possible issues on
the IETF list in the absence of such a draft.

     john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 17 Aug 2017 15:15:22 -0400

> the absence of universal trust.

​It is agreed that it is impossible to solve without trustworthy hardware.

The only thing that has stopped me adding such a feature to Mesh/Message
has been that there is a dense thicket of IPR covering such techniques and
I have not read it.

If the next President of the US was to come to me and ask if I could
provide a mechanism that would allow her to send an email message to
members of her cabinet and that supported a 'recall' feature, I would have
no hesitation in saying yes, conditional on some technical support which
Microsoft and Apple and some others are both capable of providing.

If she then said, 'What about adding the UK Prime Minister', I would answer
no.
​

> relevant email header fields identify them as obsolete.

​That might be because they were never implemented sufficiently widely. I
can turn off send receipts for example.

Another issue is that SMTP is a push service, not a pull service. For
Mesh/Message, I want to provide a superset of the capabilities of dropbox
like mail and SMTP like mail. So my basic scheme is:

When the mail is sent: Store the message on the sending server, send a
notification to the receiving server.

If the message is less than the receiving server size limit (varies by
sender), forward the body of the message after x minutes.

The reason for this is that most of the times I want to recall a message,
it is because I want to add the #Q$%%* attachment or correct the spelling
mistake.

> the IETF list in the absence of such a draft.

​Well I have released 6 drafts this week and I am currently working on
another 3...

I don't think it is a problem that is solvable within the framework of
SMTP. It is a problem that can only be solved in the context of a new
messaging infrastructure in which every user supports the capability by
default. Such infrastructures have been successful in the recent past, see
Snapchat. Sure, they are wobbling a little now. But they have more users
than S/MIME, OpenPGP, IPSEC and SSH combined.
​

---

From: "John Levine" <[email-masked]>
Date: 18 Aug 2017 01:30:37 -0000

>that have expired would in fact be nice.

See RFC 2156 and RFC 4021, section 2.1.50.  To me the interesting
question is why, since we've had Expires: for 20 years, nobody uses it
outside of netnews.

> That's a job for good-old-Usenet Supersedes:,

Seems like overkill.  How about you pay attention to the Supersedes:
(see RFC 2156 and RFC 4021, section 2.1.46) if old and new messages
both have DKIM signatures from the same domain?  Same question about
why after 20 years nobody uses it outside of netnews.

R's,
John

---

From: [email-masked]
Date: Fri, 18 Aug 2017 06:53:17 -0700 (PDT)

> question is why, since we've had Expires: for 20 years, nobody uses it

More like 30+ years. See RFC 841, section 3.2.5, also X.400-1984.

> why after 20 years nobody uses it outside of netnews.

And if you want to explore the cryprographic side of this, there's an
extensive literature. A good place to start is Radia Perlman's "The Ephemerizer
- Making Data Disappear".

				Ned

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Aug 2017 18:41:56 -0500

On 8/17/17 2:15 PM, Phillip Hallam-Baker wrote:
> members of her cabinet and that supported a 'recall' feature, I would 
> have no hesitation in saying yes, conditional on some technical 
> support which Microsoft and Apple and some others are both capable of 
> providing.

https://www.google.com/search?q=%22hdcp+stripper%22

https://www.atomos.com/ninja/

/a

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 18 Aug 2017 21:59:20 -0400

> https://www.atomos.com/ninja/

​The point is that the President has already decided to extend an
extraordinary degree of trust to the cabinet by appointing them. They can
certainly be trusted not to make use of devices of that sort (and in any
case, their use can probably be disabled on the tablet class devices, which
is what I wanted assistance from Apple and Microsoft for).

That is precisely why the same consideration would not apply even to allies
as close as the UK.

We are all very much aware of the techniques that can be used to strip out
commodity DRM for copyright enforcement. They do not apply to applications
where the data is being shared between a few dozen or a few hundred users
to anything like the same degree as sharing the data with a quarter billion
folk round the world.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 18 Aug 2017 22:01:33 -0400

> why after 20 years nobody uses it outside of netnews.

​DKIM almost helps but this is a data level feature and it really does not
work well with a presentation layer authentication scheme like DKIM.

And to make it work well, you have to start from a messaging infrastructure
where every message and sender can authenticate themselves
cryptographically from the beginning...​

---

From: "John R Levine" <[email-masked]>
Date: 19 Aug 2017 10:27:24 -0400

> work well with a presentation layer authentication scheme like DKIM.

I suppose, but you'd need something like DKIM if you want to prevent 
attacks where the bad guy splices his headers onto your message, and it 
has the advantage that it exists and is widely deployed.

It's certainly not perfect, e.g., any gmail user could supersede anyone 
else's unless gmail limited what headers they sign, but that doesn't seem 
like a high value attack.

> cryptographically from the beginning...​

  ... with a pony?

R's,
John