Hi Martin,
In Section 4 you define what is meant by the "maximum size of record"
and in TLS 1.3 it refers to the complete length of TLSInnerPlaintext,
namely
struct {
opaque content[TLSPlaintext.length];
ContentType type;
uint8 zeros[length_of_padding];
} TLSInnerPlaintext;
For TLS 1.2 you are less explicit. Is it the complete length of the
TLSPlaintext or just the fragment?
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
I prefer it to be the TLSPlaintext structure.
You write:
"an endpoint MUST NOT generate a protected
record with plaintext that is larger than the RecordSizeLimit value
it receives from its peer.
"
I think it would be good to say that a TLS stack has to check this limit
and to return an error to the application through the API so that the
application has a possibility to correct the size of the transmitted
data or to select other ways to recover from the situation.
You write:
"Unprotected messages - handshake messages
in particular - are not subject to this limit.
"
I believe what you are trying to say is that this restriction is not
applicable to the handshake protocol and also not to the alert protocol.
Whether messages are protected or unprotected does not really matter for
the code idea of this document (which is about the buffer sizes).
It might also be good to indicate a recommended value. A meaningful
value is one that is equal to or larger than the handshake messages. If
you have buffer to store the large handshake messages, such as the
Certificate message then you will also be able to have the buffer for
the subsequent data packets. Currently, the minimum size is indicated as
64 bytes, which I believe is a bit unrealistic since even a PSK-based
exchange will need larger handshake message sizes than that.
The RecordSizeLimit is indicated in bytes, correct?
I also think it might be worthwhile to move the following paragraph to
the beginning of the document since it motivates the use of this extension:
An Authentication Encryption with Additional Data (AEAD) ciphers (see
[RFC5116]) API requires that an entire record be present to decrypt
and authenticate it. Some implementations choose not to implement an
AEAD interface in this way to avoid this problem, but that exposes
them to risks that an AEAD is intended to protect against.
Ciao
Hannes
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
