Subject: Re: [Uta] Updated SMTP STS Draft

From: Jim Fenton <[email-masked]>
Date: Sun, 1 May 2016 11:18:28 -0700

On 4/25/16 6:49 AM, Leif Johansson wrote:
> On 2016-04-25 15:37, Leif Johansson wrote:
>>
>> Thanks,
>>
>> In BA there was consensus (pretty strong at that) to adopt this draft as
>> a WG document.
>>
> s/this draft/these drafts/
>
> This is 2 (two) separate consensus calls. Please express your support
> or objection for either/both documents going forward as WG documents.
>
>> This starts an adoption call for adoption as a WG document. Please
>> indicate your support or objection (with motivation) for WG adoption
>> no later than EOB (any TZ) May 1st
>>
>> 	Cheers Leif

1. TLSRPT

This looks like a useful extension, analogous in some ways to the
reporting aspects of DMARC which I understand have been beneficial. I'm
not sure how reporting fits with the UTA WG's charter though: perhaps as
one of the 'best practices' that it alludes to? With that caveat, I
support adoption of TLSRPT as a WG document.

2. STS

I'm a bit more concerned about STS. We effectively already have a policy
mechanism for SMTP servers to advertise their use of STARTTLS, but an
insecure one: the EHLO response. Other than requiring the use of DNSSEC
(which I think everyone agrees is a non-starter), other options for
domains to publish STARTTLS policy all have some security problems that
we are trying to work around by "webby" mechanisms. STS was supposed to
be easier to deploy than alternatives that required new MTA software,
but with the requirements to deploy web servers, and possibly a new
discovery mechanism to figure out where to look for them, I'm not sure
it is as easy to deploy as it once looked.

In the IRTF Open Session at IETF 95, one of the papers said that
STARTTLS  is stripped on 96.1% of email coming from Tunisia (and
significant fractions from other countries as well). We should be asking
whether STS would improve that situation, or simply whether whoever is
doing the blocking could deploy mechanisms to defeat STS as well. If it
wouldn't, long term, improve that number, we shouldn't be adding
complexity. If there are other classes of attack that would be defeated
by STS, I'd like to understand them.

For those reasons, I do not support adoption of STS as a WG document.

-Jim

---

From: "John Levine" <[email-masked]>
Date: 1 May 2016 19:32:01 -0000

>support adoption of TLSRPT as a WG document.

For DMARC, the reporting has been an essential step for large
providers so they know what will happen before they turn any of policy
knobs.  I expect the same would be the case here.

R's,
John

---

From: Daniel Margolis <[email-masked]>
Date: Sun, 1 May 2016 22:03:55 +0200

> by STS, I'd like to understand them.

Maybe this paper? http://conferences2.sigcomm.org/imc/2015/papers/p27.pdf

Presumably an attacker who can block 100% of STARTTLS can block STS policy
discovery, I agree. Transparency is a partial fix for such a scenario
(towards which TLSRPT is a small, albeit similarly vulnerable, step), but
I'm not sure there's a real fix--if your only means of communication are
completely controlled by an adversary, they can simply block all encrypted
traffic.

Do you think there are scenarios where the MITM may be transient, though,
as with (temporary) DNS injection, BGP misrouting, etc? I think in such a
scenario STS surely adds value; no?

Dan

---

From: "John Levine" <[email-masked]>
Date: 1 May 2016 21:19:33 -0000

>We'd like others to review and encourage further discussion relating to these drafts.  Thank
>you for your time.

Reporting is an important part of the design and I'd like the WG to
adopt the draft.

Having said that, the draft is missing a lot of details on how the
reports are sent.  Fortunately, most of the details can be borrowed
from DMARC: the report is a file of JSON with a name created by a rule
combining the reporter, the recipient and a timestamp, compressed with
gzip and sent as an application/gzip attachment.  This is exactly like
DMARC, substituting JSON for XML.

DMARC originally had both http and mail reporting.  I noticed fairly
late in the process that the http reporting in the spec wouldn't
actually work, so either they should fix the spec or take it out.
Since nobody had done http reporting and nobody was planning to, they
took it out.  Same choice here: it'd be easy enough to fix the text
saying that the https reporting does a PUT of an application/gzip just
like the one that'd be attached to the mail, but unless someone has a
concrete plan to implement it, I'd take it out. 

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 1 May 2016 20:45:16 -0400

> On May 1, 2016, at 5:19 PM, John Levine <[email-masked]> wrote:
> 

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.

---

From: "John Levine" <[email-masked]>
Date: 2 May 2016 00:53:32 -0000

>some detail of the TLS authentication failure, before sending QUIT.

One of the reasons DMARC reports are useful is that large domains
often don't know where all their mail servers are.  Sending the
reports to one place makes that possible.  More often than not the
reports go to a third party like Agari who does the crunching.  This
situation seems very similar to me.

Also, it would operationally be a terrible idea to demand that a
provider make software changes to every single one of its mail servers
just to collect a few statistics about how their TLS is working.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 1 May 2016 21:14:20 -0400

> On May 1, 2016, at 8:53 PM, John Levine <[email-masked]> wrote:
> 
> often don't know where all their mail servers are.

Yes, often true for outbound mail, where various internal teams
operate or outsource some specialized email flow.

This does not apply to inbound mail.  They'd better know where
their inbound mail servers are, their names and IP addresses are
listed in the MX records, and matching certificates have to be
provisioned and kept up to date.

Inbound and outbound email are very different problem spaces.

> More often than not the
> reports go to a third party like Agari who does the crunching.

Would that still make sense for inbound TLS reporting?  I'm
somewhat skeptical.

> just to collect a few statistics about how their TLS is working.

There's no need to modify every server.  Just as many of the inbound
servers as one wants to modify for a representative sample of the
traffic.  If a bunch of servers behind a load-balancer have the same
configuration (there may a few such bunches behind a single VIP) then
enabling reporting at one or two of them will quickly yield
representative data through the law of large numbers.

Ultimately, one would roll out support for the hypothetical SMTP verb
across the board.

The key thing to keep in mind is that reporting is a favour that sending
systems are willing to perform for receiving systems.  Therefore, it is
more important that reporting be simple for sending systems.

If reporting is too complex on the client side, it might not happen at all.

Also there need not be just one way to do reporting.  The in-band proposal
is just one way to it synchronously, without needing to accumulate aggregate
state on the client, and in a manner that works well when delivery ultimately
succeeds with a second MX host after failing on the first.

There can also be an aggregate asynchronous channel.  Clients would choose
whichever works best for them.

-- 
	Viktor.

---

From: "Brotman, Alexander" <[email-masked]>
Date: Mon, 2 May 2016 01:17:26 +0000

