3 ms·

Non-repudiation means that the party that sent a message cannot later deny having sent it. In TLS both sides negotiate a shared secret key(s) that they then use

Non-repudiation means that the party that sent a message cannot later deny having sent it. In TLS both sides negotiate a shared secret key(s) that they then use for fast symmetric crypto for the actual messages. Symmetric because both sides know the same keys. This means that after the fact either side can claim that the other side fabricated messages that apparently came from them, because they could have done. The point about losing keys is that if I can plausibly claim that I “lost” control of my key then I can claim that an imposter signed a message that apparently came from me. So even with digital signatures you usually need additional controls (hardware, processes, legal/regulatory etc) to really guarantee non-repudiation.

badrabbit 8y ago
I now understand your first point. > The point about losing keys is that if I can plausibly claim that I “lost” control of my key then I can claim that an imposter signed a message that apparently came from me. So even with digital signatures you usually need additional controls (hardware, processes, legal/regulatory etc) to really guarantee non-repudiation. Depends on the use-case right? For example,foss projects use gpg signatures for non-repudiation and authentication,but they can also say "the key was compromised x weeks ago". I think there is only so much a communication protocol can do. For where oauth2 would be used,I believe what some (like OP) want is session level authentication and non-repudiation. To say "I was really speaking to <other end>" as opposed to being able to say "Specific payloads and transactions with <other end> were really made with non-repudiability". For the latter,like you suggested, a protocol with awareness of the specific data,transactions and payloads is needed. Oauth2 and TLS are session aware not application aware.
- nmadden 8y ago
  Right. Most applications and protocols only need authentication. Non-repudiation is kind of an extreme security property, rarely needed outside of legal/financial transactions.

badrabbit 8y ago

I now understand your first point. > The point about losing keys is that if I can plausibly claim that I “lost” control of my key then I can claim that an imposter signed a message that apparently came from me. So even with digital signatures you usually need additional controls (hardware, processes, legal/regulatory etc) to really guarantee non-repudiation. Depends on the use-case right? For example,foss projects use gpg signatures for non-repudiation and authentication,but they can also say "the key was compromised x weeks ago". I think there is only so much a communication protocol can do. For where oauth2 would be used,I believe what some (like OP) want is session level authentication and non-repudiation. To say "I was really speaking to <other end>" as opposed to being able to say "Specific payloads and transactions with <other end> were really made with non-repudiability". For the latter,like you suggested, a protocol with awareness of the specific data,transactions and payloads is needed. Oauth2 and TLS are session aware not application aware.

nmadden 8y ago
Right. Most applications and protocols only need authentication. Non-repudiation is kind of an extreme security property, rarely needed outside of legal/financial transactions.