Subject: [ietf-smtp] Fwd: New Version Notification for draft-fenton-smtp-require-tls-00.txt

From: Jim Fenton <[email-masked]>
Date: Sun, 10 Jan 2016 14:27:46 -0800

Below is the announcement of a draft I just submitted that may be of
interest to this list. The approach here is complementary to the other
proposals I have seen along these lines (e.g., smtp-sts).

Thoughts, reviews, etc. welcomed.

-Jim

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-fenton-smtp-require-tls-00.txt
Date: 	Sun, 10 Jan 2016 14:21:37 -0800
From: 	[email-masked]
To: 	Jim Fenton <[email-masked]>

A new version of I-D, draft-fenton-smtp-require-tls-00.txt
has been successfully submitted by Jim Fenton and posted to the
IETF repository.

Name:		draft-fenton-smtp-require-tls
Revision:	00
Title:		SMTP Require TLS Option
Document date:	2016-01-10
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/internet-drafts/draft-fenton-smtp-require-tls-00.txt
Status:         https://datatracker.ietf.org/doc/draft-fenton-smtp-require-tls/
Htmlized:       https://tools.ietf.org/html/draft-fenton-smtp-require-tls-00

Abstract:
   The SMTP STARTTLS option, used in negotiating transport-level
   encryption of SMTP connections, is not as useful from a security
   standpoint as it might be because of its opportunistic nature;
   message delivery is prioritized over security.  This document
   describes a complementary option, REQUIRETLS, which causes message
   delivery to fail if a TLS connection with the required security
   characteristics cannot be negotiated with the next hop MTA or if that
   MTA does not also support REQUIRETLS.  Message originators may
   therefore expect transport security for messages sent with this
   option.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "John Levine" <[email-masked]>
Date: 11 Jan 2016 01:36:23 -0000

In article <[email-masked]> you write:
>-=-=-=-=-=-
>-=-=-=-=-=-

Interesting idea.  I implemented it on my server mail1.iecc.com.

R's,
John

PS: Of course, there's no way you can tell whether it'll actually do
anything different if you set requiretls.  The inability to detect,
much less penalize, lying strikes me as a problem.

---

From: John C Klensin <[email-masked]>
Date: Sun, 10 Jan 2016 20:49:05 -0500

--On Sunday, January 10, 2016 14:27 -0800 Jim Fenton
<[email-masked]> wrote:

> Below is the announcement of a draft I just submitted that may
> be of interest to this list. The approach here is
> complementary to the other proposals I have seen along these
> lines (e.g., smtp-sts).
> 

Jim,

I have skimmed through this.  A few observations, many of which
apply to most or all of the "other proposals along these lines"
that you mention.

(1) I appreciate the last paragraph of your Security
Considerations section.  We need to keep in mind that there are
multiple threat models to mail privacy/confidentiality and that,
if mail servers can be compromised, encryption in transit may
not add much value (or may add a false sense of security).   As
you point out,  certain DNS compromises may not be much better.

(2) The issue of encrypting information on the reverse path (not
just error messages, but delivery and non-delivery notifications
of all types) is a difficult one.  Although it is likely in the
common cases, there is no way to guarantee from the presence of
encryption capability on the forward path that encryption on the
reverse path will be supported (and properly configured, etc.)
In particular, if the preferred MX-based route between A and D
is A->B->C->D, nothing at all guarantees that the route from D
to A will go through B and C.   In a way, part of this is not
new: A doesn't have to operate an SMTP-receiver in order to send
messages to D, but it certainly needs to have one to receive
error messages (as distinct from SMTP-time rejections).

Even if you decide against it, I think you need to consider that
situation carefully and, in particular, consider whether
parameters that allow the message originator to specify levels
of preference about what should happen if notification messages
cannot be encrypted.

