ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Two recent Internet-Drafts about using TLS with email protocols

2013-10-24 03:46:37
Hi, Paul,

On 10/24/2013 10:04 AM, Paul Smith wrote:
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.

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

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
<Prev in Thread] Current Thread [Next in Thread>