tlswg / tls13-spec

TLS 1.3 Specification

TLS 1.3 Draft Specifications

This is the working area for the IETF TLS Working Group draft of [TLS 1.3]

TLS 1.3 specification:

• Editor's copy
• Working Group Draft

Contributing

Before submitting feedback, please familiarize yourself with our current issues list and review the working group home page. If you're new to this, you may also want to read the Tao of the IETF.

Be aware that all contributions to the specification fall under the "NOTE WELL" terms outlined below.

1. The best way to provide feedback (editorial or design) and ask questions is sending an e-mail to our mailing list. This will assure that the entire Working Group sees your input in a timely fashion.

2. If you have editorial suggestions (i.e., those that do not change the meaning of the specification), you can either:

a) Fork this repository and submit a pull request; this is the lowest friction way to get editorial changes in.

b) Submit a new issue to Github, and mention that you believe it is editorial in the issue body. It is not necessary to notify the mailing list for editorial issues.

c) Make comments on individual commits in Github. Note that this feedback is processed only with best effort by the editors, so it should only be used for quick editorial suggestions or questions.

3. For non-editorial (i.e., design) issues, you can also create an issue on Github. However, you must notify the mailing list when creating such issues, providing a link to the issue in the message body.

Note that github issues are not for substantial discussions; the only appropriate place to discuss design issues is on the mailing list itself.

Building The Draft

You will need kramdown-rfc2629 (https://github.com/cabo/kramdown-rfc2629) and xml2rfc (https://xml2rfc.tools.ietf.org/).

NOTE WELL

Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to:

• The IETF plenary session
• The IESG, or any member thereof on behalf of the IESG
• Any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices
• Any IETF working group or portion thereof
• Any Birds of a Feather (BOF) session
• The IAB or any member thereof on behalf of the IAB
• The RFC Editor or the Internet-Drafts function
• All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879).

Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice.

Please consult RFC 5378 and RFC 3979 for details.

A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements.

A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public.

tls13-spec's Issues

Reduce the "overhead" values in TLSCiphertext, etc.

This is currently 2^{14} + 2048 (in TLSCiphertexT) and then 2^{14} + 1024 later.

This is introduced by leaving room for compression. Should we just reduce this entirely across the board. Certainly we don't need to leave room for compression.

forking resumption keys

Does forking the resumption keys affect dropping the CCS message?

Erratum: logic inversion on ENCRYPTED-KEY-DATA padding check

http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=2643

Section E.3 says:

When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding
bytes are 0x03. If they are not, the server SHOULD generate a random
value for SECRET-KEY-DATA, and continue the handshake (which will
eventually fail since the keys will not match).

It should say:

When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding
bytes are not all 0x03. If they are, the server SHOULD generate a random
value for SECRET-KEY-DATA, and continue the handshake (which will
eventually fail since the keys will not match).

The condition is the wrong way around. When the bytes are all 0x03, that means the client supports TLS, so there must have been a version rollback attack in order for SSL 2.0 to be negotiated.

ServerKeyExchange has ServerDHParams twice?

The ServerKeyExchange message, for dhe_dss and dhe_rsa has the
ServerDHParams params;
and also as a part of the signed_params digitally-signed sub-struct. Shoudl the first one be removed?

Add non-GCM AEAD ciphers

I only added the GCM AEAD ciphers. We should add all the standards track AEAD ciphers.

Remove DH_* Cipher suites

We just removed static RSA. Should we remove static DH as well?

Separation of crypto components

A couple of people have noted that having separate parameters and negotiation for handshake and record layer crypto would simplify aspects of the protocol.

Remove length from aead input

In order to support aead suites that pad or otherwise modify length, we need to stop using the plaintext length in the aead input. An implied requirement on the cipher is to validate length.

Proof of work for DoS mitigation

Providing proof of ownership at a server is a non-trivial computational burden. If a server was able to request that a client submit proof of work, then a loaded server could use this to help separate DoS attackers from genuine clients.

enumerate all "_RESERVED" values in an appendix table

The list of obsoleted values in enums is ever increasing. Minor suggestion for the backwards compatibility appendix E: add a table of all "_RESERVED" values from all enums that are now MUST NOT sends/accepts.

Remove gmt_unix_time field from the Random values?

A number of people have suggested this to reduce fingerprinting surface.

AEAD only for the record layer

We seem to have reached consensus that the record layer will use the AEAD form only. The stream and CBC forms will be removed.

Save bytes in (ec)dhe shares

By using the same numbering space for ecdhe and dhe groups.

Probably a comment for draft-dkg

Make EC cipher suites standards track and add them to TLS 1.3 main RFC

Now that RFC 6090 has been published does this make sense?

Allow GMT time in ServerRandom

Per WG consensus we are removing GMT time in the random values.

This issue tracks whether we are mandating its removal from ServerRandom