If a system is misbehaving in some way that causes TLS problems, it may be malfunctioning in other ways that would prevent reports from making it to the appropriate place.  It might be useful to get that new command (QUIT does not take an optional parameter that I'm aware) to indicate to the receiving system why you're terminating the session, but I would agree that the detailed information should be delivered outside of that session.

--
Alex Brotman
Engineer, Anti-Abuse
Comcast
x5364

________________________________________
From: Uta <[email-masked]> on behalf of John Levine <[email-masked]>
Sent: Sunday, May 1, 2016 8:53 PM
To: [email-masked]
Subject: Re: [Uta] draft-brotman-smtp-tlsrpt

R's,
John

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

---

From: Leif Johansson <[email-masked]>
Date: Mon, 2 May 2016 22:29:40 +0200

> no later than EOB (any TZ) May 1st

Honestly I can't tell from the thread if there is consensus or not.

---

From: "John Levine" <[email-masked]>
Date: 2 May 2016 22:27:23 -0000

>Honestly I can't tell from the thread if there is consensus or not.

I don't think it's perfect, but I do think the problem it addresses
is real and the basic approach: publishing policies, and collecting
reports about actual practices is sound.

So yes, please adopt it so we can fix the problems, all of which are
soluble.

R's,
John

---

From: Mark Risher <[email-masked]>
Date: Tue, 3 May 2016 07:38:54 -0700

Thanks, John.

Others, we tried to stay as close as possible to the discussion from the
face-to-face meeting, but if anyone sees too much divergence please let us
know. There is clearly work needed on these docs, but the advice I received
was to get it into the WG sooner so we could work on it together.

I appreciate any suggestions or advice,
/m

--
Mark E. Risher |  Group Product Manager |  [email-masked] |  650-253-3123

---

From: Chris Newman <[email-masked]>
Date: Wed, 4 May 2016 15:04:41 -0700

I am opposed to using CBOR. CBOR is not well deployed. Most codebases need XML and JSON parsers but do not need CBOR parsers. So choosing CBOR significantly increases the code complexity. My codebase has a JSON and XML parser but no CBOR parser. I would strongly prefer to keep it that way, so CBOR would introduce an unnecessary deployment barrier.

Binary formats have an extremely poor track record for security-sentive applications. ASN.1 BER/DER has been an utter disaster for real-world security in PKIX (there are probably hundreds of CVE reports due to ASN.1 parser bugs including many in TLS/SSL/PKIX stacks). We should not repeat this design error in a security-sensitive context again.  

JSON parsers are widely used, simple and have been well analyzed for security usage. They are a good choice for a security sensitive context (excluding the naive Javascript implementation). Most deployed JSON parsers are secure-by-default.  

XML parsers are widely used, but are complex and have a large attack surface. Many XML parsers are insecure-by-default (they resolve the schema URI by default, even if the XML data is from a potentially untrusted source).  

I think JSON is the best choice for this use case. I can personally live with XML because I’ve built my own secure-by-default XML-subset parser (which is about 3x the size/complexity of my JSON parser), but I think it’s an inferior choice to JSON for security-sensitive applications.  

If data size is a concern, then deflate is the answer. Deflate is likely to compress JSON far better than CBOR. While deflate is subject to the security problems that binary formats have (including several releases with known security vulnerabilities), I believe it’s been around long enough that reasonably trustworthy implementations are now available (including current zlib releases). I’m not convinced data size is a concern.  

		- Chris  

On April 29, 2016 at 21:14:29 , Aaron Zauner ([email-masked](mailto:[email-masked])) wrote:

> Hi,  
>  
> I'm now specifically reviewing the STS reporting draft. We currently have a discussion on file formats within STLE/LE/Certbot. I think CBOR would be a nice format if things get bigger. I'm aware you just switched to JSON and in your specific use-case JSON will probably suffice. The future-work/forensic-reporting mode is something I'd be specifically interested in in that regard. Once these reports get big, JSON might be suboptimal.  
>  
> What's the WGs opinion on that?  
>  
> Aaron  
>  
> On Tue, Apr 26, 2016 at 9:51 AM, Aaron Zauner wrote:
> >  
> > > On 25 Apr 2016, at 20:37, Leif Johansson wrote:
> > >
> > > On 2016-04-25 15:29, Brotman, Alexander wrote:
> > >> Hello,
> > >>
> > >> We've incorporated much of the feedback we've received from the community, and would like to present updated drafts.
> > >>
> > >> * One of the most evident changes is that we've split the draft into two separate documents; one for the STS policy, and one for the TLS reporting. These are meant to replace the original SMTP STS draft (https://datatracker.ietf.org/doc/draft-margolis-smtp-sts-00).
> > >> * We've altered the name a bit from "SMTP STS" to "MTA STS" to be more in line with DEEP, and have also added elements for the DEEP registry.
> > >> * After some deliberation amongst the authors, we've also decided to remove the DNSSEC-related options for the STS policy, which should simplify work for those wishing to deploy STS validation.
> > >> * Within the TLS reporting, we've explicitly mentioned several failure modes, including those specifically relating to DANE and MTA STS.
> > >> * We've also altered the report syntax to use JSON instead of XML.
> > >>
> > >
> > > Thanks,
> > >
> > I support adoption of these drafts as WG documents, they will need some further work though. I'm of course reviewing and will provide feedback both on list and have been talking with (some of) the authors backchannel as well.
> >  
> > Aaron
>

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 5 May 2016 15:34:31 +0700

Hi Chris,

Appreciate the feedback.

> On 05 May 2016, at 05:04, Chris Newman <[email-masked]> wrote:
> 

To be upfront: I'm not, and never have been, a particular fan of CBOR myself. But I think some kind of binary format would be useful.

> Binary formats have an extremely poor track record for security-sentive applications. ASN.1 BER/DER has been an utter disaster for real-world security in PKIX (there are probably hundreds of CVE re…

There're very simple binary formats (CBOR is rather complex). We don't have to use ASN.1 nor BER nor DER. And I would never want to go that way.

> JSON parsers are widely used, simple and have been well analyzed for security usage. They are a good choice for a security sensitive context (excluding the naive Javascript implementation). Most de…

Do you have any references to the above statement? I'm not sure I'd sign that verbatim. I think a lot of JSON libraries that are out there are completely unaudited, especially for scripting languages.

> I think JSON is the best choice for this use case. I can personally live with XML because I’ve built my own secure-by-default XML-subset parser (which is about 3x the size/complexity of my JSON par…

While I cared little about the discussion in STS about switching from XML to JSON, I do prefer the latter as well.

> If data size is a concern, then deflate is the answer. Deflate is likely to compress JSON far better than CBOR. While deflate is subject to the security problems that binary formats have (including…

Well. Depending on the channel we use for feedback, DEFLATE might be a poor option:

- http://breachattack.com/
- https://www.blackhat.com/docs/asia-16/materials/asia-16-Karakostas-Practical-New-Developments-In-The-BREACH-Attack.pdf

Aaron

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 5 May 2016 10:51:59 +0100

> So yes, please adopt it so we can fix the problems, all of which are
+1. I have some editorial comments, but these are not important at this 
stage.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 5 May 2016 11:56:29 +0200

> Reporting is an important part of the design and I'd like the WG to

Thank you John!

Folks - we've seen a bunch of discussion but only one or two have
bothered to say something that looks close to a +1

We did have pretty strong support in BA for these drafts but the
fact that so few are saying "yes, adopt" now confuses me a bit as
chair.

	Cheers Leif

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 5 May 2016 06:56:44 -0700

Am I supposed to say "+1"? :)

If so, +1.

---

From: "John Levine" <[email-masked]>
Date: 5 May 2016 14:17:46 -0000

>Well. Depending on the channel we use for feedback, DEFLATE might be a poor option:

Well, yes, but anything can have security bugs, and I expect that the
libraries for gzip which have been around for a decade have been
audited a lot better than the ones for CBOR on which the paint is
still wet.  

People have beens mailing around vast numbers of DMARC reports, most
of which have an application/gzip body.  If there have been attacks
using DEFLATE bugs, nobody's gotten around to reporting them.

Perhaps it would be helpful to explain why it would be a good idea to
invent something new rather than adapt a an existing design that works
well in practice.

R's,
John

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 5 May 2016 21:29:52 +0700

Hi John

> On 05 May 2016, at 21:17, John Levine <[email-masked]> wrote:
> 

CBOR was just an idea and what I found when searching for binary-JSON-like specs available in IETF. In general I'm fine with JSON. Just thinking about the "future work" section of draft-brotman-smtp-tlsrpt-00 and how we may make use of it in Let's Encrypt in the future as explained initially.

> using DEFLATE bugs, nobody's gotten around to reporting them.

I'm not much worried about attacks on DEFLATE and SMTP traffic. But as I understand from the draft, there's also an option to report back via HTTPS. Here DEFLATE may become a security issue.

draft-brotman-smtp-tlsrpt-00 currently supports two feedback channels ('rua' in Section 3): "mailto" and "https".

> invent something new rather than adapt a an existing design that works

That's the point: I don't want to invent something new here. I'm interested in suggestions, that message wasn't supposed to sound like "we have to change this now to CBOR!".

Aaron

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 5 May 2016 07:42:48 -0700

> bothered to say something that looks close to a +1

+1

--Kurt Andersen

---

From: "John R Levine" <[email-masked]>
Date: 5 May 2016 11:04:28 -0400

> I'm not much worried about attacks on DEFLATE and SMTP traffic. But as I 
> understand from the draft, there's also an option to report back via 
> HTTPS. Here DEFLATE may become a security issue.

I don't see why.  HTTP has had gzip encoding since http/1.0 twenty years 
ago, but I only defined application/gzip for mail in 2012.  Your browser 
probably decodes deflated pages dozens of times a day.

Also, remember the DMARC experience, that in practice nobody is interested 
in http reports if they can send mail.  You might ask around and see if 
you can find anyone who would send http reports if they had the option to 
do so. I implemented the http option from the DMARC draft (sort of, given 
that the draft language was a mess) and the number of attempts I saw was 
zero.

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

---

From: Orit Levin <[email-masked]>
Date: Thu, 5 May 2016 15:58:42 +0000

Guys,
I have been sitting on my hands for five days now because I assumed that publicly (on the list) chairs need to speak in one voice. Since Leif's opinion "as a chair" doesn't represent my view and we are still working behind the scenes on convincing each other ;-) here is what I think.

First, we have got multiple explicit votes for adoption of both documents as the starting point for the WG work. We have heard one objection from Jim Felton to the 'sts' draft. No objections to the 'reports' draft. In my opinion, the ongoing discussion on the list clearly shows rough consensus. The authors should be working on making changes to the text that reflect any additional agreements (if any) since the last version and document the remaining open issues - as a new section in the end.

Secondly, I strongly encourage not losing the momentum and continue the discussion on the remaining 'unclarified' technical details. It demonstrates practical interest in the proposed solution, helps to clarify the open issues... and make everyone understand them ahead of "voting" on them in Berlin!

As I said, Leif and I are still working on resolving our differences, so please stay tuned for a little longer (but not for too long ;-) ) for the official chairs guidance.

Thank you,
Orit.

> -----Original Message-----
> From: Uta [mailto:[email-masked]] On Behalf Of Leif Johansson
> Sent: Thursday, May 05, 2016 2:56 AM
> To: [email-masked]

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 5 May 2016 23:17:29 +0700

> On 05 May 2016, at 22:04, John R Levine <[email-masked]> wrote:
> 
> I don't see why.  HTTP has had gzip encoding since http/1.0 twenty years ago, but I only defined application/gzip for mail in 2012.  Your browser probably decodes deflated pages dozens of times a day.

Exactly. And this is an open security issue today. It's the reason why people needed to come up with 'first party cookies'.

https://github.com/dionyziz/rupture

> Also, remember the DMARC experience, that in practice nobody is interested in http reports if they can send mail.  You might ask around and see if you can find anyone who would send http reports if they had the option to do so. I implemented the http option from the DMARC draft (sort of, given that the draft language was a mess) and the number of attempts I saw was zero.

I think STS is quite different from DMARC if many respects, but I'm interested in the authors opinions on that - would they prefer mail delivery or https? does it depend on deployment/hosting environment etc.

Aaron

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 5 May 2016 10:06:29 -0700

On Thu, May 5, 2016 at 9:17 AM, Aaron Zauner <[email-masked]> wrote:

> > Also, remember the DMARC experience, that in practice nobody is
> interested in http reports if they can send mail.  You might ask around and
> see if you can find anyone who would send http reports if they had the
> option to do so. I implemented the http option from the DMARC draft (sort
> of, given that the draft language was a mess) and the number of attempts I
> saw was zero.
>
> I think STS is quite different from DMARC if many respects, but I'm
> interested in the authors opinions on that - would they prefer mail
> delivery or https? does it depend on deployment/hosting environment etc.

I think it's certainly different in that with DMARC we can assume the
report sender can reliably (and securely, insofar as DMARC assumes SMTP
works!) reach the report recipient; with TLSRPT that's not exactly true.

I think the primary virtue of accepting HTTP/S reports is really in the
case where the recipient has a severely misconfigured MTA. Hopefully in
that case the report sender can still make an insecure SMTP connection, but
it's possible not.

So I sort of like keeping the option (at risk of adding another thing for
report*ers* to have to implement).

Tying this back to the original topic in this thread, though, I don't think
DEFLATE attacks on HTTPS are a a huge issue since we don't want report
contents to be very sensitive (since, if sent via SMTP, they may be subject
to interception).

I would say the main goal should be a format that's easy to generate and
easy to parse, though. My totally unscientific guess is that JSON and XML
fit the bill. Being a Googler, if it were up to me I'd use protocol
buffers, but you know... ;)

Dan

---

From: Binu Ramakrishnan <[email-masked]>
Date: Thu, 5 May 2016 17:18:17 +0000 (UTC)

DMARC is a mechanism to fight against mail related abuse (eg. spam emails). And for that matter it is sufficient to keep DMARC/DKIM/SPF records in DNS. In the case of STS, the threats we are considering is quite different from DMARC. It is because of the same reason we are not sticking policy in DNS (with no DNSSEC). So to answer the question, it is ok to send DMARC over email assuming the recipients can be reached over email. But in the case of STS, a failure means the sender is unable to verify the recipient - hence that channel is not trusted. In such cases HTTPS is preferred over mailto:.
thanks,-binu
      From: Aaron Zauner <[email-masked]>
 To: John R Levine <[email-masked]> 
Cc: [email-masked]
 Sent: Thursday, 5 May 2016 9:17 AM
 Subject: Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP STS Draft)

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 6 May 2016 00:32:59 +0700

Hi,

> On 06 May 2016, at 00:06, Daniel Margolis <[email-masked]> wrote:
> I think it's certainly different in that with DMARC we can assume the report sender can reliably (and securely, insofar as DMARC assumes SMTP works!) reach the report recipient; with TLSRPT that's not exactly true.
> 
> I think the primary virtue of accepting HTTP/S reports is really in the case where the recipient has a severely misconfigured MTA. Hopefully in that case the report sender can still make an insecure SMTP connection, but it's possible not.

So in that case why not prefer a secure HTTPS connection over an insecure SMTP connection?

> So I sort of like keeping the option (at risk of adding another thing for reporters to have to implement).
> 
> Tying this back to the original topic in this thread, though, I don't think DEFLATE attacks on HTTPS are a a huge issue since we don't want report contents to be very sensitive (since, if sent via SMTP, they may be subject to interception).

So HTTPS is mean't only as authentication mechanism in this scenario? I think feedback could possibly contain sensitive material and should be encrypted where possible. In November of 2014 the Internet Architecture Board posted the following statement to their website: https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/

```
[...]

Newly designed protocols should prefer encryption to cleartext operation. There may be exceptions to this default, but it is important to recognize that protocols do not operate in isolation.  Information leaked by one protocol can be made part of a more substantial body of information by cross-correlation of traffic observation.  There are protocols which may as a result require encryption on the Internet even when it would not be a requirement for that protocol operating in isolation.

We recommend that encryption be deployed throughout the protocol stack since there is not a single place within the stack where all kinds of communication can be protected.

The IAB urges protocol designers to design for confidential operation by default.  We strongly encourage developers to include encryption in their implementations, and to make them encrypted by default.  We similarly encourage network and service operators to deploy encryption where it is not yet deployed, and we urge firewall policy administrators to permit encrypted traffic.

[...]
```

It's certainly not easy to modify this attack to instantly work on the feedback mechanism, but I'm sure a few clever scientists and hackers may come up with something in time, so this should be considered.

> I would say the main goal should be a format that's easy to generate and easy to parse, though. My totally unscientific guess is that JSON and XML fit the bill. Being a Googler, if it were up to me I'd use protocol buffers, but you know... ;)

I like protobufs too (and was actually thinking about them). But,.. :)

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 6 May 2016 00:56:35 +0700

Allow me to revise that statement:

> On 06 May 2016, at 00:32, Aaron Zauner <[email-masked]> wrote:
> 

Since feedback policies have predictable "cribs" in them and some parts are easily guessable, it's easy to modify the attack.

But it's getting late over here and am not going to write a PoC now. I may do so in the future.

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 6 May 2016 00:58:53 +0700

> On 06 May 2016, at 00:18, Binu Ramakrishnan <[email-masked]> wrote:
> 

Thanks, that's what I assumed.

Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 May 2016 18:01:07 +0000

On Thu, May 05, 2016 at 05:18:17PM +0000, Binu Ramakrishnan wrote:

> DMARC is a mechanism to fight against mail related abuse (eg. spam emails).

I agree that DMARC is a rather distant analogy, for the reasons
you mention, because the flow is along the reverse path from
receiving systeme back to purported origin systems, where-as with
STS the flow is along the forward-path.

In the absence of a specification for reporting addresses for DANE,
I've been sending some notices to WHOIS and similar contacts to
domains whose TLSA records have issues.

As my MTA is DANE-enabled, I've configured a specific sender address
to bypass DANE policy when sending email, and send notices from
that address (using Postfix sender_dependent_default_transport_maps).

It seems clear that being able to send email despite authentication
failure would be useful not only for sending problem reports but
also to allow users who have urgent non-sensitive messages to get
those delivered in a timely manner.

Therefore, as a converse to the proposed REQUIRETLS proposed earlier
on this list we should consider standardizing an explicit MAYTLS
signal that travels via suitable header (so it can tunnel through
hops that dont explicitly support the new feature).

Given a "User-TLS-Policy: MAY" or similar header, a compliant
sending MTA would then do traditional opportunistic TLS bypassing
any attempt to do DANE or STS, ...

This would then in the vast majority of cases allow both the reports
under discussion and urgent non-sensitive traffic (Lunch invites,
...) to reach destinations that have DoSed themselves by botching
their certificate chains and/or corresponding DANE/STS policies.

Given a reasonable way to overide mandatory TLS on the forward
path, I think an email-only reporting spec should suffice.  If a
destination cannot be reached at all by ordinary insecure SMTP,
then they probably don't need a flood of reports to compound the
problem.  SMTP has gotten along without automated "your site is
down" reports for ~40 years.

So bottom line, don't preemptively specify both HTTP and SMTP report
delivery, choose one, so that every sending and receiving system
will implement just one.  If HTTPS is required, specify just HTTPS.
If SMTP is required, specify just SMTP.  Don't force all sending
systems to support two reporting formats.  Either alone should be
sufficient.

For email reports, some sort of DoS mitigation should be considered.
In particular, since such reports should not transit public mailing
lists or other forwarding services, it is reasonable to insist on
origin authentication (DKIM or similar) and suggest that any given
sending domain rate limit its reports to something like at most
one an hour per reporting email address (not target domain as the
same reporting address might support a great number of hosted
domains).

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 May 2016 18:10:09 +0000

On Fri, May 06, 2016 at 12:32:59AM +0700, Aaron Zauner wrote:

