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

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Sun, 3 Apr 2016 13:34:44 +0000

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.

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

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

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

Happy to discuss this further f2f.

Cheers, t

---

From: Daniel Migault <[email-masked]>
Date: Sun, 3 Apr 2016 14:09:49 +0000

Hi Thomas, 

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

-----Original Message-----
From: Fossati, Thomas (Nokia - GB) [mailto:[email-masked]] 
Sent: Sunday, April 03, 2016 10:35 AM
To: [email-masked]
Cc: [email-masked]
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.

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

Cheers, t

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Sun, 3 Apr 2016 15:44:50 +0000

Hi Daniel,

On 03/04/2016 11:09, "EXT Daniel Migault" <[email-masked]>
wrote:
>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.

OK, I'll go and have a look!

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

What I meant was to use one application layer transaction per LURK call.
A single mutually authenticated & encrypted tunnel (DTLS, IPsec, etc.)
between the Edge and the Key Server, once established, could sit there for
quite a long time and carry as many CoAP transactions as needed.

I think HTTPS over TCP would be a suboptimal transport for LURK because of
the HOL blocking problem I was hinting in the other email: a single packet
loss incident could potentially stop lots of "nearby" transactions.  We
should really try to avoid that.

(I'm around if you want to talk more.)

Cheers, t

---

From: Daniel Migault <[email-masked]>
Date: Sun, 3 Apr 2016 18:10:55 +0000

Ok thank you for the feed back. I see you point and hope we can talk about this week. Any other feed backs for the transport layer in lurk is welcome.

BR, 
Daniel

-----Original Message-----
From: Fossati, Thomas (Nokia - GB) [mailto:[email-masked]] 
Sent: Sunday, April 03, 2016 12:45 PM
To: Daniel Migault; [email-masked]
Cc: [email-masked]
Subject: Re: review of draft-cairns-tls-session-key-interface-01

Hi Daniel,

On 03/04/2016 11:09, "EXT Daniel Migault" <[email-masked]>
wrote:
>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 

>- 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?
>
>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 
>abstract API, is that it remains focused on the LURK protocol aspects 
>and does not deal yet on the transport aspect.

What I meant was to use one application layer transaction per LURK call.
A single mutually authenticated & encrypted tunnel (DTLS, IPsec, etc.) between the Edge and the Key Server, once established, could sit there for quite a long time and carry as many CoAP transactions as needed.

I think HTTPS over TCP would be a suboptimal transport for LURK because of the HOL blocking problem I was hinting in the other email: a single packet loss incident could potentially stop lots of "nearby" transactions.  We should really try to avoid that.

Cheers, t