Subject: [Lurk] review of draft-erb-lurk-rsalg-00

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Sat, 2 Apr 2016 21:39:54 +0000

Hi,

thanks for the draft. The RSALG idea is really nice.

A few comments:

- Re: missing support for TLSv1.x x>2.  We should probably think this a
bit more: TLSv1.3 would probably be in the wild by the time LURK is
finished?

- There is no explicit requirement on the LURK box in terms of the
algorithms it needs to support.  What is the assumption?  Probably there
should to be an interface to allow the Server to know about the LURK box
capabilities, so that it can negotiate TLS parameters with the client that
won't fail the handshake mid-air?

- I see the Server Key Exchange is still TBD, though a few things can be
extrapolated from Section 4.  I might be missing something, but I don't
understand how the {client,server}_version fields would be relevant to a
server_kx request?  Which makes me wonder whether the request types could
be refined a bit: it looks like server_kx and rsalg requests are different
enough to be separate entities?  Also, a RFC7627 version of rsalg would be
quite different from the one currently defined.  Any intention to support
it?

- Last para of Section 3.2: "An attacker who later gains access to
KeyOwner [...]" s/KeyOwner/Server/?

- Cert/key rotation functionality is missing  and I really think this
should really be a requirement for any LURK proposal.

There's a further point that I'm not very sure (I'd like to hear other
people's opinion): the security of TLS is not limited to the
signature/decryption process.  A good pseudo-random source at the Server
is also critical.  Would it be within LURK scope to let the Key Owner
audit relevant session parameters?  This could help if the Server is
compromised -- or if it's just misbehaving.

Cheers, Thomas.