Subject: Re: [Nea] Review comments on Asokan Attack Analysis

From: Joe Salowey <[email-masked]>
Date: Tue, 1 May 2012 22:12:37 -0700

Hi Clifford,

Thanks for taking time to review the document and provide good comments.
On Apr 28, 2012, at 8:36 PM, Clifford Kahn wrote:

> Hello.  I reviewed the latest version of the NEA Asokan Attack Analysis at http://datatracker.ietf.org/doc/draft-ietf-nea-asokan/. 
>  
> I found it strong right up to the conclusions, but them I found unclear.
>  
> Ø  The recommendations for addressing the NEA Asokan Attack are as follows:
>  
> To whom are these recommendations?  To implementers, or to writers of specs?   
>  

[Joe] Mostly to writers of specs, but it should also help implementers understand the motivation behind the specification. 

> Ø  1. Make use of cryptographic binding, however binding identities of the tunnel endpoints in the EMA may be useful.
>  
> The “however” is confusing.  I think it means that one should make use of cryptographic binding, and that in addition binding identities of the tunnel endpoints in the EMA may be useful.  Whether I got it right or not, please consider rephrasing.

[Joe] Good catch, this should be reworded and the bit about the tunnel identities should be removed.   How about:

"Make use of cryptographic binding to protect the integrity of the TLS tunnel.  " 

>  
> Ø  2. Use the same mechanism in L2 and L3 PT transports that make use of TLS (e.g. PT-TLS and PT-EAP).
>  
> I take it that “the same mechanism” refers to the two mechanisms in recommendation 1.  But will others take it that way? 
>  
> Doesn’t recommendation 1 entail recommendation 2?  Why is 2 here?  Since 2 is here, I take it that 1 must have in mind transports other than the ones 2 mentions.  But 1 doesn’t say what transports it has in mind – or I don’t understand.
>  

[Joe]  How about:

"Use the same cryptographic binding mechanism in L2 and L3 TLS-based PT transports (e.g. PT-TLS and PT-EAP)."

> Ø  3. Neither TLS endpoint can be in sole control of the TLS pre-master secret.  This is not strictly necessary when tls-unique channel binding values are used.
>  
> I’m a bit confused by the double negative.  The first sentence is a negative, and the second negates that negative. 
>  
> I think it means that when TLS-unique channel binding values are used, it’s kind of OK for one TLS endpoint to be in sole control of the TLS pre-master secret. Whether I got it right or not, please consider rephrasing.
>  

[Joe] Yes, that is correct.  The text is a bit confusing  and unnecessary since we recommend use of TLS unique, I think we should delete this item.  we could add to 4:

"The preferred approach is to use the tls-unique channel binding data from RFC 5929 [9].  The tls-unique value will be made available to the EMA that will use it.   This approach can utilize any TLS cipher suite based on a strong cipher algorithm."

(perhaps this just opens the can of worms of what a strong cipher algorithm is.)

> I hope that helps.
>  
> Thanks for this important work.
>                                                 Clifford Kahn
>  
> Clifford Kahn
> Pulse BU
> 1-978-589-0252    (or x20252)
>  
>  
>  
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nea

---

From: Clifford Kahn <[email-masked]>
Date: Wed, 2 May 2012 15:30:17 -0400

Hi Joe.

> Thanks for taking time to review the document and provide good comments.

Glad to help.

[Cliff] That makes sense.  So the recommendations are for protocols. The recommendations in most IETF specs are for implementations of protocols, which is a little bit different.  It may help to reword each recommendation something like:  "Protocols should make use of cryptographic binding ..."

> The "however" is confusing.  I think it means that one should make use of cryptographic binding, and that in addition binding identities of the tunnel endpoints in the EMA may be useful.  Whether I got it right or not, please consider rephrasing.

[Cliff] That works for me.

> I take it that "the same mechanism" refers to the two mechanisms in recommendation 1.  But will others take it that way? 
>  
> Doesn't recommendation 1 entail recommendation 2?  Why is 2 here?  Since 2 is here, I take it that 1 must have in mind transports other than the ones 2 mentions.  But 1 doesn't say what transports it has in mind - or I don't understand.
>  

[Joe]  How about:

[Cliff] I don't think that helps me.  Sorry to be thick.  Doesn't recommendation 1 cover all transports?  Isn't recommendation 2 a corollary and redundant?  

If recommendation 1 does not cover all transports, I suggest making it say which transports it covers.  If recommendation 1 does cover all transports and recommendation 2 is a corollary, you might either delete recommendation 2 or make recommendation 2 begin "In particular":

	"In particular, L2 and L3 TLS-based PT transports ... should use cryptographic binding ..."  

That would clear up the relationship between recommendations 1 and 2. 

> I'm a bit confused by the double negative.  The first sentence is a negative, and the second negates that negative. 
>  
> I think it means that when TLS-unique channel binding values are used, it's kind of OK for one TLS endpoint to be in sole control of the TLS pre-master secret. Whether I got it right or not, please consider rephrasing.
>

[Cliff] I like the simplification and the clarity.

If one's cipher suite is not strong enough and an attacker cracks it, then all bets are off.  That's always true.  I don't see why a strong cipher suite is more needed here than it is in other places.  If you agree with that, you might want to delete "based on a strong cipher algorithm".  

Thanks for considering my comments.
			Cliff

---

From: Joe Salowey <[email-masked]>
Date: Thu, 17 May 2012 11:51:33 -0700

> [Cliff] That makes sense.  So the recommendations are for protocols. The recommendations in most IETF specs are for implementations of protocols, which is a little bit different.  It may help to re…

[Joe] OK, sounds good. 

> That would clear up the relationship between recommendations 1 and 2. 

[Joe]  I like the second suggestion a little better. How about:

"2. In particular, L2 and L3 TLS-based PT transports (e.g. PT-TLS and PT-EAP) should use the same cryptographic binding mechanism"

> If one's cipher suite is not strong enough and an attacker cracks it, then all bets are off.  That's always true.  I don't see why a strong cipher suite is more needed here than it is in other plac…

[Joe] I agree.

---

From: Clifford Kahn <[email-masked]>
Date: Thu, 31 May 2012 15:30:36 -0400

Hi Joe.  

It all sounds good.  (Steve Hanna tells me that the protocol is to say so explicitly;  sorry if I held up the works!)

Thanks
			Cliff

-----Original Message-----
From: Joe Salowey [mailto:[email-masked]] 
Sent: Thursday, May 17, 2012 2:52 PM
To: Clifford Kahn
Cc: [email-masked]
Subject: Re: [Nea] Review comments on Asokan Attack Analysis

[Joe] OK, sounds good. 

[Joe] I agree.