Subject: [dane] DANE+SMTP draft

From: Yaron Sheffer <[email-masked]>
Date: Wed, 30 May 2012 20:53:40 +0300

Hi,

I just noticed the new draft that strengthens the use of SMTP STARTTLS.

I have always been under the impression that STARTTLS is weak in actual 
use because a MITM attacker can cause it not to be negotiated at all (a 
bid-down attack over the unencrypted, unauthenticated cleartext SMTP). 
So strengthening the TLS authentication is sort of like closing the barn 
door after the horse has already gone. Am I missing something? At the 
very least, this should be mentioned in the security considerations.

Thanks,

     Yaron

---

From: Scott Schmit <[email-masked]>
Date: Wed, 30 May 2012 18:05:32 -0400

On Wed, May 30, 2012 at 08:53:40PM +0300, Yaron Sheffer wrote:
> I have always been under the impression that STARTTLS is weak in
> actual use because a MITM attacker can cause it not to be negotiated
> at all (a bid-down attack over the unencrypted, unauthenticated
> cleartext SMTP). So strengthening the TLS authentication is sort of
> like closing the barn door after the horse has already gone. Am I
> missing something? At the very least, this should be mentioned in
> the security considerations.

STARTTLS is only weak today because the client has no way to know a
priori that it should expect it to be available.  With this document,
the client knows that secure TLSA record = STARTTLS MUST work and the
indicated certificate MUST be offered, or the connection fails.

This is explained on page 4 of -01.

-- 
Scott Schmit

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 31 May 2012 07:28:27 +0300

Hi Scott,

thanks for your response. Yes, this is indeed explained on page 4. However:

- The document has: "If any of these checks fail, the client MUST 
disconnect from the server and treat this as a temporary failure." This 
is unrealistic - if the server is not provisioned with a correct 
certificate, this is not a temporary condition. In actual use, such 
failures are more likely to be caused by provisioning issues than by 
malicious attacks.

- In addition, this sentence conflicts with the earlier text "If these 
security requirements are not satisfied, this protocol does not take 
effect.  The client SHOULD fall back to insecure delivery (which might 
be over unauthenticated TLS)." So we do allow fallback to 
"unauthenticated TLS" (and implicitly also to plaintext?), which is in 
fact vulnerable to the same MITM attacker.

Regards,
	Yaron

On 05/31/2012 01:05 AM, Scott Schmit wrote:
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Tony Finch <[email-masked]>
Date: Thu, 31 May 2012 11:59:41 +0100

Yaron Sheffer <[email-masked]> wrote:
>
> - The document has: "If any of these checks fail, the client MUST disconnect
> from the server and treat this as a temporary failure." This is unrealistic -
> if the server is not provisioned with a correct certificate, this is not a
> temporary condition. In actual use, such failures are more likely to be caused
> by provisioning issues than by malicious attacks.

You are right that other provisioning errors in SMTP lead to permanent
failures. Mail will bounce if you fail to configure your MTA to accept
mail for a domain, or if you fail to put the necessary records in the DNS.
The underlying assumption is that the network is a benign environment and
this kind of error is a mistake not an attack. That is not true for a
security protocol. So for SMTP+TLSA I think it's better to be robust not
brittle. The sender will still get delay notifications if the provisioning
error persists.

> security requirements are not satisfied, this protocol does not take effect.
> The client SHOULD fall back to insecure delivery (which might be over
> unauthenticated TLS)." So we do allow fallback to "unauthenticated TLS" (and
> implicitly also to plaintext?), which is in fact vulnerable to the same MITM
> attacker.

No, the fallback occurs when the DNSSEC part of the protocol has not been
(completely) deployed. A MITM cannot spoof DNSSEC responses, so it can't
force a downgrade on the MX or TLSA lookups. I think you are right that
the wording is not clear so I shall improve it.

Thanks for the feedback.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dover, Wight, Portland, Plymouth: West or southwest 4 or 5, occasionally 6 in
Dover. Slight or moderate. Fog patches. Moderate, occasionally very poor.