Subject: [ietf-smtp] Request for discussion of Mandatory Secure Mail Delivery proposal (draft-wchuang-msmd)

From: Wei Chuang <[email-masked]>
Date: Tue, 15 Oct 2013 12:31:17 -0700

Hi ietf-smtp,

Request for discussion (draft-wchuang-msmd) of a proposal to secure mail from
eavesdropping and MitM attacks.  All comments welcome on this thread.  I'm
mentioning the proposal also to apps-discuss@ and saag@ lists as this may
be of interest to them too, but redirecting discussion to this list so its
all happening in one place.

Here's the abstract:

   Opportunistic SMTP TLS does not enforce electronic mail delivery
   using TLS leading to potential loss of privacy and security.  We
   propose an optional mail header extension "mandatory-secure-mail-
   delivery:" and SMTP EHLO response extension "MSMD" that indicates
   mail must be delivered privately using TLS and with integrity using
   DKIM, and thereby provide a security guarantee to the user.  When
   mail is sent with the header indicating privacy and integrity and if
   the receiving party does not support this, the mail is instead
   bounced.  To protect the mail after delivery, the destination SMTP
   server must advertise its capabilities as part of the EHLO response,
   and the sender can choose whether the destination is able to honor
   the privacy requirements specified on the mail header.

Link to the proposal here:
http://datatracker.ietf.org/doc/draft-wchuang-msmd/

-Wei

PS Pardon for any IETF formatting or etiquette errors as I'm very new to
the IETF process.

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 15 Oct 2013 23:25:27 +0200

On 15.10.2013, at 21.31, Wei Chuang <[email-masked]> wrote:

> Hi ietf-smtp,
> 
> Request for discussion (draft-wchuang-msmd) of a proposal to secure mail from eavesdropping and MitM attacks.  All comments welcome on this thread.  I'm mentioning the proposal also to apps-discuss@ and saag@ lists as this may be of interest to them too, but redirecting discussion to this list so its all happening in one place.

The SMTP side is mostly what I had been thinking about earlier (although I was thinking about MAIL FROM parameter instead of a header, but I'm not sure if there's a big difference). The IMAP side of the draft makes the security "complete", but it would also seriously slow down the deployment, which is especially annoying because most of the target users are already using IMAP and SMTP with TLS, making the MSMD command requirement mostly irrelevant. If the IMAP server simply checked that the IMAP client was connected with TLS, that would make it very likely that the SMTP submission would also be done with TLS, I think? Unless maybe Google has statistics that this isn't the case?

Anyway, if the idea behind MSMD IMAP command survives, it should be done with ENABLE MSMD instead.

---

From: Wei Chuang <[email-masked]>
Date: Tue, 15 Oct 2013 17:41:18 -0700

Hi Timo,

On Tue, Oct 15, 2013 at 2:25 PM, Timo Sirainen <[email-masked]> wrote:

> > Request for discussion (draft-wchuang-msmd) of a proposal to secure mail
> from eavesdropping and MitM attacks.  All comments welcome on this thread.
>  I'm mentioning the proposal also to apps-discuss@ and saag@ lists as
> this may be of interest to them too, but redirecting discussion to this
> list so its all happening in one place.
>
> The SMTP side is mostly what I had been thinking about earlier (although I
> was thinking about MAIL FROM parameter instead of a header, but I'm not
> sure if there's a big difference). The IMAP side of the draft makes the
> security "complete", but it would also seriously slow down the deployment,
> which is especially annoying because most of the target users are already
> using IMAP and SMTP with TLS, making the MSMD command requirement mostly
> irrelevant. If the IMAP server simply checked that the IMAP client was
> connected with TLS, that would make it very likely that the SMTP submission
> would also be done with TLS, I think?

Today I think this is not the case.  Though the big webmail providers offer
IMAP w/TLS (certainly Gmail, but also I believe for example Yahoo and
Outlook), mail delivery over SMTP is typically not over TLS. Only a small
subset of providers actually offers SMTP STARTTLS and even then there's no
guarantee it will successfully deliver over TLS due to the SMTP STARTTLS
spec.

> Unless maybe Google has statistics that this isn't the case?

Yes, statistics for mail delivery to/from Gmail indicates that most
deliveries are over SMTP w/o TLS though Gmail offers SMTP STARTTLS.

Agreed that the more constrained mode called Secure Conversation and Access
("SCA") option is more difficult to deploy since requires modification of
MUA's.  That's why it is an option.  Without the additional requirements
its difficult to see how unmodified MUA's could honor the header
propagation requirement.  We believe an appropriate deployment strategy is
to incrementally take on pieces of this protocol starting from a fairly
easily achievable baseline.

Anyway, if the idea behind MSMD IMAP command survives, it should be done
> with ENABLE MSMD instead.
>
>
Thanks for the pointer to RFC5161.

-Wei

---

From: Martijn Grooten <[email-masked]>
Date: Wed, 16 Oct 2013 10:04:28 +0000 (UTC)

On Tue, 15 Oct 2013, Wei Chuang wrote:
> Request for discussion (draft-wchuang-msmd) of a proposal to secure 
> mail from eavesdropping and MitM attacks.  All comments welcome on this 
> thread.  I'm mentioning the proposal also to apps-discuss@ and saag@ 
> lists as this may be of interest to them too, but redirecting discussion 
> to this list so its all happening in one place.

Hi Wei,

Thanks for writing this down. I'm glad someone made the effort to come up 
with an actual proposal rather than just shout about email being broken. I 
think the document is well-written and clear on what it aims to achieve 
and how it intends to do that. I do have some issues and concerns though.

In general, I don't think the following is adequately addressed: if I 
don't want anyone but the intended recipient to read the email, then I 
shouldn't send the message without encrypting the body - and possibly 
shouldn't use email in the first place. If I can live with the limitations 
of the store-and-forward principle of email, would I want to risk the 
email not being delivered in case it can't be sent over secure 
connections?

What follows are some specific comments on the text.

1. Introduction

Here you rightly mention the limitations of SMTP TLS, even compared with 
HTTPS. I don't think this is addressed adequately enough further in the 
text.

2.3 DKIM

Do you want the signing domain to bear some relation to the 5321.From or 
5322.From addresses, the HELO domain, the PTR of the sending IP, or does 
it suffice for the email to have been DKIM signed?

2.6. IMAP/POP3

If my mail server server were to support this extension and refuses to let 
me download MSDM-messages through an unencrypted connection, is there any 
reason why it would let me download other messages that way?

3. TLS

I would be very wary of explicitly specifying which cryptographic 
protocols and which key lengths are to be used. Things tend to change. For 
all we know, we may soon find out that RC4, with all its limitations, is 
actually better than the alternatives. Or that new crypto-breaking 
techniques mean that we'll need keys of twice the current length to 
provide the same level of security.

(I also wonder if, given how limited the security is provided by sending 
email over secured channels, it actually makes sense to worry about RC4 
being somewhat broken.)

I do like the idea of using several tiers - but also wonder what the 
implications will be when you demand tier 2 or higher and I can only 
provide tier 1 security. Won't this just mean emails get bounced all over 
the Internet?

5. Recommendations

I don't claim to be an expert on user interfaces or in human understanding 
of tehnical protocols, but do you really think that an average user can
make an informed decision on whether to use an option that requires secure 
channels for email delivery, but still allows for the email to be read at 
many placed along delivery route, while generating the bounce in case 
one of the channels can't be adequately secured?

Martijn.

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Oct 2013 07:50:15 -0400

--On Wednesday, October 16, 2013 10:04 +0000 Martijn Grooten
<[email-masked]> wrote:

>...
> 5. Recommendations
> 
> I don't claim to be an expert on user interfaces or in human
> understanding of tehnical protocols, but do you really think
> that an average user can
> make an informed decision on whether to use an option that
> requires secure channels for email delivery, but still allows
> for the email to be read at many placed along delivery route,
> while generating the bounce in case one of the channels can't
> be adequately secured?

This continues to be my biggest concern about proposals of this
type.  By the time a plan of this nature gets translated and
interpreted to and by users, it will appear to be a promise of
"secure email" regardless of what the specification actually
says and what we understand to be the case.  For lots of
reasons, it is often far easier for attackers (or governments
engaged in surveillance activities) to compromise a delivery
server or mail store or intermediate relays than it is to
capture a message in transit.  

As Martijn points out (and I trust all of us know), hop-by-hop
transit encryption (TLS or otherwise) provides absolutely no
protection against compromised servers or relays, not just
because cleartext messages can be intercepted on such servers
but because it might be possible to "steal" enough cryptographic
information from such servers to compromise the incoming and/or
outgoing links as well.

That is certainly not an argument against doing TLS or otherwise
protecting the links because there is clearly a vunerability
there.  Whether it is worth going to extra trouble (and possibly
not having messages delivered that are otherwise ok) to promise
that such methods will be used is a more complex question that
is, indeed, closely related to what the users will perceive is
being promised.

    john

p.s. This is a mail transport function.  Layering considerations
argue strongly that the information should be entirely in the
envelope (SMTP transaction).   Requiring a relay to pull
information out of the headers, as the proposal appears to do,
is just a bad idea unless it is absolutely necessary for some
reason.

---

From: SM <[email-masked]>
Date: Wed, 16 Oct 2013 07:45:23 -0700

Hi Wei,
At 12:31 15-10-2013, Wei Chuang wrote:
>mail from eavesdropping and MitM attacks.  All comments welcome on 
>this thread.  I'm mentioning the proposal also to apps-discuss@ and 
>saag@ lists as this may be of interest to them too, but redirecting 
>discussion to this list so its all happening in one place.

There has been some discussion about opportunistic on the (IETF) 
perpass mailing list.  The problem, if I can call it that, is the 
assumption that "the destination will honor maintaining the MSMD 
protocol".  There have been several proposals previously which have 
tried to maintain that in various ways.

I suggest taking a look at RFC 6710.  If I recall correctly there was 
some discussion about why the assumptions being made might not work 
out well in general.  It may be possible to find out whether the 
"might not work out well" is incorrect as there are implementations 
of the specification.

I hope that my comments are not discouraging.  It is good to have a 
proposal such as draft-wchuang-msmd-00 as it provides a starting 
point to identify what could be done to get secure mail delivery.

I'll ask an unfair question.  Would you provide me with the assurance 
that I will be safe if I use a mail provider which supported the 
proposal?  I am aware that it is a high bar.  That's one of the 
drawbacks of using the word "secure".

Regards,
-sm

---

From: Paul Smith <[email-masked]>
Date: Wed, 16 Oct 2013 17:42:05 +0100

On 16/10/2013 11:04, Martijn Grooten wrote:
> understanding of tehnical protocols, but do you really think that an 
> average user can
> make an informed decision on whether to use an option that requires 
> secure channels for email delivery, but still allows for the email to 
> be read at many placed along delivery route, while generating the 
> bounce in case one of the channels can't be adequately secured?
This is my problem. I can see it being marketed as a 'way of sending 
secure email' rather than a 'way of getting more bounces than successful 
deliveries'.

It isn't going to make email totally 'secure' - but it will improve it 
so I can see the advantage of the idea. However, I worry that end users 
will just tick the box by default (who would choose to use the 'send 
insecure email' option?) and then the people who manage the servers will 
be deluged with problem reports about emails not being delivered.

At what level of 'secrecy' would you expect this to be used? For 'really 
top secret messages', you'd be daft to use this, as it's not totally 
secure. For 'my holiday photo messages' you'd be daft to use it, as 
they're not secret, and you'd really rather the message got through than 
caring that some CIA agent got to waste time looking at your picture of 
a mountain.

-

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 16 Oct 2013 19:09:10 +0200

On Tue 15/Oct/2013 21:31:17 +0200 Wei Chuang wrote:
> eavesdropping and MitM attacks.  All comments welcome on this thread.

Something similar to that is implemented in Courier-MTA, since a
couple of years ago IIRC.  It is shortly described here:
http://www.courier-mta.org/draft-varshavchik-security-smtpext.txt

(There are specific instruction for setting it up here:
http://www.courier-mta.org/install.html#esmtpsecurity )

I cannot tell much more, because, although that's my favorite SMTP
package, I never enabled that extension.

On Wed 16/Oct/2013 12:04:28 +0200 Martijn Grooten wrote:
> I do like the idea of using several tiers - but also wonder what
> the implications will be when you demand tier 2 or higher and I can
> only provide tier 1 security. Won't this just mean emails get
> bounced all over the Internet?

+1, I'd suggest to describe the SMTP feature separately.  A further
RFC can then take care of putting together all security related facets
of email in order to build a secure framework.  The latter
specification would be similar in spirit to a prior attempt at
standardizing Certified Electronic Mail:
http://tools.ietf.org/html/draft-gennai-appsawg-cem

Ale

---

From: Wei Chuang <[email-masked]>
Date: Wed, 16 Oct 2013 10:30:06 -0700

Hi Martijn,

On Wed, Oct 16, 2013 at 3:04 AM, Martijn Grooten <
[email-masked]> wrote:

>> thread.  I'm mentioning the proposal also to apps-discuss@ and saag@lists as this may be of interest to them too, but redirecting discussion to
>> this list so its all happening in one place.
>>
>
> Hi Wei,
>
> think the document is well-written and clear on what it aims to achieve and
> how it intends to do that. I do have some issues and concerns though.
>
> of the store-and-forward principle of email, would I want to risk the email
> not being delivered in case it can't be sent over secure connections?
>

This argument ignores the argument that there are measures to make the life
of the eavesdropper much more difficult.  I would argue that instead of
absolutist stance, that if one can make it difficult enough, then
eavesdroppers/adversary will 1) find their costs go up and number of
campaigns they can afford will drop, and/or 2) have to find somewhere else
to attack.  I would also differ in that the email would not be delivered.
 If there is a security bounce, the user will be informed that their
requested security level was not met.  It is up to them to figure out
another secure delivery method and/or communication method.  But at least
unlike the current model, the user has the choice.

> HTTPS. I don't think this is addressed adequately enough further in the
If you could expand on this, I would appreciate it.  The body of the
document was already getting long IMO but I would be happy the address
this.

> 2.3 DKIM
You last point applies is the closest to what's in the proposal though it
sounds like you have arguments that this should be changed that I would
like to explore.  The proposal requests that the MSMD header should be
signed at least leaving the rest as implementation dependent.  The
justification is to build on existing DKIM implementation with a minimum
requirement (and at some future point revisit DKIM via options).

> 5322.From addresses,

the HELO domain, the PTR of the sending IP, or does it suffice for the
> email to have been DKIM signed?
>

Request to expand on this...  i.e. which is preferred and why?

> reason why it would let me download other messages that way?

The difference is that MUA can let you reply or forward while typically a
downloaded mail is not transformed into to new derived content that gets
redelivered.

> techniques mean that we'll need keys of twice the current length to provide
> the same level of security.
>

This is the justification for using tiers, to make it easier to adjust as
TLS best practices changes.  The reason for specifying TLS minimum
parameters, is that the weak TLS configurations is worrisome.  Key size is
one example of this.  I understand that RC4 might be controversial.

> provide tier 1 security. Won't this just mean emails get bounced all over

It will mean that there will be more bounced mail.  But I would argue that
this is what the user desired as described above.

> many placed along delivery route, while generating the bounce in case one
> of the channels can't be adequately secured?

Yes this is an important argument, one that was argued over here as well,
and not fully resolved to everyone's satisfaction.

I argue that yes corporate and power users would find this useful
initially, and as the ecosystem moves to securing mail delivery, this could
be turned on by default for everyone else.  There would also have to be
education of users as well.

-Wei

>
>
> Martijn.
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>
>

---

From: Timo Sirainen <[email-masked]>
Date: Wed, 16 Oct 2013 19:40:46 +0200

On 16.10.2013, at 19.30, Wei Chuang <[email-masked]> wrote:

> I do like the idea of using several tiers - but also wonder what the implications will be when you demand tier 2 or higher and I can only provide tier 1 security. Won't this just mean emails get bounced all over the Internet?
> 
> It will mean that there will be more bounced mail.  But I would argue that this is what the user desired as described above.

Bounces could be avoided by doing a check immediately when "send securely" checkbox is clicked. If the destination SMTP server doesn't advertise MSMD capability, the UI would immediately show that it's not possible to send the mail securely.

---

From: Wei Chuang <[email-masked]>
Date: Wed, 16 Oct 2013 11:17:13 -0700

Hi John,

> says and what we understand to be the case.  For lots of

I agree, and if adopted and deployed, it will require user education/and
careful consideration during deployment not to overstate what this does.

> information from such servers to compromise the incoming and/or

Do you mean TLS downgrade, poor ciphers or stealing certs?   or do you mean
employing some sort of backdoor?  The former two issues are dealt with in
the proposal where TLS is specified and checked.  As for detecting and
mitigating bad certs, I believe this is in discussion by the IETF.  A
future TLS tier 3 could be specified as best practices for cert protection
is developed.  (We think this will be certificate transparency, which is
mentioned in the proposal, but is left open as to be determined by the
community)

Agreed that this proposal does nothing for subverted MTAs.  One argument
though is that likely this is not at all common, and for the vast majority
of email, not going to be an issue.  Only solution here is I think you're
implying is end-to-end email encryption.  I should mention that the
proposal do nothing to preclude it, and I would argue its complementary as
TLS protects metadata during delivery.

> is, indeed, closely related to what the users will perceive is

I would differ here.  As pointed out in the proposal's motivation, leaving
mail delivery as clear text mail makes mail delivery the weakest link for
many mail providers.  It invites adversaries with lots of resources to
attack this point as other interfaces become much more hardened.

-Wei

---

From: "John Levine" <[email-masked]>
Date: 16 Oct 2013 18:23:40 -0000

>careful consideration during deployment not to overstate what this does.

Given how complex this proposal is, I'm wondering whether it wouldn't
be better to do something entirely within the channel, e.g., whole
message encryption using DKIM keys.  It would accomplish pretty much
the same thing, while requiring much less of intermediate mail
systems.

R's,
John

---

From: Wei Chuang <[email-masked]>
Date: Wed, 16 Oct 2013 11:27:16 -0700

Hi  Paul,

On Wed, Oct 16, 2013 at 9:42 AM, Paul Smith <[email-masked]> wrote:

>> secure channels for email delivery, but still allows for the email to be
>> read at many placed along delivery route, while generating the bounce in
>> case one of the channels can't be adequately secured?
>>

As noted before, I don't have a fully satisfactory answer.  Perhaps:
1) consumer education
2) deployment to sophisticated users e.g. corporate users first
wait for the majority of the ecosystem to deploy SMTP STARTTLS
3) then deploy to all users

