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

["Erb, Samuel" <[e-mail]>]

Hi Thomas,
Thanks for the comments & apologies for the slow reply.

Comments in line as [SE]
Thanks,
Sam

From: "Fossati, Thomas (Nokia - GB)" <[e-mail]>
Date: Saturday, April 2, 2016 at 5:39 PM
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: review of draft-erb-lurk-rsalg-00

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?

[SE] I agree – I’m not aware of any significant changes for TLSv1.3 for this draft? I could be wrong about this. The changes I see to watch out for are:
 - SignatureAlgorithm -> SignatureScheme https://tlswg.github.io/tls13-spec/#rfc.section.6.3.2.1
 - 0RTT, but that appears to be resumption only https://tlswg.github.io/tls13-spec/#rfc.section.6.2.3

- 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?

[SE] The LURK box should communicate it’s list of SignatureAlgorithm/SignatureScheme’s as it looks like that list will be more complex with TLSv1.3 (based on the link above)

- 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?

[SE] You’re correct – the client/server version fields likely should be removed from the server key exchange request (assuming no differences with TLSv1.3). 
[SE] For an RFC7627 version of RSALG, the client/server random fields could be made into a single variable length field? Is there overlap between a need to use RSALG (/RSA decryption) and RFC7627 support? (I wish I had data on that)

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

[SE] Sorry, still need to update that. What was meant there was access to a Server (which can then contact a KeyOwner).

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

[SE] I agree. A solution here does need to keep in mind that this may be many-to-many Servers to KeyOwners. Initial cert setup likely requires a message of some kind (with some arbitrary “cert application use” field?). Key rotation may just be a signal to go through the initial setup again (possibly via some sort of additional parameter in each response to signify the certificate has been rotated?).

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.

[SE] If the goal is only auditing, simulating a real connection (as a client) may be a better path for this. For both server_kx and rsalg, you would receive server/client random values.


Cheers, Thomas.