Subject: Re: [Nea] WGLC on NEA Asokan Attack Analysis

From: Carolin Latze <[email-masked]>
Date: Fri, 04 May 2012 14:07:00 +0200

Hi

I have just one comment. In the introduction it is said that "The NEA WG 
has included several of these countermeasures in PT-TLS [5] and PT-EAP 
[6]" The first question that came into my mind was "and why not all of 
them?" :-) So maybe it would make sense to describe the reasoning behind 
the selection of the countermeasures that will be used in PT-TLS and PT-EAP.

regards
Carolin

On 04/27/2012 04:58 PM, Stephen Hanna wrote:
> As previously agreed, the NEA Asokan Attack Analysis
> has been changed into a NEA WG draft. This draft has
> received several years of discussion and review in
> our WG, dating back to its initial publication as
> draft-salowey-nea-asokan-00.txt back in October 2010.
>
> We agreed to make this document a WG draft because
> we found its analysis essential to describing the need
> for TLS channel bindings to prevent Asokan attacks.
> Both PT-TLS and PT-EAP contain informational but
> important references to this document. For those
> documents to be fully understood, it's essential
> for the NEA Asokan Attack Analysis to become an
> informational RFC.
>
> Therefore, I'd like to ask all active NEA WG
> participants to please review the latest draft
> of the NEA Asokan Attack Analysis and to send
> comments, corrections, or questions to the WG
> list. Please complete this Working Group Last
> Call review within two weeks (by 1600 GMT on
> Friday, May 11 - noon EDT or 9 AM PDT). If any
> substantive issues have been raised, we'll get
> those resolved. And if there's WG consensus to
> ask the IESG to advance the document to
> Informational RFC status, we'll do that.
>
> If you don't have any comments on the document
> but you agree that it should advance to
> Informational RFC status, you can just send
> an email in response to this one saying so.
> And if you think that it should not advance,
> please send an email saying that also. These
> emails will be useful in judging WG consensus.
>
> Here's a link to the draft for review:
>
> http://datatracker.ietf.org/doc/draft-ietf-nea-asokan/
>
> At only eight pages in length (and really only
> four pages of content), I think you will find it
> an easy but interesting read. In any event, you
> should learn something. And something quite
> relevant to NEA. If you've already read the
> document before, a quick skim should help you
> confirm that you're comfortable with the latest
> version (or not). Your brief review and comment
> would be greatly appreciated.
>
> Thanks in advance for your help,
>
> Steve
>
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nea
>

---

From: Joe Salowey <[email-masked]>
Date: Thu, 17 May 2012 13:08:15 -0700

Hi Carolin,

PT-TLS and PT-EAP implement mechanism to enforce both cryptographic binding and identity.  They do not implement all the possible mechanisms for cryptographic binding because that would be a bit redundant.   Here is an attempt at some better text:

"The PT-TLS [5] and PT-EAP [6] protocols developed by the NEA working group include mechanisms that can provide cryptographic binding and identity binding countermeasures." 

Cheers,

Joe

On May 4, 2012, at 5:07 AM, Carolin Latze wrote:

> Hi
> 
> I have just one comment. In the introduction it is said that "The NEA WG has included several of these countermeasures in PT-TLS [5] and PT-EAP [6]" The first question that came into my mind was "and why not all of them?" :-) So maybe it would make sense to describe the reasoning behind the selection of the countermeasures that will be used in PT-TLS and PT-EAP.
> 
> regards
> Carolin
>

---

From: [email-masked]
Date: Thu, 31 May 2012 16:43:32 +0200 (CEST)

Hi Joe,

sorry for the late reply. I somehow missed your mail.

I like the text you proposed. That is more clear for me.

Regards
Carolin

> Hi Carolin,
>
> PT-TLS and PT-EAP implement mechanism to enforce both cryptographic
> binding and identity.  They do not implement all the possible mechanisms
> for cryptographic binding because that would be a bit redundant.   Here is
> an attempt at some better text:
>
> "The PT-TLS [5] and PT-EAP [6] protocols developed by the NEA working
> group include mechanisms that can provide cryptographic binding and
> identity binding countermeasures."
>
> Cheers,
>
> Joe
>
>