Re: [Lurk] review of draft-cairns-tls-session-key-interface-01

[Daniel Migault <[e-mail]>]

Hi Thomas, 

Thank you very much for your comments. Please see my response inline. 

-----Original Message-----
From: Fossati, Thomas (Nokia - GB) [mailto:[e-mail]] 
Sent: Sunday, April 03, 2016 10:35 AM
To: [e-mail]
Cc: [e-mail]
Subject: review of draft-cairns-tls-session-key-interface-01

Hi guys,

I've just finished reading your draft.  There's plenty of information & references in it, thank you.

A few comments below:

- The way the RSA interface is defined at the moment suffers from the "decryption oracle syndrome".  We should really try to avoid this and let the LURK box produce the MS instead -- as you're also hinting in the DISCUSSION para of Section 5.1.1.

MGLT: You are right and I share your opinion that with RSA only the MS or EMS should be returned. I am planning to explain this during the BoF and see if everyone agree with this. Actually this document very the very early version of lurk. It describes the architecture, as well as a first LURK implementation. Outside the architecture aspects, other sections have been addressed in separate draft such as [draft-mglt-lurk-tls-use-cases-00] for the use case,  [draft-mglt-lurk-tls-requirements-00 ] for an analysis of the authentication method performed with LURK, [draft-mglt-lurk-tls-abstract-api-00] for a first protocol description.

- LURK has use cases that need high throughput: we really want to be able to fill the pipe between the Edge and Key Server, and also treat each transaction independently.  That's why a UDP based protocol is attractive, vs. for example a HTTP2/TCP based one, which would incur HOL on packet loss.  Also an efficient encoding like the CBOR/CoAP that you are proposing looks really great to keep the overhead at a minimum.  I've never used CoAP in high throughput applications though (quite the opposite, really), so I'm not sure whether its default congestion control algorithm is OK for this scenario?  Have you done any experiment?

MGLT: Thanks for your input. This is also something I would like to discuss during the BoF. Instead of having one transaction per request, we could also use a HTTPS session and tunnel all transaction through that tunnel. Do you think that is a bad idea? I am really open to any suggestion, so your comment is very useful. Actually, the reason the draft [draft-mglt-lurk-tls-abstract-api-00] has this misleading title abstract API, is that it remains focused on the LURK protocol aspects and does not deal yet on the transport aspect.

- It's too early to nit-pick on the wire format, I know, but I'd be nice to have an explicit transaction id in the LURK payloads so that the Edge Server can correlate the TLS handshake with the specific LURK transaction (for logging/debugging/analysis purposes).

MGLT: I agree. 

- The same comments I sent for draft-erb-lurk-rsalg yesterday about the lack of "LURK box capability" and "Cert/key rotation" interfaces.

MGLT: I think that information in the transactions described in draft-erb-lurk are close to what I came too. I agree that LURK client should be able to check the capabilities of the Key Server, this enable to have a very evolutive LURK protocol and start with a core set of authentication methods.

Happy to discuss this further f2f.

MGLT: Great, happy to share your recommendations / thoughts.

Cheers, t