-Wei

> It isn't going to make email totally 'secure' - but it will improve it so
> I can see the advantage of the idea. However, I worry that end users will
> just tick the box by default (who would choose to use the 'send insecure
> email' option?) and then the people who manage the servers will be deluged
> with problem reports about emails not being delivered.
>
> secure. For 'my holiday photo messages' you'd be daft to use it, as they're
> not secret, and you'd really rather the message got through than caring
> that some CIA agent got to waste time looking at your picture of a mountain.
>
>
>
> -
>
> ______________________________**_________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/ietf-smtp<https://www.ietf.org/mailman/listinfo/ietf-smtp>
>

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 16 Oct 2013 18:29:33 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of John Levine
> Sent: Wednesday, October 16, 2013 2:24 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [ietf-smtp] Request for discussion of Mandatory Secure Mail
> Delivery proposal (draft-wchuang-msmd)
> 
> >I agree, and if adopted and deployed, it will require user
> >education/and careful consideration during deployment not to overstate
> what this does.
> 
> Given how complex this proposal is, I'm wondering whether it wouldn't be
> better to do something entirely within the channel, e.g., whole message
> encryption using DKIM keys.  It would accomplish pretty much the same
> thing, while requiring much less of intermediate mail systems.
> 
> R's,
> John

John,

Presumably you are referring to using the destination domain DKIM keys to encrypt (please correct me if I am wrong). This may work well at the domain level (I'm assuming alignment) but there may be operational issues when the receiving MTA is different from the domains sending (signing) servers. I think using DKIM is certainly worth examining. During the DKIM working group discussions we had discussed the possibility of leveraging it beyond the initial intended purpose.

Mike

---

From: Martijn Grooten <[email-masked]>
Date: Wed, 16 Oct 2013 18:29:46 +0000 (UTC)

On Wed, 16 Oct 2013, Wei Chuang wrote:
> This argument ignores the argument that there are measures to make the
> life of the eavesdropper much more difficult.  I would argue that
> instead of absolutist stance, that if one can make it difficult enough,
> then eavesdroppers/adversary will 1) find their costs go up and number
> of campaigns they can afford will drop, and/or 2) have to find somewhere
> else to attack.

Hi Wei,

thanks for your comments.

I think we all agree that making an attacker's life harder is a good idea. 
Which is why we've all said that using TLS is a rather good idea. But your 
proposal has the potential (or, in my view, likely) side-effect of 
breaking email delivery, while suggesting senders have more control over 
the security of the message in transit than they really have.

Also, seeing as the text refers to "recent news": it's not my impression
that the NSA would give up if only we made life too expensive for them.

> I would also differ in that the email would not be delivered.  If there
> is a security bounce, the user will be informed that their requested
> security level was not met.  It is up to them to figure out another
> secure delivery method and/or communication method.  But at least unlike
> the current model, the user has the choice.

Only as far as they can trust whichever entity deals with the message when
it's in transit to speak the truth.

(I also think thay making people try something in a secure way and then
giving them the option to try it in an insecure way is bad for security in
general. Even if it kind of makes sense here - after all, there isn't much
guaranteed security in the first place.)

>       Here you rightly mention the limitations of SMTP TLS, even
> compared with HTTPS. I don't think this is addressed adequately enough
> further in the text.
>

The text says

     "Moreover SMTP TLS is more susceptible to active attack such as Man-
    in-the-Middle (MitM) than web client security.  Attacks such as
    certificate forgery or TLS downgrade have been mitigated with
    certificate pinning [2] and HSTS [RFC6797].  No such mechanism exists
    today with SMTP TLS."

which I read as an argument why TLS isn't all that fantastic when used for
SMTP. Then the text goes on to explain how we should use TLS for email. I
think it should be clear about what threats this protects against and what
it doesn't.

>       Do you want the signing domain to bear some relation to the
> 5321.From or 5322.From addresses, the HELO domain, the PTR of the
> sending IP, or does it suffice for the email to have been DKIM signed?
>

I'm not really sure. I think DKIM-signing emails is a good idea in
general, and I'm pretty agnostic as to who signs which emails - as long as
it happens in a somewhat consistent way.

In this case I'm just not sure - your scheme doesn't look into the
question of authenticating the sender. If it did, then having it signed by
the domain in the 5322.From address could provide some (extra)
authentication - but I'm not sure if I would want to make that a 
requirement.

> This is the justification for using tiers, to make it easier to adjust
> as TLS best practices changes.  The reason for specifying TLS minimum
> parameters, is that the weak TLS configurations is worrisome.  Key size
> is one example of this.  I understand that RC4 might be controversial.  

My point is that we all agree that weak TLS isn't a good thing. I just
don't think that hardcoding what is good security (e.g. ECC with key size
>= 250) is a good idea, as new discoveries might change our understanding
of what good key sizes are. I'd rather not see the IETF have to go through
the process of updating lots of RFCs, just because ECC turns out to be
easier to break than previously assumed.

(Disclaimer: I haven't read a lot of RFCs that deal with cryptography. 
Perhaps they do have minimum key lengths hardcoded into them - in which 
case probably for good reasons.)

> the implications will be when you demand tier 2 or higher and I can only 
> provide tier 1 security. Won't this just mean emails get bounced all 
> over the Internet?
>
>
> It will mean that there will be more bounced mail.  But I would argue 
> that this is what the user desired as described above.  

Assuming they understand what they do. I find it hard enough it imagine 
cases where someone would be happy for an email to be sent through the 
store-and-forward principle of SMTP, but would rather have it bounce than 
be sent over unencrypted connections. I find it even harder to imagine a 
case where someone is still OK with that store-and-forward principle, but 
doesn't want the email to be sent if not very strong encryption can be 
used in transit.

> initially, and as the ecosystem moves to securing mail delivery, this 
> could be turned on by default for everyone else.  There would also have 
> to be education of users as well.

I don't want to be one of these people who goes on about how users can't 
be educated, but let's it's not going to be easy. And some of the things 
you will tell people seem to contradict other things we, as the security 
community, will continue to tell people.

(I do think that there may be a point where 95% of email traffic, 
including IMAP and POP3, is sent over TLS. By that time, we may want to 
look into making MTAs refuse to send email to the other 5%. But we're 
nowhere near there yet.)

Martijn.

---

From: Wei Chuang <[email-masked]>
Date: Wed, 16 Oct 2013 11:37:21 -0700

Hi Alessandro,

On Wed, Oct 16, 2013 at 10:09 AM, Alessandro Vesely <[email-masked]> wrote:

> from

Thanks for the pointer Alessandro.  Very nicely written concise I-D.  There
are some differences:
1) lacks option mechanism
2) lacks spec for tightening TLS spec/usage

> http://tools.ietf.org/html/draft-gennai-appsawg-cem

I see your point, but we're making the argument that as MSMD provides a
kind of certification, and we would like to increase the standing of TLS,
there's benefit in moving TLS and SMTP spec together.

-Wei

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Oct 2013 14:40:29 -0400

Noting that SM and Paul Smith have made comments about the UI
and threat model problems that parallel mine, I won't repeat
myself about that.  But one additional observation that I should
have included earlier:

--On Wednesday, October 16, 2013 10:30 -0700 Wei Chuang
<[email-masked]> wrote:

>> I do like the idea of using several tiers - but also wonder
>> what the implications will be when you demand tier 2 or
>> higher and I can only provide tier 1 security. Won't this
>> just mean emails get bounced all over the Internet?
> 
> It will mean that there will be more bounced mail.  But I
> would argue that this is what the user desired as described
> above.

In general, the only thing that users (a distinct from very
technical and knowledgeable people who also use email) desire is
that the mail go through.  They may also desire that it go
through securely and privately but, if one gets down to "if that
can't happen, what general policy would you prefer", most of
them will tune out and most of those who don't will tell you
that it differs case by case and then get impatient if you make
them specify per-message options.  

Most of them will also tell you that, if the message doesn't get
delivered (that is part of "mail goes through"), they want an
absolute guarantee that they find out about it rather than
assuming the recipient got a message that recipient never saw.