> that case the report sender can still make an insecure SMTP connection,
> but it's possible not.

There's at least one common-mode failure for STS and HTTPS, namely
expiration of a wildcard certificate that is used for both the
email and HTTPS servers.

> So in that case why not prefer a secure HTTPS connection over an insecure SMTP connection?

We're discussing an error reporting mechanism, not a secure message
delivery mechanism.  It should be possible to deliver the bad news
even under adverse conditions.

If the reports contain sensitive data, let's simplify the reports
to contain less of it.  In most cases, a boolean "your cert chain
fails to verify for domain D at MX host H" is quite sufficient.

The SMTP message would be sent via opportunistic TLS, with fallback
to cleartext if STARTTLS fails or is not adverised.

For example:

    lojabrum.com.br. IN MX 10 smtp.lojabrum.com.br. ; AD=1
    _25._tcp.smtp.lojabrum.com.br. IN TLSA 3 1 1 d6e78498aeadde76946c27b44a728bac7257f3eb5dca5a0745abfa75d5fe461f
    smtp.lojabrum.com.br. IN A 200.160.111.140 ; STARTTLS not offered

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 5 May 2016 11:19:41 -0700

>From the draft:

 * In the case of `https`, reports should be submitted via POST
>    ([@!RFC2818]) to the specified URI.
>  * In the case of `mailto`, reports should be submitted to the specified
>    email address. When sending failure reports via SMTP, sending MTAs
>    MUST NOT honor SMTP STS or DANE TLSA failures.

---

From: "John Levine" <[email-masked]>
Date: 5 May 2016 18:30:38 -0000

>case where the recipient has a severely misconfigured MTA. ...

I don't understand this argument at all.  STS and DMARC both publish a
reporting URL which is usually mailto:<something>.  There is no need
for the address in the mailto: to have any connection to the domain
being reported, and more often than not it doesn't.  

On my little system, I have DMARC reporting records for 114 domains
that use several different MTAs, all of which send the mail to
[email-masked] where I have a script that parses the reports into a
database.  In the larger world, Agari provides a popular DMARC
analysis service so you will see many thousands of domains sending
their reports to the same address at Agari.  For that matter, the
DMARC reporting address for gmail.com is at google.com, which has a
different MX so I presume is not quite the same mail system.

None of these depend on the mail at the particular domain working
unless that domain happens to be the one hosting the analysis server.
Since the STS spec says that reports ignore the STS rules, it's hard
to see how the mail could be so broken that mail reports fail without
also being so broken that nobody else gets mail, either.

>buffers, but you know... ;)

Well, in case nobody's mentioned it before, we do have the working large
scale example of DMARC reports.  You might ask around to see how well it
works at Google.

R's,
John

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 6 May 2016 01:37:02 +0700

Hi,

> On 06 May 2016, at 01:10, Viktor Dukhovni <[email-masked]> wrote:
> 

We're discussion a _feedback_ mechanism, at least that's what I understood from the draft.

> fails to verify for domain D at MX host H" is quite sufficient.

What if I want to send sensitive information about delivery failures? I.e. the way a MITM was attempted?

> to cleartext if STARTTLS fails or is not adverised.

See above. Opportunistic TLS is the wrong approach here in my opinion. I never liked it and I never will. I think the reasons are obvious.

Aaron

---

From: "John Levine" <[email-masked]>
Date: 5 May 2016 19:12:19 -0000

>>    ([@!RFC2818]) to the specified URI.

By the way, that's somewhat underspecified.

While the http specs say it's OK to do a POST with an arbitrary MIME
type such as application/json or application/gzip, the web apps I know
all expect the POST body to be multipart/form-data.

If you just want to send the blob of JSON, PUT with an appropriate
filename would be more appropriate.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 5 May 2016 19:17:56 -0000

>What if I want to send sensitive information about delivery failures? I.e. the way a MITM was attempted?

It's probably not a great idea to send that kind of info unless you
already have a relationship with the recipient. 

>See above. Opportunistic TLS is the wrong approach here in my opinion. I never liked it and I never will. I think the reasons

Exactly.  If you want to receive stuff securely, you need to publish
an end-to-end encryption key, most likely PGP or S/MIME.  Of course,
then there's the question of how you know the key was published
securely and you're already halfway down the rabbit hole.  I suppose
you could try to go with https, but it's got its own MITM problems
with overly compliant CAs issuing wildcard certs to parties you and I
don't think should have them.

DMARC experience suggests that you should send routine stuff using
automated processes, and if there's something really interesting,
make arrangements with the other party.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 May 2016 19:28:04 +0000

> We're discussion a _feedback_ mechanism, at least that's what I understood from the draft.

Feedback on authentication failures, that is only really interesting
in near real-time.  Once a problem is resolved, late feedback is
old news.

This is very much unlike DMARC reporting where domains are interested
the origin and frequency of potential phishing attacks, and processing
by a third party that provides aggregated data periodically is just
fine.

With STS and DANE one primarily wants the data from the last hour,
not the last month.  This is real-time operational data.

> the way a MITM was attempted?

The MITM attacker already knows he was attempting to intercept the
traffic.

> > to cleartext if STARTTLS fails or is not advertised.
> 
> See above. Opportunistic TLS is the wrong approach here in my opinion. I
> never liked it and I never will. I think the reasons are obvious.

Too bad, and I'm not taking the bait to debate this.  That'll take
us off topic.  It suffices to say that given the need for real-time
notification, opportunistic TLS is needed for SMTP delivery of
reports.

-- 
	Viktor.

P.S.

The main reason that DANE SMTP has a very low failure rate is that
I've been sending all the failure reports for ~2 years.  In most
cases they would not have reached the guilty party if authentication
were required.

It is my hope that in the not too distant future more high volume
senders will implement outbound DANE support and tell everyone that
failure to publish correct TLSA RRs is the receiving system's
problem to fix not much different from failure to publish correct
A or MX records.  At that point folks who DoS themselves will
quickly notice the outage and address the problem.

If we standardize a "MAYTLS" header, then an informed user will
alert their correspondent to contact their administrator as part
of or instead of sending an explicit override to unauthenticated
opportunistic TLS.

At present because so few DANE sending systems are live, a receiving
domain might not notice for some time, and might blame the sender
(the usual "nobody else is having that problem").

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 May 2016 19:40:39 +0000

> being reported, and more often than not it doesn't.  

If there is a close match in the requirements for DMARC reporting
and the requirements for the proposed reporting for forward-path
authentication errors (beyond the fact that both are reports about
email sent across organizational boundaries) that case has not yet
been made in sufficient detail.

I agree that some lessons about data formats and the like are likely
applicable, but I am far less convinced that outsourcing analytics
for as with DMARC applies in this new context.

The most timely reporting mechanism may be neither HTTPS nor a
separate email report, but an ESMTP extension that can signal
authentication errors as they occur.  (Since STS supports a
non-enforcement 'trial' mode, and reporting was in large measure
intended to support that, the client would be continuing to use
the server in any case).

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 5 May 2016 12:53:43 -0700

> filename would be more appropriate.

True.  https://github.com/mrisher/smtp-sts/issues/35 for now.

Not sure about PUT.

"The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already existing
resource, the enclosed entity SHOULD be considered as a modified version of
the one residing on the origin server. "

Seems like it would require the reporter to be claiming a unique URI, no?

---

From: "John R Levine" <[email-masked]>
Date: 5 May 2016 16:01:27 -0400

> Seems like it would require the reporter to be claiming a unique URI, no?

Yes, that's a feature to weed out duplicate reports.  See section 7.2.1.1 
of the DMARC spec (RFC 7489) for an example of how to come up with a 
suitably unique name.  I suppose for PUT you might want to use slashes 
instead of exclamation marks.

Do remember that it's a feature that you can send reports for domain A to 
a report recipient in domain B, so you can aggregate all of your reports 
and use outsourced analysis providers.

Regards,

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 5 May 2016 16:24:52 -0700

Makes sense.

Yeah, that bit for validating the A->B relationship (section 7.1) is not
currently in the TLSRPT spec. Of course it's fairly trivially applicable,
but we left it out of the current draft (complexity, etc).

Do you think we should be including that if we support HTTP reporting?
Seems like a CNAME could accomplish the same in that case, unless we
require cert validation (which strikes me as pointless if we allow
plaintext SMTP).

---

From: "John R Levine" <[email-masked]>
Date: 5 May 2016 21:40:07 -0400

> Do you think we should be including that if we support HTTP reporting?

Yes, definitely, for the same reasons DMARC does.  If you're a large 
hosting provider doing mail under various brands, you'd probably want to 
do the analysis at one place, and it seems to me that the kind of stuff 
Agari does for DMARC would be useful here.

