Re: [icnrg] comments on ccnx key exchange draft

Mark,

Thanks for the feedback.  I’ll comment on #1 and #2.  I think Chris would better answer #3 and I need to look at #4.

> On Feb 4, 2016, at 1:17 PM, Mark Stapp <mjs@cisco.com> wrote:
> 
> I've read the key exchange draft, and I've got some initial comments and questions. Let me say right up front that I'm grateful for the work that's gone into the initial version - this kind of protocol is a crucial building-block for many applications.
> 
> Thanks,
> Mark
> 
> 1. tls vs quic
> 
> there seems to be quite a lot of emphasis on taking advantage of ideas from quic. I didn't always find that to be compelling, mainly because the crypto parts of quic are sort of subordinated to the transport features such as multiplexing, FEC, improved loss/dup detection, modular cong-control. I think CCN has many of the same needs, and might well benefit from a capable transport protocol stack.
> 
> however, the key-exchange draft is limited to the handshake protocol and key material derivation. the quic authors' documents say that "the quic crypto protocol is _destined to die_" [emphasis in the original] and be replaced with TLS 1.3. it'd be preferable to develop the CCN handshake and key derivation based on tls 1.3. it might be clearer to start without trying to incorporate some of the quic "optimizations", and then revisit the quic protocol when there's a desire to begin developing a CCN transport modelled on quit.

I believe the basic handshake that is in the draft is TLS 1.3.  The differences are:
- we use the hash and hash pre-image to tie round 1 and round 2 together without source addresses.
- We allow renaming the KE session to pin it to a specific name (instead of an “anycast” name).
- We allow moving the session to a different system after KE finishes (the move token).

I think the QUIC influence has to do with some of the message formats, certificate chain compression, etc.  

We need to produce a side-by-side diagram that shows how we follow TLS 1.3 and where we differ.

> 
> 2. computational work balance during handshake
> 
> In the absence of source address info, I think we may need to be more concerned about work balance between client and server during the handshake. there are a couple of places where that seems to me to be a potential problem [I'm using tls-tls13-11 as a reference]:
> 
> - client sends ClientHello, provoking server into doing DH even if the client has no intention of continuing the exchange
> 
> - client sends ClientHello, provoking a server that authenticates with a cert into producing an expensive signature proof
> 
> [I think that first one may apply even if you stick with the quic scheme: the client generates random goop for its ClientShare1 message, and then the server has to do a DH computation to try to decrypt it.]

I’m not sure how our situation is any different than DTLS.  We use a similar mechanism, where the server sends a nonce (we call it nonce2) back to the client and it has to be echoed back.  In the second round, yes the server must do a DH to then try and decrypt the client message.

So, I think anything that might apply to our situation would also apply to (D)TLS and that we should consider working through the problem in the crypto forum.

I don’t see how having source addresses makes TLS more resilient to this, when one still needs to respond with the server-provided cookie.

> 
> 3. replay/sequence counter value and GCM
> 
> I didn't follow where an appropriate counter would be conveyed for use in GCM. It wasn't clear to me - from the text in 6.2 for example - how that was meant to work?
> 
> 5. cert name indication (SNI analogue)
> 
> I think we'll need something that corresponds to SNI - Server Name Indication - the TLS extension that helps support CDNs and virtual servers. I can imagine that there may be applications that don't want to expose in the clear any more than they expose today - they reach some cdn or virtualized host, and then everything that's application-specific takes place inside the protected crypto context.
> 
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg