Thanks, will get back to this later on today, by Friday worst case. Cheers, S.
On 22/04/15 07:13, Viktor Dukhovni wrote: > On Thu, Apr 16, 2015 at 04:27:33PM +0100, Stephen Farrell wrote: > >> - 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/ >> - 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.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. > > Adopted in -16, please check. > >> - 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.) > > Rewritten (improved I think, thanks) in -16 to avoid "anchorless". > >> - 2.1.1, what does "securely opted out" mean? > > Rewritten in -16 to clarify. > >> - 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?) > > Per the list discussion, no client authentication. Definition > rephrased in -16 to make the meaning more clear. > >> - 2.2.1, last para: What is the other, to which the >> "Otherwise" at the start of the para applies? That confused >> me. > > Rewritten in -16 to clarify this as 'When not "insecure"'. > >> - 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? > > Reworked the bullets and paragraph above to make this clearer > in -16. > >> - 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.) > > Fat trimmed in -16, leaving just the meat and bones. > >> - 3.1.3, last sentence: is that needed? It seems to >> invalidate the sentence before. (And it's vague.) > > NEW (in -16): > > SMTP client treatment of TLSA RRs with certificate usages > PKIX-TA(0) or PKIX-EE(1) is undefined. As with any other > unsuppored certificate usage, SMTP clients MAY treat such > records as "unusable" > >> - 3.2.2, various places: "MUST be included" where? > > Reworded in -16. > >> - 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. > > Simplified text in -16 omits all mention of SSL 3.0. Just reminds > the reader that use of SNI precludes SSL 2.0 HELLO. > >> - 9.2, 2nd para: isn't that repetitive? That seems like a bad >> idea. > > In -16 dropped the repetition of non-support for usage 0/1. > >> - 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. > > Declined. > >> - 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." > > Any guidance from the WG on this? I neither see this change as a > compelling improvement, nor am I strongly opposed to it. Deferred > for now. > >> - 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. > > As discussed on the list, this is not a conflict nor a problem with > running code. > > Section 9.2 mentioned the the Microsoft Exchange issue where servers > are unable to send self-signed trust-anchors, and therefore must > not use them in DANE-TA(2) records, employing intermediate TAs > instead. In -16, shortened and moved that text to 3.1.2. > >> - 8.2: This is alrady handled by the generic UTA BCP. Why is >> it needed here? > > This discusses use anonymous cipher suites in SMTP opportunistic > TLS, which is not covered in the UTA BCP. Section retained. > _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