That is where things get really hard because we have moved into
a world in which concern about blowback attacks causes a lot of
mail to be discarded rather than bounced back to the originator.
It seems to me that you can't control that behavior.  At least I
didn't find anything in the current draft that addresses it.
It would be interesting if a server that advertises MSMD or a
client that requested it would be required to guarantee to
actually generate and transmit bounce messages rather than
discarding bad mail, but I haven't attempted to do enough case
analysis to guess whether that would be effective.

Given where you and your colleagues work, it may be appropriate
to note that, empirically, gmail is one of the systems that
cannot be relied upon to generate and deliver NDNs.

With the current spec as I understand it, you can continue to
say "bounce", since that is what you intend but, in thinking
about the protocol, you should understand every instance of
"user gets a bounce message" as "user gets a bounce message
unless that notification is discarded or disappears, which will
happen sometimes for no obvious reason".

    john

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Oct 2013 15:38:52 -0400

--On Wednesday, October 16, 2013 11:17 -0700 Wei Chuang
<[email-masked]> wrote:

>...
> Do you mean TLS downgrade, poor ciphers or stealing certs?
> or do you mean employing some sort of backdoor?  The former
> two issues are dealt with in the proposal where TLS is
> specified and checked.  As for detecting and mitigating bad
> certs, I believe this is in discussion by the IETF.  A future
> TLS tier 3 could be specified as best practices for cert
> protection is developed.  (We think this will be certificate
> transparency, which is mentioned in the proposal, but is left
> open as to be determined by the community)

I meant stolen certs, backdoors, or direct compromises of a mail
store or mail queue in which the messages may be sitting around
in the clear before being relayed or delivered.   See below.
 
> Agreed that this proposal does nothing for subverted MTAs.
> One argument though is that likely this is not at all common,
> and for the vast majority of email, not going to be an issue.

Actually, I suggest that it has historically been a lot more
common than subverted links, especially subverted backbone
links.  Remember that both of the following are instances of a
subverted MTA (or mail store) as far as privacy of the messages
are concerned:

	(1) Some governmental agency or similar body comes along
	with adequate documentation, claimed authority, and/or
	threats and says "please dump all messages your receive
	and give them to us", "please dump all messages sent to
	or from Elmer Fudd between now and the end of the week",
	or anything in between.
	
	(2) Some entity associated with the one that operates
	the mail service scans the contents of all messages
	sent, received, or stored there for purposes of service
	improvement, user interest detection for advertising
	purposes, or data mining and database construction.  

Note that neither of those is a technical attack and that it
makes no difference to either whether the actions are legal or
not; allowed by policies to which the user has agreed or not.
The only issue is that the messages are sitting around in the
clear and available to anyone who, with permission or not, gets
access to and control over the MTA or mail store.

> Only solution here is I think you're implying is end-to-end
> email encryption.  I should mention that the proposal do
> nothing to preclude it, and I would argue its complementary as

It protects a small amount of metadata.  How much depends on
circumstances and, in particular, whether the machines involved
support enough users each to make speculation about who is
sending messages to whom useless.

First, yes, end-to-end encryption (really content encryption) is
the only solution if one doesn't trust the relay server or mail
store operators, the security of those servers, or the
environment in which they operate.  It also has the advantage of
not being subject to the complex handoff and "get partway and
bounce" issues that you and others have commented on.  It think
that is part of what Martjin, myself, and others, said.  We all
know the problems with it even though we regularly tend to
forget that (end to end) secure messages can be exchanged among
cooperating parties by the use of old-fashioned symmetric
cryptography with shared secrets and even one-time pads (and
maybe, as we try to figure out how to make public key methods
work, we should have an Internet standards for that).  

As I said earlier, I don't want to discourage your efforts in
any way.  I think you just need to be very clear about the
threat model and what problems are actually being solved.

>> That is certainly not an argument against doing TLS or
>> otherwise protecting the links because there is clearly a
>> vunerability 
>> not having messages delivered that are otherwise ok) to
>> promise that such methods will be used is a more complex
>> question that is, indeed, closely related to what the users
>> will perceive is being promised.

> I would differ here.  As pointed out in the proposal's
> motivation, leaving mail delivery as clear text mail makes
> mail delivery the weakest link for many mail providers.  It
> invites adversaries with lots of resources to attack this
> point as other interfaces become much more hardened.

With no disrespect, a matter of opinion.   Or perhaps it is a
matter of how one thinks about the threat model.  Hardening a
server technically is of little use if someone from the
government, police, etc., can show up with legal papers and/or
threats and obtain content that way.

best,
    john

---

From: "John Levine" <[email-masked]>
Date: 16 Oct 2013 19:45:13 -0000

>Presumably you are referring to using the destination domain DKIM keys to encrypt ...

Sort of.  Here's a straw man I sent to one of the MAAWG lists last
month:

Sender fetches TXT _encrypt._domainkey.recipient.com.  If it exists,
it uses the p= public key to encrypt the whole message, embeds it as a
MIME application/dkim-encrypted body in a new message to the original
address, and sends it off.

Recipient MTA receives message, and if it has an
application/dkim-encrypted body, decrypts and unwraps it and delivers
the original message.  Intermediate MTAs don't have to do anything
special.

Bonus anti-traffic analysis hack: new wrapped message is always sent
to: [email-masked] with subject: encrypted message, real
recipient and subject recovered from Subject: and DKIM-Encrypted-To:
headers in the encapsulated message.

Key rotation and management isn't a big deal since, unlike regular
DKIM, the decoding keys aren't published.

This gets close to end to end encryption, without a lot of new
mechanism.  A suitably clued in sender MUA could do the encryption
before submission, or any other MSA or MTA along the line could do it.
The unwrapping has to happen at the target MTA since there is one key
for the entire domain, and with the postmaster hack, it needs to
unwrap the message to find out who it's for.

If you wanted to decorate this with extra hints about only display
the message via https/imaps/pops, it wouldn't be hard.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Oct 2013 15:50:44 -0400

--On Wednesday, October 16, 2013 19:40 +0200 Timo Sirainen
<[email-masked]> wrote:

> Bounces could be avoided by doing a check immediately when
> "send securely" checkbox is clicked. If the destination SMTP
> server doesn't advertise MSMD capability, the UI would
> immediately show that it's not possible to send the mail
> securely.

As long as there isn't a situation in which the first-hop relay
advertises MSMD but some subsequent one does not.  In that case,
it will be very hard to avoid either a bounce or lost mail.
When we did a similar analysis for EAI, we came to the
conclusion that most of the problems could be eliminated by
being sure that no less-capable MTA was configured in the MX
collection for a given destination (and the submission server
talks only to servers for the destination, with no intermediate
"smart hosts" involved).  But a more complicated capability
matrix will make that harder to guarantee.

   john

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Wed, 16 Oct 2013 13:38:44 -0700

> headers in the encapsulated message.

Use RFC 2442? Dan Newman had intended from the start that RFC 2442 could 
be combined with "something else" to provide end-to-end encryption of 
the envelope.

<csg>

---

From: John R Levine <[email-masked]>
Date: Wed, 16 Oct 2013 17:03:00 -0400 (EDT)

> Use RFC 2442? Dan Newman had intended from the start that RFC 2442 could be 
> combined with "something else" to provide end-to-end encryption of the 
> envelope.

I suppose so, although it seems that just sticking Return-Path: and 
Delivered-To: lines at the top of the message is all it needs to do before 
encrypting.

With 2442, either it'd be doubly wrapped, an application/batch-SMTP inside 
an application/dkim-encrypted. or it'd be a modified batch-SMTP, in which 
case it's probably not worth the effort unless people want to be able to 
send wrapped batches of messages.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Oct 2013 17:14:16 -0400

--On Wednesday, October 16, 2013 19:45 +0000 John Levine
<[email-masked]> wrote:

> Sort of.  Here's a straw man I sent to one of the MAAWG lists
> last month:
> 
> Sender fetches TXT _encrypt._domainkey.recipient.com.  If it
> exists, it uses the p= public key to encrypt the whole
> message, embeds it as a MIME application/dkim-encrypted body
> in a new message to the original address, and sends it off.
>...

John,

Interesting idea as long as both sender and recipient trust the
delivery server.  For reasons identified in one of my earlier
notes today, that might not be wise... but that depends entirely
on one's threat model, what threats are considered important,
and who one chooses to trust.

Specifically, mail sent to you or me and received one our
personally-operated mail servers falls into a rather different
category than mail sent to
SuperGiantEmailProviderInLowerSlobbovia with whom one might have
issues about either the business model of that provider or what
deals they might have with the Slobbovian secret police.

But _please_ don't use Postmaster.  Not only is the appropriate
use of that mailbox pretty well spelled out (and does not
include acting as a decryption and redelivery service) but it is
handled specially in many installations in ways that would
interfere with your model.  Since rather special recipient
processing would be needed anyway, it seems to me that there
would be little harm in inventing a new specialized address,
like "encrypted@...".  If a site already uses that address,
they'd have to adapt before advertising the keys, etc., but that
shouldn't be a really big deal.

 best,
   john

---

From: Brandon Long <[email-masked]>
Date: Wed, 16 Oct 2013 14:32:26 -0700

> threats and obtain content that way.

For the TLA's in the current news, it seems obvious that there's a
difference in capability between "able to snoop on email across any given
two endpoints regardless of ability to serve a subpoena/warrant or get a
warrant for XXX million different accounts" and the published numbers of
actual NSL's issued.

There are obviously countries which are more "open" about their
surveillance state, but large mail providers are less likely to be located
there or at least less likely to be used by non-citizens of those states.

This of course leads back to the most challenging part of this that's
already been brought up, which is that this is "more" secure, but still has
a gaping hole to what a consumer would consider secure, which makes it
problematic to expose this to the consumer at all.

Brandon

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 16 Oct 2013 23:34:58 +0200

Not quite true. The sender often sees some anti-spam third party's server, and only the anti-spam company talks to the real target.

Arnt

---

From: John R Levine <[email-masked]>
Date: Wed, 16 Oct 2013 17:35:35 -0400 (EDT)

> delivery server.

Well, sure, but my thought here is that it gives you about 90% of what the 
Google proposal does for about 20% of the cost.  If you don't trust the 
delivery server, you have to unwrap in the recipient MUA, which means per 
user keys, and we've reinvented PGP and S/MIME.

> But _please_ don't use Postmaster.

Keep in mind that the idea here is that mail with a dkim-encrypted body is 
unwrapped and readdressed before delivery, so the mailbox doesn't matter 
much.

Having recently reviewed the list of addresses in RFC 2142, I'm leaning 
toward uucp@.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: "John Levine" <[email-masked]>
Date: 16 Oct 2013 21:41:53 -0000

>Not quite true. The sender often sees some anti-spam third party's server, and only the
>anti-spam company talks to the real target.

You mean, like Postini?

R's,
John

---

From: Timo Sirainen <[email-masked]>
Date: Wed, 16 Oct 2013 23:42:35 +0200

> Not quite true. The sender often sees some anti-spam third party's server, and only the anti-spam company talks to the real target.

There are of course reasons for why checking only the first MX server's MSMD capability might not be enough, but hopefully people will implement the systems in a good way that makes it a very unlikely event. The antispam servers can do this just by having 2 different configurations (IPs) where one advertises MSMD for their end customers that do implement it, and another one that don't, and advertise MSMD accordingly for those IPs.

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Oct 2013 18:19:57 -0400

--On Wednesday, October 16, 2013 17:35 -0400 John R Levine
<[email-masked]> wrote:

>> Interesting idea as long as both sender and recipient trust
>> the delivery server.
> 
> Well, sure, but my thought here is that it gives you about 90%
> of what the Google proposal does for about 20% of the cost.
> If you don't trust the delivery server, you have to unwrap in
> the recipient MUA, which means per user keys, and we've
> reinvented PGP and S/MIME.

Absolutely to both.  And the Wei Chuang et al proposal requires
one to trust the delivery server and every relay server along
the path, so it is no better (and probably worse) along that
dimension.

> Keep in mind that the idea here is that mail with a
> dkim-encrypted body is unwrapped and readdressed before
> delivery, so the mailbox doesn't matter much.

The mailbox doesn't matter much, but Postmaster does because
some systems intercept that address and give it special
treatment _very_ early in processing, occasionally even before
"mailbox" in the usual sense becomes relevant.  Independent of
what 2142 and other things say, it (and, atypically, its
case-insensitive variants) is the only recipient address
reserved and required from RFC 821 forward.

> Having recently reviewed the list of addresses in RFC 2142,
> I'm leaning toward uucp@.

:-)
But wfm.  Anything but Postmaster.

best,
    john

---

From: Richard Clayton <[email-masked]>
Date: Thu, 17 Oct 2013 01:30:11 +0100

In message <[email-masked]>, John Levine
<[email-masked]> writes

>it uses the p= public key to encrypt the whole message,

erk ... you don't generally wish to use public keys on whole messages,
the planet is getting pretty warm already -- there are practical reasons
why existing schemes involve encrypting with a stream cipher with a
randomly chosen session key and then just using the public key system
for transmitting the session key.  This also allows you to disclose just
the session key under some levels of legal duress -- keeping your main
key secret.

>mechanism.

there are already schemes for putting keys into DNS -- here's a write up
[there may be better discusssions, this was just the first substantive
discussion that my searching threw up] that covers three schemes (and
which points at RFCs where they exist)

        http://gushi.livejournal.com/524199.html

