Subject: [icnrg] comments on ccnx key exchange draft

From: Mark Stapp <[email-masked]>
Date: Thu, 4 Feb 2016 16:17:36 -0500

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.

---

From: <[email-masked]>
Date: Fri, 5 Feb 2016 06:02:00 +0000

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 <[email-masked]> 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.

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

> 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?
> 
> 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
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: <[email-masked]>
Date: Mon, 8 Feb 2016 16:02:22 +0000

Hi Mark,

Thanks for the feedback. My response to both you and Marc are inline below.

Cheers,
Chris

On February 4, 2016 at 10:02:08 PM, [email-masked] ([email-masked]) wrote:
> > 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  
> > 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.  
>  

That and the fact that it was based on UDP instead of TLS. 

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

Yes. I’m working on this for the next ICNRG meeting. It will clarify the differences that Mark highlighted above.

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

This is correct. We limit DDoS attacks by this nonce, but we are still susceptible to “same origin" DoS attacks. This issue warrants further exploration.

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

Thanks for pointing this out. There is missing text which should state the length of the IV and how it’s fed into the AEAD algorithm (like what’s done in section 5.2.2 of tls-tls13-11). Basically, we need to do something similar. This will produce an IV of the required length and the counter will be initialized according to the spec (see page 4 of http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-spec.pdf).

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

Yes, we need support for this. We are planning to include this as an extension to the base protocol along with other fields that might be needed (see section 8.2 of tls-tls13-11).