4 ms·

TLS certs (client or server) are only used during the handshake. After that it’s symmetric crypto, so no non-repudiation if that’s what they want. (Real non-rep

TLS certs (client or server) are only used during the handshake. After that it’s symmetric crypto, so no non-repudiation if that’s what they want. (Real non-repudiation requires a lot more than just signatures though, otherwise you could just claim that you lost control of your key).

badrabbit 8y ago
Yes,the handshake is authenticated and can have two way non-repudiation. The symmetric crypto that follows the handshake uses secret key agreed upon during the handhake. because only the client and server know that secret,all messages encrypted with it also have non-repudiation. I don't get your point about losing keys,is there any form of non-repudiation that does not require keeping secret material secret? Are you also neglecting the fact that revocation is a thing and TLS non-repudiation works by way of a trusted 3rd party?
- nmadden 8y ago
  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

Yes,the handshake is authenticated and can have two way non-repudiation. The symmetric crypto that follows the handshake uses secret key agreed upon during the handhake. because only the client and server know that secret,all messages encrypted with it also have non-repudiation. I don't get your point about losing keys,is there any form of non-repudiation that does not require keeping secret material secret? Are you also neglecting the fact that revocation is a thing and TLS non-repudiation works by way of a trusted 3rd party?

nmadden 8y ago
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.