Draft: draft-ietf-tls-tls13

Commentary: Capitalize the first letter of the sentence like the rest of the alert descriptions . 
 I just noticed that noticed this too and included it in PR with quite a few more significant editorial improvements around alerts . 
 Rather than creating new PRs , I 've just a couple other minor things to this one . 
 I 've just to this two almost identical looking commits to upgrade the HTTP links to HTTPS in and Can just be deleted , or is it still needed for some reason ? 
 is needed to generate the banner that you see when opening a new issue or PR . I see no harm in including a link to from if you want to do that . 
 Transclusion would be ideal , if that capability exists . I do n't think changing it to just a link is needed . As long as they 're both being used and both updated as - needed , I have nothing against just duplicating the content . Just checking to make sure . 
 Huh . Looks like I 've found the most pedantic errata ever : it says " see page 99 " when it should 've said " see page 100 " in the TLS 1.2 spec . The most recent trivial fix in this PR changes that to an actual link to the section in question . I would guess it 's not worth actually filing an errata ticket for that . ;)
Paragraph (version A):
In this section, we define one PRF, based on HMAC RFC2104.  This PRF
with the SHA-256 hash function is used for all cipher suites defined
in this document and in TLS documents published prior to this
document when TLS 1.2 is negotiated.  New cipher suites MUST
explicitly specify a PRF and, in general, SHOULD use the TLS PRF with
SHA-256 or a stronger standard hash function.
Paragraph (version B):
In this section, we define one PRF, based on HMAC RFC2104.  This PRF
with the SHA-256 hash function is used for all cipher suites defined
in this document and in TLS documents published prior to this
document when TLS 1.2 or later is negotiated.  New cipher suites MUST
explicitly specify a PRF and, in general, SHOULD use the TLS PRF with
SHA-256 or a stronger standard hash function.
Paragraph (version A):
The protocol version the client has attempted to negotiate is
recognized but not supported.  (For example, old protocol versions
might be avoided for security reasons.)  This message is always
fatal.
Paragraph (version B):
The protocol version the peer has attempted to negotiate is
recognized but not supported.  (For example, old protocol versions
might be avoided for security reasons.)  This message is always
fatal.
Paragraph (version A):
Extensions should, as far as possible, be designed to prevent any
attack that forces use (or non-use) of a particular feature by
manipulation of handshake messages.  This principle should be
followed regardless of whether the feature is believed to cause a
security problem.
Paragraph (version A):
Often the fact that the extension fields are included in the
inputs to the Finished message hashes will be sufficient, but
extreme care is needed when the extension changes the meaning of
messages sent in the handshake phase.  Designers and implementors
should be aware of the fact that until the handshake has been
authenticated, active attackers can modify messages and insert,
remove, or replace extensions.
Paragraph (version B):
Extensions should, as far as possible, be designed to prevent any
attack that forces use (or non-use) of a particular feature by
manipulation of handshake messages.  This principle should be
followed regardless of whether the feature is believed to cause a
security problem.  Often the fact that the extension fields are
included in the inputs to the Finished message hashes will be
sufficient, but extreme care is needed when the extension changes
the meaning of messages sent in the handshake phase.  Designers
and implementors should be aware of the fact that until the
handshake has been authenticated, active attackers can modify
messages and insert, remove, or replace extensions.
Paragraph (version A):
This message is used to provide explicit proof that the server
possesses the private key corresponding to its certificate.
certificate and also provides integrity for the handshake up to
this point.  This message is only sent when the server is
authenticated via a certificate.  When sent, it MUST be the last
server handshake message prior to the Finished.
Paragraph (version B):
This message is used to provide explicit proof that the server
possesses the private key corresponding to its certificate and
also provides integrity for the handshake up to this point.  This
message is only sent when the server is authenticated via a
certificate.  When sent, it MUST be the last server handshake
message prior to the Finished.
Paragraph (version A):
Recipients of Finished messages MUST verify that the contents are
correct.  Once a side has sent its Finished message and received
and validated the Finished message from its peer, it may begin to
send and receive application data over the connection.  This data
will be protected under keys derived from the hs_master_secret
(see cryptographic-computations.
Paragraph (version B):
Recipients of Finished messages MUST verify that the contents are
correct.  Once a side has sent its Finished message and received
and validated the Finished message from its peer, it may begin to
send and receive application data over the connection.  This data
will be protected under keys derived from the hs_master_secret
(see cryptographic-computations).
Paragraph (version A):
In the absence of an application profile standard specifying
otherwise, a TLS-compliant application MUST implement the cipher
suite TODO:Needs to be selected [1].  (See the-cipher-suite for the
definition).