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

["Fossati, Thomas (Nokia - GB)" <[e-mail]>]

Hi Sam,

Thanks very much for the detailed answers.  I've inlined a few comments.

I'm looking forward for an updated version of your draft — are you planning to submit it before the interim?

Cheers, t

From: "Erb, Samuel" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 19 May 2016 15:47
To: "Fossati, Thomas (Nokia - GB)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: review of draft-erb-lurk-rsalg-00

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]<mailto:[e-mail]>>
Date: Saturday, April 2, 2016 at 5:39 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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

[TF] I think one thing to monitor would be https://github.com/tlswg/tls13-spec/issues/443 which is to re-assert server's private key in 0-RTT.

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

[TF] great.  I suppose this would be part of the "LURK-X control-plane" that needs to be specified for each X proposal.

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

[TF] Sorry Sam, I don't understand your question.

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

[TF] Sounds good to me.  The periodic message could be something like: "I'm Server X and I'm currently serving hostnames {H_i}, please provide any updated credentials".

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.

[TF] I'd need to ponder on this a bit more.  I'm not yet sure auditing would be in scope.