Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP STS Draft)

[Aaron Zauner <[e-mail]>]

> On 06 May 2016, at 14:00, Viktor Dukhovni <[e-mail]> wrote:
> 
> On Fri, May 06, 2016 at 12:57:15PM +0700, Aaron Zauner wrote:
> 
>>> 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.
>> 
>> 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.

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

> 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.

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.

> 
>> 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)

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

> 
>>> 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.
>> 
>> 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.

Which non-IETF documents? Where?

> 
>>> 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.
>> 
>> 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.

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.

> 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)>

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.

>    * 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.

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

>    * 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.

See above.

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

See above.

>    * 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 like it as well.

> 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,

I'm aware of that :)

> ...
> 
> 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.

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