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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