> require cert validation (which strikes me as pointless if we allow

Random CNAMEs and SNI play poorly together.  Might as well just use the 
TXT record to point people at the real name of the server.

R's,
John

>>> resource, the enclosed entity SHOULD be considered as a modified version
>>> of the one residing on the origin server. "
>>>

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 5 May 2016 20:15:42 -0700

> TXT record to point people at the real name of the server.

Heh. But in this case we don't really need HTTPS (or any validation), since
the SMTP reports can be sent without validation (or so we have all said, I
think).

So same question for DMARC: if you had people using HTTP reporting, would
you do the section 7.1 thing? I have no qualms about including it, given
that it's already nicely spec'ed out, but this is sort of why we didn't
bother at a first pass.

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 6 May 2016 10:39:57 +0700

> On 06 May 2016, at 02:28, Viktor Dukhovni <[email-masked]> wrote:
> 

The MITM does, the receiving party may not.

> notification, opportunistic TLS is needed for SMTP delivery of

Wasn't supposed to be bait and I'm also not interested in discussing this topic. I think we have very different viewpoints on that one.

Just as Opportunistic TLS: "MAYTLS" MAY indeed pave the way for downgrade attacks, or am I missing something?

I'd just like to note to the chairs; the way the discussion has changed on -tlsrcpt I'm currently totally -1 on this one (and that was the document I had the least problems with), I'm aware that you already adopted the document, but this is just the wrong way to do things in my opinion.

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 6 May 2016 10:49:52 +0700

> On 06 May 2016, at 02:40, Viktor Dukhovni <[email-masked]> wrote:
> 

I like this idea. But again; I think the extension shouldn't send feedback if there isn't already a secure channel in place (e.g. MITM already occurring).

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 6 May 2016 10:55:02 +0700

> On 06 May 2016, at 10:49, Aaron Zauner <[email-masked]> wrote:
> 
> 

..so in that case for an attacker that's trivially DoS'able as well. Which would require a fallback mechanism like HTTPS + WebPKI again, I suppose (unless you go opportunistic all the way of course, which is, what I assume you propose).

Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 May 2016 04:47:43 +0000

> The MITM does, the receiving party may not.

You need to keep in mind that in the vast majority of cases
authentication errors will be operational errors (self-DoS) on
receiving systems, and the task at hand is to minimize the frequency
and duration of outages, so that security is used and not just
disabled as unusable.  Maximalist approaches are highly counter-productive
here.

If there is an MITM, we don't need confidentiality of the report
that there is an MITM.  While we'd like the report to get through
to the right party in that case, sadly that's not possible, but
reports do get through to the majority of peers where the issue is
an operational SNAFU on one end or the other.

> Just as Opportunistic TLS: "MAYTLS" MAY indeed pave the way for downgrade attacks, or am I missing something?

There's no downgrade attack opportunity here, the signal would be
carried in the message content from the sender who's relaying the
message (originally the user's MUA).

Perhaps it would be wise to agree on the purpose and requirements
for reporting before we debate reporting "solutions"?

As I see it, the top 20 goals of forward path authentication failure
reporting are:

    1. Notify the receiving system they've partly messed up,
       as some of their MX hosts fail authentication.

    2. Notify the receiving system they've still partly messed up,
       and you've independent evidence they've messed from various
       3rd party test sites that confirm your observations.

    3. Notify the receiving system they've royally messed up,
       and all their MX hosts are failing authentication.

    4. Notify the receiving system they've still royally messed
       up, and you're going to soon bounce all their back to the
       senders.

    ...

    20. Keep the receiving party appraised of possible MiTM attacks,
	via post-event statistical reporting.

Yes, the above is deliberately provocative, to jolt folks out of
their comfort zones and to think about the real goals and out of
those relevant requirements.

The key requirement as I see is *timely* delivery of focused *alerts*
to operators who can fix the problem, ideally before it affects
the delivery of email, while the issue is still localized to just
a proper subset of the MX hosts.

Sites enabling DANE, STS, ... need to commit to superior operational
practices (reliable automation, monitoring, ...) and in many cases
to risk reduction by, for example, avoiding using a single wildcard
certificate for all their MX hosts that can DoS them all when it
expires.  Staggering MX host certificate rotation, so if if goes
wrong, only a subset of the MX hosts is affected, ...

Sites that don't have the operational discipline to do this right
are best off staying with opportunistic TLS and publishing neither
DANE nor STS policies.  DoSing themselves periodically, and causing
pain for senders trying to do the right thing helps no one.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 May 2016 05:01:03 +0000

On Fri, May 06, 2016 at 10:55:02AM +0700, Aaron Zauner wrote:

> > I like this idea. But again; I think the extension shouldn't send feedback
> > if there isn't already a secure channel in place (e.g. MITM already
> > occurring).

There's no way to know whether MiTM is present, or the other side
has messed up.  The vast majority of the time it's the latter.

Senders behind persistent nation-wide MiTM firewalls can't benefit
from DANE or STS, if they want secure channels to the outside, they
must find other means.  DANE and STS can reduce the incidence of,
effectiveness of and incentives to mount transient attacks (BGP
hijack, ...).  

They can also substantially simplify regulatory compliance if peers
in certain industries standardize on support for DANE and/or STS
as a means of mutual signalling of downgrade-resistant secure
transport capabilities.

> ..so in that case for an attacker that's trivially DoS'able as
> well. Which would require a fallback mechanism like HTTPS + WebPKI
> again, I suppose (unless you go opportunistic all the way of course,
> which is, what I assume you propose).

You're still erroneously looking to *secure* the alerting mechanism
from MiTM attacks, and missing the point that what's important is
a *timely* alerting mechanism, which keeps operational errors down
to a tolerable frequency and duration, as a consequence of which
security might actually stand a chance of getting deployed!

We need to MiTM protect the actual messages users are sending, not
the error alerts that are needed to keep them flowing.

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 6 May 2016 12:57:15 +0700

> On 06 May 2016, at 11:47, Viktor Dukhovni <[email-masked]> wrote:
> 

This is not what I understood from the draft in it's current form:

```
Abstract

   A number of protocols exist for establishing encrypted channels
   between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE
   [RFC6698], and SMTP MTA STS (TODO: Add ref).  These protocols can
   fail due to misconfiguration or active attack, leading to undelivered
   messages or delivery over unencrypted or unauthenticated channels.
   This document describes a reporting mechanism and format by which
   sending systems can share statistics and specific information about
   potential failures with recipient domains.  Recipient domains can
   then use this information to both detect potential attackers and
   diagnose unintentional misconfigurations.
```

The last sentence explicitly mentions "detect potential attackers".

> an operational SNAFU on one end or the other.

So if there's a MITM you'd rather have him intercept (and possibly modify!) the feedback reports as well? Confidentiality may be needed as detailed information on MITM attacks can give indication as to which paths and systems are affected (e.g. to 3rd party attackers, not the original MITM). There're many other attack vectors. Also see the IAB statement I referred to before, I took it seriously.

> those relevant requirements.

It's called "Strict Transport Security" not "How to deliver mail properly". While I do agree on most points, we need to keep in mind that this is supposed to be a security standard not merely an email delivery feedback system.

> a proper subset of the MX hosts.

I think that may be a reason for another draft in another working group. This one is called "Utilizing TLS in Applications",..

> pain for senders trying to do the right thing helps no one.

Yea, we'll try to help them out separately with Let's Encrypt automation anyway.

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 6 May 2016 13:03:10 +0700

> On 06 May 2016, at 12:01, Viktor Dukhovni <[email-masked]> wrote:
> 

There is. It depends on how detailed reports are. If I see an appliance stripped STARTTLS commands, I may want to report this back to the receiving MTA and/or 3rd party monitoring services. Likewise if there're specific TLS or downgrade attacks performed that show up in logs, I may want to report this. I think this would be a very useful feature indeed and give some indication as to who and what fucks up paths on the internet at the moment. It'll likewise give indication as to misconfigured receiving MTAs.

> effectiveness of and incentives to mount transient attacks (BGP

I never said we're going to solve the "Great Firewall of China" problem with these standards.

> the error alerts that are needed to keep them flowing.

I agree we need to protect users messages but I completely disagree that the feedback mechanism should be unencrypted. See previous and this mail above.

Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 May 2016 07:00:43 +0000

> This is not what I understood from the draft in it's current form:

The current form is not the final form.  To the expect that the
draft  emphasizes statistical reporting over problem alerting it
needs to be corrected.

> The last sentence explicitly mentions "detect potential attackers".

That nice, but it's way down the priority list of what's actually
relevant.  First we need the protocols to be usable, which means
sufficiently resilient to be deployed, which means timely error
reporting.

> So if there's a MITM you'd rather have him intercept (and possibly modify!)
> the feedback reports as well?

Yes!  The vast majority of the failures will not be MiTM-related,
and if there is an MiTM, well then you can't send the report to
the right party anyway.

> Confidentiality may be needed as detailed
> information on MITM attacks can give indication as to which paths and
> systems are affected (e.g. to 3rd party attackers, not the original MITM).

There's little need for very detailed information.  We just want
to distinguish between a few classes of failures.

    * Lack of STARTTLS (this too is often self-inflicted!)
    * Lack of shared protocol protocol parameters (protocol version/ciphers)
    * Lack of shared trust anchors
    * Reference identifier mismatch
    * (Perhaps one or two others I'm forgetting right now)

> There're many other attack vectors. Also see the IAB statement I referred
> to before, I took it seriously.

None of this matters if the protocol cannot be widely adopted, and
wide adoption requires infrequent and short additional outages.
The reporting feature needs to focus on this, and everything else
is secondary.

> It's called "Strict Transport Security" not "How to deliver mail properly".

This is an *email* security protocol.  It certainly needs to deliver
the mail properly, the result should an a working email protocol
that is used and is more secure.  An unusable email security protocol
is pointless.

> While I do agree on most points, we need to keep in mind that this is
> supposed to be a security standard not merely an email delivery feedback
> system.

The primarily role of the reporting spec needs to be to maintain
the operational stability of inter-organizational email transport.
It needs to have as much or as little security as best fits that
role.  Reporting is NOT a security protocol, its job is to help
keep the actual security protocol usable.

> I think that may be a reason for another draft in another working group.
> This one is called "Utilizing TLS in Applications",..

There will first be non-IETF documents in this space, and perhaps
ultimately some IETF BCPs once we have even more operational
experience.

> Yea, we'll try to help them out separately with Let's Encrypt automation anyway.

That's still a bit shaky, the early adopters of LE for SMTP are
where some of the most frequent DANE problems show up.  This is
because automated LE cert rotation ignores the necessity to update
TLSA records from time to time.  Survey says 424 MX hosts with
stable "IN TLSA [23] 1 ?" records and 109 MX hosts with fragile,
soon to break "IN TLSA [23] 0 ?" TLSA records.  The ratio is
improving, over time, but needs to be much better.

There are things LE can do to make this better:

    * More prominent documentation of best-practice for combining DANE
      and LE certs, and monitoring their correctness:

	; Keep server key fixed when doing automated rotation via "--csr"
	; option option.  Rotate server key manually, from time to time,
	; and update "3 1 1" record accordingly.  Do so only while the
	; "2 1 1" LE key is not also changing.
	;
	; Ensure MX hostname matches the certificate SAN
	;
	_25._tcp.smtp.example.org. IN TLSA 3 1 1 <sha256(server public key)>

	; Track LE issuer public key, update TLSA RR promptly when it changes.
	; Stable server key above makes it possible to tolerate brief mismatches
	; if the LE issuer key changes unexpectedly.
	;
	; Ensure the issuer CA cert is part of server's chain file
	; (i.e. is sent to peer in server TLS Certificate message).
	; [ This is of course also necessary for STS, as the LE issuer
	;   CA is an intermediate CA, not a trust anchor. ]
	;
	_25._tcp.smtp.example.org. IN TLSA 2 1 1 <sha256(LE issuer public key)>

    * Better advance notification of planned changes in the LE
      issuer public key, not just via the blogs, but also via email sent
      locally to the administrator by the key rotation scripts.

    * Provide tools to compute the new "3 1 1" and "2 1 1" records
      and compare them to what's in DNS.  Avoid deploying new cert
      chain if neither match.  If just one changes, deploy, but
      send alert to admin to update the TLSA RRs.

    * As explained a recent post to this list (NEWSFLASH thread),
      the "3 1 1" + "2 1 1" combination is quite resilient if
      sensibly monitored.

    * The "mail in a box" project has done a good job of integrating
      LE and DANE and DNSSEC for a complete turn-key system, and
      I see very few errors from those machines.  They just routinely
      have correct working TLSA RRs across cert rollovers.  Kudos
      to that project. <https://mailinabox.email/>

I've for a long time been deeply involved in the day-to-day practice
of MTA SMTP transport security.  Designing and implementing the
Postfix TLS interface, supporting Postfix TLS users on the mailing
list, authoring DANE support in OpenSSL, monitoring DANE adoption.
Monitoring and resolving DNSSEC interop issues at hosting providers,
...

So yes, I don't just view this as a pure security protocol issue.
All the pieces have to fit together to actually create something
that gets used.  Think systemically, optimization of the security
of a small component of a large system can easily turn out to be
at the expense of the security system as a whole.

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 6 May 2016 14:14:37 +0700

> On 06 May 2016, at 14:00, Viktor Dukhovni <[email-masked]> wrote:
> 

I'm aware of that, but if the draft turns out to be a delivery reporting system, I'm not going to support it.

> and if there is an MiTM, well then you can't send the report to

There're currently multiple feedback channels proposed, if one would fail, you might fall back to the other one. Though I doubt that MITM on the HTTPS channel  will be very frequent given CT and scanning efforts.

>    * (Perhaps one or two others I'm forgetting right now)

I understand this is what you consider relevant. I'd like to know why and how attacks happen as well, if possible.

> ultimately some IETF BCPs once we have even more operational

Which non-IETF documents? Where?

> improving, over time, but needs to be much better.

No it isn't shaky, it's non-existent. People that currently deploy LE certs on their mailservers do so on their own, without guidance and without any support nor automation. And I'm sorry to say: I don't care about DNSSEC (and thus unfortunately DANE, wich is a nice standard by itself), thus will probably implement support at the very last moment possible.

> 	_25._tcp.smtp.example.org. IN TLSA 2 1 1 <sha256(LE issuer public key)>

Again: there's currently neither incentive nor effort within LE to look at DANE. Nor enough man-power available. Nor is it really relevant in my opinion.

>      locally to the administrator by the key rotation scripts.

Agreed. Please talk to the LE-Ops team about that, I'm working on an entirely different part and have zero influence on that.

>      send alert to admin to update the TLSA RRs.

See above.

>      the "3 1 1" + "2 1 1" combination is quite resilient if

See above.

>      to that project. <https://mailinabox.email/>

I like it as well.

> Monitoring and resolving DNSSEC interop issues at hosting providers,

I'm aware of that :)

> at the expense of the security system as a whole.

We're currently trying to fix ancient (as in early 80ties) protocols, that will be around for another 20 years. I'd rather consider every detail than rush a standard through the IETF process.

Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 May 2016 08:51:30 +0000

> I'm aware of that, but if the draft turns out to be a delivery reporting system, I'm not going to support it.

The draft will likely move forward with at least one of us not
entirely in agreement with its content.  I think the most productive
approach is to raise your issues as best you can.  You can of course
walk away as or when you see fit.

I think we should stop the deep dive and come back to prioritizing
goals.  Rank and/or replace the below, and then we can figure out
how to address the right problem:

    * Near real-time forward-path alerting of (likely) receiver
      misconfiguration?

    * Aggregate reporting of authentication success/failure
      stats?

    * CT-like reporting to public "observatories"?

    * Other goals?

We may also have to pin down some technical details:

    * Reliability of report delivery?  (DMARC is not trying
      to defend against MiTM attacks so is not concerned with
      MiTM attacks on the reporting channel, here things are
      different).

Relevant issues for aggregate reporting might include:

    * How long should a sender keep on trying to deliver a report?
    * How often to retry?
    * How does one avoid DoSing a target site with reports?

The above will require some care.

The simplest thing to in the near term do is to just communicate
authentication failure inline, and either continue delivery (if
authentication is not yet in hard-fail mode) or move on to the next
MX host.  This gets to the right party in near real-time.

Sites that want real time reports of this sort would enable
a new ESMTP feature advertisement that makes it possible for
the client to send:

	TLSSTATUS DANE|STS NOSTARTTLS
	TLSSTATUS DANE|STS UNTRUSTED
	TLSSTATUS DANE|STS NOTMATCHED
	TLSSTATUS DANE|STS SUCCESS
	TLSSTATUS FALLBACK

    (handshake failures are communicated via TLS alerts)
    (the FALLBACK status is for cleartext retries after
     STARTTLS failure in opportunistic mode).

The MTA on the receiving end can log these, and raise alarms under
appropriate conditions.  This would need support in sending and
receiving MTAs and does not require either a "mailto:" or "http"
reporting address.  Just new inline signalling.

If the status is signalled as part of an actual delivery it might
also be recorded in new message trace headers.  Tony Finch some
time ago suggested "Transmitted:" as a sender-added trace header
to complement "Received:".  It did not get traction at the time,
but still looks like a reasonable idea.

> how attacks happen as well, if possible.

Reporting that conveys longer-term metrics is admittedly also of
some interest, but we rather strongly disagree on its relative
importance at this early stage of the evolution of authenticated
MTA-to-MTA transport.

> Which non-IETF documents? Where?

Some folks are writing a DANE BCP for SMTP with Postfix, and we'll
try to include as material as possible that is MTA-neutral.  I'll
let you known once we have something ready.

> No it isn't shaky, it's non-existent. People that currently deploy LE
> certs on their mailservers do so on their own, without guidance and without
> any support nor automation.

Well some guidance is available in the LE community forum posts,
one of mine is even administratively pinned.  But more is possible.

> And I'm sorry to say: I don't care about DNSSEC

[ This sounds needlessly dogmatic. ]

> Again: there's currently neither incentive nor effort within LE to look
> at DANE. Nor enough man-power available. Nor is it really relevant in my
> opinion.

At least one of the folks behind LE has been reasonably supportive,
though admittedly not yet to the extent of explicit support for
DANE in the tooling.

> I'd rather consider every detail than rush a standard through the IETF
> process.

I am also not in a hurry to skip important details.

--
	Viktor.

---

From: "John R Levine" <[email-masked]>
Date: 6 May 2016 08:59:38 -0400

> the SMTP reports can be sent without validation (or so we have all said, I

I suppose, but if you do use https, it would be a cruel joke to specify 
it in a way that made the certs not verify.

> that it's already nicely spec'ed out, but this is sort of why we didn't

The filenames are useful in SMTP reports to detect duplicates, for 
debugging, and perhaps to decide where to file what.  I'd think all of 
those would apply for http reporting as well.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 6 May 2016 16:20:47 -0000

>> authentication errors as they occur. ...

I'm getting the impression that it would be helpful to try and write
down some scenarios about what the reports are for.  Here's a few:

1.  Company has lots of MTAs, collect statistics to see which ones
are misconfigured in preparation for publishing policy statements.

2.  Company's published policy statements, monitoring to see if
MTAs are screwing up.

3.  Detecting various sorts of MITM attacks.

4.  Detecting other attacks, details unclear.

For items 1 and 2, the ESMTP extension won't work, since the MTAs as
likely as not won't have it.  (If they did, they wouldn't be
misconfigured.)  For item 3 it probably won't work either since the
MITM will block it.

As I've said before, I expect that in practice people will send
reports by mail because it's easier, but https could work if there
is anyone who actually wants to use it.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 May 2016 16:49:15 +0000

On Fri, May 06, 2016 at 04:20:47PM -0000, John Levine wrote:

> likely as not won't have it.

That's not a fair objection, they would have to deploy upgraded
MTAs that support the new extension, just as would deploy MTAs that
support DANE or STS to enjoy the benefits of those (yes at present
upgrades are only needed for outbound support).

They would also need upgraded MTAs to support any future DEEP
policies, or implement TACK, ...

> (If they did, they wouldn't be misconfigured.)

That's false.  The most common misconfigurations are untrusted,
expired, non-matching or incomplete certificate chains, followed
by selectively enabled STARTTLS (perhaps based on client reputation,
...).

Once the upgraded MTA software is deployed, the extension would
only fail to be present if some non-conformant SMTP servers are
later added to the mix.  Some basic self-monitoring is also expected.

For receivers that don't enforce, a "Transmitted:" header can also
convey the authentication status along the path, even past MTAs
that are not explicitly aware of their role in DANE or STS.

I also did not mention that sending MTAs should probably also
send

    TLSSTATUS DANE|STS RETRYMX

when skipping a first MX host to use a second.

> For item 3 it probably won't work either since the
> MITM will block it.

Yes, the real-time in-band reporting is for the 99.9% of cases that
are self-inflicted.

> is anyone who actually wants to use it.

If aggregate reporting is the only nail, then the email reporting
hammer is the only/primary tool needed in the tool-belt.

My experience strongly shows that the first-order problem is timely
misconfiguration alerting.

-- 
	Viktor.

---

From: Orit Levin <[email-masked]>
Date: Fri, 6 May 2016 18:05:32 +0000

Thank you, guys, for the great discussion and great points on both 'sides' :-)
It would be great if the authors could capture the requirements (and maybe even scenarios, as John suggested) in the draft.
It seems that you are setting a high bar by discussing at depth the scenarios, the requirements, and the implementation in a single document cycle! 
We should probably arrange for a longer session in Berlin to go over the material and the discussion points to let the whole audience to judge :-).
Orit.

> From: Uta [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
> Sent: Friday, May 06, 2016 1:52 AM
> To: [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 May 2016 18:12:13 +0000

On Fri, May 06, 2016 at 06:05:32PM +0000, Orit Levin wrote:

> We should probably arrange for a longer session in Berlin to go over the
> material and the discussion points to let the whole audience to judge :-).

Definitely worth further discussion.

Just a quick comment.  IIRC, "the whole audience" is the mailing
list.  I may not make it to Berlin, TBD.

-- 
	Viktor.

---

From: Orit Levin <[email-masked]>
Date: Fri, 6 May 2016 18:23:55 +0000

Victor,
I should have said for a 'wider' audience (i.e., beyond the list, which is where the official voting happens).
We all hope that you make it, though! In the worst case, you will have to use a bridge! :-)
Orit.

> Sent: Friday, May 06, 2016 11:12 AM
> To: [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 6 May 2016 23:01:00 -0000

>upgrades are only needed for outbound support).

No kidding.  The point of the reports is to find the MTAs that haven't
been upgraded so they can fix them.  When you have a giant server
farm, you can't upgrade everything at once, so you do rolling upgrades
and sometimes you miss a few or the upgrades fail.  If you depend on
the upgrades succeeding to get reports that tell you that the upgrades
failed, well, ...

>by selectively enabled STARTTLS (perhaps based on client reputation,

In some environments, sure.  In other environments, nope.  I'd prefer
to use a reporting design that works in as many places as possible
rather than only on the mistakes I expect.

>hammer is the only/primary tool needed in the tool-belt.

I have a folder of 55,000 individual DMARC failure reports, most sent
and received within a couple of seconds of when the failure was
detected.  (That's separate from the folder of 90,000 aggregate
reports.)  It really is not helpful to claim that it is inherently
hard or slow to mail failure reports.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 6 May 2016 23:02:06 -0000

>list.  I may not make it to Berlin, TBD.

I'm pretty sure I'll be there.  Perhaps I can channel Viktor's
arguments.  Or more realistically, Meetecho works pretty well now.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 May 2016 23:56:47 +0000

> the upgrades succeeding to get reports that tell you that the upgrades

The key observation on that point is that failures to support
authentication properly behave very differently from DMARC.

When an MTA is misconfigured, if reports are sent in real-time via
email, every remote site that connects to the broken MTA will
generate a new email generating a notification flood.  This is
much less likely to happen with DMARC.

Notifying the MTA via ESMTP extension one-liners in-band makes it
possible for the receiving MTA to efficiently consolidate the
reports without doubling the traffic load or routing as much email
to the report mailbox as to all other recipients combined.

I should point out I the providers with large hosting mail farms
are not the problem we need to worry about.  Frankly, they can
damn-well quite effectively monitor themselves!  It is the long
tail of much smaller domains where SMTP transport security needs
an effective alerting channel.  

Many small to medium site MTAs don't have a dedicated operations
team.  I can easily add a bit of code of Postfix to send them
intermitten reminder alerts every 30 minutes in which the fraction
of authentication failures alerts exceeds some threshold.  They
would then benefit from automated monitoring by the wold at large,
and would not have to *publish* an email address for collecting
reports or configure scripts to process them...  The (as yet
skeletal) design satisfies KISS.

> rather than only on the mistakes I expect.

I think we're looking at two different problem sets, both of which
may need solutions.  Clearly, we disagree or their relative
importance, or simply on which one we personally wish to expend 
precious mental cycles.

> hard or slow to mail failure reports.

I posit that inbound TLS auth does not behave sufficiently similarly
to DMARC to support a completely analogous design.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 7 May 2016 01:08:44 -0000

>much less likely to happen with DMARC.

For one thing, DMARC notifications come in clusters all the time.  If
you send a message to a large mailing list like NANOG, or some botnet
uses fake return addresses in your domain, you'll get a big blat of
failure reports.  For another, so what?  If you're a large mail
system, you scale things so you can handle the reports you get.  This
is not a new or unsolved problem.

>damn-well quite effectively monitor themselves!

This news may come as a surprise to the large hosting mail farms
whose employees are the authors of this draft.  Perhaps they can
let us know what their concerns and experience are.

> It is the long tail of much smaller domains where SMTP transport security needs

So they can point the reports at some place like dmarcian.com, which
does the analysis for small mail systems for free.  Once again, this
is not a new problem, and practical solutions are well known to people
who take a few seconds to look for them.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 7 May 2016 01:43:21 +0000

> who take a few seconds to look for them.

Most of the small domain operators will not do that.  And this leaks
sensitive data.

If you can't send DMARC reports to some domain, no big deal nobody
cares.  There's little operational impact.  If their certs expire,
and they don't notice, everybody who's trying to send them email
(and their postmaster staff getting support calls) feels the pain.

I am not buying the outsourced processing model as sufficiently
broadly applicable.  Why are you so opposed to recognizing that
perhaps we have two different use-cases to address, and might well
address both?  I am not denying your use case, just saying it is
less urgent based on operational experience of resolving TLS issues
in forward delivery.

As for the authors of the draft, they should not be focused on
*just* the large provider problem if this is to be broadly applicable
technology.  If their part of the elephant requires aggregate report
flows, so be it.  Not everyone will send them such reports, they
require a bunch of heavy-lifting.  A simple in-band status indication
stands a better chance of being enabled by default.

[ I am really hoping to not hear a counter-argument, I don't think
  I am saying anything radically controversial, but I keep being
  surprised ... ]

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Sun, 8 May 2016 10:24:37 -0700

Sorry, everyone. I've been out of the office the last few days on holiday
and haven't had a chance to catch up on the whole thread.

Regarding big providers' ability to monitor for misconfigurations, I think
we should not assume they will always catch errors. Especially in the early
stages of deployment, as Viktor noted, a small percentage of dropped mail
could go unnoticed, so having a means to accurately report failures and
their causes strikes me as valuable to everyone. Anyway, I'm not really
seeing an argument that only certain classes of mail hosts would benefit
from this, and of course that's not anyone's goal.

It sounds to me from the tail end of this thread that the main argument
here is contrasting out of band reporting (via HTTP) with SMTP-based
reporting in a separate message and in-band reporting via some SMTP status
indicator. Is that right?

If so, can I guess at the pros and cons (non-exausively) as something like:

- HTTP
pro: works with hosted mail, works with outsourcing reporting (a la
dmarcian), works even if the only MX for a domain is down
con: requires a separate HTTP endpoint (that can handle POST or PUT, which
is more than STS requires)

- SMTP-separate-message
pro: similar to DMARC, can be outsourced, requires no new infrastructure
con: requires senders to not validate STS/DANE or requires recipients to
have a different dedicated domain/outsourced recipient; potentially fails
in the same way as the original message

- SMTP-in-band
pro: doesn't require aggregation, allows indication at a fine granularity
("this transaction failed"), no extra infrastructure required
con: doesn't provide aggregation, in-band means if the MX is really
misconfigured or the sender never talks to the right MX there's no way to
get reports across

These don't strike me as mutually exclusive. Having an in-band indicator of
why the sender terminated the connection (like "STARTTLS wasn't supported
and I require it") seems useful. Having out-of-band aggregation also seems
very useful.

In particular, one of the methods by which we would hope an *intermittent
MITM* would be revealed is that reports of the occasional STARTTLS failure
would indicate exactly this. If reports can only be sent *during the MITM
to the MITM'ed MX*, this property is lost, is it not?

So I believe we need to keep some method for aggregate reporting; I don't,
however, think the option for aggregate reporting precludes more verbose
in-band indicators of why a connection is terminated.

(I will sit down and read the rest of the thread in the next day or two, so
if I've missed something, please be patient.)

Dan

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 9 May 2016 15:41:32 +0000

> indicator. Is that right?

Yes, I'm advocating for simple in-band signalling as one of the
mechanisms that should probably be supported.  This won't carry
very detailed information, but will be timely and will be seen by
the *actual* MX host that is misconfigured.

With MX hosts on anycast addresses, behind load-balancers or both,
the client will often not be able to accurately identify which
actual host it was talking to in out-of-band reports.

> dmarcian), works even if the only MX for a domain is down

Right, though if the only MX host is down, one has a bigger problem
than TLS authentication.  Presumably the site's operators are
working to fix that.

> in the same way as the original message

Right, and may cause a flood of notices to a single address, creating
congestion (processing and/or storage bottleneck).  Naive designs
that "pipe" the notices to a script or append them to a mailbox
can easily fail to scale.

> ("this transaction failed"), no extra infrastructure required

Though it does require (as noted up-thread) an upgraded MTA that supports
the proposed feature.

> misconfigured or the sender never talks to the right MX there's no way to

The assumption is that the MX host in question will report the
alerts to the administrator, performing reasonable aggregation when
alerts arrive quickly.  This can be as simple a cronjob that looks
at the last 10 minutes of logs and sends a report if some threshold
is met.  A daily report can be sent to summarize any missed events
below the threshold.

> and I require it") seems useful. Having out-of-band aggregation also seems

Definitely not mutually exclusive.  The case I'm trying to make is
that the initial operational priority is timely notification of
misconfiguration (expired, untrusted or wrong name certs).

> to the MITM'ed MX*, this property is lost, is it not?

That depends on what the MITM does of course, but yes an MITM may
be able to suppress the in-band reports.  The purpose of the in-band
reports is to maintain the health of the ecosystem against operator
error, not MiTM attack.  I believe this is a pre-requisite for
broad deployment of authenticated SMTP transport.  Once we are able
to reach broad deployment we can then think about doing more, like
reporting potential MiTM sightings.

> in-band indicators of why a connection is terminated.

Indeed neither precludes the other.  Both have their place, and
some sites might elect to not solicit the aggregate reports, while
others might not implement the in-band mechanism (though they really
should, if they care about the reliability of their inbound mail
flow).

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 9 May 2016 17:59:09 -0000

>the *actual* MX host that is misconfigured.

So long as we understand that you also need out-of-band reporting to
catch MTAs that can't take the in-band reports, sure, and also for
aggregate reports (see below.)

>can easily fail to scale.

This is pure FUD.  Lots of people take similarly bursty DMARC reports
and we don't have any trouble with them.  On the other hand, a design
so bad that it chokes trying to process a lot of SMTP reports coming
in at once is equally likely to choke on a lot of in-band reports.

>alerts arrive quickly.

Um, no.  A quick review of the draft will remind us that that there
are aggregate reports and there are failure reports, and they're
different.  My DMARC failure report parser sticks the info into a
a database as the reports arrive.  What you do with the reports
is definitely out of scope here.

>misconfiguration (expired, untrusted or wrong name certs).

I'd really like to hear from people who plan to implement this
at scale rather than guessing what they will find important.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 9 May 2016 18:21:47 +0000

> at scale rather than guessing what they will find important.

You seem rather sure and repeatedly suggest that I have no relevant
operational experience and that I'm "guessing" or I am not one of
the exalted elite who operate SMTP at scale.  To be honest that's
rather patronizing and you should stop.

For two years I've been monitoring the deployment of authentication
for SMTP (the distinction between DANE and STS is not especially
relevant here) and notifying administrators of errant MX hosts.
It is quite clear that misconfiguration notifications are and will
continue to be important.

Prior to that for a decade I was operating PKIX mandatory TLS
peering relationships for a "too big to fail" financial with 80,000
users, and supported TLS for a large community of Postfix users.
Microsoft reached out to me for advice when they were designing
improved TLS support in Exchange 2007 and implemented a few of the
key suggestions.  I've more experience in this space than the folks
you're suggesting I need to defer to.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 9 May 2016 22:44:11 -0000

It occurs to me that another reason to prefer out of band reporting is
that it's a lot easier to ramp up.

My impression is that many, perhaps most, existing MTAs can be
configured to do STARTTLS.  But of course, at this point none of them
have any reporting extensions.  Viktor and I can write reporting
extensions for our favorite MTAs, but under the most optimistic
scenario it'll take quite a while for those extensions to become
popular in all the MTAs that people use, and no extension, no in-band
reporting.

On the other hand, you can set up out of band reporting with a DNS
record pointing to the URL, and a little mail handling script or web
CGI script to accept all of your reports, no MTA patches needed.  Once
you start getting the reports, you can start adjusting the existing
STARTTLS configs, again most likely no MTA patches needed.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 9 May 2016 23:56:08 +0000

> popular in all the MTAs that people use, and no extension, no in-band

Legacy MTAs also won't have STS support.  We won't get new security
capabilitie ex nihilo.

> STARTTLS configs, again most likely no MTA patches needed.

I'm not suggesting that out-of-band reporting should not also be
specified.  Let's also specify in-band reporting.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 10 May 2016 01:15:34 -0000

>Legacy MTAs also won't have STS support.  We won't get new security

If you want to do the client stuff, you need new code in the MTA, but
for the server side part, publishing a statement saying here's the
names of my MXes and what their certificates should look like, you
don't.  Just stick the info on a web server, publish a DNS record or
two to point at it, and you're all set.

Given how long the software upgrade cycles are a lot of places, the
ability to do at least a partial implementation with existing pieces
is likely to be useful.

R's,
JOhn

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 May 2016 05:36:15 +0000

> two to point at it, and you're all set.

The proposal is exceedingly simple.  Instead of just sending "QUIT"
when TLS peer authentication fails, (or STARTTLS is not offered),
the SMTP client may be able to send a one line TLS status command.

Some MTAs would support this and some wouldn't.  Over time likely
more would than won't.  Lack of day-one support is not a valid
objection.

I'm proposing an *additional* notification channel for can be more
timely, and does not require the use of any third parties to which
one discloses one's traffic details, or publication of any email
addresses for receiving reports that may get spammed, or require
custom plumbing for report processing.

In Postfix, I can provide built-in support for the new verb in a
a way that consolidates notices for reporting to the system
administrator.

Nothing you've said in this thread makes the proposal impractical
as an *additional* mechanism for notification.  I am done with this
thread.  Over and out.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 10 May 2016 08:14:32 -0700

Yeah, I think we've spent more time on this discussion than we would on
some simple implementations. ;)

I think Viktor is right that sending something other than "QUIT" is quite
reasonable. Obviously some MTA operators may have trouble implementing it
(like if their MTA doesn't support it and they don't want to write custom
code), so for that reason and for the purposes of MITM transparency (as I
noted up-thread) we should *also* support out-of-band reporting. (MTAs need
not support STS in order to generate meaningful reports about, e.g.,
expired certs, so supporting reporting with no required MTA changes is a
useful property.)

I think we all agree that we should do both, in an ideal world. And the
discussion of priorities here strikes me as mostly misplaced, since it
mostly depends on what's easy for a given developer or host to implement;
some will implement only one or the other, I imagine.

So the only real question I have here is, should we include something about
in-band reporting (the "QUIT" alternative) in the TLSRPT draft? I think
not, as it seems a bit misplaced for the draft. But it seems like we could
fairly easy write basically a one-pager describing this other verb.

Does that make sense? Basically something like STARTTLS, where you say
"TLSQUIT [some parameters about failure]" and if you don't get back a 221
you then do a "QUIT."

(Viktor, if you want to draft something like this, I'm happy to proof read
it...)

Dan

---

From: Neil Cook <[email-masked]>
Date: Tue, 10 May 2016 17:04:45 +0100

+1 for a separate draft on in-band reporting.

Neil

> On 10 May 2016, at 16:14, Daniel Margolis <[email-masked]> wrote:
> 
> Yeah, I think we've spent more time on this discussion than we would on some simple implementations. ;)
> 
> I think Viktor is right that sending something other than "QUIT" is quite reasonable. Obviously some MTA operators may have trouble implementing it (like if their MTA doesn't support it and they don't want to write custom code), so for that reason and for the purposes of MITM transparency (as I noted up-thread) we should also support out-of-band reporting. (MTAs need not support STS in order to generate meaningful reports about, e.g., expired certs, so supporting reporting with no required MTA changes is a useful property.)
> 
> I think we all agree that we should do both, in an ideal world. And the discussion of priorities here strikes me as mostly misplaced, since it mostly depends on what's easy for a given developer or host to implement; some will implement only one or the other, I imagine.
> 
> So the only real question I have here is, should we include something about in-band reporting (the "QUIT" alternative) in the TLSRPT draft? I think not, as it seems a bit misplaced for the draft. But it seems like we could fairly easy write basically a one-pager describing this other verb.
> 
> Does that make sense? Basically something like STARTTLS, where you say "TLSQUIT [some parameters about failure]" and if you don't get back a 221 you then do a "QUIT."
> 
> (Viktor, if you want to draft something like this, I'm happy to proof read it...)
> 
> Dan
> 
> On Mon, May 9, 2016 at 10:36 PM, Viktor Dukhovni <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/uta <https://www.ietf.org/mailman/listinfo/uta>
>

---

From: Chris Newman <[email-masked]>
Date: Tue, 10 May 2016 10:07:06 -0700

> specified. Let's also specify in-band reporting.  

The MUA STS (aka DEEP) specification already has in-band reporting for SMTP Submission. We could extend that model for SMTP relay. How closely does that approach match to what you’re thinking about?

		- Chris

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 May 2016 18:01:43 +0000

On Tue, May 10, 2016 at 10:07:06AM -0700, Chris Newman wrote:

> The MUA STS (aka DEEP) specification already has in-band reporting for
> SMTP Submission. We could extend that model for SMTP relay. How closely
> does that approach match to what you�re thinking about?

Yes, the 

    CLIENT latch-fail <security-tag>

    (some places in your draft appear to use "latch-failure").

command is related in spirit to what I'm thinking of, but the
specific set of "security-tag" values is not quite as detailed as
I would hope for.

You have "tls10", "tls12", "tls-cert" and "tls-dane-tlsa".

I am more inclined to separate the mechanism and send
more detail along the lines of:

    * Sent in clear, (can be pipelined with QUIT when peer
      supports PIPELINING):

	TLSSTATUS (STS|DANE|...) NOSTARTTLS <CRLF> [ QUIT <CRLF> ]

    * Sent over unauthenticated TLS (can be pipelined with QUIT
      when peer supports PIPELINING):

	TLSSTATUS DANE NOTRUST <tlsa-base-domain    (source of policy)
	TLSSTATUS STS NOTRUST <nexthop-domain>	    (source of policy)
	TLSSTATUS (STS|DANE) EXPIRED <mxhostname>   (SNI/MX hostname)
	TLSSTATUS (STS|DANE) NOMATCH <mxhostname>   (SNI/MX hostname)

    * Either cleartext or over TLS as applicable when attempting
      to use a "backup" MX host when primary fails authentication
      and was skipped:

	TLSSTATUS (STS|DANE) BACKUP <nexthop-domain> <primary-mx-skipped>

      That way if the primary is messed up and unmonitored, the signal
      may get through via the backup, and the backup administrator will
      know why they are suddenly getting the traffic.

The idea is to give the administrator of the receiving system a
concise, but actionable, indication of what's wrong, even when the
MX host supports multiple domains and perhaps multiple cert chains
via SNI, only some of which have issues.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 May 2016 18:22:59 +0000

> 	TLSSTATUS (STS|DANE) NOMATCH <mxhostname>   (SNI/MX hostname)

Oh, and of course I forgot:

    TLSSTATUS DANE SUCCESS <tlsa-base-domain>
    TLSSTATUS STS SUCCESS <nexthop-domain>

which can be pipelined before "MAIL FROM".  It is also useful to
signal success.  Finally, in addition to "STS" and "DANE" another
mechanism is just plain-old sender-configured TLS policy (ideally
via bilateral agreement, ...).  We can call that "POLICY" or some
such.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 10 May 2016 12:56:54 -0700

Agreed; makes sense to me. I'm not sure if it makes sense to extend the
DEEP-specific reporting to cover this case; it may be easier to just draft
a short separate spec on this. What do you think?

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 May 2016 20:06:04 +0000

> a short separate spec on this. What do you think?

Yes, I think the alignment is only in spirit, there are major
differences in the flesh.  So a separate spec seems the right way
at the moment.

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 11 May 2016 04:45:19 +0700

Hey,

> On 09 May 2016, at 00:24, Daniel Margolis <[email-masked]> wrote:
> 
> Sorry, everyone. I've been out of the office the last few days on holiday and haven't had a chance to catch up on the whole thread.
> 

Me too,..

> Regarding big providers' ability to monitor for misconfigurations, I think we should not assume they will always catch errors. Especially in the early stages of deployment, as Viktor noted, a small percentage of dropped mail could go unnoticed, so having a means to accurately report failures and their causes strikes me as valuable to everyone. Anyway, I'm not really seeing an argument that only certain classes of mail hosts would benefit from this, and of course that's not anyone's goal.

Big providers, and nowadays even smaller ones, use config management, cluster schedulers, queueing frameworks et cetera (not an unsolved problem after all) -- but small mail ops do not. Please keep that in mind, guys.

> These don't strike me as mutually exclusive. Having an in-band indicator of why the sender terminated the connection (like "STARTTLS wasn't supported and I require it") seems useful. Having out-of-band aggregation also seems very useful.

+1

> 
> In particular, one of the methods by which we would hope an intermittent MITM would be revealed is that reports of the occasional STARTTLS failure would indicate exactly this. If reports can only be sent during the MITM to the MITM'ed MX, this property is lost, is it not?

Yes, but it also depends how the MITM is attempted. Sometimes an attacker might not resort to all "tools" available, or it may be a simple scripted attack without any insight into what's happening real-time.

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 11 May 2016 04:55:43 +0700

> On 10 May 2016, at 05:44, John Levine <[email-masked]> wrote:
> 

Ask you the package maintainer of your favourite distro to update in time.

Extensions and updates must happen eventually, we can't support CentOS 5 machines only because there're many. This isn't really something that should even come up during a discussion on a IETF document, is it?

> STARTTLS configs, again most likely no MTA patches needed.

DNS isn't MITM safe. DNSSEC non-existent. Also: I'd rather not see hacked-up cronjobs but proper implementations.

Aaron

---

From: "John R Levine" <[email-masked]>
Date: 10 May 2016 19:37:11 -0400

> Ask you the package maintainer of your favourite distro to update in time.

Distro?  Largish mail systems tend to use commercial software, which 
updates when it updates.  You mght want to talk to the people who maintain 
Port25 and Communigate and MDaemon and MS Exchange and see what their 
schedules look like.

> DNS isn't MITM safe. DNSSEC non-existent. Also: I'd rather not see hacked-up cronjobs but proper implementations.

Yes, we know.  But, oddly, people send around gazillions of DMARC reports 
by e-mail every day and it appears that the vast majority of them get to 
the right place.

Regards,

---

From: Chris Newman <[email-masked]>
Date: Tue, 10 May 2016 18:02:25 -0700

> differences in the flesh. So a separate spec seems the right way 

Submission and SMTP relay are syntax-aligned but not semantics aligned. I object to deviation from that design. So there should be only one syntax for in-band SMTP reporting, but exactly what is reported will vary based on whether it is the submission or relay use case. If someone wants to write a separate spec for this, I am fine removing the present syntax from MUA STS and suggesting submission-relevant text for the separate spec.

	- Chris

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 May 2016 03:03:41 +0000

On Wed, May 11, 2016 at 04:55:43AM +0700, Aaron Zauner wrote:

> DNSSEC non-existent.

I do have some counter-examples to that claim, that have not only
DNSSEC, but also DANE TLSA records for inbound SMTP:

    gmx.at
    registro.br
    gmx.ch
    gmx.com
    mail.com
    bund.de
    gmx.de
    jpberlin.de
    lrz.de
    posteo.de
    ruhr-uni-bochum.de
    web.de
    octopuce.fr
    comcast.net
    dd24.net
    gmx.net
    key-systems.net
    mpssec.net
    t-2.net
    xs4all.net
    xs4all.nl
    debian.org
    freebsd.org
    gentoo.org
    ietf.org
    isc.org
    openssl.org
    samba.org
    torproject.org
    (and 30500 others that are less well known)

Yes, it is true that both DNSSEC and IPv6 still have some catching
up to do with vanilla DNS and IPv4, respectively.  A sample of
DNSSEC adoption for a few TLDs:

    TLD		DNSSEC
    ----------  -----
    .bank	100.0%
    .ovh         46.4%
    .amsterdam	 24.9%
    .email        1.4%
    .edu          1.4%
    .net	  0.61%
    .com	  0.44%
    .xyz	  0.29%
    .berlin	  0.13%
    .nyc	  0.0066%

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 11 May 2016 10:11:44 +0700

> On 11 May 2016, at 06:37, John R Levine <[email-masked]> wrote:
> 
> Distro?  Largish mail systems tend to use commercial software, which updates when it updates.  You mght want to talk to the people who maintain Port25 and Communigate and MDaemon and MS Exchange and see what their schedules look like.

I figure GMail and Yahoo run their own implementation, whereas large ESPs I've seen do indeed run open-source products on commodity hardware.

FYI: My background includes large-scale WebOps, mail service providers and HPC engineering. I think I still have a Port25 shirt somewhere, these folks where rather reasonable, and I think they would not mind to add more security to their (quite excellent) product.

> Yes, we know.  But, oddly, people send around gazillions of DMARC reports by e-mail every day and it appears that the vast majority of them get to the right place.

Because nobody cares to MITM DMARC reports, at least I wouldn't.

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 11 May 2016 10:14:10 +0700

> On 11 May 2016, at 10:03, Viktor Dukhovni <[email-masked]> wrote:
> 

Do you have percentages which of these aren't either:

a) a open-source project where there's large community demand (for some reason)
b) hosted in germany where there's a BSI guide-line to implement DNSSEC (I talked to these guys a while ago, they're largely unfamiliar with the topic of cryptography AFAICT)
c) aren't .gov, .mil etc. where a similar policy to the BSI one exists - though large outages still happen frequently

?

Thanks,
Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 11 May 2016 10:22:07 +0700

> DNSSEC adoption for a few TLDs:

Doesn't get more biased.

nic.nl incentivises DNSSEC adoption with reduced domain rates (there're similar effort in Scandinavia as I am told by the PowerDNS people). I think DNSSEC is required for .bank and OVH just does their own thing.

Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 May 2016 00:01:09 -0400

> On May 10, 2016, at 11:14 PM, Aaron Zauner <[email-masked]> wrote:
> 

The open-source projects are a very tiny subset of the overall list,
they are a large fraction only of the "more prominent" domains, by
being "more prominent" then the mostly small domains with DANE support.

> b) hosted in germany where there's a BSI guide-line to implement DNSSEC (I talked to these guys a while ago, they're largely unfamiliar with the topic of cryptography AFAICT)

