Hiya, The authors were hassling me (nicely:-) to do a review of this and since I'm no longer the AD for the WG I figured that'd be a good idea, as I'm very supportive of this, so long as we (the WG/IETF), figure out how to do this without that damaging deployment of DANE/TLSA. Overall, my take is that there's a set of folks for whom this will be usable, and who won't yet deploy DANE/TLSA, and so I think this should improve the security of mail, so I'm keen, but as I said don't want to see this damage DANE/TLSA deployment either. Properly figuring out what RFC-text is right for that might take a bit of discussion.
Anyway, my detailed review is below. The draft does need a chunk of work, but I see no reason at all why that can't be done pretty quickly and result in something good. Cheers, S. PS: Apologies if I've forgotten some of the discussion on this in Berlin (which I have), hopefully I'm not going to contradict something I said there:-) - Too many authors: the IETF has a strong preference for 5 or fewer authors. (There's a long history for why that's the case, but it's worth abiding by.) Probably the best thing here is to pick one or two of the current set of folks and list those as "editors" and have the rest of those listed as contributors. See RFC7322, section 4.11 [1] for some instructions, and/or ask the UTA WG chairs about how to do it. [1] https://tools.ietf.org/html/rfc7322#section-4.11 - Title: Suggest including "MTA-STS" in the title if you want to use that acronym in the abstract. The title would then be "SMTP MTA Strict Transport Security (MTA-STS)" - 1.1: I think an example in the definition of "policy domain" would help me at least, e.g. say that when sending mail to "[email protected]" then "example.com" is the policy domain. - 2.1: I'm not sure if this is better included or not tbh. I do think we want to say "TLSA also does this and in some ways better" but not sure if it's best done as pros and cons, which may generate more controversy than is worthwhile. I'd say best would be to start a thread on the WG list specifically about what this ought say about DANE/TLSA and see what consensus emerges. My bet is that after a bunch of discussion the WG might come to consensus on a fairly short paragraph or two that'd do the trick. - section 3: I'd delete the forward reference to the "future work" section, and indeed that entire section. RFCs don't usually have that. (Also see below.) - section 3: What exactly does "plain-text" mean? I guess you mean ascii but you need to say. You also need to say something that clearly works both for TXT RRs and for JSON. - section 3: "rua" is I guess from the reporting draft, in which case please say so and add the reference here. (And that becomes a normative reference because of this.) I'm not sure if it'd be better to define "rua" here or not. - section 3, "mx": the wildcards here would seem to open an attack - if mail is supposed to go to foo.example.com and I operate a web server on bar.example.com and see "mx=*.example.com" then the operator of bar.example.com can mount an attack (if they can inject an MX RR). Pretty easy to get that wrong I'd say if the value of "mx=" is complex. I'd say you need to warn explicitly about that in the security considerations section. - section 3, "policy_id": you need to say that this MUST be the same as an "id=" value seen in a TXT RR I think. - section 3, "id": I think you ought say that there's no implied ordering (i.e. newer vs. older) in the value of the "id" field, but then how can I tell which policy or policies to apply at run time? - section 3, "max_age": "integer seconds" could include "-100000", (a negative number) I think you want only positive values. - section 3: "A lenient parser SHOULD accept a policy file implementing a superset of this specification, in which case unknown values SHALL be ignored." That implies that no additional fields (for v=STSv1) can ever be restrictions, they all need to be advisory. That is ok, but worth saying. You also repeat this statement twice in section 3, I'm not sure why, but those should be merged, or maybe the 1st one is meant to be about the TXT RR and not the policy file? In any case, merging will be better. - 3.1: I didn't check the ABNF. You should get a few folks to do that. I bet a beer that domain-match will have some issues:-) - 3.1.1 and 3.1.2: you should add examples to both, or elsewhere. The more the merrier probably, esp. if there are corner cases. I see they're down at the end - I think they may be better in-line as they're easier on the reader than ABNF. - 3.3: Don't you need to say that the value of the TXT RRs I find at _mta_sts.example.com needs to include one (or more) with "v=STSv1" and that's how I know there's some STS policy? People will I guess include other stuff in TXT RRs at _mta_sts.example.com even if you said they MUST NOT;-) - 3.3: "Web PKI is the mechanism" - I think you need to say that you're depending on the set of CAs/roots in the sending MTA, being similar to those in a typical web browser or OS. I don't think you can mandate that but saying something should help the sending MTA implementer pick e.g. what libraries or configs to use/support. - 3.3: I forget why "policy.mta-sts" is what's prepended to the policy domain. Personally, I dislike the two-level thing there and don't see that it's useful. If you do keep it, then it'd be good to justify it. But that's mostly a matter of taste I think. OTOH, it might be a small barrier to deployments in some places, not sure. - 3.3: is the "current" in ".well-known/mta-sts/current" hardcoded? If so, then "To consider the policy as valid, the "policy_id" field in the policy MUST match the "id" field in the DNS TXT record under "_mta_sts"." seems problematic as it implies there's only one JSON object in the HTTPS response there. Why not fetch ".well-known/mta-sts/<id>" where <id> is what I got from the TXT RR? Or, if not that, then you need to say how I get and parse >1 JSON object in the response (in which case "current" seems a bit wrong). - 3.4: You're missing a MUST I think - the MX name MUST also match something in the domain_match from the JSON version of the policy. - 3.5, 1st para: I think the "MAY apply" there is bogus use of 2119 terms. s/MAY apply/applies/ would be fine I think. I also think you should be clearer in saying that "report" vs. "enforce" is up to the sending MTA as well being influenced by the "mode" in the JSON thing. (Which you neglect to say.) - 3.5, "enforce" mode: what is the exception that causes you to say "SHOULD" and not "MUST" here? I don't get that. - 3.5, step 4: I'd replace the "*" bullets with letters or numbers like "4.1" for ease of reference when those are discussed (e.g. on the mailing list). - 3.5, step 4, 1st bullet: is there any way I can make use of this check to attempt a DoS against someone? Not sure, but it smells a bit like there may be. - 3.5, step 4: What happens if I check for a new policy, find something, but it's crap? Or what if it is crap, but new crap each time I retrieve it? Seems like there may be an infinite loop there. - section 4: I'd say delete this and just add references to the reporting draft as and where needed. - section 4: Where does it say what to do if the TLS session establishment fails? Are you assuming that's handled within "deliver mail"? I think you need to say and presumably if in "enforce" mode, that the sending MTA does not fall back to plain. - section 5: The .well-known stuff needs an IANA considerations section to register "mta-sts" as per RFC5875, see for example [2] for what that'd look like. [2] https://tools.ietf.org/html/rfc7486#section-9.2 - section 6: "protects against" may be a bit overstated, I think "provides some enhanced protection against" would be more accurate. - section 6, 2nd last para: I don't agree that compromised CAs, nor fraudulently matching domain_match cases are "out of scope" - you should instead note that those are residual threats that are real. - section 7: I think this should be deleted. The first two are speculative, and the last two seem to break the earlier statements about lenient parsing. It's fine that someone has to define "v=STSv2" later to handle any such extensions, and there's no need to predict now what that'd be. - section 8: I'm not sure this is useful at that level of detail. - section 9.1: Is this the 1st time you say "HTTP GET"? If so, that needs to be earlier and I didn't spot that it was missing:-) - section 10: I think this also disappears to somewhere else? - order of text: If/when you've taken the above into account, I'd suggest an editing pass that considers the order in which things are presented in the draft. Right now, there's a lot of forward referencing that I think could be avoided by moving text about, and which'd lead to an easier read, that's more easily understood.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
