On Thu, Feb 20, 2014 at 11:50:19AM -0500, Wietse Venema wrote:
> WHAT STATUS INFORMATION TO LOG
> ==============================
> If cost is not a concern, then we could log everything like this:
>
> ... tls_protocol=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384
> tls_keysize=256/256 ...
>
> This format is fully extensible, but it adds a lot to the logfile,
> and it repeats all the information that is already logged when the
> TLS handshake is completed.
>
> Currently people seem to care primarily whether mail was delivered
> in plaintext or not, so we could suffice with just the TLS cipher.
>
> tls_cipher=ECDHE-RSA-AES256-GCM-SHA384
>
> Alternatively we could use a non-extensible format such as
>
> tls_status=TLSv1/ECDHE-RSA-AES256-GCM-SHA384/256/256
For an SMTP client per-record log entry I'd suggest a very condensed
format:
smtp[pid]:
QUEUE-ID:
to=<rcpt>,
[orig_to=<orig_rcpt>,]
[security=none|passive|active,]
in which "passive" protects against passive attacks and consolidates
Anonymous, Untrusted and Trusted, while "active" protects against
MITM attacks and handles "Verified" connections (success at security
level "fingerprint", "verify", "secure" or "dane").
My guess is that the protocol version, cipher bits, ... are rarely
interesting at this level. People just want to know the overall
channel security status. The "security" element can either be
always present, with "none" to signal non-TLS delivery, or simply
absent to signal the same.
For the SMTP server, if the server actually makes use of a client
certificate, it can be reasonably confident that its connection
with that client resists active MITM attacks. More generally,
one would expect to see one of:
security=none|passive
channel integrity for SMTP is generally the sender's job.
--
Viktor.