(3) The EAI WG struggled for a long time with the relationship
between a requirement for certain SMTP options (i.e., if the
option is requested (or required) by the client but the server
will not accept it, the message content must not be sent) and
our MX structure.  For example, suppose (to generalize, the XYY
option is at issue and required.   Suppose we have 

   example.com. IN MX 10   A.EXAMPLE.COM.
                IN MX 10   B.EXAMPLE.COM.

A supports XYZ and B does not. 

Now, suppose D.example.net wants to send a message to
[email-masked] and wants to send it with transport encryption.
RFC 5321 is fairly clear that it is to pick arbitrarily between
A and B.  If it happens to select A, then all is well.   But, if
it selects B and successfully opens the SMTP connection, B will
not advertise REQUIRETLS and your spec, as I read it, then
requires that D stop, close the session, and tell the originator
that delivery was not possible.  More complex versions of that
scenario with, e.g., choices at different preferences or names
with multiple addresses but different services supported at each
address, can create even more interesting solutions, different
paths, etc.

In the EAI case, it turns out that there is no plausible
"downgrade" path corresponding to "give up and send clear text"
in historic STARTTLS so "required extension" is the only game in
town and messages either go through or they don't.   However,
the strongest critique of EAI -- IMO an entirely valid one at
least until the protocol extensions are widely deployed -- is
that it basically divides the email world into two communities
who can't talk with each other.  You risk the same type of
issues here.    I would recommend (and, again, this applies to
this family of proposals, not just yours) careful study of the
EAI specs to help understand the issues and tradeoffs.

(4) Similarly, you can say that, if a message arrives with
REQUIRETLS, IMAP and POP clients and servers use "authenticated,
encrypted channels".  However, in actual systems as deployed,
carrying the REQUIRETLS information along the SMTP path and
acting on it may be (and typically is) far more simple than
doing whatever is necessary to carry that information through
the mail store and make it available to control the behavior of
the server side of various split-UAs.  Equally important, it is,
in the general case, impossible for a server to know what
selection of delivery-side client (and their capabilities) are
available to a given user and the idea of having some messages
in the message store for a particular user that can be retrieved
and read by that user via some clients but not others is a
troubling one.   It may, in some cases, be even more troubling
for transport security than it is for the EAI cases.   Again, a
study of the EAI specs and their history may prove helpful.

In addition, to a much greater degree with IMAP and POP than
with SMTP transport, if, e.g., an IMAP server can determine the
message content has already been encrypted by some end-t0-end
mechanism, it may be reasonable for it to care a great deal less
about an encrypted channel than it might otherwise.  Such a
server might even encrypt the message using end-to-end
techniques before delivering it (just as some IMAP servers are
set up to hold sufficient private keys and decrypt such messages
at the time they are requested by the client.   So I think that
section may need a bit more thought and explanation.

best,
    john

---

From: Jim Fenton <[email-masked]>
Date: Sun, 10 Jan 2016 19:15:52 -0800

[not sure if this is germane to the shutup list if I understand the
charter there correctly, but I'll go along with it for now]

> Interesting idea.  I implemented it on my server mail1.iecc.com.

That was quick :)

> much less penalize, lying strikes me as a problem.

You're describing a mail server that not just hasn't deployed TLS and
REQUIRETLS, but one that is being actively deceptive. There are more
fundamental undetected issues even without REQUIRETLS.

As a mail originator sending messages I consider sensitive, my biggest
concern would be that my outgoing mail operator isn't lying about
REQUIRETLS. There could easily be test reflectors that fail REQUIRETLS
in various ways, i.e., not supporting TLS at all, not supporting
REQUIRETLS, and offering certificates that don't meet various
verification requirements. If the messages go through, the user knows
that someone is lying.

The more general cases of REQUIRETLS deception, particularly within an
administrative management domain, may be hard to test, but those
probably aren't the biggest areas of concern for TLS deployment either.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Sun, 10 Jan 2016 19:38:01 -0800

> you point out,  certain DNS compromises may not be much better.

Thanks. The flip side of this is that end-to-end encryption doesn't
protect the metadata. We would still want to protect it from being
visible on the wire.

> of preference about what should happen if notification messages

This is a good topic for further discussion. One option might be to send
a bounce that contains very little information about the original
message other than the message ID and the envelope-from address. I want
to make sure that we don't expose the metadata any more than absolutely
necessary since protecting it is part of the value proposition of SMTP TLS.

I'm a little cautious about having another option for bounce treatment.
Under what circumstances would you send a message with REQUIRETLS and
not care about the security of what's in the bounce message?

> EAI specs to help understand the issues and tradeoffs.

More explicit treatment of multiple MX situations like this is
definitely needed.

I haven't been following the EAI work at all; if you have more specific
pointers to the split-communities problem you describe, that would be
very helpful.

> section may need a bit more thought and explanation.

I am trying to constrain this mechanism to the SMTP protocol as much as
possible. The intent in section 3.4 is that MDAs that support REQUIRETLS
should deliver all their mail, not just the REQUIRETLS-tagged messages,
via encrypted channels. It would be kind of a mess for IMAP to only
deliver a subset of the messages in the mailbox compared with IMAPS.
Probably even worse for POP. Delivery over encrypted channels is the
Right Thing To Do anyway.

Thanks for your comments.

-Jim

---

From: "John Levine" <[email-masked]>
Date: 11 Jan 2016 05:27:20 -0000

>> issues here.

Only sort of.  In this case, the downgrade path is obvious, you
ignore the TLS flag and send the message along.

Upon slightly more reflection, I think I see why this isn't likely to
be useful.  Any MTA that understands the REQUIRETLS flag will almost
certainly do opportunistic TLS anyway, so you haven't gained much
there.  In the absence of DNSSEC, you still have the attack where a
bad guy sends you a fake MX, so you deliver 100% securely to the wrong
place, so you have yet another steel door on a cardboard box.

If you do have DNSSEC, you can use RFC 7672 TLSA to be sure you're
delivering to the right place.  So what does this buy you in practice?

Speaking of RFC 7672, see its section 1.3 which looks to me like it
contemplates an approach like this and describes its problems.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Mon, 11 Jan 2016 02:29:02 -0500

--On Sunday, January 10, 2016 19:38 -0800 Jim Fenton
<[email-masked]> wrote:

>...
>> I have skimmed through this.  A few observations, many of
>> which apply to most or all of the "other proposals along
>> these lines" that you mention.
>> 
>> Considerations section.  We need to keep in mind that there
>> are multiple threat models to mail privacy/confidentiality
>> and that, if mail servers can be compromised, encryption in
>> transit may not add much value (or may add a false sense of
>> security).   As you point out,  certain DNS compromises may
>> not be much better.
> 
> Thanks. The flip side of this is that end-to-end encryption
> doesn't protect the metadata. We would still want to protect
> it from being visible on the wire.

Strictly speaking, hop-by-hop TLS doesn't protect "the metadata"
either.  It just protects the SMTP envelope.  The information
about what systems are connecting to what other systems is still
exposed to anyone with access to the relevant links (especially
links close to the originator) and, at least with current
technology, so are the DNS MX queries that precede the opening
of SMTP connections.  For example, if an attacker can monitor
the links out of your submission server, log all SMTP queries
for MX records and all outgoing SMTP connections, and perform
some fairly simple statistical analysis over a period long
enough to work around DNS caching (or if the submission server
is not running a full-service resolver), it would have fairly
good information about which hosts and sending messages to which
other hosts.  Following up on John Levine's comments, if,
instead of passively monitoring those links, it is in a position
to interfere with them by, e.g., mounting appropriate MITM
attacks, then, unless the client can verify the server with keys
and a very strong CA that can be trusted to verify identity
independent of domain ownership especially given the rotten
state of reverse mapping records (you do cover much of that, but
I'm not sure how plausible it is given practical experience),
the server can be spoofed by address diversion and all bets are
off.  

Of course, one gets significantly more protection from
information disclosure by transmitting from an origin at HotOl
to a destination at YaOgle, simply because of the amount of
traffic on those links, but one probably doesn't want to go
there, especially since transmission between two YaMail accounts
(or within any of the other relevant systems) doesn't involve
SMTP over the public Internet at all.

If that analysis is correct, then hop-by-hop TLS still provides
fairly good protection against casual eavesdropping, including
eavesdropping whose purpose is to see if anything interesting
turns up, but might be fairly weak against a focused and
determined attack by an attacker with significant resources.

And we should really, really, stop throwing the term "metadata"
around as if it described precise sets of information.

>> (2) The issue of encrypting information on the reverse path
>> (not just error messages, but delivery and non-delivery
>> notifications of all types) is a difficult one.  Although it
>> is likely in the common cases, there is no way to guarantee
>> from the presence of encryption capability on the forward
>> path that encryption on the reverse path will be supported
>> (and properly configured, etc.) In particular, if the
>> preferred MX-based route between A and D is A->B->C->D,
>> nothing at all guarantees that the route from D to A will go
>> through B and C.   In a way, part of this is not new: A
>> doesn't have to operate an SMTP-receiver in order to send
>> Even if you decide against it, I think you need to consider
>> that situation carefully and, in particular, consider whether
>> of preference about what should happen if notification
>> messages cannot be encrypted.
> 
> This is a good topic for further discussion. One option might
> be to send a bounce that contains very little information
> about the original message other than the message ID and the
> envelope-from address. I want to make sure that we don't
> expose the metadata any more than absolutely necessary since
> protecting it is part of the value proposition of SMTP TLS.

See above about "metadata", note that the observation of forward
and reverse path connections may provide a lot of information.
Or not, depending on the sets of systems involved.  But yes, my
thought about those parameters, while vague, involved the sender
being able to express preferences for situations in which an
encrypted reverse path was not available including drop (the
only option in your current draft), cleartext, minimal response
(maybe more variations than the one you outline above), send to
trusted third party as a fallback, and maybe some others.   An
originator who is smart and concerned enough to make rational
"I'd prefer that this message be bounced if it cannot go end to
end, encrypted during every hop" decisions out to be able to
sort those kinds of options out.   Note that we've already got
options to request non-return of content in the notification
extensions.

> I'm a little cautious about having another option for bounce
> treatment. Under what circumstances would you send a message
> with REQUIRETLS and not care about the security of what's in
> the bounce message?

I think the question is rather about how much I care and why I
care.  If my main goal is to make life miserable for casual
eavesdropping (including raising the costs to anyone who is
doing it) rather than actually to protect specific message
content and/or I know something specific about the return path
(noting that the sender or something within the sender's
administrative domain is presumed to control those MX records
although not the MX records of the destination), I actually
might not care enough to want any non-delivery messages to be
anything but crystal clear.  Similarly, if I've protected the
content end to end and in other ways, I might want the
incremental protection of envelope information by hop-by-hop
link encryption, but I might conceivably not care very much.

>> our MX structure.  For example, suppose (to generalize, the
>> XYY option is at issue and required.   Suppose we have 
>> 
>> [email-masked] and wants to send it with transport
>> encryption. RFC 5321 is fairly clear that it is to pick
>> arbitrarily between A and B.  If it happens to select A, then
>> all is well.   But, if it selects B and successfully opens
>> the SMTP connection, B will not advertise REQUIRETLS and your
>> spec, as I read it, then requires that D stop, close the
>> session, and tell the originator that delivery was not
>> possible.  More complex versions of that scenario with, e.g.,
>> choices at different preferences or names with multiple
>> addresses but different services supported at each address,
>> can create even more interesting solutions, different paths,
>> etc.
>> 
>> "downgrade" path corresponding to "give up and send clear
>> text" in historic STARTTLS so "required extension" is the
>> only game in town and messages either go through or they
>> don't.   However, the strongest critique of EAI -- IMO an
>> entirely valid one at least until the protocol extensions are
>> widely deployed -- is that it basically divides the email
>> world into two communities who can't talk with each other.
>> You risk the same type of issues here.    I would recommend
>> (and, again, this applies to this family of proposals, not
>> just yours) careful study of the EAI specs to help understand
>> the issues and tradeoffs.
> 
> I haven't been following the EAI work at all; if you have more
> specific pointers to the split-communities problem you
> describe, that would be very helpful.

Have a look at RFCs 6530-6532, noticing what they don't say as
much as what they do, and compare to 4952, 5504, 5825, 5336, and
5335 to get some sense of the earlier "try to fix it up on the
fly" techniques.   The i18n issues are different from the ones
you face, but, as I suggested, the whole notion of "if this
extension isn't acceptable and excepted, forget sending" gets a
little tricky... something we were aware of when RFC 1425 was
coming together.   One could imagine some interesting ways to
get around it, including reflecting the availability or absence
of certain SMTP extensions in the DNS, but that was before SRV
records and would have involved some of the same issues that led
to deprecating WKS.

>> REQUIRETLS, IMAP and POP clients and servers use
>> "authenticated, encrypted channels".  However, in actual
>> systems as deployed, carrying the REQUIRETLS information
>> along the SMTP path and acting on it may be (and typically
>> is) far more simple than doing whatever is necessary to carry
>> that information through the mail store and make it available
>> to control the behavior of the server side of various
>> split-UAs.  Equally important, it is, in the general case,
>> impossible for a server to know what selection of
>> delivery-side client (and their capabilities) are available
>> to a given user and the idea of having some messages in the
>> message store for a particular user that can be retrieved and
>> read by that user via some clients but not others is a
>> for transport security than it is for the EAI cases.   Again,
>> a study of the EAI specs and their history may prove helpful.
>> 
>> with SMTP transport, if, e.g., an IMAP server can determine
>> the message content has already been encrypted by some
>> end-t0-end mechanism, it may be reasonable for it to care a
>> great deal less about an encrypted channel than it might
>> otherwise.  Such a server might even encrypt the message
>> using end-to-end techniques before delivering it (just as
>> some IMAP servers are set up to hold sufficient private keys
>> and decrypt such messages at the time they are requested by
>> the client.   So I think that section may need a bit more
>> thought and explanation.
> 
> I am trying to constrain this mechanism to the SMTP protocol
> as much as possible. The intent in section 3.4 is that MDAs
> that support REQUIRETLS should deliver all their mail, not
> just the REQUIRETLS-tagged messages, via encrypted channels.
> It would be kind of a mess for IMAP to only deliver a subset
> of the messages in the mailbox compared with IMAPS. Probably
> even worse for POP. Delivery over encrypted channels is the

It is a good thought, but maybe you should just take it out and
write an IMAP/POP specific document.  To the extent to which
delivery over encrypted channels is the right thing to do
generally, it doesn't make any difference whether the message
arrived at the final delivery server via an encrypted link or
not, it is still the right thing to do.   It is fairly easy to
make the case that is the right thing to do if the IMAP
client-server connection transits the public Internet and those
two systems are under separate administrative control.  However,
if the client machine opens a well-designed secure tunnel to the
server or something with a local and protected connection to the
server and uses that tunnel for more than IMAP traffic (e.g,,
reaching web proxies, making DNS queries), then that tunnel will
hide everything, including whether IMAP is being used and
connections between the submission MUA and submission server.
Insisting that the IMAP connections then use IMAP-specific TLS
encryption is then properly described as "useless overhead".
Again, being clear about the threat models against which one is
protecting would be a big help, both in your document and more
generally.

best,
    john

---

From: John C Klensin <[email-masked]>
Date: Mon, 11 Jan 2016 02:47:29 -0500

(off list)

John, 

FWIW, my initial intuition/ reaction was very close to your
conclusion that, in practice, this was unlikely to accomplish
much.  I've wanted to push on it a little bit because, unlike
some of the folks who have been behaving as if, if they chant
"more privacy" loudly enough, real analysis and thinking about
threat models is unnecessary, I know Jim has been around long
enough and thinks clearly enough that his draft could probably
be used to push a bit on some of those issues -- including the
ones you have identified more clearly than I have, the
circumstances in which hiding the envelope reduces the amount of
information available to an eavesdropper significantly and those
in which it doesn't, etc.   I am, as predicted, finding that
discussion helpful.  I hope Jim is too.  Even more important,
I'm hoping that people with ideas much more naive than his are
paying attention.

A few comments below.

--On Monday, January 11, 2016 05:27 +0000 John Levine
<[email-masked]> wrote:

>>> entirely valid one at least until the protocol extensions
>>> are widely deployed -- is that it basically divides the
>>> email world into two communities who can't talk with each
>>> other.  You risk the same type of issues here.
> 

Not quite.  Jim suggests minimal replies, I'd probably want to
at least see non-return of content as a matter of principle.
Those downgrade paths, which not as obvious or trivial as just
ignoring the flag, do prevent exposing a lot of the information
the sender was presumably trying to protect.

> Upon slightly more reflection, I think I see why this isn't
> likely to be useful.  Any MTA that understands the REQUIRETLS
> flag will almost certainly do opportunistic TLS anyway, so you
> haven't gained much there.  In the absence of DNSSEC, you
> still have the attack where a bad guy sends you a fake MX, so
> you deliver 100% securely to the wrong place, so you have yet
> another steel door on a cardboard box.
> 
> If you do have DNSSEC, you can use RFC 7672 TLSA to be sure
> you're delivering to the right place.  So what does this buy
> you in practice?

Agreed, but it is a little worse.   If the hypothetical bad guy
has sufficient access/control to mess with both DNS replies (to
tamper with the MS responses whether DNSSEC provides warning
about that or not) and the link that SMTP-over-TLS is
protecting, then, with only a little bit more MITM interference,
it can presumably:

  (i) Let the correct MX records come back from the DNS query
  (ii) Let the IP addresses associated with those MX records
come back correctly, whether as additional information or in a
separate query-response transaction.   Up to this point, DNSSEC
would be happy.
  (iii) Intercept the target IP address and direct the traffic
to a compromised system.

Unless I've missed something, 7672 doesn't help.

> Speaking of RFC 7672, see its section 1.3 which looks to me
> like it contemplates an approach like this and describes its
> problems.

Yep, at last some of them.

thx.
    john

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 11 Jan 2016 10:14:18 +0100

Hi, John,

On 11-01-16 02:49, John C Klensin wrote:
> that delivery was not possible.  

Isn't this a generic problem when MX hosts for a domain provide
different 'levels of service'? I mean: if MX host A advertises a SIZE of
10 Mbyte and MX host B advertises a SIZE of 15 Mbyte, a message of 12
Mbyte may reach or not reach the destination, dependent on which MX host
is used to transfer the message.

And to a lesser extent, the difference in 'service' applies for support
of DSN and other extensions as well. Isn't it primarily the
responsibility of the domain owner to use MX hosts with equal
characteristics? Granted, the Sender may experience inconsistent
behaviour when the Receiver chooses to use MX hosts with different
characteristics, but the question is: do we have to take this into
account when designing (new) protocols? I think the answer is 'yes, but
to what extent'?

/rolf

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 11 Jan 2016 11:38:46 +0100

Hi Jim,

On Sun 10/Jan/2016 23:27:46 +0100 Jim Fenton wrote: 

> Below is the announcement of a draft I just submitted that may be of interest
> to this list. The approach here is complementary to the other proposals I have
> seen along these lines (e.g., smtp-sts).

Your approach looks rather similar to Courier's "SECURITY" extension than
Strict Transport Security.  I think you'd be interested in having a look to the
former.  For example, its provision to increase the requirement level allows
practical use of the extension even in the absence of supporting MUAs.

http://www.courier-mta.org/draft-varshavchik-security-smtpext.txt
(That was implemented in 2001, before DANE, and even before SNI.)

> Thoughts, reviews, etc. welcomed.

Neither proposal seems to allow clients to specify a set of root CAs (to be
transmitted along with the envelope).  That lack is tantamount to assuming that
the trust relationship is transitive.  Is it, or is it me?

Ale

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

---

From: Tony Finch <[email-masked]>
Date: Mon, 11 Jan 2016 12:15:47 +0000

> proposals I have seen along these lines (e.g., smtp-sts).

This is a good idea.

REQUIRETLS should be a MAIL FROM parameter, since it relates to a specific
message rather than to the session.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: West or southwest, veering northwest, 7 to severe gale 9,
decreasing 5 to 7 later. Rough or very rough, occasionally high. Thundery
showers. Good, occasionally poor.

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Mon, 11 Jan 2016 09:07:20 -0500

At 20:49 -0500 on 01/10/2016, John C Klensin wrote about Re: 

>address, can create even more interesting solutions, different

There is another way to handle this situation that we already use for 
connect fails. When I try B and can not connect I can try A and if 
that also fails go to some MX with a higher priority value number.

In this case of B not returning XYZ, in lieu of giving up 
immediately, why not try A FIRST? Only when ALL the first priority 
MXs get rejected would we give up and bail out. I note that this may 
not cover the complex scenario version you reference but it can 
handle some simple versions such as the single setting support one.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 11 Jan 2016 08:08:10 -0800

On 1/10/16 11:29 PM, John C Klensin wrote:
[points out that envelope information isn't all the metadata, and this
would only protect envelope information]
> around as if it described precise sets of information.

I winced a bit as I typed the word metadata, because of course the fact
of a connection between two MTAs is metadata in itself. I'll resolve to
be more precise in my terminology. But SMTP TLS protects about more than
the envelope information: the message header, including header fields
like Subject, To, and Cc, are sent in the clear for end-to-end encrypted
email, and this reveals a lot more information to an eavesdropper.
> options to request non-return of content in the notification

Doing something other than drop the bounce needs to be considered very
carefully because it has the potential to be exploited. I'm particularly
concerned about the trusted third-party fallback: granted that this
creates another reason to bounce a message, but if bounces are that
critical, wouldn't someone have already proposed fallback bounce mechanism?
> link encryption, but I might conceivably not care very much.

This is just semantics; "make life miserable for casual eavesdropping"
strikes me as an answer to "why".
> records and would have involved some of the same issues that led

Looks like I have a bit of homework to do. I can definitely see how
REQUIRETLS would create a community of a subset of MTAs that can
communicate when that option is requested, but I don't see any situation
where a non-REQUIRETLS capable sender would not be able to send to the
REQUIRETLS community.

> protecting would be a big help, both in your document and more

Maybe an IMAP/POP document will come along eventually, but in any case
it's important to acknowledge the need for secure delivery.

-Jim

---

From: John C Klensin <[email-masked]>
Date: Mon, 11 Jan 2016 11:10:26 -0500

--On Monday, January 11, 2016 10:14 +0100 "Rolf E. Sonneveld"
<[email-masked]> wrote:

>> possible.  
> different 'levels of service'? I mean: if MX host A advertises
> a SIZE of 10 Mbyte and MX host B advertises a SIZE of 15
> Mbyte, a message of 12 Mbyte may reach or not reach the
> destination, dependent on which MX host is used to transfer
> the message.
> 
> And to a lesser extent, the difference in 'service' applies
> for support of DSN and other extensions as well. Isn't it
> primarily the responsibility of the domain owner to use MX
> hosts with equal characteristics? Granted, the Sender may
> experience inconsistent behaviour when the Receiver chooses to
> use MX hosts with different characteristics, but the question
> is: do we have to take this into account when designing (new)
> protocols? I think the answer is 'yes, but to what extent'?

Right.   Of course it is.  But, at least from my point of view,
we've historically optimized Internet email in favor of messages
getting through.  If someone needs to make a choice between more
robustness through absolutely consistent service offerings,
we've generally chosen the robustness.  If we've had a choice
between a cruddy gateway and not being able to move messages
between some other system and Internet mail, we've usually
embraced the cruddy gateway.  Our historical response to a
message with fouled-up headers has been to deliver it based on
envelope information and let the recipient system sort things
out.  Until MIME and the SMTP extension model came along, we
didn't even have a clear requirement that messages contain
822-ish bodies to be delivered (although there were wide
differences in interpretation about what to do when they
didn't).  

Postel's robustness principle has been really important to the
design and our standards have been written on a model of "if you
deviate, the behavior is undefined and we don't make any
promises about what will happen" rather than "follow our rules
or abandon hope of message delivery".

We've taken several steps away from those principles in recent
years, including the notion that it is ok for relays to open
messages, review them for signs of spam, malware, and other bad
behavior, and treat the messages harshly if those signs appear.
But, for legitimate messages, we've mostly still been on track
with "try to deliver it no matter how messed up things are"
Even SIZE was thought of as more of a "these are my limitations,
try to adjust to them" statement than as a prohibition (you may
recall that it was specified partially in the context of
assumptions that message/partial would be adopted and deployed,
allowing a sender who encountered size limitations to break the
message into chunks rather than bounding/rejecting it).

I see moves in the direction of "if you don't implement this,
the mail isn't going to go through" as bringing two problems
with them:

(i) They will tend to divide the Internet into islands,
separating those who implement from those who haven't or refuse
to (or who are prohibited to do so by some regulatory process).
We can probably stand an island or two, especially when their
boundaries are transitional and inclusive, but the problem with
islands of this type is that they are determined by the
intersection among requirements rather than being independent
with each function.   Certainly there were several alternatives
to the Internet (not just for email) who have had experience
with islands determined by option and parameter profiles.  They
became, in Marshall Rose's words, the road kill on the
information superhighway.

(ii)  They reinforce any inclinations powerful providers might
have to say "I've got 5 gadzillion mailboxes; if you want to
communicate with any of them, you are going to use my protocol
profile and options".   If different of those providers adopt
different profiles, we fall back to the days where mail sending
systems have to know which destinations maintain which profiles
and adjust what they send accordingly (the WKS experience
notwithstanding, we probably know how to do that, but it is a
pain and maybe not as robust as we would like, especially where
distribution lists or mailing list exploders are concerned).
More important, it risks creating an environment in which users
have to maintain mailboxes on separate systems to communicate
with the users of those system.  Any of those of us who have
been there (and I think that likely includes you and Jim)
understand why it is not a good way to have to live.

Now that doesn't mean we shouldn't do it if it is really
important.  The email i18n community concluded that, for them,
the SMTPUTF8 extensions actually were.   Frankly, I still wonder
whether we would have been better off sticking with basic Latin
addresses and focusing more on 5322 display names and maybe a
non-mandatory SMTP extension to include those names in the
envelope and, even though I usually think they/we made the right
decision, I will probably continue to wonder until SMTPUTF8 is
so widely deployed that we don't need to worry about that as an
island and more.    

However, for each new mandatory, "this may create another set of
islands and it narrows my configuration options and choices and
management of fallback MX servers" feature, I think we have to
think at least as carefully about whether the value-added is
real and whether it justifies the costs and risks to Internet
mail as a whole as about whether we can make the feature work
among cooperating parties.  I know this puts me in the minority
in the IETF right now, but I don't think that "improves privacy"
is sufficient to justify those costs, no matter how high or
risky they are.  In that context, analyses like John Levine's
that address the question of how much incremental privacy such a
feature buys and my continuing concern that, for most types of
attackers, it has historically been much easier to compromise
hosts and servers than the transit network are really important,
even if they just contribute to a better understanding of the
attacks we are protecting against or the cost-benefit tradeoffs.

best,
    john

---

From: Jim Fenton <[email-masked]>
Date: Mon, 11 Jan 2016 08:23:43 -0800

> ignore the TLS flag and send the message along.

That's the opposite of the goal here. SMTP makes tries to delivery
messages, even if that results in a downgrade in security. The goal here
is to fail the transmission of REQUIRETLS tagged messages that can't be
sent in accordance with the originator's security requirements.

> place, so you have yet another steel door on a cardboard box.

The goal here is to not send messages to MTAs that don't do TLS (and
REQUIRETLS).

But you make a good point about the fake MX problem: if you're concerned
about DNS attacks, you need to make sure that the recipient domain, and
not just the domain of the MX server, is DNSSEC protected. That's an
oversight in the specification I will correct.

> delivering to the right place.  So what does this buy you in practice?

It buys the originator of the message the ability to specify that TLSA
actually be used. As long as it's opportunistic, the message might be
sent in the clear, and TLSA is then moot.

> contemplates an approach like this and describes its problems.

This directly addresses the STARTTLS Downgrade Attack in 1.3.1 and does
not require sender policy as described in 1.3.3. The problem of too many
certificate authorities in 1.3.4 is addressed by the DANE option. The
Insecure Server Name Without DNSSEC in 1.3.2 will be addressed when I
correct the above oversight.

-Jim

---

From: "John Levine" <[email-masked]>
Date: 11 Jan 2016 16:29:56 -0000

>the sender was presumably trying to protect.

I meant obvious as in what people will do as opposed to what matches
the semantics of some threat model.  If you have an EAI message with
a UTF-8 address, handing that to a non-EAI mail server is unlikely
to do anything useful.  If you have a tls-only message, handing it
to a non-tls-only mail server is likely to get it delivered, albeit
without the TLS coverage and perhaps (lacking DNSSEC) to the wrong
place but that could happen anyway.

>Unless I've missed something, 7672 doesn't help.

With RFC 7672 the MX and A/AAAA records are signed so you know you
have the right IP address.  There's also a signed TLSA record for the
MX, e.g.

  _25._tcp.mailserver.example.com IN TLSA blah

If the mail server you contact doesn't present a certificate that
matches the TLSA record, you know you have problems.

By my reading of 7672, if a domain goes to the trouble of publishing
the signed MX, A, and TLSA, you should believe it and decline to
deliver mail if you don't get the right cert.  This is basically the
reverse side of Jim's proposal, the recipient asserts that it does TLS
rather than the sender asserting that it wants TLS.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 11 Jan 2016 16:34:01 -0000

>sent in accordance with the originator's security requirements.

Of course, but there's no reason for recipient MTAs to pay any
attention to the tag if they don't want to.  There is no penalty to
them for doing so.  With EAI there's at least the penalty of messages
getting smashed.

>oversight in the specification I will correct.

RFC 7672 which has already addressed that issue in great detail.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Mon, 11 Jan 2016 08:36:28 -0800

> (That was implemented in 2001, before DANE, and even before SNI.)

Hadn't heard of this; I'll have a look.

> the trust relationship is transitive.  Is it, or is it me?

Rather than specify root CAs, REQUIRETLS has an option to require that
certificates be verified via DANE (TLSA). My thought is that a sender
that is concerned about PKI-related attacks probably wants to avoid the
CAs entirely.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Mon, 11 Jan 2016 08:39:15 -0800

> message rather than to the session.

I hadn't considered MAIL FROM parameters. That has the nice property
that it removes some inappropriate statefulness from the session. Let me
see what that would look like.

-Jim

---

From: John C Klensin <[email-masked]>
Date: Mon, 11 Jan 2016 11:45:17 -0500

> There is another way to handle this situation that we already
> use for connect fails. When I try B and can not connect I can
> try A and if that also fails go to some MX with a higher
> priority value number.
> 
> immediately, why not try A FIRST? Only when ALL the first
> priority MXs get rejected would we give up and bail out. I
> note that this may not cover the complex scenario version you
> reference but it can handle some simple versions such as the
> single setting support one.

Without commenting on whether I think it is a good idea or not,
it is an obvious one (and one that EAI did talk about).  But it
violates the retry model in 5321 as now written (and in 974 --
nothing much has changed in that area in the 30 years (this
month) since 974 was published).  Could we change SMTP or invent
an extension that would change the behavior?  Probably.   But
that leaves the "is it a good idea" question, especially in the
light of the observation that, if the parties configuring the MX
entries, preferences, and machines are sensitive to the issue
and really care, it is possible to have all configured servers
support the same services.

Other questions include whether, if there are a whole collection
of MX records with different preference levels and one can't get
through to any of the best-preference ones, does one try
multiple servers at the first preference level to which a
connection is possible?  Higher-numbered preferences if those at
one level are not sufficient?  Remember that, if one reaches a
third-preference-tier server, it has no obligation to use SMTP
and the better MX preferences to forward the message -- it can
do any or a wide range of out-of-band things.   Also remember
that any of these steps converts "try" from "see if you can open
a TCP connection and whether it times out or is reset or
otherwise rejected" into "open a TCP connection and start
negotiating".  The historical assumption has been that the costs
are very different.

    john

---

From: John C Klensin <[email-masked]>
Date: Mon, 11 Jan 2016 12:17:07 -0500

Sorry... I'm still missing something...

--On Monday, January 11, 2016 16:29 +0000 John Levine
<[email-masked]> wrote:

>...
> I meant obvious as in what people will do as opposed to what
> matches the semantics of some threat model.  If you have an
> EAI message with a UTF-8 address, handing that to a non-EAI
> mail server is unlikely to do anything useful.  If you have a
> tls-only message, handing it to a non-tls-only mail server is
> likely to get it delivered, albeit without the TLS coverage
> and perhaps (lacking DNSSEC) to the wrong place but that could
> happen anyway.

Ok.  I get that part.  And there is less different from the EAI
case than you presume.  In the EAI case, what the originator
does upon discovering the message couldn't be delivered is to
try to find an all-ASCII address (and/or pick up the virtual
telephone).  In this case, it tries to find a non-TLD-only
server (which may be hard if, as other messages have suggested,
all servers for a given destination have exactly the same
service configuration).  Perhaps the easiest way to do that is
to find a different/better address... and that is almost exactly
the same as the EAI case.   Where the two cases actually differ
is that all that needs to be done for the TLS case is to find a
server that will let the message through; for EAI, the
originator is likely (but not always) to have to some serious
alterations to message, or at least message header, content.

Howver...

> With RFC 7672 the MX and A/AAAA records are signed so you know
> you have the right IP address.  There's also a signed TLSA
> record for the MX, e.g.
> 
> If the mail server you contact doesn't present a certificate
> that matches the TLSA record, you know you have problems.
> 
> By my reading of 7672, if a domain goes to the trouble of
> publishing the signed MX, A, and TLSA, you should believe it
> and decline to deliver mail if you don't get the right cert.
> This is basically the reverse side of Jim's proposal, the
> recipient asserts that it does TLS rather than the sender
> asserting that it wants TLS.

Ok.  So you are a sender.  You have an IP address, say 1.2.3.4,
that you have gotten from the DNS after making an MX query.  It
is signed, certified, and gold-plated.  You open a TCP
connection to port 25 on that address and send the packets out.

I'm a nasty and motivated attacker who has compromised part of
either your LAN or the WAN (before the LAN of the delivery
server) your connection has to traverse, and I've compromised it
thoroughly -- not only can I eavesdrop, but I "own" the routers.
I can take the packets you are sending to 1.2.3.4 and divert
them anywhere I like.  If you want a cert bound to that address,
I can make one up and send it to you.

Now, one could further harden that by making DNS records that
identified, e.g., the CA that would be required to sign any
certs or records from the address.  My skimming of 7672 suggests
it doesn't go that far.  Other DANE pieces sort of try.
Experience with the variable quality of coordination and
cooperation between mail server operators and DNS operators in
organizations large enough to have them be separate functions
suggests that level of linkage will lead to a lot of false
negatives and unnecessary rejections, but maybe that is a
different matter. 

We have a mechanism, IPSEC, for protecting against those types
of attack.  I'm pessimistic about our really being able to
emulate its functionality at the applications layer.  

On the other hand, as I understood you to point out earlier, if
the recipient asserts it can accept TLS in a way that makes both
the assertion and the addresses and credentials verifiable, then
the value added by a "if you refuse to do this, reject the
message" extension is fairly small.

     john

---

From: "John R Levine" <[email-masked]>
Date: 11 Jan 2016 12:49:47 -0500

> either your LAN or the WAN ...
> If you want a cert bound to that address,
> it doesn't go that far.

Ah, but it does.  That's what the TLSA record is.  It has too many options 
(being after all a recent product of the IETF) but it can contain a hash 
of the certificate itself, or a hash of the CA signing certificate that 
the SMTP server has to offer when it does the STARTTLS.

> Experience with the variable quality of coordination and cooperation 
> between mail server operators and DNS operators in organizations large 
> enough to have them be separate functions suggests that level of linkage 
> will lead to a lot of false negatives and unnecessary rejections, but 
> maybe that is a different matter.

I wouldn't disagree, but if you want a path for your mail that prevents 
MITM, it's hard to see how to make it any simpler.  This is the same issue 
that DANE has had all along, that the people who understand DNS and who 
manage DNS are often not the ones who manage whatever applications are 
using certificates.  It's only been in the past couple of weeks that 
there's even been a beta version of openssl that can check DANE certs.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 11 Jan 2016 11:25:28 -0800

> them for doing so.  With EAI there's at least the penalty of messages

Misbehavior by MTAs is outside the scope of the threat model for SMTP
TLS. I have already described how such behavior could be detected; the
erosion of trust resulting from that is likely to be harmful to the mail
provider's business model.

-Jim

---

From: Sam Varshavchik <[email-masked]>
Date: Mon, 11 Jan 2016 19:22:01 -0500

Jim Fenton writes:

> interest

Originally, back in 2001, before DANE existed, I took a different tack on  
addressing the PKI issues, which is also described, less formally, here:

http://www.courier-mta.org/install.html#esmtpsecurity

Last time I checked, setting up DNSSEC is still a bit painful. Few  
registrars, TMK, support DNSSEC directly. Maybe this has changed.

---

From: "John Levine" <[email-masked]>
Date: 12 Jan 2016 02:00:41 -0000

>registrars, TMK, support DNSSEC directly. Maybe this has changed.

https://www.icann.org/resources/pages/deployment-2012-02-25-en

It's changed somewhat.  Some large registrars like Godaddy, Gandi, and
Tucows support it, some like NetSol don't.  I have about 300 zones on
my DNS server, all signed locally, but I've only been able to upload
the DS records for half of them.

For DANE, application software that supports TLSA and DNSSEC based TLS
verification is still pretty thin.  Versions of opsnssl with DANE
support only became available within the past month.

Having said all that, it's still far from clear to me that something
other than DANE would work any better, particularly considering how
cruddy the CA world is turning out to be.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 12 Jan 2016 09:56:11 +0100 (CET)

> cruddy the CA world is turning out to be.

As with IPv6 it considerably varies per country/region/TLD. Statistics for the ccTLD .nl can be found here:

http://stats.sidnlabs.nl/#dnssec

It appears some 43.9 percent of the 5.5 million domainnames under .nl are signed (2.4 million domainnames). The page shows also some information about DANE queries. This however doesn't say anything about the registrars...

/rolf

---

From: Claus Assmann <[email-masked]>
Date: Tue, 12 Jan 2016 06:20:34 -0800

! 1.  Introduction
! ...
!    messages.  In this application, TLS is used only upon mutual
!    agreement (successful negotiation) between the client and server; if
!    this is not possible, the message is sent unencrypted.  Furthermore,

That's not the case for all MTAs. sendmail only recently introduced
an option to allow this:

	To automatically handle TLS interoperability problems for outgoing
		mail, sendmail can now immediately try a connection again
		without STARTTLS after a TLS handshake failure.

This was triggered due to the decision of OpenSSL to enforce some
policy in the library without a simple option to override that and
the resulting delivery problems...

Before that, mails would get stuck in the queue and hopefully get
the attention of a postmaster to fix the interoperability problem.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 12 Jan 2016 07:13:27 -0800

> the attention of a postmaster to fix the interoperability problem.

That's good to know, but isn't quite the situation the draft was trying
to describe. The "negotiation" intended here was support for STARTTLS
itself. If the server MTA doesn't advertise STARTTLS in its EHLO
response, clients will generally just send mail without negotiating TLS.
Likewise, if the client MTA doesn't want to do STARTTLS, the server will
accept mail anyway. Similarly, the client will usually ignore failure of
the server's certificate to verify (other than to perhaps log this fact).

-Jim

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 12 Jan 2016 16:45:18 +0100 (CET)

Hi, Jim,

> response, clients will generally just send mail without negotiating

The ambiguous way 'negotiation' is used here in these two lines is quite confusing and I'd suggest you use another term in your draft for the mere advertisement of STARTTLS and the detection of support for STARTTLS by the client.

Regards
/rolf

---

From: Jim Fenton <[email-masked]>
Date: Tue, 12 Jan 2016 10:48:30 -0800

> The ambiguous way 'negotiation' is used here in these two lines is quite confusing and I'd suggest you use another term in your draft for the mere advertisement of STARTTLS and the detection of sup…
Fair enough. I'll try to word it better in the next revision.

-Jim