[ I get it, you really don't care for DNSSEC. :-)  But that's not
  a sound reason to then also dislike anyone who is not like-minded. ]

While the BSI does have some influence over government systems and
large email providers, ... the vast majority of .de domains with DANE
TLSA records are individual vanity and small-business domains, and
they are choosing to enable email transport security, not BSI
conformance.

A lot of the .de domains with DANE TLSA are hosted by udmedia.de, that
specifically marketed DNSSEC/DANE support to owners of small domains,
and hosts around 6000 domains under .de/.eu/.com/.net/...

Of the .de 3200 domains with DANE TLSA (that I was able to find, I
don't have anything like a complete list) ~1300 are not hosted by
udmedia.de or transip.nl or the other 3 top DNSSEC+DANE hosting
providers.  They are "Mom&Pop" vanity domains and domains of
some small businesses.

> c) aren't .gov, .mil etc. where a similar policy to the BSI one exists
> - though large outages still happen frequently

While .gov and .mil mandate DNSSEC, they don't have any domains with
DANE at present.  The closest you'll get to that in the DANE space is

   ncaa.go.tz
   zanzibarjustice.go.tz

I doubt Tanzania was substantially influenced by either BSI or the USG.
More likely someone with a bit of initiative there though it was a good
idea and made it happen.

