Hi, Viktor Dukhovni wrote: > I don't think domain-level pinning, rather than per-server pinning > is workable. Pins expire, domains change hands, and MTAs unlike > MUAs and browsers don't have users to "click OK" when stuff breaks.
How would you imagine per-server pinning with workable key-rollover? I too see problems with expired pins -- see below. > With STS (which I am not currently endorsing as a universal approach > beyond the small club of the largest providers behind this design) > the destination domain owner publishes the policy which essentially > pins the MX RRset and specifies authenticaiton of same. The > webserver that authenticates the policy is at a well-known URI > associated with the destination domain. The MX operator just has > to maintain valid WebPKI certificates from some widely trusted CA, > that are associated with the MX hostname. I don't see why CT > support or lack thereof is pertinent here. It's not but would be nice to have, no? > >> Currently more than 60% of SMTP MTAs do _not_ have signed certificates, >> far less even provide valid CN or SAN X.509 information. > > Because why pay for bits everyone is going to ignore anyway. The > sysadmins are behaving rationally. Sure. But then again they need signed certs for the WebPKI reporting and authentication anyway as far as I understand the current proposal (it's not submitted to IETF so we're discussing something that the authors might not even envision). > >> TACK does not >> require certificates to be CA-signed, this is completely optional. TACK >> also makes revocation and key-rollover a bit easier than this proposal. > > I'd considered TACK for SMTP, but gave up once it became clear that > TACK (per-server key pinning) is of no use given MX indirection. TACK has various problems there, and it's a bit dated by now given change in some parts of the WebPKI infrastructure and new protocol proposals within IETF. We could pick it up, dust it off and find a proper way to use it for e-mail though, this is my idea. There's no reason in verbatim employing TACK as currently documented. > FWIW, I don't think that STS is universally applicable either, ... > That said I'm going to contribute some cycles and text to making > it as good as it can be, and then time will tell. Worst case it > will help the large providers secure their inter-organizational > connections and protect a large fraction of mail by volume, rather > than domain diversity. I see it makes a lot of sense for large hosting providers, and have noted so repeatedly. The problem is: they're already doing fine with security deployment and some of them might already have some form of "pinning" (say Google knows Yahoo's server information and the other way around - not sure if that's really the case but I'd do it this way on that scale even without a proper protocol given the Snowden disclosures). If we end up with a protocol that's only deployable for large providers we don't get added security for the small self-hosted MXs on the Internet - and this is my concern. We can't just tell all of them to use GMail as an MX. Thanks for your feedback, Aaron
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
