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
|
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