Erratum: supported_signature_algorithms in CertificateRequest

See http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=1585
And http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=2864

Section A.4.2 says:

struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

It should say:

struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    SignatureAndHashAlgorithm
      supported_signature_algorithms<2..2^16-2>;
    DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

The definition in Section 7.4.4 (which includes the "supported_signature_algorithms" field) is the correct one (confirmed by Eric Rescorla on 2009-02-27)

The supported_signature_algorithms field is a variable length array. As such ceiling and floor should be specified, and they should be multiple of the base type (which is two bytes long in this case).

Make the PRF hardware module friendly

Mike StJohns points out several ways in which the current PRF is inimical to clean hardware module design in an email and in a draft.

Enumerate where the extensions can go.

Padding for AEAD cipher suites

It's been observed a number of times that the AEAD cipher suite definitions don't actually accommodate ciphers which pad. See:

http://www.ietf.org/mail-archive/web/tls/current/msg09776.html
http://www.ietf.org/mail-archive/web/tls/current/msg09783.html
http://www.ietf.org/mail-archive/web/tls/current/msg12871.html

We should either fix this or remove padding.

ASN.1Cert isn't "legal"

The data definition language says ASN.1Cert is an ASN item with a field having the illegal name 1Cert. We should make all of those be ASN1Cert probvably.

Fix Insecure Resumption

The issues in https://secure-resumption.com/ need to be fixed. There are many options for doing this.

Don't forget to import padding draft.

Rekeying

If we ditch renegotiation (#3), then we will need a way to rekey sessions to extend their lifetime.

Nico suggests that sending ChangeCipherSpec and then using an increasing counter to extract new keys (i.e., add a counter to the key expansion PRF input), which would seem to be sufficient.

Update text to deal with being able to use DSA with SHA > SHA-1

Erratum: missing )

See http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=2165

Section 6.2.3.2 says:

