> On May 1, 2016, at 5:19 PM, John Levine <[email protected]> wrote:
>
> Reporting is an important part of the design and I'd like the WG to
> adopt the draft.
One pertinent question is whether DMARC is sufficiently similar to make
aligning the reporting protocols the right course of action.
IIRC with DMARC the party receiving the reports is the purported origin
of messages that pass or fail authentication at some receiving system.
With STS (and DANE SMTP) the party interested in the report is not the
origin, but rather the operator of the nexthop SMTP server.
One way to dramatically simplify reporting is communicate the reports
in-band. That is, when authentication of a peer fails, complete the
TLS handshake anyway, and send a suitable SMTP command that signals
some detail of the TLS authentication failure, before sending QUIT.
The example below is a quick sketch:
S: 220 <servername> ESMTP
C: EHLO <clientname>
S: 250-<servername>
250-<TLSREPORT>
250 STARTTLS
C: STARTTLS
S: 250 Make my day
C&S: <TLS handshake that fails authentication>
C: EHLO <clientname>
S: 250 <servername>
C: TLSREPORT STS example.com FAILED
OR
C: TLSREPORT DANE _25._tcp.smtp.example.com FAILED
S: 250 OK
C: QUIT
S: 221 Ciao
The content that goes with "TLSREPORT" would perhaps be a bit
more detailed.
Note that this way of doing it reports on cases where clients
fail to authenticate the legitimate server because of operational
issues on one or the other side. If the server were a real MITM,
it might pretend to accept the reports and the real server would
not learn that a client encountered an MITM attack.
I think that's OK, I don't expect that reports of real MITM are
the main concern or would be much more reliable out of band.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