Now I understand that there's more than just encryption to the proposal
(in particular the way that out of the box PGP doesn't hide Subject
header fields surprises many people), but staying closer to existing
proposals rather than trying to add this onto DKIM seems wiser

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

From: John R Levine <[email-masked]>
Date: Wed, 16 Oct 2013 23:00:53 -0400 (EDT)

> for transmitting the session key.

Seems it'd be easy enough to put a band-aid on that.  The outgoing MTA 
generates a random key for a block cipher, and the 
application/dkim-encrypted is the session key encrypted under the public 
key, followed by the message encrypted under the session key, perhaps with 
some intevening random crud since the beginning of a message is often a 
known plaintext.

I don't purport to know enough crypto to design something secure, but I 
gather this is similar to what PGP does.

Regards,

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Wed, 16 Oct 2013 23:57:52 -0400

At 01:30 +0100 on 10/17/2013, Richard Clayton wrote about Re: 

>for transmitting the session key.

How about doing the message encryption with the stream cipher and use 
the public key to encrypt it as a separate MIME part (ie: The message 
is multi-part with the key MIME part and the encrypted MIME part)?

---

From: Russ Allbery <[email-masked]>
Date: Wed, 16 Oct 2013 21:58:18 -0700

"Robert A. Rosenberg" <[email-masked]> writes:

> At 01:30 +0100 on 10/17/2013, Richard Clayton wrote about Re: [ietf-smtp]
> DKIM encryption, was Request for discussion:

> How about doing the message encryption with the stream cipher and use the
> public key to encrypt it as a separate MIME part (ie: The message is
> multi-part with the key MIME part and the encrypted MIME part)?

Coming up with a secure encryption protocol is hard, with a lot of
potential traps and caveats.  I recommend reusing RFC 3156 and the
underlying OpenPGP format as much as possible to avoid incorrectly
reinventing a wheel.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 17 Oct 2013 10:23:49 +0200

On Wed 16/Oct/2013 23:35:35 +0200 John R Levine wrote:
> 
> Having recently reviewed the list of addresses in RFC 2142, I'm
> leaning toward uucp@.

What's wrong in having a ra= tag telling the domain-specific local
part of that service, in the TXT at _encrypt._domainkey.example.com?

Ale

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 17 Oct 2013 10:52:26 +0200

On Wed, Oct 16, 2013 at 11:42:35PM +0200, Timo Sirainen wrote:
> There are of course reasons for why checking only the first MX
> server's MSMD capability might not be enough, but hopefully people
> will implement the systems in a good way that makes it a very unlikely
> event. The antispam servers can do this just by having 2 different
> configurations (IPs) where one advertises MSMD for their end customers
> that do implement it, and another one that don't, and advertise MSMD
> accordingly for those IPs.

True. I should have thought of that. Forgive my blathering.

Arnt

---

From: Wei Chuang <[email-masked]>
Date: Thu, 17 Oct 2013 10:02:55 -0700

On Wed, Oct 16, 2013 at 7:45 AM, SM <[email-masked]> wrote:

> There has been some discussion about opportunistic on the (IETF) perpass
> mailing list.  The problem, if I can call it that, is the assumption that
> "the destination will honor maintaining the MSMD protocol".  There have
> been several proposals previously which have tried to maintain that in
> various ways.
>
> I suggest taking a look at RFC 6710.  If I recall correctly there was some
> discussion about why the assumptions being made might not work out well in
> general.  It may be possible to find out whether the "might not work out
> well" is incorrect as there are implementations of the specification.
>

Agreed this was useful to look at.  Was the I-D for RFC 6710 discussed on
this mailing list? or if you happen to know the I-D name, I can try to
search for it. The discussions would be interesting.

If this is a pattern, I wonder if a common platform could be built to
support specifying behavior at mail delivery and having the propagate along
with the message and derivatives?  This is what this proposal is trying to
do for the more specific mail delivery security context.

> proposal such as draft-wchuang-msmd-00 as it provides a starting point to
> identify what could be done to get secure mail delivery.
>
> I'll ask an unfair question.  Would you provide me with the assurance that
> I will be safe if I use a mail provider which supported the proposal?

I would answer with something wishy washy like "more safe".

>  I am aware that it is a high bar.  That's one of the drawbacks of using
> the word "secure".
>

Its conditioned by "mail delivery".

> -sm

thanks for the pointers,
-Wei

---

From: Wei Chuang <[email-masked]>
Date: Thu, 17 Oct 2013 10:13:18 -0700

> the same thing, while requiring much less of intermediate mail

FWIW I think your DKIM idea is really good, i.e. provides protection over
intermediary hops that using TLS alone does not provide.  I look forward to
see how the DKIM encryption thread develops.

I would point out that much of the complexity is worrying about situations
that could leak information such as the recipient replying or forwarding to
the message, and what to do about bounce messages.  It also deals
infrastructure issues such as mailing lists and allowing the protocol to
adapt as the crypto technology changes (as TLS is changing rapidly).  I
would argue that a lot of the ideas from this I-D could apply to those
situation for your proposal.

-Wei

---

From: Martijn Grooten <[email-masked]>
Date: Thu, 17 Oct 2013 17:18:44 +0000 (UTC)

> the session key under some levels of legal duress -- keeping your main

These are good points, but, as John said, it won't be hard to make this 
work. I do think it is good to note that the system doesn't provide 
perfect forward secrecy though (but I also think that's pretty much 
impossible with email).

> proposals rather than trying to add this onto DKIM seems wiser

But doesn't DKIM also contain a scheme for putting keys into DNS? I don't 
see what these schemes offer that DKIM can't do, other than that they all 
focus on putting your personal key into DNS. Apart from the fact that DKIM 
already provides such a scheme and various software packages exist to 
extract the public key from the DNS record, by focusing on organisations 
rather than individuals, John's plan should scale well, for the same 
reason that DKIM is widely used, but PGP-signing email isn't.

Of course, it only provides organisation-to-organisation encryption, 
rather than end-to-end encryption. But this is already a big leap forward 
from the current situation, or from various TLS-or-bounce proposals I've 
seen.

It's also good to note that because of web gateways, for many 
organisations HTTPS only provides organisation-to-organisation encryption 
anyway.

Another advantage of using DKIM, apart from the existence of software that 
knows how to read keys, is that it may be easier to 'sell'. Seeing as 
every man and his dog seem to be working on a plan for post-PRISM email, 
this may be rather important.

Anyway, I think this deserves being written down.

Martijn.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Oct 2013 10:56:59 -0700

> Anyway, I think this deserves being written down.
I'm in for spec writing and doing implementation experiments.

-MSK

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 17 Oct 2013 20:04:39 +0200

On 10/17/2013 07:18 PM, Martijn Grooten wrote:
> These are good points, but, as John said, it won't be hard to make 
> this work. I do think it is good to note that the system doesn't 
> provide perfect forward secrecy though (but I also think that's pretty 
> much impossible with email).
>
> But doesn't DKIM also contain a scheme for putting keys into DNS? I 
> don't see what these schemes offer that DKIM can't do, other than that 
> they all focus on putting your personal key into DNS. Apart from the 
> fact that DKIM already provides such a scheme and various software 
> packages exist to extract the public key from the DNS record, by 
> focusing on organisations rather than individuals, John's plan should 
> scale well, for the same reason that DKIM is widely used, but 
> PGP-signing email isn't.
>
> rather than end-to-end encryption. But this is already a big leap 
> forward from the current situation, or from various TLS-or-bounce 
> proposals I've seen.
>
> organisations HTTPS only provides organisation-to-organisation 
> encryption anyway.
>
> Another advantage of using DKIM, apart from the existence of software 
> that knows how to read keys, is that it may be easier to 'sell'. 
> Seeing as every man and his dog seem to be working on a plan for 
> post-PRISM email, this may be rather important.
>

+1

There might be a potential 'conflict' however between a) the original 
idea of Wei, where the end-user can request from within his _MUA_ for a 
secure transport and b) the way DKIM operates, in general between 
boundary MTA's of sending ADMD and receiving ADMD. For example: the MUA 
can check for the existence of public keys in the domain of the intended 
recipient, but it doesn't know whether the MSA or his ADMD-boundary MTA 
and/or the receiving ADMD boundary MTA will support the requested level 
of security.

As for the trustworthiness of the receiving domain publishing its key: 
here we might benefit from the work of the repute workgroup: a better 
reputation might indicate (or might be interpreted) as more 
trustworthiness. However, it is far too simplistic to say 
'trustworthiness=reputation'.

/rolf

---

From: Steve Atkins <[email-masked]>
Date: Thu, 17 Oct 2013 11:23:43 -0700

On Oct 17, 2013, at 10:56 AM, "Murray S. Kucherawy" <[email-masked]> wrote:

> On Thu, Oct 17, 2013 at 10:18 AM, Martijn Grooten <[email-masked]> wrote:

+1

Cheers,
  Steve

---

From: Dave Crocker <[email-masked]>
Date: Fri, 18 Oct 2013 07:26:30 +1300

On 10/18/2013 6:56 AM, Murray S. Kucherawy wrote:
> On Thu, Oct 17, 2013 at 10:18 AM, Martijn Grooten
> <[email-masked] <mailto:[email-masked]>> wrote:
>

+1

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 17 Oct 2013 19:08:52 -0000

>> I'm in for spec writing and doing implementation experiments.

I'll write something up for the DKIM thing.  If anyone actually
understands PGP or S/MIME (you can stop laughing now) help would be
appreciated, since I want to borrow as much as possible from one of
them to avoid inventing my own probably broken crypto scheme.

R's,
John

---

From: Martijn Grooten <[email-masked]>
Date: Thu, 17 Oct 2013 19:51:35 +0000 (UTC)

On Thu, 17 Oct 2013, Rolf E. Sonneveld wrote:
> There might be a potential 'conflict' however between a) the original idea of 
> Wei, where the end-user can request from within his _MUA_ for a secure 
> transport and b) the way DKIM operates, in general between boundary MTA's of 
> sending ADMD and receiving ADMD. For example: the MUA can check for the 
> existence of public keys in the domain of the intended recipient, but it 
> doesn't know whether the MSA or his ADMD-boundary MTA and/or the receiving 
> ADMD boundary MTA will support the requested level of security.

I think that most end users won't understand what the various levels of 
security mean. Nor should they. Those that do are probably able to perform 
some checks themselves, should security really matter to the email they 
want to send. In which case they'll probably conclude that they need 
end-to-end encryption and switch to something like PGP.

What I like about this idea is that it makes email traffic more secure for 
everyone, but does so entirely behind the scenes. Kind of like DKIM signs 
emails, without bothering the end-user, who probably has a different idea 
of 'signing' anyway, with telling them about it.

> As for the trustworthiness of the receiving domain publishing its key: here 
> we might benefit from the work of the repute workgroup: a better reputation 
> might indicate (or might be interpreted) as more trustworthiness. However, it 
> is far too simplistic to say 'trustworthiness=reputation'.

I think trustwhorthiness is pretty hard to quantify here and in many cases 
will include subjective assertions, or things that only become known after 
the fact. Also, given that this proposal only claims to protect the 
transaction up to the recipient's mail server, I don't think it should 
pretend it can say anything about what happens afterwards.

Martijn.

PS happy to help write/test/comment if and when needed.

---

From: Wei Chuang <[email-masked]>
Date: Thu, 17 Oct 2013 13:15:46 -0700

Martjin,

[sorry if this is a resend]

On Wed, Oct 16, 2013 at 11:29 AM, Martijn Grooten <
[email-masked]> wrote:

> proposal has the potential (or, in my view, likely) side-effect of breaking
> email delivery,

The other side of the coin is that this is a feedback signal for the sender
as well as the destination mail provider.  Also I would just reiterate the
point (which really is the motivation for this I-D) that the ecosystem is
in a partially state with only a few providers with SMTP STARTTLS.
 Initially this feature would be used likely by a small set of users that
need this say for business requirements, but can scale up as the ecosystem
adopts SMTP STARTTLS.  Also this proposal provides a way for a SMTP server
to display the providers capabilities, so users won't have to randomly send
messages that will break during delivery.

> while suggesting senders have more control over the security of the
> message in transit than they really have.

> think it should be clear about what threats this protects against and what
I brought up eavesdropping and MitM as threats to be concerned about and
addressed them in the proposal.  The baseline does not do a good job
against those attacks but the TLS tiers mitigate them as noted in the
example.

> case probably for good reasons.)
I think there was a suggestion to break out the TLS spec from this proposal
(if it gets to around to being updated)- it could exist as a best practices
document?

> doesn't want the email to be sent if not very strong encryption can be used
> in transit.
>
>
>

I think this is the chief criticism, and one that was argued by colleagues
here at Google as well.

thanks for the comments,

-Wei

---

From: Wei Chuang <[email-masked]>
Date: Thu, 17 Oct 2013 13:16:58 -0700

> access to and control over the MTA or mail store.
Agreed that this proposal does nothing to protect against this type of
threat.  If the proposal gets around to being rewritten, I'll further
clarify this point.

thanks for the clarification,
-Wei

---

From: Richard Clayton <[email-masked]>
Date: Thu, 17 Oct 2013 23:36:48 +0100

In message <[email-masked]>
, Martijn Grooten <[email-masked]> writes
>But doesn't DKIM also contain a scheme for putting keys into DNS?

