Clarify crypto context for Connection Close #1818
Conversation
Partially resolves #1786.
|
Seems reasonable. |
changing criteria for sending 1-RTT connection close.
|
Is this sufficient? The peer might ignore handshake level packets when ACK'ing 1-RTT. |
|
@mikkelfj It shouldn't. If it decrypts the packet, it MUST tear it down. Worst case, it's already tossed the keys, which seems a bit premature in this context. But we could suggest sending in both contexts. |
|
@mikkelfj I think what the PR says is sufficient, because it an endpoint is expected to hold the Handshake key for 3 RTO after all transmission using the key has been complete. Quoting from Section 4.9 of the TLS draft:
|
I think that the second piece to #1786, which was to make allowances for fatal errors arising from Initial packets won't be necessary. I'm happy to see a PR, of course, but the sentiment I've heard expressed is that it is very hard to manage this, and the spec wouldn't expressly prevent someone from trying to build a system that was resilient to maliciously-crafted Initial packets, but we wouldn't take steps in this document to deal with that. As previously agreed, if you are attacked and the attacker was able to modify Initial packets, then they can deny you the ability to connect. Closes #1818, #1786.
I think that the second piece to #1786, which was to make allowances for fatal errors arising from Initial packets won't be necessary. I'm happy to see a PR, of course, but the sentiment I've heard expressed is that it is very hard to manage this, and the spec wouldn't expressly prevent someone from trying to build a system that was resilient to maliciously-crafted Initial packets, but we wouldn't take steps in this document to deal with that. As previously agreed, if you are attacked and the attacker was able to modify Initial packets, then they can deny you the ability to connect. Closes #1818, #1786.
Partially resolves #1786.