The top 5 DANE/DNSSEC enable registrars are the primary MX hosts of
25.3k of the 30.5k domains. The remaining 5.2k domains are fairly diverse,
and yes a large fraction are in Germany.  If we also exclude domains with
a secondary MX with one of those registrars we end up with:

1263 com
1013 de
 655 net
 360 org
 234 eu
 181 nl
 174 cz
  84 se
  82 ch
  81 info
  78 fr
  78 com.br
  71 xyz
  58 at
  56 email
  53 dk
  53 be
  48 me
  42 io
  28 biz
  27 us
  25 name
  22 co.uk
  18 uk
  17 ovh
  16 pt
  16 hu
  14 net.br
  13 si
  13 lu
  12 ru
  11 pl
  11 is
  20 fi
  11 co
  10 nu
   9 cc

Many of the .com/.net/.eu/.org domains are likely also German, but there
is also a considerable fraction of AT/CZ/SE/CH/FR/DK/BE/NU domains.  So,
yes, at present most the deployment is in Northern Europe, but note also
some signs of life in the eastern block .si/.ru/.hu/.pl

With only one MTA open-source supporting DANE at present, and only with
relatively recent releases, and OpenSSL 1.1.0 still (for a couple more
weeks) in beta, it is not surprising that deployment is still light.
We can't expect deployment when supporting code is not yet widely
available.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 May 2016 00:15:04 -0400