yes it does -- but this has pretty much nothing to do with DKIM in terms
of functionality  (and I had to look very carefully at the DKIM specs to
check that John Levine hadn't created a clash with DKIM selectors (he
has not) -- because that might have ended up with the same key being
used for signing and encryption, which risks a very significant security
failure; and even using different names for keys, people may decide to
be lazy, create one key and fall into this hole).

> I don't 
>see what these schemes offer that DKIM can't do

or vice versa  --  so I'm with Dr Occam here; concentrate on the notion
of opportunistic encryption at the message level at an early hop and the
subsequent unpacking for final delivery. That's what I haven't seen
before. Expressing this with some generic view of what sort of
encryption is involved (even if that description is later folded into
the draft) will show whether the basic idea has legs

>, other than that they all 

DKIM is widely used because of the way in which various large financial
institutions have seen it as a way of combating criminality

PGP is also widely used -- but less by organisations, more by
individuals

>Anyway, I think this deserves being written down.

Yes ... but what needs to be made crystal clear is what the threat model
is perceived to be (because you can never assess a security solution
without that being fully understood); and we will avoid a lot of
iterations (as piecemeal fixes are applied) if it is reviewed by
competent security folks prior to seeing wide circulation (certainly
before adding in any of the crypto detail).

There are things that you might try and do with the crypto that may well
be safe in context, but that are generally seen as living dangerously
that it would be best to avoid.

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

---

From: SM <[email-masked]>
Date: Thu, 17 Oct 2013 17:48:48 -0700

Hi Wei,
At 10:02 17-10-2013, Wei Chuang wrote:
>Agreed this was useful to look at.  Was the I-D for RFC 6710 
>discussed on this mailing list? or if you happen to know the I-D 
>name, I can try to search for it. The discussions would be interesting.

The I-D name is draft-melnikov-smtp-priority.  It was discussed on 
[email-masked].  There is a (previous) thread at 
http://www.ietf.org/mail-archive/web/ietf/current/msg72179.html

>If this is a pattern, I wonder if a common platform could be built 
>to support specifying behavior at mail delivery and having the 
>propagate along with the message and derivatives?  This is what this 
>proposal is trying to do for the more specific mail delivery security context.

It's an interesting question.  I'll comment below.

>I would answer with something wishy washy like "more safe".

That's a step forward.  This is a quick thought.  I would explore 
"hand-off of responsibility".

Regards,
-sm

---

From: Ned Freed <[email-masked]>
Date: Thu, 17 Oct 2013 18:03:32 -0700 (PDT)

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> the draft) will show whether the basic idea has legs

I am in complete agreement with this. I think all references to DKIM needs to
be dropped from this draft. DKIM is not an end-to-end signature or encryption
mechanism in any case, and adapting it to be used this way diverts attention
away from what should be the focus here: Protecting the contents of messages in
transit.

I'm less sure about whether the focus should be on opportunsitic encryption
or guaranteeing a secure path. I can argue this one either way.

Beyond that there are a lot of isses with the draft, including, but not limited
to:

(1) The idea of sending a forward nondelivery notification to the recipient
    was tried in X.400. It did not work out well at all - for better or worse
    people just don't grok notifications about messages they never sent or
    received. I'm also fairly confident that our current spammy environment will
    make this problem worse, not better. As such, I think this needs to be
    dropped from the specification, and if it is retained, a specific format
    for such things needs to be specified along the lines of a DSN or MDN
    so that they can be detected and handled appropriately by an MUA.

(2) Given that this is an SMTP extension, carrying information about
    transport requirements in a header is a mistake. This should instead be
    done with a MSMD parameter on the MAIL FROM. That way the server can
    reject mail sent to recipients where it has prior knowledge that the
    necessary security requirements cannot be met. You already have serious
    issues with messages vanishing silently when the path the DSN takes
    cannot meet the necessary guarantees, so it makes sense to provide
    to avoid pointless relay operations.

    You do need a header, but one of a different sort: One that is added on
    final delivery so that POP and IMAP servers can do the right thing.
    This can have essentially the same format, but a different name is
    probably in order.

(3) I assume the purpose of the MSMD indicator in POP3 and IMAP4 is so that
    security assurances can be continued across the mail access layer. If
    so, this needs to be explained in more detail, because in that case
    the parameter really doesn't offer any sort of capability to the client.
    Rather, it is saying that certain operations the client attempts may
    fail unless the client enables the necessary level of security.

(4) You need to define a way to inform POP3 and IMAP4 clients that the
    reason they cannot access a given message is due to security requirements
    not being met. It may also be appropriate to provide an indication of
    what those security requirements are. Or not; this is a tricky one.

(5) I believe others have pointed out that the discussion of MX handling
    is inadequate. I concur.

(6) There needs to be discussion of the MSMD extension in the context of
    SUBMIT.

That will do for now.

				Ned

---

From: SM <[email-masked]>
Date: Fri, 18 Oct 2013 07:41:35 -0700

>away from what should be the focus here: Protecting the contents of 

There are cases where DKIM verification will fail.  These cases are 
significant enough to avoid DKIM as an end-to-end mechanism.  Note 
that the are use-cases where DKIM may be appropriate but that is not 
really relevant to the problem the draft tries to solve.

Regards,
-sm

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 18 Oct 2013 22:17:37 +0200

On 10/17/2013 09:08 PM, John Levine wrote:
> I'll write something up for the DKIM thing.

DKIM is the abbreviation of DomainKeys _Identified_ Mail. I agree with 
others that the term 'DKIM' cannot be used for this new protocol, the 
authors of DKIM have always tried to limit the scope of DKIM in many 
discussions on ietf-dkim, with the result of DKIM being defined as:

    DomainKeys Identified Mail (DKIM) permits a person, role, or
    organization that owns the signing domain to claim some
    responsibility for a message by associating the domain with the
    message.

If, nonetheless, the consensus would be to use DKIM for this new 
protocol in order to be able to benefit from the fact that DKIM is 
well-known and has a large installed base, then in my view 'DKIM would 
need to be redefined, for example to refer to 'DomainKeys Internet 
Mail'. In which case there's an awful lot of work to do to either 
explain the two incarnations of DKIM, or to come up with one combined 
standard describing both types of usage of DKIM (similar to S/MIME which 
covers both signing and encryption).

> If anyone actually

As for the part that describes storage of the keys in DNS I'd suggest to 
take a look at DANE [1]. Looking at DANE and a number of new related 
drafts [2], [3], [4], together with this new draft John will write, and 
given the fact that in the future there probably will be more protocols 
with a need to store keys in DNS, it seems to me that there is a need to 
unify all of these DNS key storage schemes.

/rolf

[1] http://tools.ietf.org/html/rfc6698
[2] http://tools.ietf.org/html/draft-wouters-dane-openpgp-00
[3] http://tools.ietf.org/html/draft-ietf-dane-smime-02
[4] http://tools.ietf.org/html/draft-wouters-dane-otrfp-00

---

From: "John Levine" <[email-masked]>
Date: 18 Oct 2013 21:16:23 -0000

In article <[email-masked]> you write:
>others that the term 'DKIM' cannot be used for this new protocol

OK, the working name is PICKLE.

R's,
John

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 18 Oct 2013 23:45:51 +0200

> OK, the working name is PICKLE.

Nice ;-) Looking forward to it.

/rolf

---

From: Ned Freed <[email-masked]>
Date: Sat, 19 Oct 2013 00:51:26 -0700 (PDT)

> really relevant to the problem the draft tries to solve.

Exactly. DKIM has a purpose; this isn't it. Using DKIM in this context will
only make the service less reliable while providing no benefit, and given the
significant reliability risks it already has this is no small thing.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Sat, 19 Oct 2013 05:05:41 -0400

--On Thursday, October 17, 2013 18:03 -0700 Ned Freed
<[email-masked]> wrote:

> Beyond that there are a lot of isses with the draft,
> including, but not limited to:
> 
> (1) The idea of sending a forward nondelivery notification to
> the recipient     was tried in X.400. It did not work out well
> at all - for better or worse     people just don't grok
> notifications about messages they never sent or     received.
> I'm also fairly confident that our current spammy environment
> will     make this problem worse, not better. As such, I think
> this needs to be     dropped from the specification, and if it
> is retained, a specific format     for such things needs to be
> specified along the lines of a DSN or MDN     so that they can
> be detected and handled appropriately by an MUA.

In addition to the X.400 experience, I would encourage anyone
who wants to go down that path to try to review and understand
the EAI discussions, especially in the experimental round, about
trying to fix up messages in transit and what could be done if
that were not feasible.  The X.400 experience was much more
fully developed and the general problems more obvious; the EAI
analysis was more specific to the characteristics of Internet
email and the strengths and limitations of the SMTP extension
model.

In addition, even if there were no other issues with forward
notifications, if the idea behind this proposal is to encrypt
and thereby hide information in transit, the specific format to
which Ned refers would have to provide enough information to be
useful without disclosing anything that was supposed to be
hidden.  If it did disclose that information, we would be
essentially back to the problem of SASL fallback.  It is not
clear to me --especially in the context of the notification
coming as a surprise to the recipient that Ned mentions-- that
the resulting redacted notification would contain enough
information to be either useful or comprehensible.

> (2) Given that this is an SMTP extension, carrying information
> about     transport requirements in a header is a mistake.
>...

Yes.  Mentioned earlier.

> (3) I assume the purpose of the MSMD indicator in POP3 and
> IMAP4 is so that     security assurances can be continued
> across the mail access layer. If     so, this needs to be
> explained in more detail, because in that case     the
> parameter really doesn't offer any sort of capability to the
> client.     Rather, it is saying that certain operations the
> client attempts may fail unless the client enables the
> necessary level of security.

Again, some of the EAI discussions may help illuminate the
tradeoffs and issues with this.  Or perhaps not.

> (4) You need to define a way to inform POP3 and IMAP4 clients
> that the     reason they cannot access a given message is due
> to security requirements     not being met. It may also be
> appropriate to provide an indication of     what those
> security requirements are. Or not; this is a tricky one.

Very.  And, especially for POP3, the whole question of how to
tell a client that it cannot access a message (but that some
other client might be able to do so) is a very tricky one.
Again, a similar problem was necessarily explored as part of the
EAI work and a review by the authors of this document of that
work might be helpful.

The EAI work also identifies another concern that wasn't on
Ned's list.  Until EAI, there were, as far as I know, no cases
(at least no standardized ones), in which a message could be
successfully delivered to the delivery server and mail store but
a POP3 or IMAP client could find itself in a position of not
being able to retrieve that message because it lacked some
important capability.  EAI necessarily introduced one such case
-- one in which the mail store could handle non-ASCII header
information (in other than encoded word form) -- but the client
could not.  Part of what made that work more complicated was the
realization that a user might use one client, with one set of
capabilities, one day and a different one the next: assumptions
that a delivery MTA can know the intended recipient's
capabilities are quite problematic.

There is one sense in which the problem posed by this draft is
even more complex than the EAI one.  Because EAI doesn't promise
any security above that of "bare" SMTP and IMAP/POP3, it is ok
for a POP3 or IMAP server to display a mailbox table of contents
to a client that may not be able to retrieve all of the messages
in it (even if it has to do some conversions or conventional
representations to do so).  With this new set of ideas,
displaying such a TOC in the clear might disclose information
then sender intended be kept encrypted.

best,
   john

---

From: Wei Chuang <[email-masked]>
Date: Sat, 19 Oct 2013 11:12:18 -0700

> away from what should be the focus here: Protecting the contents of

There is another aspect to the MSMD not really addressed by the Levine
proposal, or at least directly.
MSMD is making a guarantee about private delivery (or not at all) in an
ecosystem where many of
the SMTP servers do not support STARTTLS.  If the Levine proposal uses
DKIM's public key form
DNS TXT, it may conflate support for DKIM at the destination with support
for the proposed domain
encrypted message format.  I would conjecture that this could be repaired
by using a new TXT entries
for the proposed protocol or a new DNS RR.  Their presence indicates
support for the Levine protocol.

The other aspect is how should the Levine protocol handle situation where
the destination doesn't support
the protocol.  Presumably it shouldn't send, along with some notification
but that should be specified.

> Beyond that there are a lot of isses with the draft, including, but not

In the following I'm just responding for the MSMD proposal:

DKIM can be removed from the proposal without harm to main concepts.

>     so that they can be detected and handled appropriately by an MUA.

In the likely initial uses for MSMD, likely the sender and recipient would
already have a relationship
that requires this feature e.g. corporate or consumer financial so probably
would wouldn't treat
such notifications as spam.  That said it can be dropped without harm to
main proposal, and
restored if that's found to be useful later.

>     transport requirements in a header is a mistake.

It would very helpful if you could elaborate on this as I don't see this
argument fully.  In the MSMD proposal
the mail headers is a place to store the requirements through delivery and
afterwards if its desired to protect through
derived messages (reply/forward).

>    This should instead be

>     to avoid pointless relay operations.

I see the benefit in passing the MSMD requirements as parameters to MAIL
FROM.   If this is
place of the the SMTP client side check, then I would point out that there
is benefit in having
the client do the check especially if the SMTP server side is ignorant of
the MSMD protocol.

>     security assurances can be continued across the mail access layer. If

Yes that's correct.

>     fail unless the client enables the necessary level of security.

