[icnrg] comments on ccnx key exchange draft

[Mark Stapp <[e-mail]>]

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

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

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.