On 22/04/15 07:59, Stephen Farrell wrote: > > Thanks, will get back to this later on today, by Friday > worst case.
Sorry, I didn't get a chance to look that over in detail and now probably won't tomorrow either, so I've requested IETF LC start and I'll take a peek at it again during the LC. Thanks, S. > > 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 > > _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
