Subject: [dane] DANE WG Interim Virtual Meeting, December 2, 2014

From: IESG Secretary <[email-masked]>
Date: Thu, 13 Nov 2014 12:15:12 -0800

DANE WG Interim virtual Meeting: SMIME Usage cases and Requirements

Date: December 2’nd at 10:00 Eastern 

The DANE WG will have a 1 hour long Interim meeting on December 2’nd to 
cover SMIME usage.

The goal of the meeting is to facilitate discussion on what the actual 
requirements are, please send in drafts outlining how you envision SMIME 
to be used/supported, or send such statements to the working group 
mailing list for discussion in advance.

A list of documents submitted for discussion will be posted to the list 
a week in advance.

Olafur & Warren 

DANE
Tuesday, December 2, 2014
10:00 am  |  Eastern Standard Time (New York, GMT-05:00)  |  1 hr
 
Join WebEx meeting:
https://ietf.webex.com/ietf/j.php?MTID=md5def721def32dd731a704859cf83218
Meeting number:	640 822 261
Meeting password: 1234
 
Join by phone
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 640 822 261

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 25 Nov 2014 09:29:44 -0500

Dear colleagues 
Just a reminder that the virtual meeting is happening next week on Tuesday. 
Please send in usage statements ASAP, as that will help frame the discussion 

thanks
	Olafur & Warren 

> On Nov 13, 2014, at 3:15 PM, IESG Secretary <[email-masked]> wrote:
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Warren Kumari <[email-masked]>
Date: Wed, 26 Nov 2014 12:38:59 -0500

> Please send in usage statements ASAP, as that will help frame the discussion

Also, please read
https://datatracker.ietf.org/doc/draft-osterweil-dane-ent-email-reqs/
and
https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-usage-01 before
the meeting[0].

Also worth considering / discussing is the whole "Bob writes a mail on
March 1st and then leaves the Acme, Inc. on March 2nd. Alice finally
gets around to opening the mail on April 10th - should it validate?"
or
"Bob gets fired on March 2nd and is understandably disgruntled. He has
his laptop at home and sends mail on March 3rd. Can Acme, Inc prevent
this / invalidate the keys?"
and
http://www.ietf.org/mail-archive/web/dane/current/msg07021.html

[0]: For those folk in the USA - you might want to print these out /
sync them to a reading device so you have something to do while
recovering from too much turkey.

W

-- 
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: Doug Montgomery <[email-masked]>
Date: Sun, 30 Nov 2014 13:26:57 -0500

> gets around to opening the mail on April 10th - should it validate?"

Not sure the notion of "to open" is well defined at a MUA.   Given the
models of POP vs IMAP vs webmail vs ..... it is not even clear to me that
"delivered to MUA" is well defined.

But, your MUA, or MTA if privy to your trust anchors, should mark if the
message signatures were valid at time of first delivery.   Optionally if
the app wants to show if the signature is still valid, it could, but this
is less important.

A good test is to substitute "10 years later" for "on April 10th" above and
see if it changes your thinking.

or
> this / invalidate the keys?"

Not sure if your question is about the timing (1 day) or the capability at
all.

But in general if Acme can't revoke invalid or compromised credentials...
then the system is next to useless.   I know of very large IDM systems and
supporting policies/laws that require credential revocation within 24 hours
or less of employee termination.

Ideally Acme would be able to publish (somewhere) a policy that says all
Acme.com email is signed ... and would be able to insure there is no valid
binding between Bob and a email signing key for the domain.

Those two bits of information would be enough to enable receivers that care
to check / enforce the ability to determine that Bob's disgruntled email
does not come from a valid acme.com network identity.

In a somewhat related point on historical keying material, I think MUAs
should mark that encrypted messages were encrypted at time of first
delivery and not store the message in its original encrypted form.    The
problem of historical key escrow so that I can go back and recover my old
keys and read emails sent to me years ago seems bizarre, yet I know large
IDM systems that do this.   Store your inbox on an encrypted file store if
you wish, but the idea that I should maintain an infinite historical key
store to read the email you encrypted to me 10 years ago seems the wrong
model ... but yet I know large IDM systems that do this.

dougm

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 30 Nov 2014 18:56:37 +0000

> > gets around to opening the mail on April 10th - should it validate?"

The correct answer is "no, it should not validate".  Business
processes can be applied to send Alice a new email signed by Bob's
successor if that's required.  Bob's signing key is no longer
published at the time that Alice reads the mail.

Alice has no way to know whether Bob's email was sent before or
after Bob left Acme.  Bob's S/MIME signature is not securely
timestamped, all Alice knows is that the message was signed in the
past.  Signed time-of-receipt by Alice's mail system would be needed
to do better, and no standard specifies these at present.

> "delivered to MUA" is well defined.

User agents that support encryption and signing need to be able to
distinguish "new" mail from "old".  Otherwise, they are too crippled
to usefully support end-to-end encryption.

> see if it changes your thinking.

Actually, 10 years later is different if the mail was originally read
in a timely manner, and is being re-read 10 years later.

> > this / invalidate the keys?"

Just the same as the first case.  Depublish Bob's keys.

> Store your inbox on an encrypted file store if

Secure local storage of decrypted email (with any signature
verification status at time it was first read) is a local requirement
for an MUA that adequately supports email encryption and signing.

Out of scope for DANE, but inescapable for MUA usability.

-- 
	Viktor.