> On May 10, 2016, at 11:22 PM, Aaron Zauner <[email-masked]> wrote:
> 

Indeed, I am showing you the full spectrum.  No intention to mislead
anyone with biased data.  Obviously the double-digit percentages are
outliers, and various incentives are at play.  And undoubtedly DNSSEC
is mandatory for .bank (no other plausible explanation for the above
100% support).  The more realistic overall estimated support level is
O(0.5%), which e.g. translates to just south of 600k domains in the
.com zone.

There are many legitimate points of difference with respect to DNSSEC,
but I don't think that any are worthy of dogmatic zeal.

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 11 May 2016 12:02:56 +0700

Hey Viktor,

> On 11 May 2016, at 11:01, Viktor Dukhovni <[email-masked]> wrote:
> 
> 

It's not that I didn't like them. They were nice guys.

But, among quite a few other things, if they're talking about new guidelines -- some with regard to X.509 -- and haven't heard about CT or how CT works, that's a bit weird, IMO. BSI is the former crypto department of the BND, as I'm sure you're aware. I'm from a german speaking country with similar bureaucracies in place, and I have very little trust in their ultimate recommendations, findings and laws they support. But that's just me, I don't like governments in general. That doesn't mean they do not have good people around, there're some, I've even met a few.

It's also a bit off-topic w.r.t. the DNSSEC/DANE discussion. I do like the DANE standard itself, I just hate that it builds on DNSSEC. Shifting trust-anchors from (now audited, monitored) CAs to TLDs (now we have tons of weird gTLDs), is just not the way to go. Besides DNSSEC being a 15 year old standard that totally fails in many information security regards, hasn't been updated to an extent that I'd consider it "modern" etc.

> they are choosing to enable email transport security, not BSI

I'd still see this as a somewhat "german trend". Sysadmins talk to each other, use the same forum posts, et cetera.

> More likely someone with a bit of initiative there though it was a good

Agreed.

> We can't expect deployment when supporting code is not yet widely

That's more to the point, thanks for the data. Are your raw data-sets public anywhere (e.g. scans.io)?

Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 May 2016 01:32:34 -0400

> On May 11, 2016, at 1:02 AM, Aaron Zauner <[email-masked]> wrote:
> 

