Subject: [weirds] Security Requirements: Non-repudiation

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 15 Oct 2012 13:27:05 +0000

I haven't been able to find any requirements for non-repudiation services. In the interest of clarity it may help to repeat the definition of "non-repudiation service" from RFC 4949:

"A security service that provide protection against false denial of involvement in an association (especially a communication association that transfers data)."

Digital signatures are often used to provide this service. Does anyone know of any requirements for signed queries or signed responses?

Scott

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 20 Oct 2012 21:15:50 -0700

> Digital signatures are often used to provide this service. Does anyone know of any requirements for signed queries or signed responses?

<participant>

Not specifically.  We get that property for free if the request has
been secured by TLS (i.e., https), which seems the most likely
solution to the anti-eavesdropping notion, but I've never heard a need
for the capability to provide replies that are signed yet not
encrypted.

</participant>

-MSK

---

From: Peter Koch <[email-masked]>
Date: Mon, 22 Oct 2012 16:43:17 +0200

> for the capability to provide replies that are signed yet not

there is a difference between a signed object, which could be used
detached from the transport and the TLS secured connection itself.
There is also a diffference in semantics between object and
channel security, in general and in particular.  There are TLD
registries that offer "signed whois" today.  Given that this is
a third party attestation to some extent, I'm not sure it really
falls into the 'non-repudiation' category.

-Peter

---

From: Marcos Sanz <[email-masked]>
Date: Thu, 25 Oct 2012 09:46:13 +0200

> > I haven't been able to find any requirements for non-repudiation
> services. In the interest of clarity it may help to repeat the
> definition of "non-repudiation service" from RFC 4949:
> >
> > "A security service that provide protection against false denial
> of involvement in an association (especially a communication
> association that transfers data)."
> >
> > Digital signatures are often used to provide this service. Does
> anyone know of any requirements for signed queries or signed responses?
>
> <participant>
>
> been secured by TLS (i.e., https),

Unfortunately TLS/SSL does not provide with the non-repudiaton property.

Best regards,
Marcos

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 28 Oct 2012 02:21:23 -0700

> Unfortunately TLS/SSL does not provide with the non-repudiaton property.

I've been hanging out in layer 7 too long.  Thin air.

But I'm confused by this: If a connection authenticated and encrypted
with TLS/SSL sends some payload to me, how could it claim later that
it did not?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 28 Oct 2012 16:54:05 -0000

>with TLS/SSL sends some payload to me, how could it claim later that

It could say we don't show that transaction in our logs.  For
non-repudiation you need the crypto stuff attached to the payload
rather than the channel.

Having said that, none of the current WHOIS and WHOIS-ish provide
non-repudiation, so I'd be interested to hear what concrete problem
(as opposed to an item on a generic security checklist) people think
that it solves.

R's,
John

PS: Please don't refer to courts or lawsuits unless you can point to
actual cases where a digital signture on a document made a difference.

---

From: SM <[email-masked]>
Date: Sun, 28 Oct 2012 12:48:59 -0700

Hi Murray,
>with TLS/SSL sends some payload to me, how could it claim later that

If I understood Marcos Sanz's comment, it is about TLS providing data 
integrity.  TLS only secures communication between the two 
end-points.  It does not have any non-repudiation property.  An 
authenticated connection does not provide that property either.

Regards,
-sm

---

From: Andy Newton <[email-masked]>
Date: Mon, 29 Oct 2012 00:58:20 +0000

>authenticated connection does not provide that property either.

If the difference here is between channel security and object security, I
think you can save the transaction and replay it. After all, if the server
is the only entity with the corresponding private key for the public key
that started off the session, why isn't that non-repudiation? Yeah, its
not the classic case you see in object security but the property is still
there.

-andy

---

From: "John Levine" <[email-masked]>
Date: 29 Oct 2012 01:18:04 -0000

>that started off the session, why isn't that non-repudiation?

Or you can use a third party service that fetches objects and signs
them with a timestamp, analogous to what a notary public does in the
real world.  Either way, I don't see why WEIRDS has to build in
non-repudiation when none of its predecessors have provided it.

R's,
John

---

From: Marcos Sanz <[email-masked]>
Date: Mon, 29 Oct 2012 08:33:08 +0100

Murray,

> with TLS/SSL sends some payload to me, how could it claim later that

the TLS/SSL connection starts by setting up a secure channel via public-key cryptography. Then a shared key for symmetric crypto is agreed among the
two participants, which will be used for the rest of the session (or until renegotation). The latter key is known to both parties, so any party could
repudiate a payload claiming the other one made it up.

If you need the non-repudiation feature, you have to provide it at a higher level.

Best regards,
Marcos

---

From: SM <[email-masked]>
Date: Mon, 29 Oct 2012 00:47:09 -0700

Hi Andy,
>not the classic case you see in object security but the property is still

I might use what you described above for a statement.  Personally, I 
would not call it non-repudiation.

Regards,
-sm

---

From: Andy Newton <[email-masked]>
Date: Mon, 29 Oct 2012 11:29:58 +0000

>would not call it non-repudiation.

Given that Marcos just proved me wrong, it is not. :)

We can always use JOSE if we want or CMS if we want to be masochistic.
This is all very interesting, but I think John's point still stands: this
is scope creep. Are we also gonna specify cert hierarchies for validating
signed objects? Develop a PKIX profile? Define cert path validation?

-andy

---

From: SM <[email-masked]>
Date: Mon, 29 Oct 2012 07:59:27 -0700

Hi Andy,
>signed objects? Develop a PKIX profile? Define cert path validation?

I prefer not to do all that.

Regards,
-sm