[TLS] TLS 1.3 comments

[Yaron Sheffer <[e-mail]>]

Below a long list of comments, generally minor. The document is already very good - we're making great progress!

• The record length field is limited by encrypted-length+2048. Shouldn't it be 1024? - "Each AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes".
• 6: the definition of session contents should also contain identities. The client's identity, if authenticated by cert, or the peers' PSK identity.
• "Access denied" alert: the description starts with "a valid certificate was received", but it may also apply to PSK.
• Handshake_failure alert seems to be synonymous with insufficient_security (and Sec. 6.2.1 proves it...). Can we clarify the difference, or deprecate one of them?
• Typo: "via a certificates".
• Server Configuration: how does the client know to whom the configuration applies? For example if I connected to "*.example.com" (a wildcard cert) and now I connect to "srv.example.com", should I use the stored configuration?
• 6.2.2: typo: has complete.
• 6.3.2.3.2: it's time we specified that the recipient (in this case, the server) MUST verify the received ECDHE public key (see RFC 6989). This is mentioned in Appendix D but only for modular DH.
• 6.3.2.4: "identifier" should read "identity".
• 6.3.4: "Perhaps have a whitelist of which extensions can be unencrypted and everything else MUST be encrypted." - this doesn't work, because we might come up in the future with an extension that needs to be unprotected. Maybe we can say "SHOULD" instead.
• 6.3.7: expiration_date: there's no reason to force/assume time synchronization between client and server. This can just as well be relative time (number of seconds since negotiation), like ticket_lifetime_hint.
• 6.3.10: "If the client does not send any certificates, the server MAY at its discretion either continue the handshake without client authentication ... Also, if some aspect of the certificate chain was unacceptable ... the server MAY at its discretion either continue the handshake (considering the client unauthenticated) or send a fatal alert." This is strange. There is no way for the client to understand that the server considers it unauthenticated and modify its behavior accordingly. A warning alert would be appropriate here, even if in general we don't like warning alerts.
• Typo: main-in-the-middle
• "Note that using non-anonymous key exchange without actually verifying the key exchange is essentially equivalent to anonymous key exchange, and the same precautions apply. " This is not precisely true, because the other peer may not know that you're not verifying the exchange, and so it might behave differently.
• D.1.2: do we really need to worry about version rollback to SSLv2? I suggest to remove this section.

Thanks,
    Yaron