Hiya, Sorry for being slow with this but I've finally gotten my AD review for this done. (See below.)
A couple of things to check before starting IETF LC: (1) What is the behaviour when all RRs required for this are published except for no DNSSEC RRs? I have heard tell of some people who would like to experiment in that way, and would like to know if the WG have a clear answer for them as to what ought happen. Is that answer here? (If so, it's fairly well hidden;-) (2) Doesn't this need to be consistent with other recent IETF documents, in particular the generic UTA BCP and deprecating SSL 3.0? I don't believe it current is entirely consistent with either. (See minor comments below for details.) Why is that ok? The rest (below) are more minor comments, please treat these as IETF LC comments. Cheers, S. - intro: end of 1st para could reference rfc7435, just to be sure that the opportunistic term is well defined in this context - 1.2, 2nd para: s/trusted public keys/public keys/ - 1.2, 2nd para: s/a new/the/ - 1.2, 3rd para: s/directly delegated/delegated/ - 1.2, 3rd para: s/data integrity/data origin authentication/ TLS provides data integrity for application PDUs in all cases - 1.3, 2nd para: s/traditional PKI/traditional Web PKI/ - 1.3.1, s/such as the use of PKIX// I don't think that says anything really and I've no clue what "use of PKIX" might mean exactly - better left out I'd say - 1.3.2, s/A PKIX TLS client/A TLS client/ - 1.3.2, The MX lookup is vulnerable as stated but isn't the A/AAAA similarly vulnerable? I think you ought note that too, but also that this specification can mean that DNSSEC for that lookup is not needed based on the name in the MX response being bound (via x.509 or tlsa) to the TLS server private key. (Well, that assumes I've gotten that correct:-) Without DNSSEC for the MX name->address mapping a bad actor could however, insert themselves into the path and gain whatever can be gained via traffic analysis of the SMTP/TLS session. - 2.1.1, 2nd para: s/must be used/MUST be used/? Not sure myself, but I'd make it uppercase for emphasis. (Other people will disagree from all points of view though, no matter what you do or don't do here;-) - 2.1.1, the term anchorless should probbaly get a mention in 1.1 with a forward pointer to 2.1.1. Or maybe you can avoid the term since it's not used much. (Just in 2 adjacent paragraphs.) - 2.1.1, what does "securely opted out" mean? - 2.2, I'd re-phrase "A connection to the MTA MUST be made using authenticated and encrypted TLS" as "Any connection to the MTA MUST be made using authenticated and encrypted TLS" The current text could be read to say that the client MUST make the connection, whereas I think you just mean if you do make a connection it MUST use TLS. - 2.2, Could "authenticated" here mean mutually authenticated with TLS client certs? If not, maybe say so. (And for the last sentence before 2.2.1, what about the client cert names - what's done with those?) - 2.2, 3rd bullet: Is it a good idea to mix the insecure TLSA RRSet and validated non-existence in one bullet? I find it confusing. Maybe it'd be better to have two bullets even if the new one says "do as above." - 2.2.1, last para: What is the other, to which the "Otherwise" at the start of the para applies? That confused me. - 2.2.2: bullet 1 - what's that mean? (In this context) This section generally has a bunch of paragraphs that start with a conditional, and it's not clear how they all fit. Could you add some more structure (e.g. pseudo-code) to clarify? - 3.1: All but the first and last two paras of this seem to be repetitive of 6698 and 7218. I don't see that it's a good idea to do that. (In what is already an over-long document.) - 3.1.2 - does the MUST include TA in the TLS handshake conflict with common implementations of 5246? 5246 section 7.4.2, says that the TA MAY be omitted, but I wonder if we might be causing ourselves trouble (some) with running code. - 3.1.3, last sentence: is that needed? It seems to invalidate the sentence before. (And it's vague.) - 3.2.2, various places: "MUST be included" where? - 8.1, para 1: We've (the IETF) just deprecated SSL 3.0, [1] so don't you need to reference that and say to not do that? At least the MAY at the end of that paragraph seems not to conform with the BCP. I think a ref to [1] is needed. [1] https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie - 8.2: This is alrady handled by the generic UTA BCP. Why is it needed here? - 9.2, 2nd para: isn't that repetitive? That seems like a bad idea. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
