Document the static key share attack #1049
Conversation
In section 6.2, the diagrams make reference to three secrets: static, ephemeral, and master. But the master secret was not defined in the introduction of the section.
Align to latest draft
draft-ietf-tls-tls13.md
Outdated
| @@ -1,4 +1,4 @@ | |||
| --- | |||
| --- | |||
There was a problem hiding this comment.
This change is why travis is complaining. Removing the hypen would be fine, but adding a byte order mark isn't.
|
That pernicious BOM remains. I assume that if this PR is OK, that's an easy editorial fix, so I wouldn't stress about it. |
Align Christian's fork to tlswg master
|
I am really stumped. I just tried integrating the recent changes in the master copy, in case there would be some kind of incompatibility. |
Parentheses in the section title are probably not the source of the travis build failure.
|
Finally fixed. I have no idea where the extra dash came from. |
|
There's a bunch of merge commits that shouldn't be in here in addition to the churn from fixing the build failure (which was likely a result of the former, somehow). Ideally, you should have concise commits of just what you're changing in the PR. Can be fixed via git commands, easily enough: Please do a git squash of these changesets down to a single commit, then rebase it on top of the current upstream master. Do a diff to upstream master to make sure it matches the cumulative diff shown here, clean up the commit message if needed, then force push to this PR branch to update it. For this PR, exactly one commit is sufficient. |
|
@davegarrett : I am of course willing to do that, but it appears to be a notch above my level of expertise in git. Do you have a pointer to a "how to" doc? Or, I can give you access to my fork if that helps. |
|
@huitema: First, taking a longer look at this PR technically, it seems you're pushing this PR from your master branch. That's why we have merge commits and stuff listed from 2015. PRs should be submitted from separate branches made for each PR. (this'll probably still work, so don't start over; just for future reference, to avoid similar pitfalls) You can create new branches via the command line or just use the GitHub web interface to edit, both of which can be synced and then edited with the other. It's much easier to avoid/fix test fails if you've got a clean PR branch with just your new work. Here's a quick link for rebasing with squash: An simpler way to do this, because this changeset is just a paragraph, is to just save the block of new text separately, do a git reset on your PR branch (your fork's master in this case here) to make it match upstream master exactly, then make a new clean commit with the new text. When you force push your local version to GitHub, it will overwrite this PR (but leave most of the comments, generally). Resetting a branch to match upstream exactly is just "git reset --hard upstream/master" whilst on your branch (assuming you've mapped upstream as such, and have fetched latest). Of course, make sure you've already backed-up your change to re-commit and always check a diff to upstream master before force pushing. |
There was a problem hiding this comment.
Just a couple of very minor editorial nits.
If @ekr is ok with the rest of the text, he can probably just manually merge this easily enough, regardless of the extraneous commits here.
draft-ietf-tls-tls13.md
Outdated
| ## Static (EC) DH Shares | ||
|
|
||
| For various reasons, some implementations may be tempted to use static | ||
| (EC) DH private key. Using such keys lowers the security guarantees of |
There was a problem hiding this comment.
nit: do "(EC)DH" without the space, for each instance, to match usage elsewhere
draft-ietf-tls-tls13.md
Outdated
| For various reasons, some implementations may be tempted to use static | ||
| (EC) DH private key. Using such keys lowers the security guarantees of | ||
| TLS 1.3. Adversaries that get access to the static (EC) DH private key | ||
| can now get access to the content of the communication. Adversaries that |
|
If one replaces "static (EC)DH private keys" with PSK (static or for session resumption), the consequences of this attack are about the same. It's a reasonable assumptions that the compromise of a cached ECDH share should imply compromise of all sessions that the server can resume. The corresponding state is expected to live in the same RAM of the server. This compromise is mitigated by managing the lifetime of PSKs or ECDH shares. To put it differently, if a server operator takes this text as a serious concern, the server operator must disable session resumption and any use of PSK, unless the ECDH with PSK is the only option. Should this text at least mention a similar attack on resumption and PSK? |
| @@ -5924,6 +5924,21 @@ server-to-client encryption keys because that would entail | |||
| the reuse of those keys. This parallels the use of the early | |||
| application traffic keys only in the client-to-server direction. | |||
|
|
|||
| ## Static (EC)DH Shares | |||
|
|
|||
| For various reasons, some implementations may be tempted to use static | |||
There was a problem hiding this comment.
Implementations probably should not be assumed to have motive, whereas implementors would.
|
|
||
| For various reasons, some implementations may be tempted to use static | ||
| (EC)DH private keys. Using such keys lowers the security guarantees of | ||
| TLS 1.3. Adversaries that get access to the static (EC)DH private key |
There was a problem hiding this comment.
Lowering a guarantee feels like an odd phrasing to me, as a guarantee is supposed to be a fixed thing. So, one might reduce the level of security that is guaranteed, or break a guarantee, or similar, instead.
| can get access to the content of the communication. Adversaries that | ||
| acquire the key in real-time can compromise the confidentiality of the | ||
| conversation. Adversaries that acquire the key later can use it to | ||
| access the content of recorded sessions, thus breaking the forward |
There was a problem hiding this comment.
This text doesn't really do much to distinguish post-handhsake compromise from contemporary compromise, in that they can "compromise confidentiality" or "access the content of", which is basically synonymous. If we are to cover these cases separately, it would be good to be more clear about what is different between them.
| acquire the key in real-time can compromise the confidentiality of the | ||
| conversation. Adversaries that acquire the key later can use it to | ||
| access the content of recorded sessions, thus breaking the forward | ||
| secrecy promise of the protocol. TLS 1.3 clients should detect the use |
There was a problem hiding this comment.
I don't know that I'm very happy about "should" (vs. "SHOULD") for this.
| access the content of recorded sessions, thus breaking the forward | ||
| secrecy promise of the protocol. TLS 1.3 clients should detect the use | ||
| of static (EC)DH keys by corresponding servers, and should treat servers | ||
| using such keys as compromised. Clients can perform this detection by |
There was a problem hiding this comment.
"treat as compromised" is somewhat vague; it might be better to also add that clients should assume that confidentiality is not protected on connections to such servers, etc.
| using such keys as compromised. Clients can perform this detection by | ||
| comparing keys proposed by the same server at different times, or by | ||
| cooperating with other clients to compare the keys proposed to them by | ||
| sets of servers. |
There was a problem hiding this comment.
This sort of cooperating with other clients seems to suffer from the same client fingerprinting issue that has plagued attempts to introduce gossiping in CT.
|
I'm not detecting a lot of consensus for this. |
As discussed on the mailing list, here is a short proposal to document the "static (EC) DH private key" sharing attack.