Original text:
peers.  There are a number of ways in which a man-in-the-middle attacker can attempt to make two entities drop down to the least secure method they support.  The protocol has been designed to <del> minimize this risk, but there are still attacks available: for </del>  example, an attacker could block access to the port a secure service <del> runs on, or attempt to get the peers to negotiate an unauthenticated </del>  connection.  The fundamental rule is that higher levels must be cognizant of what their security requirements are and never transmit information over a channel less secure than what they require.  The TLS protocol is secure in that any cipher suite offers its promised <del> level of security: if you negotiate AES-GCM GCM with a 1024-bit DHE key exchange with a host whose certificate you have verified, you can expect to be that secure. </del>  These goals are achieved by the handshake protocol, which can be summarized as follows: The client sends a ClientHello message which

Reviewer comments:
A newer recommendation could be put in as a replacement, however I don't think the sentence adds anything to the explanation, nor do I expect whatever could be recommended to hold up forever. Also fix some punctuation in the same paragraph.
Ok, I've added a new security recommendation. I'm listing a TODO with it, though, as Curve25519 is probably what we're going with as MTI for a reasonable expectation of security and there's nothing to cite yet. I don't think we'd want P256 cited in there for the baseline recommendation. This is fine until the MTIs are updated, I think. People would probably say 2048 DHE is fine, which for now it is, but I went with 3072 to match the same security level for the curve. Might need to discuss on list.
I actually expect P256 to be the MTI based on the discussion in person and on-list. Given that RSA 2048 seems to be what browsers are pushing, I suspect that that's what's needed here.
I essentially have no problem with that currently, but this spec will be around for quite a while. I'd rather have the new general purpose expectations in the new spec so that this will age better. (you could argue I'm overthinking this, though) I could also just drop the DHE and list only ECDHE.
I'm fine with changing this to 256-bit EC keys, but note that you'll want to refer to that for signatures as well.
Ok. I've switched it to just 255 bit ECDHE and added 224 bit ECDSA as the minimum signature. (arguably the latter could be higher, but we went with 112 bit symmetric in the backwards compatibility restrictions) I'm specifically going with 255 instead of 256 so Curve25519 isn't ruled out by a bit.
TLS 1.2 currently supports a number of ciphersuites and mechanisms that are little-used or outdated. In particular SHA-1, MD5, RC4, DSA with any modulus size, RSA with small moduli. Some of these will get chopped out as a result of other issues, but others will not.
Dependencies: SHA1: PR MD5: PR RC4: PR DSA: PR weak RSA: PR Statuses: the pending PR drops SHA1 to SHOULD NOT MD5 is currently MUST NOT & PR also adds a MUST always error if seeing it RC4 is currently a MUST NOT DSA is pending decision & discussion on-list (issue ; PR ) weak RSA is currently considered "not appropriate" with the following text: Merging the pending PRs listed as dependencies above should be sufficient to close this issue.
This is done

Revised text:
peers.  There are a number of ways in which a man-in-the-middle attacker can attempt to make two entities drop down to the least secure method they support.  The protocol has been designed to  <ins> minimize this risk, but there are still attacks available.  For </ins> example, an attacker could block access to the port a secure service  <ins> runs on or attempt to get the peers to negotiate an unauthenticated </ins> connection.  The fundamental rule is that higher levels must be cognizant of what their security requirements are and never transmit information over a channel less secure than what they require.  The TLS protocol is secure in that any cipher suite offers its promised  <ins> level of security: if you negotiate AES-GCM GCM with a 255-bit ECDHE key exchange with a host whose certificate chain you have verified, you can expect that to be reasonably secure. </ins> These goals are achieved by the handshake protocol, which can be summarized as follows: The client sends a ClientHello message which