Hi Daniel,

> On 04 Apr 2016, at 19:56, Daniel Margolis <[email protected]> wrote:
> 
> It's been a long time since I looked at TACK, but if I remember right, 
> doesn't this only help with the CA/trust issue?
> 
> To me the big question with STS as is is how to exchange policy/routing 
> information, which I believe is mostly unrelated to TACK, right? In fact STS 
> is quite agnostic about how to determine if you trust the HTTPS certificate 
> presented--I think TACK is potentially applicable there (as is Cert 
> Transparency, though we also considered CT as a future option for publishing 
> or discovering policy presence).
> 
> Or am I totally misremembering what TACK does?

TACK is a pinning proposal primarily focused on HTTPS (but also considers other 
application layer protocols) client/server interaction. It's also almost three 
years old, uses old signature schemes et cetera. - It's not what I'd want to 
use right away. It's neither a standard nor has it been updated since it's 
inception back then. It needs considerable love, but would also work for 
server<->server transmissions. My thinking in the past revolved around an SMTP 
extension that indicates (updated, SMTP-)TACK use and may, additionally, 
contain arbitrary security information (similar to your policies) once 
authenticated.

The main properties that make building on TACK interesting for me are:
- Lifecycle-management / Key-rollover (no accidental lock-out as you may get 
with HPKP)
- No need for CA-signed certificates (fits well into the SMTPS domain)
- Ease of deployment
- Ease of maintenance (a good, automated implementation may do everything on 
it's own)

Given there're now multiple proposals for mail security, I think it would not 
be very constructive to write/publish a competing I-D for this.

Hmm. I haven't given any thought on how to best incorporate that into your STS 
proposal. Could you use it instead of the webpki authentication method and 
distribute TACK fingerprints via DNS?

w.r.t. Certificate Transparency: how do you see CT working for SMTP mail 
certificates? It's currently EV-only and more than 60% of MTAs are unsigned. Do 
you mean building on technology/hash-trees like CT?

Thanks for the feedback,
Aaron

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta

Reply via email to