Its more that the client can declare to the server it is compliant,
otherwise the server should not (or must not if the sca option
is set) get access to the mail message.  I can clarify this in the proposal.

>     what those security requirements are. Or not; this is a tricky one.

This can be clarified further.

> (5) I believe others have pointed out that the discussion of MX handling

Do you the various delivery patterns as described  RFC5321 sec 3.6 and 3.7
relaying
and gateways? and working through the scenarios?

> (6) There needs to be discussion of the MSMD extension in the context of

Can you expand this more?  I'm sorry I didn't catch this.  Submit as in
Mail Submission Agent?

thanks for the comments
-Wei

---

From: "John Levine" <[email-masked]>
Date: 19 Oct 2013 18:23:50 -0000

>DKIM's public key form DNS TXT, ...

No problem, it doesn't.  My plan is to use a key from a distinguished
DNS name which was _encrypt._domainkey.<domain> (to reuse tools people
already have to publish DKIM keys) but could be anything else.

The existence of that record is the signal that the recipient domain
is prepared to decrypt and unwrap pickled mail.

>DKIM can be removed from the proposal without harm to main concepts.

Right.

>restored if that's found to be useful later.

If they already know each other, now I'm wondering what the practical
advantage is over S/MIME.

R's,
John

---

From: Wei Chuang <[email-masked]>
Date: Sat, 19 Oct 2013 11:56:08 -0700

> email and the strengths and limitations of the SMTP extension

Thanks both for the pointers...  My first pass at looking for X.400 docs
has been sparse, just some wiki article but no discussion.  EAI has more.

> hidden.

Yes forward notifications has the risk of leaking information as noted in
the proposal, and
presumed its use depends on the scenario and so had to be enabled.  Can be
removed.

>  If it did disclose that information, we would be

I see now, though I'd argue that putting a copying of the security header
to SMTP envelope
makes sense, and leave the message security header in place would be fine.

> capabilities are quite problematic.

Agreed.  Its compounded by a limited knowledge of what those clients are,
hence the approach of having the clients self identify they are security
compliant.

> then sender intended be kept encrypted.

This was mean to be covered be the notion of non-compliant client's being
prevented
from accessing the protected messages which in an admittedly very broad
brush
presumed things like TOC.  Another feature (assuming that it survives) that
could be clarified better.

>    john

thanks again for the detailed comments,
-Wei

---

From: Ned Freed <[email-masked]>
Date: Sat, 19 Oct 2013 11:37:45 -0700 (PDT)

> support for the Levine protocol.

I'm not talking about the Levine proposal here. I'm talking about MSMD's
own DKIM requirements, which are entirely superfluous to MSMD's purpose.

> but that should be specified.

Again, I'm talking about MSMD's own DKIM requirements, not some future
use of DKIM to implement encryption.

> DKIM can be removed from the proposal without harm to main concepts.

Exactly. And it needs to be.

> such notifications as spam.

Again, past experience says otherwise. You might also want to look at the
surprisingly high number of cases where a user presses the "this is spam"
button for a message from someone the user knows.

I'll also note that sending a forward nondelivery notification over a link
which by definition doesn't meet the message's security standards has to
expose metadata regarding the failed exchange in order to be useful. If
people are serious enough to want to use a mechanism such as this I doubt
they will be comfortable with that exposure.

> That said it can be dropped without harm to
> main proposal, and restored if that's found to be useful later.

And IMO should be.

> derived messages (reply/forward).

The problem is inherent to the nature of SMTP itself - if you pass this
information in a header field it's not available until the message is
transferred. Suppose the message is sent to multiple recipients, one
of whom the MTA knows can't be delivered to while meeting the MSMD
requirements. In this case the MTA has no choice but to send a DSN
for that recipient, which could easily go awry because of the carryover
of MSMD restrictions that apply to any generated DSN.

Also consider how this appears in a user agent. The user is better off
knowing immediately that some recipients are unreachable with the required
security guarantees.

In general the sooner you're able to reject a message, the better the
infrastructure works. This is especially the case when you're doing things that
can fail at an intermediate hop.

> the client do the check especially if the SMTP server side is ignorant of

And if you're passing the information in a MAIL FROM, then also having
it in a header opens the door to silly states where the two disagree. It
really needs to be one or the other. And in this case since you require
the SMTP to transfer anyway, there's no cost to using a MAIL FROM
parameter.

> is set) get access to the mail message.  I can clarify this in the proposal.

There is at present no mechanism in either POP3 or IMAP4 for the client to
declare a capability to a server. You'd need to define a command to do that.

But I have to wonder if having the client use SSL/TLS on the connection
isn't sufficient here. Yes, this means that the client may not be compliant
and may send on part of a sensitive message without the same protections
as the message it came from.

But you're fighting a losing game here. The minute you go past providing a
transport mechanism that guarantees a certain level of security and start
talking about carrying security labels around as pieces of messages move
around, you're entering the territory of a full-on multi-level security system.

Speaking as someone who did part of the implementation of one of these, this is
far beyond anything we should be specifying. And even if we did manage to get
one implemented, there is substantive evidence that even experienced security
professionals cannot deal with the result.

> and gateways? and working through the scenarios?

Yes.

> Can you expand this more?  I'm sorry I didn't catch this.  Submit as in

Yes, that's the case I'm referring to. This definitely qualifies as 
a SUBMIT extension and that needs to be discussed.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sat, 19 Oct 2013 14:27:46 -0700 (PDT)

> headers in the encapsulated message.

A single header field for the recipient(s) really doesn't cut it. There's lots
more to message envelopes these days. I suggest you take a look at RFC 2442
instead. Batch SMTP has a long and quite successful history of being used for
this sort of thing.

And now, I'm afraid, I'm going to have to do the IPR dance: I'm aware that
there may be intellectual property claims on this scheme. Unfortunately I
really cannot say more than that - not because of any sort of  confidentiality
restrictions, but rather because I don't know the details.

Specifically, I was contacted maybe 6 months ago by a law firm looking for
prior art on exactly this scheme. They didn't identify the patent and I didn't
ask for any details because I'm instructed by my employer to never do that.
But apparently there's one out there.

				Ned

---

From: John R Levine <[email-masked]>
Date: Sat, 19 Oct 2013 17:48:10 -0400 (EDT)

> instead. Batch SMTP has a long and quite successful history of being used for

Huh, I've looked at it but never run into an implementation.  Seems 
straightforward enough.

> prior art on exactly this scheme.

Sigh.

Regards,

---

From: Ned Freed <[email-masked]>
Date: Sat, 19 Oct 2013 14:39:43 -0700 (PDT)

> is multi-part with the key MIME part and the encrypted MIME part)?

multipart/encrypted, in other words. See RFC 1847.

And if we're going to consider various security building blocks, how
about identity-based encyption? It could be used here to extend this
to a full end-to-end mechanism without having to put keys for every address
in the DNS.

OTOH, IBE is probably patented to the hilt. So maybe not.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sat, 19 Oct 2013 14:53:11 -0700 (PDT)

> Huh, I've looked at it but never run into an implementation.  Seems

Ever hear of BITNET? BITNET email was built on top of NJE using batch SMTP to
provide for multiple recipients and addresses with more than 8 character in
either the localpart or host.

				Ned

---

From: John R Levine <[email-masked]>
Date: Sat, 19 Oct 2013 18:06:50 -0400 (EDT)

> either the localpart or host.

Wow, it's been a while.

Do you know if anyone's used it in this millenium?  I agree that if you 
need to encapsualate a message and envelope, it's as good an approach as 
any.

Regards,

---

From: John R Levine <[email-masked]>
Date: Sat, 19 Oct 2013 18:16:22 -0400 (EDT)

> multipart/encrypted, in other words. See RFC 1847.

Hmmn, that does let you encapsulate

> OTOH, IBE is probably patented to the hilt. So maybe not.

True, but 1847 is 18 years old.  That's a pretty early priority date.

Regards,

---

From: John R Levine <[email-masked]>
Date: Sat, 19 Oct 2013 18:17:09 -0400 (EDT)

> multipart/encrypted, in other words. See RFC 1847.

Ahem, does let you encapsualte a message/rfc822 and encrypt it, doesn't 
it?  It even works in ordinary MUAs.

Regards,

---

From: Ned Freed <[email-masked]>
Date: Sat, 19 Oct 2013 15:41:06 -0700 (PDT)

> it?  It even works in ordinary MUAs.

No, the purpose of multipart/encrypted is to separate the encrypted content
from the encryption metadata. You can put anything, including a message/rfc822
part, inside, but you could do that with any random encypted container.

There are various advantages to having the separation. For example, you could
generate multiple types of metadata for the same encrypted payload, in which
case the metadata part could be a multipart/alternative. There are streaming
applications for bandwidth limited devices: Fetch the first part, decrypt the
interchange key, and then provide that key to a display that then uses URLFETCH
to pull the data, decrypt it, and display it.

That said, I don't any of the advantages of multipart/encrypted coming into
play in a scenario where the message is encrypted by the MSA and decrypted
by the MDA. It's really only useful in end-to-end cases.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Sat, 19 Oct 2013 19:01:26 -0400

> part, inside, but you could do that with any random encypted container.

I'm pretty sure you're both right.

Yes, the design of /encrypted separates meta-data from encrypted 
content, but the encrypted content could be a message, yes?

My own hope for /ecrypted was that the commonalities of PGP and S/MIME 
might allow for joint use, but of course, that was foolish idealism.

d/

---

From: "John Levine" <[email-masked]>
Date: 19 Oct 2013 23:05:28 -0000

>content, but the encrypted content could be a message, yes?

Sure.  Fire up your favorite S/MIME aware MUA, open a message, forward
it as an attachment to someone whose key you know and tell it to sign
the forwarded message.  Works great, recipient will see the attached
message/rfc822.

>My own hope for /encrypted was that the commonalities of PGP and S/MIME 

Oh, well.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 20 Oct 2013 00:14:17 -0000

In article <[email-masked]> you write:
>it as an attachment to someone whose key you know and tell it to xxxx

encrypt

---

From: Russ Allbery <[email-masked]>
Date: Sat, 19 Oct 2013 22:14:55 -0700

> the forwarded message.  Works great, recipient will see the attached

Likewise for OpenPGP messages, for what it's worth.  (Which of S/MIME or
OpenPGP one uses seems to be heavily driven by what community one is part
of.  S/MIME appears to be the standard among the Windows security people,
but the Linux distribution security folks use OpenPGP essentially
exclusively.)

---

From: Ned Freed <[email-masked]>
Date: Sun, 20 Oct 2013 15:50:11 -0700 (PDT)

> need to encapsualate a message and envelope, it's as good an approach as

I can't tell one way or the other. All I can say is that the code
to do it is still shipping and we haven't received any reports of problems.

				Ned

---

From: Wei Chuang <[email-masked]>
Date: Tue, 22 Oct 2013 10:20:00 -0700

On Sat, Oct 19, 2013 at 11:37 AM, Ned Freed <[email-masked]> wrote:

> > > I am in complete agreement with this. I think all references to DKIM
> needs
> > > to

Understood.

> the SMTP to transfer anyway, there's no cost to using a MAIL FROM
At a minimum there will have to be a check from the SMTP client perspective
to see if the STMP server has the MSMD extension in the EHLO response.
 Given that then I can see how any additional requirements could be checked
by a compliant SMTP server when passed MAIL FROM.

> professionals cannot deal with the result.

The "SCA" option can be removed from the document and revisited (if needed)
at some later date.

> a SUBMIT extension and that needs to be discussed.

These details can be clarified.

-Wei

---

From: Martijn Grooten <[email-masked]>
Date: Tue, 22 Oct 2013 17:42:17 +0000 (UTC)

So after my initial excitement about the idea of using something DKIM-like 
to ensure organisation-to-organisation encryption for SMTP, I've started 
to have some doubts.

I basically have two concerns.

Firstly, while I understand the important difference between guaranteeing 
encryption of the connection to the next hop (as STARTTLS does) and 
guaranteeing encryption of the full transit to the recipient's mail server 
(as this proposal aims to do), in practice how often do these two differ? 
The only widely used example I can think of are organisations using hosted 
email (for filtering spam etc.) - but not decrypting the emails at the 
cloud-based host would defeat the whole point of using hosted email.

Secondly, I don't think the proposal includes a way to authenticate the 
receiving server. I think this is important to defend against active 
man-in-the-middle attacks by attackers who are able to modify DNS 
responses (as happened in the case of some prominent security firms 
recently - though web rather than email was the attackers' main target). 
In this proposal as I understand it, as in DKIM itself, DNS is a single 
point of failure. I know authentication requires the use of certificates, 
which adds complications and introduces a likely cost and that sometime 
DKIM-like is therefore a lot easier to implement. But is this compromise 
worth it?

Martijn.

---

From: Steve Atkins <[email-masked]>
Date: Tue, 22 Oct 2013 10:51:00 -0700

On Oct 22, 2013, at 10:42 AM, Martijn Grooten <[email-masked]> wrote:

> So after my initial excitement about the idea of using something DKIM-like to ensure organisation-to-organisation encryption for SMTP, I've started to have some doubts.
> 
> Firstly, while I understand the important difference between guaranteeing encryption of the connection to the next hop (as STARTTLS does) and guaranteeing encryption of the full transit to the recipient's mail server (as this proposal aims to do), in practice how often do these two differ?

If the encryption is done in the MUA this protects the content at the MUAs smarthost.

Of course, in the common case the entity that controls the smarthost also controls the DNS recursive resolver...

> The only widely used example I can think of are organisations using hosted email (for filtering spam etc.) - but not decrypting the emails at the cloud-based host would defeat the whole point of using hosted email.
> 
> Secondly, I don't think the proposal includes a way to authenticate the receiving server. I think this is important to defend against active man-in-the-middle attacks by attackers who are able to modify DNS responses (as happened in the case of some prominent security firms recently - though web rather than email was the attackers' main target). In this proposal as I understand it, as in DKIM itself, DNS is a single point of failure. I know authentication requires the use of certificates, which adds complications and introduces a likely cost and that sometime DKIM-like is therefore a lot easier to implement. But is this compromise worth it?