Example: If the block length is 8 bytes, the content length
(TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes,
then the length before padding is 82 bytes (this does not include the
IV**)**. Thus, the padding length modulo 8 must be equal to 6 in order to
make the total length an even multiple of 8 bytes (the block length).
The padding length can be 6, 14, 22, and so on, through 254. If the
padding length were the minimum necessary, 6, the padding would be 6
bytes, each containing the value 6. Thus, the last 8 octets of the
GenericBlockCipher before block encryption would be xx 06 06 06 06 06
06 06, where xx is the last octet of the MAC.

Anti-replay mechanism

A 0-RTT mode needs some sort of replay protection for both application data and any client credentials that might appear in the first flight from a client.

All mechanisms rely on some amount of server state, but differ in how they allow a server to limit the total state commitment. There are plenty of options, each with their own trade-offs, we just need to pick one.

Renegotiation

We need to decide whether renegotiation is a part of the protocol.

If not, then suitable replacements for the following features may be needed (thanks Nico for the list):

• rekeying
• authenticate the client when needed rather than always at handshake time
• privacy protection for the client's identity
• privacy protection for the server's identity
• privacy protection for the server identity desired by the client

I'll raise separate issues for tracking these.

SNI encryption

Server Name Indication could be encrypted to protect it from being inspected by passive attackers. There are some virtual-hosting type situations where hiding this information is considered desirable. If we can encrypt SNI, then it is probably trivial to encrypt other extensions.

However, this complicates the handshake. A lot. It also complicates virtual-hosting scenarios. Rich summarizes the issues pretty well here: http://www.ietf.org/mail-archive/web/tls/current/msg11823.html

Should we have explicit rejection in ServerHello

Currently the way you detect that ServerHello is a "try-again" is to check the DL/ECC extensions and see if it matches the CKE. This seems inelegant. Options include:

• Leave as-is
• Have some explicit rejection indicator
• Add a new message type, though it is pretty much going to have the same contents.

Drop static RSA

Tracking issue for the removal of static modes.

Erratum: padding

We might just close this one out based on #7.

See http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=2390

Section 6.2.3.3 should have marked text on padding removed:

The additional authenticated data, which we denote as
additional_data, is defined as follows:

 additional_data = seq_num + TLSCompressed.type +
                    TLSCompressed.version + TLSCompressed.length;

where "+" denotes concatenation.

The aead_output consists of the ciphertext output by the AEAD
encryption operation. The length will generally be larger than
TLSCompressed.length, but by an amount that varies with the AEAD
cipher. Since the ciphers might incorporate padding, the amount of
overhead could vary with different TLSCompressed.length values. Each
AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
Symbolically,

I suggest leaving the sentence about padding out. The value for TLSCompressed.length is required by additional_data for both encryption and decryption. Therefore, it must be possible to determine the TLSCompressed.length from the ciphertext before decryption.

In practice this is done by subtracting the integrity check value length from the ciphertext length, where the integrity check value length is defined by each AEAD cipher separately. If the cipher incorporates variable padding, it is impossible to calculate the TLSCompressed.length without an explicit value sent for each ciphertext separately. Therefore to avoid confusion, it would be better not to mention anything about padding at all.

(issue discussed on [email protected] and with Eric Rescorla, result of both discussions was that padding in AEAD ciphers doesn't seem to be possible with the current specification)

Do we retain CCS and Finish messages?

@ the interim the WG briefly discussed the possibility of removing the CCS and Finish messages.

Update references

A number of the references, e.g. RFC 3280, are out of date. Update.

Rewrite strict order for (ec)dhe groups

This makes it easier to enforce uniqueness constraints.

Erratum: missing };

http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=3123

Section A.4.2. says:

   struct {
       select (KeyExchangeAlgorithm) {
           case dh_anon:
               ServerDHParams params;
           case dhe_dss:
           case dhe_rsa:
               ServerDHParams params;
               digitally-signed struct {
                   opaque client_random[32];
                   opaque server_random[32];
                   ServerDHParams params;
               } signed_params;
           case rsa:
           case dh_dss:
           case dh_rsa:
               struct {} ;
              /* message is omitted for rsa, dh_dss, and dh_rsa */
           /* may be extended, e.g., for ECDH -- see [TLSECC] */
   } ServerKeyExchange;

It should say:

   struct {
       select (KeyExchangeAlgorithm) {
           case dh_anon:
               ServerDHParams params;
           case dhe_dss:
           case dhe_rsa:
               ServerDHParams params;
               digitally-signed struct {
                   opaque client_random[32];
                   opaque server_random[32];
                   ServerDHParams params;
               } signed_params;
           case rsa:
           case dh_dss:
           case dh_rsa:
               struct {} ;
              /* message is omitted for rsa, dh_dss, and dh_rsa */
           /* may be extended, e.g., for ECDH -- see [TLSECC] */
       };
   } ServerKeyExchange;

The '};' which belongs to 'select (KeyExchangeAlgorithm) {' is missing in the original text.

Update IANA considerations for TLS 1.3

Triple Handshake fix

This needs to be done for TLS 1.3

Depreciation of various kinds

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.

Remove renegotiation

At the interim we agreed to remove renegotiation

Add AECDH AEAD cipher suites?

Suggested by Viktor Dukhovni.

Reduce the "overhead" values in TLSCiphertext, etc.

This is currently 2^{14} + 2048 (in TLSCiphertexT) and then 2^{14} + 1024 later.

This is introduced by leaving room for compression. Should we just reduce this entirely across the board. Certainly we don't need to leave room for compression.

Remove compression

Tracking issue for the removal of generic record layer compression.

Retry on ClientHello

MUST include all the original shares, plus the one the server selected. Otherwise we create a downgrade opportunity.

Rename ClientKeyExchange

Wan-Teh points out that the new CKE is very different from the old CKE. should we rename?

PRF fixes

In this email (and this draft) Karthik et. al. outline issues with renegotiation that can be exploited to create multiple sessions with the same master secret.

For a new protocol version, it seems like the best solution is to change the master secret calculation to include more of the handshake as input. This can probably be addressed along with #5.

Require extensions to be either encrypted or not encrypted

" The EncryptedExtensions message simply contains any extensions
which should be protected, i.e., any which are not needed to
establish the cryptographic context. The same extension types
MUST NOT appear in both the ServerHello and EncryptedExtensions.
If the same extension appears in both locations, the client MUST
rely only on the value in the EncryptedExtensions block. [[OPEN
ISSUE: Should we just produce a canonical list of what goes where
and have it be an error to have it in the wrong place? That seems
simpler. Perhaps have a whitelist of which extensions can be
unencrypted and everything else MUST be encrypted.]]
"

Determine replacement MTI cipher suite

Now that we are removing static RSA cipher suites, we need a new MTI cipher suite.

Erratum: missing comma

http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=3122

Section A.4. says:

   enum {
       hello_request(0), client_hello(1), server_hello(2),
       certificate(11), server_key_exchange (12),
       certificate_request(13), server_hello_done(14),
       certificate_verify(15), client_key_exchange(16),
       finished(20)
       (255)
   } HandshakeType;

It should say:

   enum {
       hello_request(0), client_hello(1), server_hello(2),
       certificate(11), server_key_exchange (12),
       certificate_request(13), server_hello_done(14),
       certificate_verify(15), client_key_exchange(16),
       finished(20),
       (255)
   } HandshakeType;

The comma after finished(20) is missing in the original text.

PRF negotiation

Mike StJohns notes that the hash function used in the PRF isn't known until the ServerHello is received by a client. This means that the client needs to either calculate and store multiple hashes of the ClientHello OR remember the contents of the ClientHello.

Alternatively, negotiation of the hash function can be removed. SHA-256 might be good enough until we get to the next version of the protocol.

Rewrite backward compatibility section to deal with TLS 1.3