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.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
