Re: [TLS] draft-ietf-tls-rfc4347-bis-00.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TLS] draft-ietf-tls-rfc4347-bis-00.txt



Hi Eric,

I would prefer something like:

- For DTLS over TCP or SCTP, which automatically fragment
  and reassemble datagrams, the upper layer protocol
  MUST NOT write any record that exceeds 2^14 byte.

The reason is that a while ago it took me some time
to understand that someone talking about small messages
really was talking about messages of 64KB. Large message
were about several MB. I'm not sure what these guys
would understand when reading "effectively infinite".

Best regards
Michael

On Oct 14, 2008, at 12:46 PM, Eric Rescorla wrote:

At Tue, 14 Oct 2008 10:04:37 +0200,
Robin Seggelmann wrote:

Hello all,
I was just checking the draft for changes relevant to DTLS over SCTP
and came across the following new paragraph:

- For DTLS over TCP or SCTP, which automatically fragment
  and reassemble datagrams, the upper layer protocol
  SHOULD be informed that the PMTU is effectively infinite.

What does 'effectively infinite' mean? TLS limits the message size to
2^14 bytes, so shouldn't this limit also apply to DTLS? If the
message size really is arbitrary, doesn't this affect some cipher
algorithms? Or should the application then ignore the announced
'infinite' PMTU and limit the message size anyway?


Yes, that's a fair point. OTOH, this is a maximum message size
which is related to, but not identical to, the PMTU. Operationally
the application needs to restrict itself to 2^14 and associated
limits. I'm tempted to simply add a parenthetical "(though of
course applications still MUST NOT write any record that exceeds
2^14 bytes)"

-Ekr


_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls


_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.