Ben Kaduk's TLS Comment 25

[LPardue]

@kaduk said:

Section 9

In various places (e.g., §4.1.4) we recommend to buffer (or "retain")
data that cannot be processed yet. Perhaps it goes without saying, but
such buffering needs limits in place in order to avoid DoS.

It may be too banal to mention again here that the Initial secret/keys
are not particularly secure, but I'll mention it just in case we want
to.

[martinthomson]

Two separate comments in this issue:

1. We address buffering and retention in Section 7.5 of the transport doc and referenced in Section 4.1.3. I think that suffices.
2. Given that we dedicate Section 7 to the issue of "security" for Initial packets, it probably isn't necessary to repeat things here. (We might consider moving Section 7 to this section, I guess. I just don't like the grab-bag that is security considerations.)

I don't think we should do anything in response to this, though I might be convinced to move Section 7. I will say that it's really annoying to move sections, so I'd need a push.

[seanturner]

I do not see any reason to move it. This entire document is all about security considerations.

[kaduk]

1. We address buffering and retention in Section 7.5 of the transport doc and referenced in Section 4.1.3. I think that suffices.

Yes, that looks like it should suffice. (I read -tls before -transport and didn't think to check if -transport said anything on this topic.)

2. Given that we dedicate Section 7 to the issue of "security" for Initial packets, it probably isn't necessary to repeat things here. (We might consider moving Section 7 to this section, I guess. I just don't like the grab-bag that is security considerations.)

I only mentioned it because sometimes people skip to the named security considerations section and pretend they can ignore the rest of the document. That's ill-advised, of course, and we need not go out of our way to support it -- we do already say that there are many security-relevant details in the rest of the document. So this one is looking like close with no change, and thanks for the pointer to the transport section.