DNSSEC is probably the answer to that (which doesn't mean that doing something additional wouldn't be a decent idea, if there's any low hanging fruit there).

Cheers,
  Steve

---

From: Martijn Grooten <[email-masked]>
Date: Tue, 22 Oct 2013 20:09:45 +0000 (UTC)

On Tue, 22 Oct 2013, Steve Atkins wrote:
> Of course, in the common case the entity that controls the smarthost 
> also controls the DNS recursive resolver...

Yes. If your threat model includes the possibility that attackers have 
taken control of the smarthost, you have bigger things to worry about (and 
you should use Tor and/or a VPN rather than a scheme like this).

I can see that by doing the encryption in the MUA, you get the same kind 
of control that the original proposal (by Wei Chuang et al) wanted to give 
you. And it would mean that you (or your MUA) can make sure the message is 
encrypted during transit. But for this to be useful, it would have to be 
implemented as the default setting in MUAs. I'm not convinced (anymore) 
that it would be easier to make MUAs and (receiving) MTAs adopt a 
yet to be written protocol than it would be for sending and receiving MTAs 
to adopt an existing protocol. Even if the existing protocol isn't trivial 
to implement.

I have to admit that I would't know the reason why MTA are using STARTTLS. 
If there are fundamental reasons for not using it, reasons that don't 
apply to this protocol, then I think it is a rather nice way of getting 
more or less the same security with relatively little effort. If these 
reasons are that, well, it is a little bit difficult and no one seems to 
care anyway, then I wonder if this new protocol is where we should focus 
our efforts.

Martijn.

---

From: James Cloos <[email-masked]>
Date: Tue, 22 Oct 2013 19:30:44 -0400

>>>>> "MG" == Martijn Grooten <[email-masked]> writes:

MG> Secondly, I don't think the proposal includes a way to authenticate
MG> the receiving server.

DANE provides that.

The draft which suggests how to use DANE with SMTP suggests that TLS
MUST be used, and the server's offerred cert verified, whenever the path
to the MX is dnssec-verified and a TLSA record exists for the smtp server.

Of course, that would not protect against an attacker which can remove
the DS record from the parent zone (not just block it, but also provide
proof of non-existence).  But nothing really can protect against those
who control the parent zone(s).

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Wei Chuang <[email-masked]>
Date: Tue, 22 Oct 2013 23:33:26 -0700

> But apparently there's one out there.
My read of this and RFC 3979 is that possible IPR problems with an idea
such as Levine's proposal, doesn't preclude it from further discussion,
though correct me if I'm wrong.  Also what you've written paints a very
broad brush.  The way I see it, his proposal actually has three parts, and
does that prior art exactly cover all three parts?  That is:
1) Use of DNS for public key distribution.  The obvious prior art is DKIM.
2) Use of a domain wide public key (e.g. DKIM public key)  Surely one can
create a new RR that isn't covered by any patent?
3) Wrap at sender MTA or MUA, and only unwrap at the recipient MTA, with
relays seeing only cipher text.

If only item 3) is encumbered, then surely there's something to work with
from 1) and 2) ?

my two cents,
-Wei

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Oct 2013 13:48:01 -0400

I'd like to call the list's attention to two other Internet-Drafts
regarding use of TLS with email protocols:

1. draft-ietf-dane-smtp-with-dane-00
<http://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/>

This is (mostly) about SMTP mail relaying using Opportunistic TLS, and
how to make it work well by using TLSA records to both (a) provide a
secure indication that the SMTP server supports STARTTLS (thus thwarting
MITM downgrading attacks) and (b) provide a way to verify that the SMTP
server is the right server (given a chain of DNSSEC-signed
MX/CNAME/A/AAAA etc. records) without requiring the server to present a
TLS certificate for every possible DNS name for which that server is
authorized to accept mail.

The document seems to be fairly well written and worked out in a decent
amount of detail.   It proposes Opportunistic TLS rather than an SMTP
extension or message header that would require secure delivery for the
entire path.   For mail relaying I think Opportunistic TLS is a more
realizable goal.  But even if people want to propose an SMTP extension
to mandate use of TLS for the remainder of the path to the recipient, I
think it would need to use the certificate verification mechanisms
described in this draft.

2. draft-moore-email-tls-00
<http://datatracker.ietf.org/doc/draft-moore-email-tls/>
This is a document recommending use of TLS in all interactions between
MUAs and mail servers (IMAP, POP, Submission).   It basically has two
sets of recommendations - one for client and server implementations, and
another for mail service providers - because there are operational as
well as implementation concerns.

This started out to be a document recommending TLS for both MUA-MSP
interactions and for mail relaying, but it turned out that the two cases
are different enough that trying to specify both in the same document
made it too large and complex.   When I discovered that
draft-ietf-dane-smtp-with-dane-00 existed and used the same approach I
was recommending, and also that the dane-smtp draft had things worked
out in more detail, I removed the portions from my draft that related to
SMTP relaying. 

To me it seems that a comprehensive approach to encrypting email traffic
actually needs to cover three separate cases: (1) mail relaying, (2)
MUA-MSP interactions, and (3) end-to-end encryption.   Cases (1) and (2)
are similar in goal - protect emails being transmitted over the network
from eavesdroppers and active attacks - but subtly different in
implementation.   Case (3) protects emails from being disclosed to
servers which are operated by third parties and which might be
compromised.   None of these is sufficient by itself, because (1) and
(2) by themselves don't protect the messages while they're stored on
third-party servers, and (3) doesn't protect against traffic analysis -
which when dealing with mass surveillance seems to be as important as
protecting the actual contents of the messages.

Of these, the most difficult problem seems to be (3).   Solutions for
(3) e.g. PGP and S/MIME have been around for a long time, but they
haven't been widely deployed.    This seems like an area that is worth
revisiting.

Keith

---

From: Paul Smith <[email-masked]>
Date: Thu, 24 Oct 2013 09:04:51 +0100

On 23/10/2013 18:48, Keith Moore wrote:
>
> The document seems to be fairly well written and worked out in a 
> decent amount of detail.   It proposes Opportunistic TLS rather than 
> an SMTP extension or message header that would require secure delivery 
> for the entire path.   For mail relaying I think Opportunistic TLS is 
> a more realizable goal.  But even if people want to propose an SMTP 
> extension to mandate use of TLS for the remainder of the path to the 
> recipient, I think it would need to use the certificate verification 
> mechanisms described in this draft.

