On Wed, Nov 13, 2019 at 06:29:44AM -0500, Kathleen Moriarty wrote: > Hi Ben, > > Just replying to the parts of the tread that were not responded to already > as Stephen will likely be looking at the headers/updates per his message. > Thanks for your careful review. > > On Mon, Nov 11, 2019 at 2:54 PM Benjamin Kaduk <ka...@mit.edu> wrote: > > > Hi all, > > > > This is a "preliminary" review only because there's some strangeness > > relating to the Updates: (and Obsoletes:) headers, and any changes there > > would make me need to go and recheck the relationship of this document to > > the ones listed. So, I haven't done any of that yet, in an attempt to only > > have to do it once. > > > > Specifically, there's skew between the list of documents updated in the top > > header and the list in Section 1.1. Evern more annoyingly, the (tools) > > HTML version seems to be missing some numbers from the document header, > > that are present in the TXT version. (Henrik is going to take a look, per > > > > https://mailarchive.ietf.org/arch/msg/tools-discuss/Maeh0f_WfOy5sfnGQpwGPs_sYcU > > .) > > > > Thanks. > > > > > Additionally, Section 1.1 lists some RFCs that "have been obsoleted", but > > there is no "Obsoletes:" header at the top of the document. > > > > I think nits is right about references (square-bracketed "[RFC6347]") in > > the Abstract; we should change those to normal textual (parenthesed > > "(RFC 6347)") before IETF LC. > > > > Some other notes from a quick pass over the main text (though I'll probably > > read it again once the above are addressed) follow. > > > > Section 1 > > > > It feels a little backwards for a "primary technical reason" to > > deprecate a protocol version being that "at least one widely-used > > library has plans to drop [it]". > > > > I see what you are saying. The major library dropping it has to do with > the number of versions available and supporting them all is cumbersome and > could lead to configuration errors on the part of the user. Would you just > like "primary" removed or would you prefer more of a change to the text?
The main reason I raised it is that it doesn't feel like a *technical* reason; it's done for expediency and perhaps with a bit of politics, but there's nothing technical about the protocol involved. > > > > > I do appreciate that we give discussion about what we intend > > "deprecation" to mean and for whom -- thank you for that! > > > > Section 2 > > > > TLS 1.3, specified in TLSv1.3 [RFC8446], represents a significant > > change to TLS that aims to address threats that have arisen over > > the years. Among the changes are a new handshake protocol, a new > > key derivation process that uses the HMAC-based Extract-and-Expand > > Key Derivation Function (HKDF), and the removal of cipher suites > > that use static RSA or DH key exchanges, the CBC mode of > > operation, or SHA-1. The list of extensions that can be used with > > TLS 1.3 has been reduced considerably. > > > > While it's true that the initial list of extensions usable with TLS 1.3 > > is smaller than the list of extensions usable at TLS 1.2 taken at the > > same time, it's also true that the requirements for allocating a new > > extension codepoint have been reduced dramatically. So I think I'd say > > that this reflects not a desire to reduce the attack surface (as > > "measured" by number of extensions) but rather a paradigm shift in how > > the protocol works, which leaves some existing functionality > > incompatible with the new model. I don't really get a clear sense of > > what this current last sentence is trying to say (i.e., whether it's one > > of those two descriptions I offered above). > > > > Would you prefer "a significant change", be "a paradigm shift"? If not, > could you propose text? I'm trying to say that the reduced size of the list of extensions is just a side effect, not an end in its own right. But, I seem to have missed that this paragraph is part of a quotation from a NIST document, so I don't get to wordsmith it :) > > > > Section 3 > > > > Similarly, the authentication of the handshake depends on signatures > > made using SHA-1 hash or a not stronger concatenation of MD-5 and > > SHA-1 hashes, allowing the attacker to impersonate a server when it > > is able to break the severely weakened SHA-1 hash. > > > > My recollection of the WG discussions (which I will go review) is that > > we don't really have consensus on the "not stronger" portion of this. > > Is that a key component of the document here? (N.B. this is *not* an > > invitation to rehash that discussion again! The chairs or I can provide > > a summary of points not resolved by previous discussion and points > > believed to be adequately agreed upon, which would be a trigger for any > > additional discussion that might be needed.) > > > > Since you are already looking at the consensus of this with the chairs, we > can wait for your guidance. Okay. That might not happen until after Singapore, though. -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
