December 2014, Available from
@url{http://www.ietf.org/rfc/rfc7413.txt}.
+@item @anchor{RFC7918}[RFC7918]
+A. Langley, N. Modadugu, B. Moeller, "Transport Layer Security (TLS) False Start",
+August 2016, Available from
+@url{http://www.ietf.org/rfc/rfc7918.txt}.
+
@item @anchor{RFC6125}[RFC6125]
Peter Saint-Andre and Jeff Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)",
March 2011, Available from
N. Williams, "On the Use of Channel Bindings to Secure Channels",
November 2007, available from @url{http://www.ietf.org/rfc/rfc5056}.
+@item @anchor{RFC5764}[RFC5764]
+D. McGrew, E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)On the Use of Channel Bindings to Secure Channels",
+May 2010, available from @url{http://www.ietf.org/rfc/rfc5764}.
+
@item @anchor{RFC5929}[RFC5929]
J. Altman, N. Williams, L. Zhu, "Channel Bindings for TLS", July 2010,
available from @url{http://www.ietf.org/rfc/rfc5929}.
All strings that are to provided as input to @acronym{GnuTLS} functions
should be in UTF-8 unless otherwise specified. Output strings are also
in UTF-8 format unless otherwise specified. When functions take as input
-passwords, they will normalize them using @xcite{rfc7613} rules (since
+passwords, they will normalize them using @xcite{RFC7613} rules (since
GnuTLS 3.5.7).
When data of a fixed size are provided to @acronym{GnuTLS} functions then
@item %DUMBFW @tab
will add a private extension with bogus data that make the client
hello exceed 512 bytes. This avoids a black hole behavior in some
-firewalls. This is the @xcite{rfc7685} client hello padding extension, also enabled
+firewalls. This is the @xcite{RFC7685} client hello padding extension, also enabled
with %COMPAT.
@item %NO_EXTENSIONS @tab
@cindex False Start
@cindex TLS False Start
-The TLS protocol was extended in @xcite{draft-ietf-tls-falsestart-01} to allow the client
+The TLS protocol was extended in @xcite{RFC7918} to allow the client
to send data to server in a single round trip. This change however operates on the borderline
of the TLS protocol security guarrantees and should be used for the cases where the reduced
latency outperforms the risk of an adversary intercepting the transferred data. In GnuTLS
process will complete properly (i.e., no early return). To verify that false start was used you
may use @funcref{gnutls_session_get_flags} and check for the @acronym{GNUTLS_SFLAGS_FALSE_START}
flag. For GnuTLS the false start is whitelisted for the following
-key exchange methods (see @xcite{draft-ietf-tls-falsestart-01} for rationale)
+key exchange methods (see @xcite{RFC7918} for rationale)
@itemize
@item DHE
@item ECDHE