On 11/13/17 8:06 AM, Daniel Margolis wrote: > Hey, thanks to you both for the discussion. I'll try to centralize the > issues here a little bit, if you don't mind.
Good summary, thanks for organizing it. Comments inline. > > > Security properties of policy discovery and risks of persistent MITM > preventing discovery. > > I'm going to take a pass on this discussion, Jim, unless it's a > blocker. As Viktor said, this is a tradeoff that's been there since > the beginning, but we've discussed it many times before and resolved > (I think) to go forward. So this is simply a risk we have to document, > as we have done in Security Considerations. OK. > > > Mode "report" vs "none". > > You make a fair point that "report" is a no-op if there's no TLSRPT, > but I think it's somewhat nice to call it out as "report" because it > indicates the likely usage of this setting--to generate data for > observers. This isn't TLSRPT-specific; it's just that absent TLSRPT or > human intervention there's no good way to share reports with the > domain admin. > > Nicolas's suggestion of "testing" works for me, but frankly I would > prefer not to change this since it requires changing a bit of code in > a few places and will take a few minutes longer than it takes for me > to just say I'd prefer to be lazy and keep "report". If you feel > strongly, let me know. ;) I'm mixed on this. This is at the draft stage so some changes should be expected. The key question that I have, and implementers will need to know, is if there is any semantic difference between "report" and "none". I can't find any, except possibly in Section 7.3, "Removing MTA-STS", and I'm not sure if that is really a difference. My main concern with "report", which I probably said before, is that it might confuse domains that are publishing MTA-STS policies and don't know about TLSRPT. > > > SNI > > To be clear, SNI is only required to be /sent/ by the SMTP and HTTPS > clients. This is necessary in that servers cannot use SNI if they > cannot assume clients will send it. But that doesn't mean servers must > support SNI; they can simply ignore it if they want. So this is the > minimum requirement to make SNI functional, as was discussed on this > list before. My mistake here; the spec does clearly say the client MUST have SNI support, not the server. > > > Cert validity and max_age. > > There's no relationship at all between max_age and cert lifetimes. > Certificate validation involves checking the cert as one normally > would, i.e., by verifying the signing chain and the expiry (and, > optionally, revocation). There's no implication of policy ages > applying to anything other than the policy, I think. I'm happy to > clarify this if you suggest language, of course. Seems reasonable, it's just a question that came up in my head while I was reading the spec. Not sure it warrants clarification. > > > How strongly to require senders to proactively refresh the policy > (as currently in 9.2). > > I'm OK with moving this up in the doc and making it more prominent. I > don't know if we want to make it normative (MUST) because a) the > system works "fine" without it and b) there's no way to really say > someone is "not compliant" if they don't do this. But I think it makes > sense to make it a SHOULD and (as discussed already in Security > Considerations) make clear the risks in not doing so regularly. Yes, please move it up. Security considerations is more of a discussion of the characteristics of the protocol, and implementers are likely to miss it there. I would also add, since it's a SHOULD: Publishers of MTA-STS policies MUST NOT depend on updates to be retrieved before the expiration of the max_age. -Jim
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