Since more than one of my sources is non-public, I think I am not at
liberty to publish the raw underlying data. :-(  Sorry about that.

The main thrust of the survey is to find DANE-enabled domains whose
records go stale, and nudge them to fix.  Ditto with DNSSEC zones
that drop TLSA queries or mangle denial of existence.

This effort has payed off in that both sets of problems are quite
rare, and would not have been otherwise.

With the early adoption cycle protracted, and early enthusiasm
to publish records not necessarily translating to operational
discipline, it is important to artificially maintain hygiene
until real incentives kick in due to broader adoption.

Once more senders enable DANE outbound, receiving systems with
broken records will have real incentives to fix problems quickly.
However, if the early adopters were all messed up, there'd be
strong disincentives for broader adoption.  So I've lowered
the barriers to adoption by keeping the error rates much lower
than they would naturally have been at this stage.

Making the data public was not a primary goal, though I have
posted some aggregate summaries from time to time at
[email-masked], [email-masked], [email-masked]
and this list.

There are still more HOWTO documents to write, a bit of time
to invest in improving the experimental support in Exim, perhaps
more TLS libraries to augment beyond OpenSSL, ...

This takes time, but so far so good.  The German and Dutch
domains are an adequate incubator.  The lessons will be
applied to better deployment guides for those who deploy
later.

It me a while to realize that a combination of "3 1 1"
and "2 1 1" records provides optimal operational resilience.
This allows decoupling of DNS updates from cert chain
updates, provided that at any given time at least one of
the issuer CA or server public keys remains unchanged.

One can deploy a new server keypair with a cert signed
by the same issuer without pre-publishing an updated
TLSA RRset, and then update the TLSA RRset some time
after.  Or deploy a new cert for the same server keypair
from the same issuer.

This is especially well suited for Let's Encrypt, but
generalizes also to use of a private issuing CA.

This will be written up in more detail in the next
few months, bundled with Postfix docs, and ideally
also as an informational RFC on DANE best-practice.

-- 
-- 
	Viktor.

---

From: "John R Levine" <[email-masked]>
Date: 11 May 2016 11:20:57 -0400

> FYI: My background includes large-scale WebOps, mail service providers and HPC engineering. I think I still have a Port25 shirt somewhere, these folks where rather reasonable, and I think they woul…

Um, port25 has nice tee shirts but it isn't open source.  You must know 
different ESPs than I do if they're running postfix or other open source 
stuff.  ESPs tend to run port25, large ISPs run Openwave or Momentum, the 
largest ISPs as you say rull their own.  Medium sized businesses may use 
Exim or Postfix, but a lot use nicely packaged stuff like MDaemon.

> Because nobody cares to MITM DMARC reports, at least I wouldn't.

We really need a threat model beyond "someone might be spying on me."

If you look at the MITM paper by Durumeric et al., particularly tables 12 
and 15, it looks like overall the biggest cause of STARTTLS failures was 
corporate firewalls, and beyond that there are some places wwhere it looks 
like the ISPs MITM some or all of the mail traffic, notably Tunisia.  I 
can only guess what they're looking for, but it seems kind of a stretch 
the think they'd be looking for reports with XML or JSON attachments.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 11 May 2016 20:25:42 -0000

Hmmn.

>    TLD		DNSSEC

3173 domains

>    .ovh         46.4%

about 22,000 of 47,000 domains

>    .amsterdam	 24.9%

about 6200 of 25,000 domains

I think it's fair to say that we're still a long way away from broad
DNSSEC adoption.  This doesn't mean we should ignore it, but it does
mean that non-DNSSEC approaches like the one here are worth thinking
about.

R's,
John

PS: I specifically take no position about the relative credibility of
some random DNSSEC signed ccTLD from a country I've never visited and
some random CA in my browser's list with a CPS link that's 404.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 May 2016 18:21:56 -0400

> On May 11, 2016, at 4:25 PM, John Levine <[email-masked]> wrote:
> 

Quite fair, though DNSSEC adoption does not happen in a vacuum, there
have to incentives to do it.  If the large providers got enough round
twoits and implemented DANE/DNSSEC for their domains, there would be
a stronger incentive for others to follow suit.

> some random CA in my browser's list with a CPS link that's 404.

Here I posit we gloss over the fact that while some random CA can issue
certificates for any domain, the registry for some ccTLD can only sign
delegations for that ccTLD, and unlike the CA they are actually
authoritative for such delegations.  But we digress, the key thing to
avoid is comparing EV with DANE/DNSSEC, the right comparison is with DV,
and DANE+DNSSEC is stronger than DV, where proofs of control are rather
skimpy, and rogue CAs unrelated to the domain's registration can mint
"out of the blue" certificates.

Yes, the STS train will leave the station.  There's no substantive
disagreement between us, just minor misunderstandings and differences
of emphasis.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 12 May 2016 03:58:55 -0000

>a stronger incentive for others to follow suit.

It's more complicated than that.  Google has said that they could turn
on DNSSEC for their domains if they wanted, but there's still enough
stuff that breaks other places that they won't.  

On my tiny system, I have about 300 zones, all signed, but I've only
been able to install parent DS records for about half of them, my own
and ones for which I'm the registrar reseller.  A few are in TLDs that
still don't do DNSSEC, gTLDs .aero and .travel, for example.  The rest
are registered by other people, and although the registries have
delegated DNS to me, I have no practical way to tell them what DS
records to use.  There's some work in dnsop to try and fix that, see
draft-dnsop-ogud-maintain-ds

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 May 2016 00:43:03 -0400

> On May 11, 2016, at 11:58 PM, John Levine <[email-masked]> wrote:
> 

Yep, there a lot of work remaining to be done.  Of the ISO 2-letter
ccTLDs 109 have DNSSEC enabled and 138 don't.  And the remaining TLDs
without DNSSEC are as you mention:

aero
int
mobi
pro
tel
travel

Plus 25 IDN forms of some of the ISO ccTLDs.  The good news that the
6 TLDs above are not particularly popular.

Three key obstacles to universal availability are lack of support
at the 138 ISO + 25 IDN ccTLDs, that not all registrars support
publication of DS RRs, and a key rotation barrier when zone data
management (including DNSKEY management and zone signing) is
outsourced, but the registrar relationship remains with the domain
owner.  We need a standard way for DNS service providers to update
DS RRs on an ongoing basis, after the customer uploads the initial
DS RRset to the registrar.

You're quite right that not all the pieces are yet in place to
address all the needs.  Some groups of users cannot at present
be supported.

-- 
	Viktor.

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 12 May 2016 13:36:19 +0700

> On 11 May 2016, at 22:20, John R Levine <[email-masked]> wrote:
> Um, port25 has nice tee shirts but it isn't open source.

I never said it was? I'm aware it's a closed-source product. And it's quite good - I've been using it extensively in the past. Though their devs. were very cooperative and reversing *would* have been easy given we got debug symbols for their binaries,.. :x

BTW: Your book on linkers & loaders is among my most valued literature for debugging.

> We really need a threat model beyond "someone might be spying on me."

Sorry, but I completely disagree. Because "someone" *is* spying on all of us! It's called full-take and they do it in real-time. Have you been reading the news since June 2013?

> If you look at the MITM paper by Durumeric et al., particularly tables 12 and 15, it looks like overall the biggest cause of STARTTLS failures was corporate firewalls, and beyond that there are some places wwhere it looks like the ISPs MITM some or all of the mail traffic, notably Tunisia.  I can only guess what they're looking for, but it seems kind of a stretch the think they'd be looking for reports with XML or JSON attachments.

Transmission-failure data in this paper is entirely based on a GMail-only data-set as far as I can tell (please correct me if I'm wrong) and was accompanied by scanning results. Ralph Holz and we did some as well (full TLS enumeration in our case), if you're interested:

- https://arxiv.org/abs/1511.00341
- https://arxiv.org/abs/1510.08646

To have a proper picture of world-wide traffic interception I'm strongly suggesting the feedback mechanism be extensible. If that's the case we can easily report detailed TLS failures, MITM attacks and operational failures back to decentralized monitoring services as well as recieving MTAs (who may also only be able to pick that up via a 3rd party). We currently have no conclusive picture in this domain. RIPE ATLAS is the best project I'm aware of, but they do not focus on e-mail.

Aaron

---

From: "John R Levine" <[email-masked]>
Date: 12 May 2016 09:48:36 -0400

> I never said it was? I'm aware it's a closed-source product. And it's 
> quite good - I've been using it extensively in the past. Though their 
> devs. were very cooperative and reversing *would* have been easy given 
> we got debug symbols for their binaries,.. :x

There's a bottle of wine in my fridge that the head of development at 
port25 gave me.  He's very nice, and very competent, but he's also very 
busy.  The last time I talked to him he was working on EAI, and I gather 
there's a long list of other stuff to add and improve.  We could probably 
get STS reporting on the list, and on the similar lists for MDaemon and 
Communigate and Openwave and Momentum, but by the time it's written, 
tested, packaged, shipped, and the customers put it into their 
installation schedules, it'll be at least a couple of years.  That's why 
"ask your favorite distro to update" isn't going to work any time soon in 
the places that matter.

My original point which I thought, perhaps wrongly, was obvious, is that 
all of these MTAs already have TLS support, so if we define a way to 
receive failure reports that doesn't need MTA changes, they can start 
collecting reports now and fixing their configuration errors.  Our 
experience with DMARC is that at for the first year, hardly anyone but 
Google and Yahoo were sending reports, but since they handle so much mail 
to everyone else, if you published a DMARC record and started collecting 
reports, you'd find out a lot about your mail configuration, and 
invariably learn about configuration mistakes you could just fix.

> Sorry, but I completely disagree. Because "someone" *is* spying on all of us! It's called full-take and they do it in real-time. Have you been reading the news since June 2013?

Of course there's lots of spying, but I hope we all remember the maxim 
never to attribute to evil what can be explained by incompetence.  For 
every TLS session broken by malicious spying, there will be many more 
broken by misconfigured TLS in the MTA, or a firewall in the wrong place, 
or any of the other reasons we all know.  The sooner people can start 
collecting info about the failures, the sooner they can start fixing the 
screwups that cause them.

I'm not saying we should ignore malicious MITM, but I also think that 
anyone smart enough to do MITM is likely to be smart enough to defeat 
whatever reporting we invent if they care enough to do so, or in places 
like Tunisia where everyone uses one or two state-controlled ISPs, 
prevent users from circumventing MITM even when they're aware of it.

So we should try and understand what are the reasons that TLS fails, and 
start with approaches that can address the most common ones.

Regards,

---

From: Jim Fenton <[email-masked]>
Date: Thu, 12 May 2016 11:26:49 -0700

On 5/12/16 6:48 AM, John R Levine wrote:
>> Sorry, but I completely disagree. Because "someone" *is* spying on
>> all of us! It's called full-take and they do it in real-time. Have
>> you been reading the news since June 2013?
>
> broken by misconfigured TLS in the MTA, or a firewall in the wrong
> place, or any of the other reasons we all know.  The sooner people can
> start collecting info about the failures, the sooner they can start
> fixing the screwups that cause them.

Incompetence will show up consistently and therefore can be detected by
a considerably simpler mechanism: a testing site, like Qualys SSL Labs.
I see that there is a checktls.com that does exactly this. Incompetent
email operators will probably not implement reporting anyway.

Reporting is, however, useful for detecting TLS breakages that don't
consistently show up, which are much more likely to be caused by, as you
put it, "evil".

-Jim

---

From: "John Levine" <[email-masked]>
Date: 12 May 2016 18:54:00 -0000

>consistently show up, which are much more likely to be caused by, as you

Maybe, maybe not.  If you have several MTAs behind a load balancer, or
geographically distributed MTAs with the usual DNS tricks to point
people at the closest host, and one is misconfigured, the symptom
would be flakiness. A one-off test like Qualys does would likely
to hit one of the good ones.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 May 2016 19:09:04 +0000

> email operators will probably not implement reporting anyway.

This assumes that the operators of the receiving tests are bothering
to perform adequate tests.  Many do not.  This is an empirical
observation, not a guess.

Reporting of misconfiguration will be useful, as will use of every
available notification channel.  In-band, out-of-band or both as
made available by the receiving system.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 May 2016 19:17:00 +0000

On Thu, May 12, 2016 at 09:48:36AM -0400, John R Levine wrote:

> My original point which I thought, perhaps wrongly, was obvious, is that all
> of these MTAs already have TLS support, so if we define a way to receive
> failure reports that doesn't need MTA changes, they can start collecting
> reports now and fixing their configuration errors.

This means a strong asymmetry in the protection of the SMTP traffic.
The MTAs with just existing TLS support will not support outbound
STS or DANE, and will continue to do opportunistic TLS.  The only
direction in which SMTP would be protected with such sites would
be outbound from the early adopters of STS like Google/Yahoo/...

Perhaps that's somewhat useful, but with email flowing back and
forth, if either direction is easy to MiTM, we're not gaining that
much.

> Of course there's lots of spying, but I hope we all remember the maxim never
> to attribute to evil what can be explained by incompetence.  For every TLS
> session broken by malicious spying, there will be many more broken by
> misconfigured TLS in the MTA, or a firewall in the wrong place, or any of
> the other reasons we all know.  The sooner people can start collecting info
> about the failures, the sooner they can start fixing the screwups that cause
> them.

On this we're in strong agreement.

> start with approaches that can address the most common ones.

Indeed.

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 13 May 2016 03:34:21 +0700

> On 13 May 2016, at 01:54, John Levine <[email-masked]> wrote:
> 

True, but admins usually at least know where their stuff is (hosted), don't they?

You can do Qualys on your own:
```
# totally not production ready
pip install --upgrade sslyze
domain="azet.org" # change domain to an array of actual IP addresses if your DNS is using GeoIP
for mx in $(dig mx ${domain} +short); do sslyze_cli.py --regular --certinfo_full --starttls=smtp ${mx}; done
```
Kinda.

Aaron

---

From: "John R Levine" <[email-masked]>
Date: 12 May 2016 16:41:43 -0400

> True, but admins usually at least know where their stuff is (hosted), don't they?

You would hope so, but in sufficiently large organizations, sometimes not. 
It's off in the cloud, somewhere.

Regards,

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 May 2016 20:46:20 +0000

> It's off in the cloud, somewhere.

And in many small organizations just deploy and wait for someone
to complain (the "test in production" approach).

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 13 May 2016 10:28:47 +0700

> On 13 May 2016, at 03:41, John R Levine <[email-masked]> wrote:
> 
> You would hope so, but in sufficiently large organizations, sometimes not. It's off in the cloud, somewhere.

"The cloud" usually offers APIs. For example if I were to use e.g. Cloudflare for GeoDNS or another service, they all offer me an API I can query and feed into a tool like sslyze. You do have a point though, during our scans we routinely discovered completely misconfigured servers.

Aaron

---

From: Sean Leonard <[email-masked]>
Date: Sun, 15 May 2016 01:10:32 -0700

I have a small contribution to this discussion, about CBOR, and then some stuff on encoding and submission formats.

> On May 5, 2016, at 1:34 AM, Aaron Zauner <[email-masked]> wrote:
> 
> Hi Chris,
> 
> Appreciate the feedback.
> 

CBOR is a newer format but it corrects the deficiencies of other prior formats. Comparing it to the so-called problems in ASN.1 is shortsighted.

> 
>> Binary formats have an extremely poor track record for security-sentive applications. ASN.1 BER/DER has been an utter disaster for real-world security in PKIX (there are probably hundreds of CVE reports due to ASN.1 parser bugs including many in TLS/SSL/PKIX stacks).

And there are many thousands of such reports due to parsing bugs and programmer incompetence for text formats like SQL, HTML, and XML.

The common thread is not binary vs. text; the common thread is that it’s a security-sensitive program.

>> We should not repeat this design error in a security-sensitive context again.
> 

Actually CBOR is pretty simple. There are only eight major types: positive integer, negative integer, binary string, utf-8 string, array, map, tag, and special types. You can implement a parser in less than 1K. And a big advantage of (many) binary formats in general is that they do not require data payloads to be re-encoded, e.g., in base64, which requires unnecessarily enlarging the payloads.

To get to where the topic is today: if JSON is the way this draft is going, then JSON-as-CBOR is possible. JSON is just a strict subset of CBOR, so it should be pretty easy to define this in JSON, and leave the option of the wire format being in CBOR as a flag or media type field.

Reading draft-brotman-smtp-tlsrpt-00, I suggest the following:
Section 3. Reporting Policy should have an additional field:
"f": Accepted formats of the report. This parameter is ASCII and case-insensitive; each accepted format type is indicated by one ASCII character. Values can be “j” for JSON, “c” for CBOR, and “jc” or “cj” for both. Unrecognized values can be ignored. Implementations are expected to accept JSON.

In both the https and mailto upload formats, it is desirable to specify the format (specifically, the media type) of the submission. Currently this could be inferred from the current draft -> RFC 7469 -> RFC 7159, but I think it should be clearer. Specifically: is the format a single MIME content with application/json (in the case of a JSON report), and by extension, application/cbor (in the case that CBOR is acceptable) and application/xml (in the case of possible XML), or can the body be multipart/mixed? Are there other headers that ought to be specified? For example, when doing mailto, what if the mailto URI has “?subject=foo”?

While we are on the topic of mailto, what if the local-part is EAI? Does that mean that the rua directive is UTF-8 encoded, or must the local-part be percent-encoded when in mailto? (Note that in the formulation above, I specifically called out “f” as being in ASCII. Since URIs are ASCII, I would think that non-ASCII characters in URIs would need to be percent-encoded, and that the domain of “rua” should suitably be limited to ASCII.)

Sean