Aaron, I think the important point here is when you say TOFU (Trust On First
Use) - that means no trust anchor is involved at least during the initial step.
In the case of STS, the policy is served over webpki. In fact sender can
possibly skip DNS indicator flag and directly fetch policies from recipient's
well known HTTPS endpoint. Note that DNS STS record is a convenience, not a
must to have component.
> One of the main issues currently is that most MTA-MTA traffic is over
>connections established without a CA signed certificate. You're now requiring
>them to use one anyhow, just in a different place.Using untrusted cert is not
>a feature, but an important security issue that needs to be fixed either
>through DANE or PKIX.
thanks,-binu
From: Aaron Zauner <[email protected]>
To: Binu Ramakrishnan <[email protected]>
Cc: Mark Risher <[email protected]>; "[email protected]" <[email protected]>; Orit Levin
(CELA) <[email protected]>; Daniel Margolis <[email protected]>
Sent: Tuesday, 5 April 2016 3:26 PM
Subject: Re: [Uta] New proposal: SMTP Strict Transport Security
Hi,
> On 05 Apr 2016, at 03:13, Binu Ramakrishnan <[email protected]> wrote:
> 1. TACK TOFU model promotes trusting self-signed certificates. It is similar
> to SSH and it is less trusted than PKIX.
You can use TACK with self-signed or with CA signed certificates. I'm not sure
I agree that there is less trust than with just PKIX.
> 2. What is the process followed when you change your MX from abc.com to
> xyz.com ? Basically explain how to differentiate a legitimate MX redirection
> with an attacker diverting the traffic, especially in short notice?
A TACK pin is bound to a hostname and TACK signing key (TSK). While ordinarily
you'd probably just publish a new TACK for a new hostname it's possible to have
multiple hostnames signed by the same TSK and this could be used to manage
hostname-rollover if I'm not mistaken (the original draft does of course not
consider this scenario).
You do have a similar problem with STS: You'd need DNSSEC to ensure that an
attacker can't divert traffic on the first connection attempt. You already
mention this in the "Future Work" section of your document under "certificate
pinning" (I think it's supposed to say "public key pinning"). One of the main
issues currently is that most MTA-MTA traffic is over connections established
without a CA signed certificate. You're now requiring them to use one anyhow,
just in a different place.
> 3. (repeating) Whether you use Git or append logs or "pins" from 3rd party,
> you still need to fetch policies from a remote location possibly over HTTPS.
Sorry I think that wasn't clear: my discussion on git/CT/reporting and interest
in your CT-related work had nothing to do with TACK or authentication.
>
> >It's a TOFU model. So you establish trust on first use / flight. From
> >thereon you have pins.
> > See above w.r.t. roll-over.
>
> Why to use TOFU, when there are better options? STS directly fetches policies
> over HTTPS and the trust is established over PKIX
Again; you may use PKIX with TACK.
Aaron
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
