Draft: draft-ietf-tls-tls13

Commentary: A newer recommendation could be put in as a replacement , however I do n'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 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 do n't think we 'd want  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 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 is n'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
Paragraph (version A):
Note that higher layers should not be overly reliant on whether TLS
always negotiates the strongest possible connection between two
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
minimize this risk, but there are still attacks available: for
example, an attacker could block access to the port a secure service
runs on, or attempt to get the peers to negotiate an unauthenticated
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
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.
Paragraph (version B):
Note that higher layers should not be overly reliant on whether TLS
always negotiates the strongest possible connection between two
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
minimize this risk, but there are still attacks available.  For
example, an attacker could block access to the port a secure service
runs on or attempt to get the peers to negotiate an unauthenticated
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
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.