I had a thought about a low impact idea which may help wrt TLS security, 
but this draft doesn't include it and I haven't seen it anywhere else 
(apologies if it is there and I've missed it)

It may be a waste of time, but I'll throw it into the mix anyway ;-)

At the moment I have no idea how 'secure' a message was on its journey 
to me. Would it be sensible/a good idea for MTAs/MSAs/MDAs to add the 
'TLS' state into the Received trace line somehow - eg instead of

Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com
  (Postfix) with ESMTP id 737EC11E8372; Wed, 23 Oct 2013 10:48:15 -0700
  (PDT)

have

Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com
  (Postfix) with ESMTP (TLS:no) id 737EC11E8372; Wed, 23 Oct 2013 10:48:15 -0700
  (PDT)

(or some such)

Then, at the receiving end, you would have an idea that the message was 
sent in a plain session at some point in its transfer (you could have 
something like 'TLS:no', 'TLS:yes', and the absense of such a marker 
would indicate that that MTA doesn't tell you).

It wouldn't make a message more secure, but it'd be trivial to code, I 
can't see it breaking anything, and it would at least let you know if 
there had been a time when the message had been at risk of snooping in 
transit.

-

---

From: Stephan Bosch <[email-masked]>
Date: Thu, 24 Oct 2013 10:32:41 +0200

On 10/24/2013 10:04 AM, Paul Smith wrote:
>> an SMTP extension or message header that would require secure
>> delivery for the entire path.   For mail relaying I think
>> Opportunistic TLS is a more realizable goal.  But even if people want
>> to propose an SMTP extension to mandate use of TLS for the remainder
>> of the path to the recipient, I think it would need to use the
>> certificate verification mechanisms described in this draft.
>
> I had a thought about a low impact idea which may help wrt TLS
> security, but this draft doesn't include it and I haven't seen it
> anywhere else (apologies if it is there and I've missed it)
>
> Then, at the receiving end, you would have an idea that the message
> was sent in a plain session at some point in its transfer (you could
> have something like 'TLS:no', 'TLS:yes', and the absense of such a
> marker would indicate that that MTA doesn't tell you).
>
> transit.tf-smtp 

I think this is what you mean:

https://tools.ietf.org/html/rfc3848

This is in common use today. Some MTAs even add extra information about
the TLS session in a comment.

Regards,

Stephan.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 24 Oct 2013 10:46:12 +0200

Hi, Paul,

> there had been a time when the message had been at risk of snooping in 

seems RFC3848 (http://tools.ietf.org/html/rfc3848) is what you're 
looking for? Please note, that the mere presence of a Received line with 
a "with" clause of  'ESMTPS' or 'ESMTPSA' in itself is no proof that the 
message actually has been sent via an encrypted channel.

/rolf

---

From: Wei Chuang <[email-masked]>
Date: Thu, 24 Oct 2013 09:50:46 -0700

On Wed, Oct 23, 2013 at 10:48 AM, Keith Moore <[email-masked]>wrote:

> 1. draft-ietf-dane-smtp-with-dane-00<http://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/>
>
> This is (mostly) about SMTP mail relaying using Opportunistic TLS, and how
> to make it work well by using TLSA records to both (a) provide a secure
> indication that the SMTP server supports STARTTLS (thus thwarting MITM
> downgrading attacks) and (b) provide a way to verify that the SMTP server
> is the right server (given a chain of DNSSEC-signed MX/CNAME/A/AAAA etc.
> records) without requiring the server to present a TLS certificate for
> every possible DNS name for which that server is authorized to accept mail.
>
> realizable goal.  But even if people want to propose an SMTP extension to
> mandate use of TLS for the remainder of the path to the recipient, I think
> it would need to use the certificate verification mechanisms described in
> this draft.
>

I just wanted to note that the draft-wchuang-msmd-00 recommends that
additional CA verification be done through Certificate Transparency
[RFC6962]. We didn't put a stronger requirement since some deployment
details are not specified (according to one of the authors), and our
understanding is that the community hasn't registered a strong preference
to either DANE TLSA or Certificate Transparency (or some other scheme).
Certificate Transparency doesn't directly depend on DNSSEC which is only
slowly being deployed, and instead builds upon the existing X.509 CA
infrastructure. It provides means for 3rd parties to observe the signing of
certificate, and quickly verify if a particular CA is doing the right
thing. To stir the pot up, I just want to point out this comparison of the
alternatives:
http://www.certificate-transparency.org/comparison

> MUAs and mail servers (IMAP, POP, Submission).   It basically has two sets
> of recommendations - one for client and server implementations, and another
> for mail service providers - because there are operational as well as
> implementation concerns.
>
> are different enough that trying to specify both in the same document made
> it too large and complex.   When I discovered that
> draft-ietf-dane-smtp-with-dane-00 existed and used the same approach I was
> recommending, and also that the dane-smtp draft had things worked out in
> more detail, I removed the portions from my draft that related to SMTP
> relaying.
>
>
> implementation.   Case (3) protects emails from being disclosed to servers
> which are operated by third parties and which might be compromised.   None
> of these is sufficient by itself, because (1) and (2) by themselves don't
> protect the messages while they're stored on third-party servers, and (3)
> doesn't protect against traffic analysis - which when dealing with mass
> surveillance seems to be as important as protecting the actual contents of
> the messages.
>
> Of these, the most difficult problem seems to be (3).   Solutions for (3)
> e.g. PGP and S/MIME have been around for a long time, but they haven't been
> widely deployed.    This seems like an area that is worth revisiting.
>

+1  (While I'm one of the authors of a TLS based approach, I'd also like to
see more discussion/ideas of privacy protecting end-to-end approaches)

-Wei

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 Oct 2013 01:52:14 -0400

On 10/24/2013 12:50 PM, Wei Chuang wrote:
>
>     To me it seems that a comprehensive approach to encrypting email
>     traffic actually needs to cover three separate cases: (1) mail
>     relaying, (2) MUA-MSP interactions, and (3) end-to-end
>     encryption.   Cases (1) and (2) are similar in goal - protect
>     emails being transmitted over the network from eavesdroppers and
>     active attacks - but subtly different in implementation.   Case
>     (3) protects emails from being disclosed to servers which are
>     operated by third parties and which might be compromised.   None
>     of these is sufficient by itself, because (1) and (2) by
>     themselves don't protect the messages while they're stored on
>     third-party servers, and (3) doesn't protect against traffic
>     analysis - which when dealing with mass surveillance seems to be
>     as important as protecting the actual contents of the messages.
>
>     Of these, the most difficult problem seems to be (3).   Solutions
>     for (3) e.g. PGP and S/MIME have been around for a long time, but
>     they haven't been widely deployed.    This seems like an area that
>     is worth revisiting.
>
>
> +1  (While I'm one of the authors of a TLS based approach, I'd also
> like to see more discussion/ideas of privacy protecting end-to-end
> approaches)

One idea I've wondered about is whether social networks (perhaps with
real-time video conferencing) can be leveraged to assist web-of-trust
style key signing.

Keith

---

From: Ned Freed <[email-masked]>
Date: Thu, 24 Oct 2013 23:00:13 -0700 (PDT)

> (or some such)

Already dealt with to this level of detail; see RFC 3848's definition of
the ESMTPS and ESMTPSA protocol types, e.g.,

Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com
  (Postfix) with ESMTPS id 737EC11E8372; Wed, 23 Oct 2013 10:48:15
  -0700 (PDT)

The real question is whether or not this is sufficient. If we
want to log the ciphersuite or similar information the way to do that is
by defining additional Received: clauses, e.g.,

Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com
  (Postfix) with ESMTPS ciphersuite SSL_RSA_WITH_RC4_128_MD5 id 737EC11E8372;
  Wed, 23 Oct 2013 10:48:15 -0700 (PDT)

or something along those lines.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 25 Oct 2013 13:01:04 -0000

>or something along those lines.

Having recently added TLS to my mail daemon, I've been looking at various
ESMTPS and ESMTPSA received headers.  Most of them put cipher info in
a comment.  Since we all seem to log that info anyway, it might be worth
inventing a standard syntax for it.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 25 Oct 2013 13:10:07 -0000

>real-time video conferencing) can be leveraged to assist web-of-trust

In theory perhaps, but I can't think of any real social networks that
I would trust enough to use for key bootstrapping.

They all have business models that depend on maximum user data which
leads to vast numbers of Facebook "friends" who you barely know, and
abominations like LinkedIn's new MITM IMAP proxy.

R's,
John

---

From: Wei Chuang <[email-masked]>
Date: Fri, 25 Oct 2013 11:23:32 -0700

Perhaps adding information about whether DNSSEC was used, as well as the
strength of the certificate verification would be useful?  This is to help
detect conditions that make MitM harder for an adversary.  For certificate
info- whether certificate was self signed, or if the signed by CA, and
whether the chain could be verified against DANE TLSA record, or by
certificate transparency.

-Wei

---

From: Brandon Long <[email-masked]>
Date: Fri, 25 Oct 2013 11:30:17 -0700

Given that you can only trust the last Received header, I'm not clear what
is accomplished.

Brandon

---

From: Wei Chuang <[email-masked]>
Date: Fri, 25 Oct 2013 11:44:13 -0700

I mentioned "conditions that make MitM harder" as this is just to help
understand and debug the delivery chain in general which I thought was the
intent of this subthread. Of course an active MitM could write whatever
they want with the content, and depending on this information for securing
a link isn't a good idea.

-Wei

---

From: Wei Chuang <[email-masked]>
Date: Fri, 25 Oct 2013 12:18:02 -0700

One other thought to the point about standardizing this- that flexibility
to extend the disclosure mechanism would be good, since it seems that
details account for in TLS is expanding over time.

-Wei

---

From: Ned Freed <[email-masked]>
Date: Fri, 25 Oct 2013 14:49:12 -0700 (PDT)

> Given that you can only trust the last Received header, I'm not clear what

False. You can trust the Received: chain back to the point where it reaches an
IP you don't trust to insert Received: fields reliably. Depending on the
circumstances that number can be anywhere from 0 to as many Received: fields as
there are in the message.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 Oct 2013 18:04:35 -0400

> there are in the message.

By the way, there might be an opportunity to improve accountability 
implied by this discussion exchange:

      signing the audit trail.

DKIM doesn't validate any content other than its own d= value, of course.

However one might define a value-added snap-on tool that declared 
content signed with the domain name asserting the snap-on tool to be valid.

So if it signed a Received sequence, including the snap-on tool/field, 
it would be declaring that Received sequence valid.  (Small issue of 
having the signature indicate exactly which Receiveds it is reference, 
since it needs to excludes the one it cannot assert trust over.)

This won't mean that the signed Receiveds automatically known to be 
valid, but it means you know who to contact about them, to the extent 
you can contact the owner of the validity-asserting signer is...

That is, I'm trying to take the implicit trust that is built into the 
model Ned just referenced and find a way to extend it with some extra 
mechanism.

d/

---

From: Paul Smith <[email-masked]>
Date: Sat, 26 Oct 2013 11:57:37 +0100

On 25/10/2013 19:30, Brandon Long wrote:
> Given that you can only trust the last Received header, I'm not clear 
> what is accomplished.

Maybe not much, but this is a similar issue to the one a 'mandatory TLS' 
spec has - if you don't trust an MTA, you just don't trust it, period.

If A sends a message to B, if you know it only goes through trusted 
MTAs, then a header saying 'this message was sent over TLS' can be trusted

If you don't know if it only goes through trusted MTAs, then it doesn't 
matter whether it was sent over TLS or not, the message has potentially 
been compromised (unless it has end-to-end encryption).

-

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 31 Oct 2013 17:22:11 +0000

Hi Keith,
I am glad to see your draft. Some specific comments:

2.1.  Mail Server Requirements

    The following requirements apply to IMAP, POP, and Submission server
    implementations:

    All IMAP, POP, and Submission servers MUST be configurable to support
    the use of TLS and the Implicit TLS mechanism when communicating with
    MUAs.

While reading your document I was wondering where the secure submission
is defined. Then I finally found a request for a new port in the IANA
considerations section.

Several MUAs and multiple MSPs implement secure submission on port 465.
This was never document and is not registered. (I think this was a Microsoft
invention, but I don't know exact history.) The port is officially
assigned to another protocol.

There are a couple of problems with that. One is trying to register 
unofficially used 465.
Alternatively, we can try to register a new port, but what are the 
chances of people
actually migrating to the new default for secure submission?

2.2.  Mail User Agent Requirements

    This section describes requirements on Mail User Agents (MUAs) using
    IMAP, POP, and/or Submission protocols.

    Note: Requirements pertaining to use of Submission servers are also
    applicable to use of SMTP servers (whether on port 25 or on another
    port as advertised by a SRV record with _smtp._tcp or _smtps._tcp
    label) for mail submission.

This note seems a bit out of place, as you already mentioned elsewhere
that MTA-to-MTA SMTP is out of scope for this document. Plus you are sort
of trying to register smtps here, but you really don't.

2.2.8.  Requirements for MUA use of TLS

    MUAs MUST use the procedure defined in [RFC6125] to determine whether
    a server's TLS certificate contains an identifier which matches the
    DNS name to which the MUA is attempting to connect, and MUST abort
    the TLS session if the server's certificate does not present an
    identifier that matches one of the MUA's predetermined reference
    identifiers for that server.

    It is important to avoid using DNS names obtained from SRV records
    (rather than from explicit user configuration) as reference
    identifiers when comparing with presented identifiers in TLS server
    certificates, unless those SRV records were signed with DNSSEC and
    the signatures were verified by the MUA.

    Note in Draft: [I-D.melnikov-email-tls-certs] describes a profile of
    [RFC6125] for use in MUA checking of presented identifiers in TLS
    server certificates.

Not surprisingly, I think that you should delete the second quoted paragraph
(my draft already includes it) and update the first paragraph to reference
[I-D.melnikov-email-tls-certs]. This would also make 
[I-D.melnikov-email-tls-certs]
normative.

The problem with your first paragraph is that just referencing RFC 6125 is
not enough to get interoperability, because any use of RFC 6125
needs to describe use or non use of several parameters, like SRV-ID, 
CN-ID, etc.

2.2.12.  Use of DANE by MUAs

   o  TLSA record exists and has a valid DNSSEC signature, and the
       public key specified in a TLSA record matches the public key in
       the X.509 certificate presented by the server.  However, the
       server certificate is not signed by a trusted certificate
       authority,

I think this might not be relevant, depending on the TLSA record type used.

       nor has the MUA been explicitly configured ("pinned")
       to accept that particular certificate.  In this case the
       connection MUST gracefully terminate the session with the server
       without attempting to authenticate or request services.

Isn't this the case for asking the user to pin the certificate?

3.3.  TLS Server Certificate Requirements

    MSPs MUST maintain valid server certificates for all servers. Those
    server certificates MUST present DNS-IDs and SRV-IDs conforming to
    [RFC6125] and which will be recognized by MUAs meeting the
    requirements of this memo.  In addition, those server certificates
    MAY provide other DNS-IDs, SRV-IDs, or CN-IDs needed for
    compatibility with legacy MUAs.

Again, I think this should reference [I-D.melnikov-email-tls-certs].

    [RFC4409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
               RFC 4409, April 2006.

This was obsoleted by RFC 6409, so there is no need to reference both 
Normatively.

---

From: Keith Moore <[email-masked]>
Date: Thu, 31 Oct 2013 15:59:54 -0400

> actually migrating to the new default for secure submission?

I think it might be tricky to get approval for a standard recommending
use of an already-assigned port 465 for mail submission.   So I suspect
the right thing to do is to still ask IANA for a new port for Submission
over TLS, but to document (non-normatively) that some implementations
are using port 465 for this purpose.

Note that if an MSP advertises its submission servers using SRV records,
it can use any port(s) it wishes to use.

> of trying to register smtps here, but you really don't.

The note could certainly use rewording.   But the basic idea is that either

a) an MSP's SRV records could advertise _smtp._tcp (or _smtps._tcp if
such a thing existed), but not _submissions._tcp, in which case the MUA
should probably assume that that service is the way to submit mail

OR

b) an MSP could document (say on its web pages) that MUAs should be
configured to submit mail to server xxx.example.com at port 25

and in either of those cases the requirements defined for mail
submission by an MUA still apply: e.g. if the configuration says "TLS
required", then the MUA MUST use TLS (whether Implicit TLS or STARTTLS)
and MUST NOT submit mail without using TLS, it MUST use the certificate
verification rules and name matching rules, it MUST NOT blindly trust
SRV records unless they're DNSSEC signed and verified, etc.

I think the _smtps._tcp is just an oversight.  I wasn't intending to
propose that we define an smtps service.

> needs to describe use or non use of several parameters, like SRV-ID,

I certainly agree that 6125 is not sufficient.

If I recall correctly, I had some questions about
melnikov-email-tls-certs that made me somewhat reluctant to reference it
as normative for my -00 draft.   But I'll reread your draft (hopefully
before Monday) and get back to you about it.

I took a stab at writing a profile of 6125 myself, and found it
difficult to write text that clearly described what needed to happen.  
There are lots of different error conditions that need to be considered,
and it wasn't clear to me what was the right thing to do for every case.

> I think this might not be relevant, depending on the TLSA record type

The DANE/TLSA text in my draft currently doesn't go into anywhere nearly
enough detail, and needs a lot of work.  For version -01 I plan to crib
from draft-ietf-dane-smtp-with-dane but I want to double check it to
make sure it makes sense.

Aside: One thing about DANE that I find very dubious is the idea that a
DNSSEC-signed TLSA record is a suitable /replacement/ for a certificate
signed by a CA.   I don't know of any reason to assume that the chain of
DNSSEC signatures from the root to the zone that signs the TLSA record
is any more trustworthy than the signature of a well-known CA.   Yes, we
know of cases where the latter have proven untrustworthy - presumably
because the CA acted inapporpriately or because its private key was
compromised - but I don't know why this is less likely to happen for
DNSSEC signatures.   I'm all for using TLSA records to provide an
additional trust anchor for a server's certificate beyond that provided
by the server's CA - so that the attacker will have to compromise
multiple parties in order to impersonate the server - but doubt that
it's a good idea to say that a signed TLSA record is sufficient by
itself.    Relying entirely on signed TLSA records actually appears to
me to be structurally weaker than relying entirely on well-known CAs.

(And I understand that small-scale servers would like to use self-signed
certificates, but I haven't yet figured out how to permit that without
making users vulnerable.... except by allowing MUAs to "pin"
certificates that aren't verifable.   And even that seems like shaky
ground, but it's probably needed for testing anyway.)

> Isn't this the case for asking the user to pin the certificate?

I would like to clearly separate two conditions:

- during configuration, it's okay to for an MUA to say "This server's
certificate isn't verifable, but if you know for sure that it's valid,
you can configure the account to trust it.   If you don't know for sure
that it's valid, you should contact your mail service provider to verify
it."

- during normal mail reading, submission, etc., it's NOT okay to offer
to let the user pin the certificate.   IMO, the MUA should report this
to the user as a potential attack and refuse to read/submit mail until
the condition is fixed.   The user should probably contact his/her mail
service provider for further instructions.

Now maybe this isn't exactly how things should be implemented.   But the
point is, if the user interface makes it too easy for the user to just
'click past' warnings without really understanding what's going on or
verifying that the condition is reasonable, we haven't gained anything
in terms of privacy in exchange for the added complexity - we've only
gained the illusion of privacy.

> This was obsoleted by RFC 6409, so there is no need to reference both

good catch.  thanks.

Keith