Subject: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-03.txt

From: [email-masked]
Date: Mon, 03 Feb 2014 11:24:51 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Crypto Forum Research Group Working Group of the IETF.

        Title           : Dragonfly Key Exchange
        Author          : Dan Harkins
	Filename        : draft-irtf-cfrg-dragonfly-03.txt
	Pages           : 17
	Date            : 2014-02-03

Abstract:
   This document specifies a key exchange using discrete logarithm
   cryptography that is authenticated using a password or passphrase.
   It is resistant to active attack, passive attack, and off-line
   dictionary attack.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-dragonfly/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-irtf-cfrg-dragonfly-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-dragonfly-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 3 Feb 2014 11:27:39 -0800 (PST)

Hello,

  I updated the dragonfly draft to incorporate the comments received
from Rene and Scott. Please take a look.

  regards,

  Dan.

On Mon, February 3, 2014 11:24 am, [email-masked] wrote:
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Watson Ladd <[email-masked]>
Date: Mon, 3 Feb 2014 11:47:11 -0800

> from Rene and Scott. Please take a look.

It still doesn't compare favorably to JPAKE or SPAKE2. TLS has shown less
then zero interest in it. No reduction or evidence for claims made is
forthcoming. The draft excludes curves with uniform hashing to points.

Why is this specific PAKE a work item and not the other alternatives? Was
this a joke for groundhog day?

---

From: David McGrew <[email-masked]>
Date: Mon, 03 Feb 2014 16:49:39 -0500

On 02/03/2014 02:47 PM, Watson Ladd wrote:
>
>
> On Feb 3, 2014 11:27 AM, "Dan Harkins" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >
> >
> >   Hello,
> >
> It still doesn't compare favorably to JPAKE or SPAKE2. TLS has shown 
> less then zero interest in it. No reduction or evidence for claims 
> made is forthcoming. The draft excludes curves with uniform hashing to 
> points.
>
> Why is this specific PAKE a work item and not the other alternatives?
>

You mean like draft-irtf-cfrg-augpake-00?

Drafts are taken up when someone is willing to write one, and there are 
sufficiently many other people that are interested.

> Was this a joke for groundhog day?
>

The sarcasm is not helpful.  Let's stick to a technical discussion.

This draft most certainly should be reviewed, since security concerns 
were raised regarding earlier versions of the draft, especially 
regarding implementation guidance and timing channels.

The process by which CFRG drafts can become RFCs is described in 
http://wiki.tools.ietf.org/html/rfc5743#section-2.1   Note that there is 
a paragraph in the RFC that describes the relationship of that work to 
the research group.    This mechanism enables the sentiment of the RG to 
be captured in the RFC.

Let me ask: can you suggest text for the security considerations section 
of this draft that captures your concerns regarding the lack of 
reduction and uniform hashing?

David

---

From: Watson Ladd <[email-masked]>
Date: Mon, 3 Feb 2014 14:11:25 -0800

>> It still doesn't compare favorably to JPAKE or SPAKE2. TLS has shown
less then zero interest in it. No reduction or evidence for claims made is
forthcoming. The draft excludes curves with uniform hashing to points.
> This draft most certainly should be reviewed, since security concerns
were raised regarding earlier versions of the draft, especially regarding
implementation guidance and timing channels.
> The process by which CFRG drafts can become RFCs is described in
http://wiki.tools.ietf.org/html/rfc5743#section-2.1   Note that there is a
paragraph in the RFC that describes the relationship of that work to the
research group.    This mechanism enables the sentiment of the RG to be
captured in the RFC.
> Let me ask: can you suggest text for the security considerations section
of this draft that captures your concerns regarding the lack of reduction
and uniform hashing?

Sure: "Despite significant efforts, no variant of this protocol has been
proved secure even in the random oracle model with nonstandard assumptions.
None of the security claims are sensible in any accepted formalization of
security protocols. Significant dissent in the WG existed with publication
due to the lack of any more than superficial analysis. No Internet protocol
should use this PAKE when alternatives exist." Just about sums it up.

---

From: David McGrew <[email-masked]>
Date: Mon, 03 Feb 2014 17:53:16 -0500

On 02/03/2014 05:11 PM, Watson Ladd wrote:
>
>
> On Feb 3, 2014 1:49 PM, "David McGrew" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >
>
> > Let me ask: can you suggest text for the security considerations 
> section of this draft that captures your concerns regarding the lack 
> of reduction and uniform hashing?
>
> Sure: "Despite significant efforts, no variant of this protocol has 
> been proved secure even in the random oracle model with nonstandard 
> assumptions. None of the security claims are sensible in any accepted 
> formalization of security protocols.
>

Could you rewrite that in a way that would be accessible to someone who 
is not a crypto specialist, and suggest references for the ROM and 
standard assumptions (and the uniform hashing)?   Perhaps cite a 
formalization of a PAKE protocol?

David

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 3 Feb 2014 15:51:50 -0800 (PST)

> should use this PAKE when alternatives exist." Just about sums it up.

  Well the sum is nil due to your statement contradicting itself. You assert
that protocol received "significant efforts" to prove it secure while
simultaneously asserting that it suffers from a "lack of any more than
superficial analysis." Instead of constructing sentences by stitching
together separate phrases purely for their rhetorical effect, I suggest
you use words to construct a sentence that conveys the idea you have.

  And the less derogatory your sentence is the more likely it will be
accepted and become part of the draft.

  Dan.

---

From: Paul Lambert <[email-masked]>
Date: Mon, 3 Feb 2014 16:43:01 -0800

>From: Cfrg [mailto:[email-masked]] On Behalf Of Watson Ladd
>Sent: Monday, February 03, 2014 2:11 PM

>Sure: "Despite significant efforts, no variant of this protocol has been proved
>secure even in the random oracle model with nonstandard assumptions.

A proof might be desirable but should not block the use of a proposed protocol.
For example there is no adequate proof that integer factorization is “secure”.
This is not a reason to stop using RSA based algorithms.  The lack of
a  complete security proof for draft-irtf-cfrg-dragonfly-03.txt should not
stop it’s use (in fact it’s already in other standards that would benefit
from the analysis and improvements of this group).

I would like to reverse the question.

Watson, in your technical analysis of the
protocol in its current form (draft-irtf-cfrg-dragonfly-03.txt),
can you identify any exploitable security flaw specific to
the protocol?

Paul

From: Cfrg [mailto:[email-masked]] On Behalf Of Watson Ladd
Sent: Monday, February 03, 2014 2:11 PM
To: David McGrew
Cc: [email-masked]
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-03.txt

On Feb 3, 2014 1:49 PM, "David McGrew" <[email-masked]<mailto:[email-masked]>> wrote:
>> On Feb 3, 2014 11:27 AM, "Dan Harkins" <[email-masked]<mailto:[email-masked]>> wrote:
>> >
>> >
>> >   Hello,
>> >
>> It still doesn't compare favorably to JPAKE or SPAKE2. TLS has shown less then zero interest in it. No reduction or evidence for claims made is forthcoming. The draft excludes curves with uniform hashing to points.
>>
> Drafts are taken up when someone is willing to write one, and there are sufficiently many other people that are interested.
>
> This draft most certainly should be reviewed, since security concerns were raised regarding earlier versions of the draft, especially regarding implementation guidance and timing channels.
>
> The process by which CFRG drafts can become RFCs is described in http://wiki.tools.ietf.org/html/rfc5743#section-2.1   Note that there is a paragraph in the RFC that describes the relationship of that work to the research group.    This mechanism enables the sentiment of the RG to be captured in the RFC.
>
> Let me ask: can you suggest text for the security considerations section of this draft that captures your concerns regarding the lack of reduction and uniform hashing?

Sure: "Despite significant efforts, no variant of this protocol has been proved secure even in the random oracle model with nonstandard assumptions. None of the security claims are sensible in any accepted formalization of security protocols. Significant dissent in the WG existed with publication due to the lack of any more than superficial analysis. No Internet protocol should use this PAKE when alternatives exist." Just about sums it up.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 3 Feb 2014 17:08:45 -0800

> >Sure: "Despite significant efforts, no variant of this protocol has been
proved
> from the analysis and improvements of this group).

But there is a proof that OAEP has a reduction to RSA security. PKCS 1.5
had no proof, and got broken a few times. RSA has been intensively studied
for decades, dragonfly hasn't. Slight variants of RSA (Rabin-Williams) are
provably reducible to factoring, an extensively studied problem for
centuries.

Kerberos is the poster child for provable security. v4 had a flaw that went
undiscovered until efforts to prove security were made. In retrospect the
flaw is obvious.

Ignoring the 40 years of cryptography in favor of "looks secure" is
malpractice. No structural engineer would ever build a bridge ignoring the
science of mechanics.

Protocols should use augpake or jpake instead.
> can you identify any exploitable security flaw specific to

Yes: an algorithm exists that guesses passwords in time 2^40. I can't
exhibit it, but it exists. JPAKE doesn't have this issue.
>l
> > Let me ask: can you suggest text for the security considerations
section of this draft that captures your concerns regarding the lack of
reduction and uniform hashing?

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 3 Feb 2014 23:37:38 -0800 (PST)

On February 3, 2014 5:08 pm, Watson Ladd (aka Cotton Mather) wrote:
> exhibit it, but it exists.

  I kind of hoped that spectral evidence did not apply in the hard
sciences.

  Dan.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 4 Feb 2014 08:20:02 +0000

> can you identify any exploitable security flaw specific to

Yes: an algorithm exists that guesses passwords in time 2^40. I can't exhibit it, but it exists. JPAKE doesn't have this issue.

2^40 times doing what?  Is it 2^40 calculations based on a single observed authentication?  Observing 2^40 successful authentications?  Actively interacting 2^40 times with the authentication server?

For password-based authentication, these are totally different things, because most passwords come from a 16-bit pool, and nearly all come from a 24-bit pool ([1]). That means that they are very vulnerable to active guessing, which is why pretty much every application limits an attacker's guessing using timeouts.

So what kind of attack is it that you can't exhibit?

Yoav

[1] http://www.maths.tcd.ie/~dwmalone/p/www2012-slides.pdf

---

From: Watson Ladd <[email-masked]>
Date: Tue, 4 Feb 2014 08:01:21 -0800

On Tue, Feb 4, 2014 at 12:20 AM, Yoav Nir <[email-masked]> wrote:
>
> On Feb 4, 2014, at 3:08 AM, Watson Ladd <[email-masked]> wrote:
>
>
> 2^40 times doing what?  Is it 2^40 calculations based on a single observed
> authentication?  Observing 2^40 successful authentications?  Actively
> interacting 2^40 times with the authentication server?

p calculations, where p is the number of passwords, after conducting
one round with the authentication
server.

The algorithm takes the p discrete logarithms of the password elements
with respect to some base, and uses them
to identify the password that leads to the confirmation being sent.
Concretely, the attacker sends g^x, receives g^y
and guesses p that makes g^(xyp^{-1}) the key going into the confirmation.

For MODP groups maybe this can actually be turned into an exhibitable
attack. I don't know: I've not thought about
it enough. But it is still enough to cause issues as I will explain below.

There is also the fact that in the CK model, where ephermental keys
are leaked, dragonfly reveals the pssword
element, and hence the password, in time p. This algorithm can be
exhibited. It's slightly less interesting, because
CK is very strong, but apparently people care.

This issue is more than a curiosity: it forces reductions of dragonfly
to take place in a very artificial security
model where the hash function is selected randomly. Any reduction in
the ROM or standard model assuming
a less than CK adversary will take the first algorithm I outlined, and
only say that attacks with better performance
then it do not exist. But it will not determine whether or not they
can be exhibited.

The model in which the foundations-of-hashing doesn't matter and a
proof is possible is a model which I know nothing about.
I don't know if its been proposed before, or what separation results
exist between it and the ROM, or what
those separations say about what we can and can't do. I also don't
know if Dragonfly in some good model
of PAKE reduces in hardness to something hard in that model.

These sorts of reductions are at the core of the science of
cryptography. Ignoring

Finally, we can adopt AugPAKE or JPAKE and avoid all of these issues
entirely: there is no compelling
reason why Dragonfly should be used instead of AugPAKE. I'm struggling
to see the rationale for standardizing
a solution inferior to protocols we already have.

>
> For password-based authentication, these are totally different things,
> because most passwords come from a 16-bit pool, and nearly all come from a
> 24-bit pool ([1]). That means that they are very vulnerable to active
> guessing, which is why pretty much every application limits an attacker's
> guessing using timeouts.

I used 2^40 from horsebatterystaplecorrect style. Turns out it's worse
than I thought.
> So what kind of attack is it that you can't exhibit?

Foundations of hashing.

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Mike Hamburg <[email-masked]>
Date: Tue, 4 Feb 2014 10:29:53 -0800

Hello CFRG,

Let's see if I can provide a less controversial, or at least less theoretical, defense of the notion of cryptographic proof.

If this protocol is widely deployed, and people actually use it, there will be an incentive for various organizations to break it.  For example, NSA might ask Don Coppersmith to lead a team of similarly-clever cryptographers to spend a month trying to break it.  They would have access to classified techniques and massive computing power.  I am almost certain that the NSA and their contractors would put in this kind of effort and more into a new widely-deployed symmetric or asymmetric cipher.  This is why they hire more mathematicians than anyone else.  I suspect that a new protocol would attract a similar effort unless they have a better reason than I do to believe it's secure.

Likewise, other nations would mount attacks.  Outside researchers would too, but at least in that case we'd know if they broke it and could switch to something else.

When deploying a new protocol, I want a good reason to believe that it's better than the other alternatives.  "Better" could mean that it takes less work to implement, or is faster, or has fewer IPR concerns, or is easier to use correctly, or that it takes less bandwidth, or has more features, or it enables new security systems (like a PAKE).  But "better" also means that there is less risk that the NSA or the Chinese or the French or Adi Shamir will break it a month or a year down the road.  Risk is all we can talk about here, because of course someone might build a quantum computer or solve the discrete log problem.

There are two ways to convince me that the risk is low.  One is to have teams of elite cryptographers work for months trying to attack the system.  This is what happened with AES and SHA-3, but it really isn't scalable to every new cipher and protocol.

The other way to convince me is a proof of security.  There are better and worse models for this (RO vs standard model, gap assumptions vs CDH, whatever), but in the end, a proof is much better than no proof.  It means that as long as you haven't messed up the proof and I haven't messed up checking it, the adversary will need to pass a certain very high bar of cleverness (breaking the model and/or assumptions) in order to attack the system.  The more conservative and standard and commonly-used the model and assumptions are, the higher the bar will be and the more convincing the proof will be.  This doesn't guarantee that the adversary will fail, but at least it gives good evidence in that direction.

The argument given for Dragonfly is that we've patched all the security problems which people have found already, and since then they haven't found more.  And also, it looks like it ought to be secure.  These arguments are not very convincing.  I don't know who's been looking for attacks and how long, but I suspect it hasn't been a monthlong effort with a team of elite cryptographers.

I don't have an attack against Dragonfly.  I worked on attacking it for maybe an hour, and I'm no Coppersmith.  It looks to me like it ought to be secure.  But there have historically been plenty of protocols which looked secure and turned out not to be.

What's more, there isn't a formal security definition of Dragonfly.  This increases the risk that it will be deployed incorrectly, because it makes it harder to analyze the security properties of such a deployment.

Despite these problems, Dragonfly would still be the "best" PAKE protocol out there, and even worth deploying, if there weren't other good options.  But in fact there are SPAKE2 and "SPAKE2 Elligator Edition", which are also IPR-clean, similarly fast and simple, take less bandwidth, and have formal security models and proofs.  Furthermore, they (optionally) support an augmented/asymmetric PAKE interaction, which Dragonfly does not.  This may not matter to Dan Harkins, but it will matter to some people.

The advantage that Dragonfly has over these protocols is momentum: it's written up in an RFC, and SPAKE2 EE isn't even written up in a white paper.  But I, and several other people on this list, don't find that to be enough to outweigh its disadvantages.

In sum, saying "if you don't think it's secure, where's your attack against it?" isn't productive.  I think that Dragonfly is probably secure.  But I want to be much more certain than I am now.  There's not even any point in me spending a month trying and failing to break it, since I could spend that month writing an RFC and an implementation and a paper for SPAKE2 EE instead.

Cheers,
-- Mike Hamburg

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 4 Feb 2014 10:47:01 -0800 (PST)

> and guesses p that makes g^(xyp^{-1}) the key going into the confirmation.

  This is mentioned in section 6.3 of RFC 5931 (dragonfly as an EAP
method), knowledge of r where PE = r * G can enable a dictionary
attack. But knowledge of r requires doing a discrete logarithm. A discrete
logarithm is assumed to be "computationally infeasible" and you're talking
about doing 2^40 of them!?!

> CK is very strong, but apparently people care.

  Well, just define Reveal() to only give the session key, that's what
AugPAKE does-- doing Reveal() does not give W = g^password. Not
that I have proved dragonfly is secure in the CK model, just that the CK
model let's the particular protocol define what is its "session state"
that gets revealed.

  Dan.

---

From: Robert Ransom <[email-masked]>
Date: Tue, 4 Feb 2014 11:41:37 -0800

> about doing 2^40 of them!?!

<http://cr.yp.to/papers.html#nonuniform> is relevant here.  It
discusses several other ‘attacks’ of this general type, and explains
why they should not be taken seriously.

Robert Ransom

---

From: Watson Ladd <[email-masked]>
Date: Tue, 4 Feb 2014 12:11:31 -0800

> why they should not be taken seriously.

Bernstein actually argues that one should define complexity measures to
exclude such attacks. This is clear in the paper. Unfortunately time memory
product for the weak password variation is only 2^40.

The problem with foundations of hashing usually isn't a real problem: one
can sign r,H (r, m) with r random to bypass it.

This attack is interesting because of the limits it puts on reductions,
which are the main tool for doing cryptography. If dragonfly could be shown
to have no other weaknesses this would be fine, but no such proof is
forthcoming.

Such a proof would be in the ROM, but as the IETF 88 slides show it would
be tricky.

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 4 Feb 2014 15:42:48 -0500

> why they should not be taken seriously.

Robert,

I think you hit the nail on the head, and made an excellent point.

Thanks!
--
Regards,
Uri               <[email-masked]>
<Disclaimer>

---

From: Paul Lambert <[email-masked]>
Date: Tue, 4 Feb 2014 14:06:41 -0800

>Sent: Tuesday, February 04, 2014 12:12 PM

>This attack is interesting because of the limits it puts on reductions, which are
>the main tool for doing cryptography. If dragonfly could be shown to have no
>other weaknesses this would be fine, but no such proof is forthcoming.

When you say ‘no other’ you continue to imply that you have identified a realistic exploitable weakness. The difficulty in ‘reducing’ the Dragonfly proposal is not a exploitable flaw.  The changes necessary in protocol to allow a formal proof may in fact weaken the overall security of the protocol (reference below).

                        On the Security Loss in Cryptographic Reductions
Proceeding: EUROCRYPT '09 Proceedings of the 28th Annual International Conference on Advances in Cryptology: the Theory and Applications Cryptographic Techniques
Pages 72 - 87
Almost all the important cryptographic protocols we have today base their security on unproven assumptions, which all imply NP $\ne$ P, and thus having unconditional proofs of their security seems far beyond our reach. One research effort then is to identify more basic primitives and prove the security of these protocols by reductions to the security of these primitives. However, in doing so, one often observes some security loss in the form that the security of the protocols is measured against weaker adversaries, e.g., adversaries with a smaller running time. Is such a security loss avoidable? We study two of the most basic cryptographic reductions: hardness amplification of one-way functions and constructing pseudorandom generators from one-way functions. We show that when they are done in a certain black-box way, such a security loss is in fact unavoidable.

Your adamancy to make up issues with Dragonfly seems to imply you feel this is a ‘down selection’ between multiple protocols.  It is not.  TLS is one possible application, but the Dragonfly protocol was written in a generic manner to specifically allow the analysis independent of the target application.  Other schemes would be viable for TLS and I would strongly support publication and review of multiple password protocol  alternatives for TLS.

The Dragonfly protocol has been in other standards act ivies for quite a few years (usually called  SAE).  The review in this forum has improved side channel security.  Your suggestions for other TLS solutions should not block the analysis of this protocol if it is secure.  Making sure we have clarity on the actual security of a fielded solution in critical and we should be professional and correct in our analysis.  Mesh networking networks are using SAE (aka Dragonfly).  Other consumer oriented applications will appear based on the analysis that the protocol has no exploitable weakness.

Do also note that the  IPR disclosures for AugPAKE that you advocate have limitations and are constrained to the IETF and TLS.  AugPAKE is completely unacceptable for any broader application in consumer equipment (IMHO).  There are many engineering criteria to balance in the section of appropriate algorithms for the industry.  Support of ‘reductions’ for a formal proof are way down the list in my priorities.  I see that we disagree on this point, and hope that you would look at the broader set of industry requirements  and tone down your rhetoric.  If you continue to have objections, please be clear and correct with the analysis.  You still owe the group a clarification or a retraction on your claimed  2^40th attack on Dragonfly.

Thanks,

Paul

From: Cfrg [mailto:[email-masked]] On Behalf Of Watson Ladd
Sent: Tuesday, February 04, 2014 12:12 PM
To: rransom. 8774; [email-masked]
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-03.txt

On Feb 4, 2014 11:41 AM, "Robert Ransom" <[email-masked]<mailto:[email-masked]>> wrote:
>
> On 2/4/14, Dan Harkins <[email-masked]<mailto:[email-masked]>> wrote:
>

Bernstein actually argues that one should define complexity measures to exclude such attacks. This is clear in the paper. Unfortunately time memory product for the weak password variation is only 2^40.

The problem with foundations of hashing usually isn't a real problem: one can sign r,H (r, m) with r random to bypass it.

This attack is interesting because of the limits it puts on reductions, which are the main tool for doing cryptography. If dragonfly could be shown to have no other weaknesses this would be fine, but no such proof is forthcoming.

Such a proof would be in the ROM, but as the IETF 88 slides show it would be tricky.

---

From: Michael Hamburg <[email-masked]>
Date: Tue, 4 Feb 2014 14:31:44 -0800

> When you say ‘no other’ you continue to imply that you have identified a realistic exploitable weakness. The difficulty in ‘reducing’ the Dragonfly proposal is not a exploitable flaw.  The changes…
Does that reference actually show a case where provable security makes things weaker?  It looks from the abstract as though “security loss” just means that you can’t make the proof’s bounds as tight as you’d hope, at least for standard proof strategies.

Cheers,
— Mike

---

From: Watson Ladd <[email-masked]>
Date: Tue, 4 Feb 2014 15:43:56 -0800

> >This attack is interesting because of the limits it puts on reductions,
which are
> When you say ‘no other’ you continue to imply that you have identified a
realistic exploitable weakness. The difficulty in ‘reducing’ the Dragonfly
proposal is not a exploitable flaw.  The changes necessary in protocol to
allow a formal proof may in fact weaken the overall security of the
protocol (reference below).

The paper below claims no such thing. I am claiming that there is a
weakness in standard model security for dragonfly,  not that there is an
exploitable flaw.

In fact tight reductions are possible, despite your claim otherwise.
> Proceeding: EUROCRYPT '09 Proceedings of the 28th Annual International
Conference on Advances in Cryptology: the Theory and Applications
Cryptographic Techniques
>
> Pages 72 - 87
>
> Almost all the important cryptographic protocols we have today base their
security on unproven assumptions, which all imply NP $\ne$ P, and thus
having unconditional proofs of their security seems far beyond our reach.
One research effort then is to identify more basic primitives and prove the
security of these protocols by reductions to the security of these
primitives. However, in doing so, one often observes some security loss in
the form that the security of the protocols is measured against weaker
adversaries, e.g., adversaries with a smaller running time. Is such a
security loss avoidable? We study two of the most basic cryptographic
reductions: hardness amplification of one-way functions and constructing
pseudorandom generators from one-way functions. We show that when they are
done in a certain black-box way, such a security loss is in fact
unavoidable.
>
>
>
>
>
> Your adamancy to make up issues with Dragonfly seems to imply you feel
this is a ‘down selection’ between multiple protocols.  It is not.  TLS is
one possible application, but the Dragonfly protocol was written in a
generic manner to specifically allow the analysis independent of the target
application.  Other schemes would be viable for TLS and I would strongly
support publication and review of multiple password protocol  alternatives
for TLS.

I am not "making up issues". I simply think that when a protocol goes into
an RFC it gets used. And that means we should be careful with the protocols
we publish.

Which alternative do you think TLS should use?
>
>
> The Dragonfly protocol has been in other standards act ivies for quite a
few years (usually called  SAE).  The review in this forum has improved
side channel security.  Your suggestions for other TLS solutions should not
block the analysis of this protocol if it is secure.  Making sure we have
clarity on the actual security of a fielded solution in critical and we
should be professional and correct in our analysis.  Mesh networking
networks are using SAE (aka Dragonfly).  Other consumer oriented
applications will appear based on the analysis that the protocol has no
exploitable weakness.

Not our problem. We are the IETF not the consumer electronics board.
Analyse it yourself. Or wait for someone else to do so. Or pay.

>
> Do also note that the  IPR disclosures for AugPAKE that you advocate have
limitations and are constrained to the IETF and TLS.  AugPAKE is completely
unacceptable for any broader application in consumer equipment (IMHO).
There are many engineering criteria to balance in the section of
appropriate algorithms for the industry.  Support of ‘reductions’ for a
formal proof are way down the list in my priorities.  I see that we
disagree on this point, and hope that you would look at the broader set of
industry requirements  and tone down your rhetoric.  If you continue to
have objections, please be clear and correct with the analysis.  You still
owe the group a clarification or a retraction on your claimed  2^40th
attack on Dragonfly.

It's a foundations of hashing style attack: utterly impractical but
theoretically important.

Why don't you list the requirements, and we'll come up with a protocol that
meets them?

What about being secure against reflection attacks or being well studied?

Of course I thought we were here to support the IETF. Still, this explains
WEP: marvel does not have a single cryptographer reviewing standards
submissions and expects it to be done by the community.
be tricky.

---

From: David McGrew <[email-masked]>
Date: Wed, 05 Feb 2014 08:32:02 -0500

On 02/04/2014 06:43 PM, Watson Ladd wrote:
>
>
> On Feb 4, 2014 2:06 PM, "Paul Lambert" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >
> >
> >
> > >From: Cfrg [mailto:[email-masked] 
> <mailto:[email-masked]>] On Behalf Of Watson Ladd
> > When you say 'no other' you continue to imply that you have 
> identified a realistic exploitable weakness. The difficulty in 
> 'reducing' the Dragonfly proposal is not a exploitable flaw. The 
> changes necessary in protocol to allow a formal proof may in fact 
> weaken the overall security of the protocol (reference below).
>
> weakness in standard model security for dragonfly,  not that there is 
> an exploitable flaw.
>
> > Proceeding: EUROCRYPT '09 Proceedings of the 28th Annual 
> International Conference on Advances in Cryptology: the Theory and 
> Applications Cryptographic Techniques
> >
> > Pages 72 - 87
> >
> > Almost all the important cryptographic protocols we have today base 
> their security on unproven assumptions, which all imply NP $\ne$ P, 
> and thus having unconditional proofs of their security seems far 
> beyond our reach. One research effort then is to identify more basic 
> primitives and prove the security of these protocols by reductions to 
> the security of these primitives. However, in doing so, one often 
> observes some security loss in the form that the security of the 
> protocols is measured against weaker adversaries, e.g., adversaries 
> with a smaller running time. Is such a security loss avoidable? We 
> study two of the most basic cryptographic reductions: hardness 
> amplification of one-way functions and constructing pseudorandom 
> generators from one-way functions. We show that when they are done in 
> a certain black-box way, such a security loss is in fact unavoidable.
> >
> >
> >
> >
> >
> > Your adamancy to make up issues with Dragonfly seems to imply you 
> feel this is a 'down selection' between multiple protocols.  It is 
> not.  TLS is one possible application, but the Dragonfly protocol was 
> written in a generic manner to specifically allow the analysis 
> independent of the target application.  Other schemes would be viable 
> for TLS and I would strongly support publication and review of 
> multiple password protocol  alternatives for TLS.
> >
>
> I am not "making up issues". I simply think that when a protocol goes 
> into an RFC it gets used. And that means we should be careful with the 
> protocols we publish.
>

There are plenty of RFCs that specify things that are rarely used. For 
instance, CAST-128, CAST-256, and RC5 were defined in RFCs, yet never 
saw significant use in the Internet.   Anyway, my understanding is that 
Dragonfly is already in use, as Paul describes below.

It makes sense for CFRG to publish an RFC that describes how it can be 
implemented in a way that avoids timing attacks,  and that documents 
security considerations around its use, including considerations around 
the lack of a proof of security.   In the past, some people have been 
very vocal in their criticism of the dragonfly draft for *not* 
containing these things.   It is just not a credible suggestion to ask 
that the draft not be improved, and that the changes to the draft not 
get review from this list.

Instead of trying to prevent the publication or review of improved 
versions of the draft, you should suggest changes and additions to the 
draft that describe the issues that you have found.   If you suggest 
text that the RG agrees with, it will end up in the draft, and you will 
have made your points.

> > The Dragonfly protocol has been in other standards act ivies for 
> quite a few years (usually called  SAE).  The review in this forum has 
> improved side channel security.  Your suggestions for other TLS 
> solutions should not block the analysis of this protocol if it is 
> secure.  Making sure we have clarity on the actual security of a 
> fielded solution in critical and we should be professional and correct 
> in our analysis.  Mesh networking networks are using SAE (aka 
> Dragonfly).  Other consumer oriented applications will appear based on 
> the analysis that the protocol has no exploitable weakness.
> >
> >
>

CFRG is the IRTF, not the IETF.

> > Do also note that the  IPR disclosures for AugPAKE that you advocate 
> have limitations and are constrained to the IETF and TLS.  AugPAKE is 
> completely unacceptable for any broader application in consumer 
> equipment (IMHO).  There are many engineering criteria to balance in 
> the section of appropriate algorithms for the industry.  Support of 
> 'reductions' for a formal proof are way down the list in my 
> priorities.  I see that we disagree on this point, and hope that you 
> would look at the broader set of industry requirements  and tone down 
> your rhetoric.  If you continue to have objections, please be clear 
> and correct with the analysis.  You still owe the group a 
> clarification or a retraction on your claimed  2^40th attack on Dragonfly.
> >
>
> Why don't you list the requirements, and we'll come up with a protocol 
> that meets them?
>
> Of course I thought we were here to support the IETF. Still, this 
> explains WEP: marvel does not have a single cryptographer reviewing 
> standards submissions and expects it to be done by the community.
>

This slap at Paul and Marvel is not OK.   Discussion on the list needs 
to stick to technical substance and be polite.

David

> >
> >
> > Thanks,
> >
> >
> >
> > Paul
> >
> >
> >
> >
> >
> >
> >
> > From: Cfrg [mailto:[email-masked] 
> <mailto:[email-masked]>] On Behalf Of Watson Ladd
> > To: rransom. 8774; [email-masked] <mailto:[email-masked]>
> > > discusses several other 'attacks' of this general type, and explains
> > Bernstein actually argues that one should define complexity measures 
> to exclude such attacks. This is clear in the paper. Unfortunately 
> time memory product for the weak password variation is only 2^40.
> >
> > The problem with foundations of hashing usually isn't a real 
> problem: one can sign r,H (r, m) with r random to bypass it.
> >
> > This attack is interesting because of the limits it puts on 
> reductions, which are the main tool for doing cryptography. If 
> dragonfly could be shown to have no other weaknesses this would be 
> fine, but no such proof is forthcoming.
> >

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 5 Feb 2014 14:36:21 +0000

On 2014-2-5, at 14:32, David McGrew <[email-masked]> wrote:
> This slap at Paul and Marvel is not OK.   Discussion on the list needs to stick to technical substance and be polite.  

Agree with David.

Watson, RG participants have already asked me to suspend your posting rights per BCP38 due to repeated unprofessional statements on the list. I am monitoring this. Please consider yourself warned.

Lars Eggert
IRTF Chair

---

From: "Manger, James" <[email-masked]>
Date: Thu, 6 Feb 2014 10:34:45 +1100

Watson,

Please keep up your very valuable contributions to this group. They far outweigh a few raw or impolite statements about previous failures and sloppiness in crypto.

Lars,

Instead of publicly warning a useful contributor, could you take a minimal stand against the sabotage of crypto standards by the NSA. I'm glad other IETF groups are trying to address pervasive surveillance with technical measures, but we also know: the NSA has sabotaged crypto standards; they have not told us which standards bodies or which specifications are affected; they haven't told us the nature of the sabotage. The NSA have tarnished a lot of work by our standards community on improving internet security. In this situation it is totally untenable for an NSA employee to chair this crypto standards group. Make it clear that an organization cannot both sabotage our work and have their employees openly participate in our civil community.

--
James Manger

> -----Original Message-----
> From: Cfrg [mailto:[email-masked]] On Behalf Of Eggert, Lars
> Sent: Thursday, 6 February 2014 1:36 AM
> To: David McGrew
> Cc: [email-masked]
> Subject: Re: [Cfrg] publishing dragonfly (was: Re: 2^40. I can't
> exhibit it, but it exists.)
> 
> > This slap at Paul and Marvel is not OK.   Discussion on the list
> needs to stick to technical substance and be polite.
> 
> Agree with David.
> 
> Watson, RG participants have already asked me to suspend your posting
> rights per BCP38 due to repeated unprofessional statements on the list.
> I am monitoring this. Please consider yourself warned.
> 
> Lars Eggert
> IRTF Chair

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 6 Feb 2014 07:16:06 +0000

Hi,

On 2014-2-6, at 0:34, Manger, James <[email-masked]> wrote:
> Instead of publicly warning a useful contributor,

I'm not debating the usefulness of Watson's contributions (I am in no position to). I am warning him that his tone has on occasion been problematic, and informed him that I have been asked to consider a BCP38 posting rights action.

> could you take a minimal stand against the sabotage of crypto standards by the NSA. I'm glad other IETF groups are trying to address pervasive surveillance with technical measures, but we also know: the NSA has sabotaged crypto standards; they have not told us which standards bodies or which specifications are affected; they haven't told us the nature of the sabotage. The NSA have tarnished a lot of work by our standards community on improving internet security. In this situation it is totally untenable for an NSA employee to chair this crypto standards group. Make it clear that an organization cannot both sabotage our work and have their employees openly participate in our civil community.

The CFRG is not a standards group. It does not produce standards. It's discussions and documents may influence IETF standards, but those discussions happen in IETF working groups governed by the IETF process. This is important, because not all of the IETF rules apply to the IRTF, see RFC2014. (For example, IRTF research groups need not come to consensus on their output.)

As an individual, I am fully in favor of making widespread wiretapping as difficult and costly as possible, and I am very supportive of anything the IETF and IRTF can do here.

That said, replacing Kevin Igoe as co-chair of the CFRG is not an action that will get us any closer towards that goal. Please see my detailed reply to Trevor for why; the short version is that I don't believe that Kevin (or David, for that matter) have any greater influence over the output of the research group than other participants. They don't have any veto rights, or an ability to suppress contributions or discussions, or a way to mandate certain outcomes.

Our best defense against IRTF and IETF work being subverted is transparency, and getting as much review from as diverse a group of people as possible. Eliminating groups of people from participating because of their current or past employment status, or based on whom they consulted for or took research grants from weakens that open process.

Lars

---

From: "Manger, James" <[email-masked]>
Date: Fri, 7 Feb 2014 02:00:09 +1100

>> could you take a minimal stand against the sabotage of crypto
>> standards by the NSA. I'm glad other IETF groups are trying to address
>> pervasive surveillance with technical measures, but we also know: the
>> NSA has sabotaged crypto standards; they have not told us which
>> standards bodies or which specifications are affected; they haven't
>> told us the nature of the sabotage. The NSA have tarnished a lot of
>> work by our standards community on improving internet security. In this
>> situation it is totally untenable for an NSA employee to chair this
>> crypto standards group. Make it clear that an organization cannot both
>> sabotage our work and have their employees openly participate in our
>> civil community.

> The CFRG is not a standards group. It does not produce standards.

These look and smell like standards to me, and this is where they are worked on.

draft-irtf-cfrg-advice
draft-irtf-cfrg-augpake
draft-irtf-cfrg-cipher-catalog
draft-irtf-cfrg-cwc
draft-irtf-cfrg-dragonfly
draft-irtf-cfrg-fast-mac-requirements
draft-irtf-cfrg-icm
draft-irtf-cfrg-kdf-uses
draft-irtf-cfrg-ocb
draft-irtf-cfrg-rhash
draft-irtf-cfrg-tmmh
draft-irtf-cfrg-ust
draft-irtf-cfrg-zss
draft-irtf-cfrg-zssbn
draft-mcgrew-aead-*
...

> It's
> discussions and documents may influence IETF standards, but those
> discussions happen in IETF working groups governed by the IETF process.
> This is important, because not all of the IETF rules apply to the IRTF,
> see RFC2014. (For example, IRTF research groups need not come to
> consensus on their output.)
> 
> As an individual, I am fully in favor of making widespread wiretapping
> as difficult and costly as possible, and I am very supportive of
> anything the IETF and IRTF can do here.

NSA have been sabotaging crypto standards. This is separate from widespread wiretapping.

> That said, replacing Kevin Igoe as co-chair of the CFRG is not an
> action that will get us any closer towards that goal.

Removing Kevin Igoe will be a concrete statement that we find the NSA sabotage of crypto standards unacceptable. It will also make it just that bit more difficult and costly for future sabotage of standards.
Not because Kevin is no longer a chair, but by making it just a little bit harder for the NSA to attract budding cryptographers, who will be just a bit more wary of joining the NSA when it might crimp their ability to contribute to forums such as CFRG.

> Please see my
> detailed reply to Trevor for why; the short version is that I don't
> believe that Kevin (or David, for that matter) have any greater
> influence over the output of the research group than other
> participants. They don't have any veto rights, or an ability to
> suppress contributions or discussions, or a way to mandate certain
> outcomes.

Of course chairs have some greater influence, but that it not particularly relevant.
Removing Kevin is a signal about sabotaging standard.

> Our best defense against IRTF and IETF work being subverted is
> transparency, and getting as much review from as diverse a group of
> people as possible.

That is one defence.
Another one is to add one more factor for the NSA to weigh when they next consider sabotaging crypto. If Kevin is removed they are more likely to remember that it harms their remit to improve security, and harms their employees.

> Eliminating groups of people from participating
> because of their current or past employment status, or based on whom
> they consulted for or took research grants from weakens that open
> process.

We are not eliminating groups, we are saying we strongly object to one organization's actual behaviour.
My understanding is that Kevin Igoe is a current employee of the NSA, paid (at least in part) to work on crypto standards.

>past employment status
>consulted for
>took research grants

No one is suggesting anything about those categories.
Listing them feels like an attempt to invoke an imaginary slippery slope as an excuse not to act.

--
James Manger

---

From: Alexandre Anzala-Yamajako <[email-masked]>
Date: Thu, 6 Feb 2014 16:14:54 +0100

At the very least we should be able to demand from the members of cfrg to
take a public stand against the NSA sabotage of crypto standards. As far as
I know this has been asked of Kevin Igoe and was only met by silence.

As a non-us citizen working in crypto engineering my efforts to get grad
students involved with the cfrg has been met with disbelief and disinterest
when finding out the affiliation of one of its chairs.
According to me, the question whether or not what's happening to Kevin Igoe
is fair (until proven otherwise, I don't doubt his judgement or his
honesty) is interesting but beyond the point. Right now we should be
thinking about what's fair to the cfrg

Regards

-- 
Alexandre Anzala-Yamajako

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 6 Feb 2014 16:20:23 +0000

Hi,

I want to respond to a few of your points. I won't get into a prolonged debate here.

> These look and smell like standards to me, and this is where they are worked on.

<snip>

but they aren't. By definition, the IRTF does not produce standards, and the first sentence of the boilerplate of any IRTF RFC says

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

and then goes on to state even more caveats. That's about as clear as we can be.

> NSA have been sabotaging crypto standards. This is separate from widespread wiretapping.

Fair point.

I would also be in favor of any action that would make it more difficult for anyone to subvert the work we do. I still do not believe that replacing Kevin as chair would actually serve that purpose.

> Removing Kevin Igoe will be a concrete statement that we find the NSA sabotage of crypto standards unacceptable.

No, it wouldn't. It would be a demonstration that we believe in guilt by association. We'd make Kevin the scapegoat, irrespective of the fact that his personal actions do not warrant such a removal.

If the CFRG wants to make a statement about the actions of the NSA, then it can certainly do exactly that, i.e., folks can craft text to that effect and then the group can see if it has consensus to publish that statement. (The IETF did make such a statement via the Vancouver plenary poll.)

> Listing them feels like an attempt to invoke an imaginary slippery slope as an excuse not to act.

You are arguing to remove Kevin based on his affiliation. I'm therefore guessing you have similar concerns about other current NSA employees. And possibly the other groups I listed above, since their financial relationship with the NSA could be argued to influence their participation. The slippery slope is not an excuse - where do you draw the line?

All that said, I fully understand people's anger at the action's of the NSA, and I do share it. I also understand the impulse to want to do something. But I don't consider punishing an individual contributor to the group for the actions of his employer an appropriate action. I also do not believe that the solution lies in preventing individuals from contributing solely based on their affiliation.

Lars

---

From: Watson Ladd <[email-masked]>
Date: Thu, 6 Feb 2014 09:00:44 -0800

> and then goes on to state even more caveats. That's about as clear as we can be.

Just because a document says this, doesn't mean it's actually true.
And when it comes to the CFRG, it largely isn't.
IETF working groups will follow suit if they see that some new
protocol is documented by the CFRG. That's the role
the CFRG exists to play: supporting IETF WGs when they have to
evaluate crypto. Furthermore, if we aren't actually
producing documents meant to say "This is X, and X is good" for some
definition of good, what are we doing here?

Sincerely,
Watson Ladd

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 6 Feb 2014 10:48:32 -0800

On Feb 6, 2014, at 9:00 AM, Watson Ladd <[email-masked]> wrote:

> protocol is documented by the CFRG.

Can you give examples of that? Having been active in many IETF WGs for 15+ years, I can't think of one, but I could have forgotten some.

> That's the role
> evaluate crypto.

Evaluating crypto is quite different than creating "some new protocol". The CFRG most often evaluates existing crypto protocols and modes, it doesn't create them.

> Furthermore, if we aren't actually

Lots of things:

- This is X, and while X is good, doing Y in X would be very bad

- This is X, and we have some shaky feelings about X, but we're totally fine with Z, which can be used in most of the same places

- Current IETF protocols use X, but X is now out of favor for these reasons; please strongly consider using Z

In the latter two cases, Z is not "some new protocol", they are existing ones that have been studied.

--Paul Hoffman

---

From: Watson Ladd <[email-masked]>
Date: Thu, 6 Feb 2014 11:10:24 -0800

> Can you give examples of that? Having been active in many IETF WGs for 15+ years, I can't think of one, but I could have forgotten some.

Dragonfly in TLS was the first time this happened. Had Rene Struik not
noticed that CFRG hadn't done anything, life would be interesting.
My understanding was that CFRG existed so that IETF WGs without
cryptographers could borrow some temporarily from us. That's what the
HTTP
auth people are doing, and what TLS did with Dragonfly.

> Evaluating crypto is quite different than creating "some new protocol". The CFRG most often evaluates existing crypto protocols and modes, it doesn't create them.

I think we're saying the same thing: IETF WG wants a protocol that
does blah. They look around and see the proposals blah1, blah2 etc.
exist.
Then one of them gets picked. Whether this is defining a new protocol
or evaluating the existing blah1, blah2, etc. is I think more semantic
than anything else. A useful evaluation results in changes to address
found deficiencies, or a statement that there are none and will be
none. The easiest time to replace a broken mechanism is when it is
being designed, before it is deployed. If we are playing catchup to
deployment, the only thing we can say is "we're doomed" when we find a
problem.

There is also the everpresent turning the paper into a spec. This is
fairly routine for most protocols, but the details matter, and can
completely change what actually is going on. SSL v3 looked like it was
using CBC mode, but because they decided to use chained IV's, actually
were doing something completely different.

> In the latter two cases, Z is not "some new protocol", they are existing ones that have been studied.

Are any of the CFRG WG drafts/IRTF publications actually of this form?
I really don't know: from my review of the mailing list
the CFRG did very little up until last year or so. I agree these are
also documents that require production, especially when some ancient
protocol hasn't been studied because it isn't as attractive a target
as TLS. We need some sort of idea how to do this kind of review
systematically.
I've tried by reviewing all cfrg drafts, but there are some emails I'm
behind on, and there is no way I can do all 7 thousand RFCs in a
reasonable amount of time.

Sincerely,
Watson Ladd

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 6 Feb 2014 11:29:12 -0800

On Feb 6, 2014, at 11:10 AM, Watson Ladd <[email-masked]> wrote:

> Dragonfly in TLS was the first time this happened.

Sorry, but that is wrong. Dan Harkins brought it to the TLS WG long before it was considered by the CFRG.

> Had Rene Struik not

Life is always interesting. :-)

> cryptographers could borrow some temporarily from us.

I hope Lars' repeated messages about that have disabused you of that notion. There are lots of cryptographers in the TLS WG, the IPsecME WG, the defunct S/MIME and OpenPGP WGs, and so on.

> That's what the

It is incorrect to state that the httpauth WG and the TLS WG have no cryptographers.

A different view, one that we rely on in the IPsecME WG, is that any time we're doing something "interesting" with crypto, we alert the CFRG. Almost all the time, we don't hear anything back, so we assume that we can continue.

> deployment, the only thing we can say is "we're doomed" when we find a

Fully agree. But I fear you place too much emphasis on IETF WGs for that. In the case of Dragonfly, the work was initiated *outside the IETF*, and only brought in later when it seemed we might align with other SDOs.

> were doing something completely different.

Yes, that. The CFRG used to be much more active in those evaluations. I would love to see it get re-energized on that. If nothing else, there are enough crypto professors here who could say to one of their indentured servants^W^Wgrad students, "take a look at this new proposal; finding something wrong with it is the correct answer".

> Are any of the CFRG WG drafts/IRTF publications actually of this form?

Many of the encryption mode documents and advice given to WGs are exactly of that form. Your current "new curves; warnings attached" document seems to be.

> reasonable amount of time.

Consider cloning....

--Paul Hoffman

---

From: David McGrew <[email-masked]>
Date: Thu, 06 Feb 2014 15:40:10 -0500

> Can you give examples of that? Having been active in many IETF WGs for 15+ years, I can't think of one, but I could have forgotten some.

Well, AEAD was adopted by TLS following the AEAD RFC that was 
extensively reviewed in CFRG, and it has been adopted by some other IETF 
protocols as well.

David

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 7 Feb 2014 00:31:10 -0800 (PST)

On Thu, February 6, 2014 11:10 am, Watson Ladd wrote:
>> Can you give examples of that? Having been active in many IETF WGs for
>> 15+ years, I can't think of one, but I could have forgotten some.
>

  I don't want to perpetuate this unfortunate thread but I would like
to correct the record. I came up with the dragonfly exchange quite
a long time ago and have been promoting its use in different
protocols-- EAP, IKE, 802.11, TLS. All that activity precedes the
CFRG draft.

  Rene's review of the CFRG draft was, as he notes in the title of his email,
"triggered by" the TLS-pwd last call. Note that the hullabaloo over
TLS-pwd was triggered by Trevor Perrin's realization (after 2 years)
that TLS-pwd existed and his subsequent incorporation of dragonfly
into a conspiracy theory involving the NSA. So actually, had Trevor
paid as little attention to the TLS WG that week as he did the previous
2 years, things would've been less "interesting" (to use your word).

  Basically, the timeframe and the process you're suggesting is a
little off.

  Also, note your "understanding was that CFRG existed so that IETF
WGs without cryptographers could borrow some temporarily" is
without basis. The WG that produced IPsec and IKE had such notable
cryptographers as Krawczyk, Canetti, Orman, and Bellovin, as active
participants (and I commit a sin of omission here by failing to mention
others, my apologies). Other working groups have similar participation
by very well-respected experts.

  Now, you may have issues with IPsec, IKE, TLS, or whatever but
please realize that is most likely the result of the sausage making
function of a standards process. I have lots of problems with IKE but
none of them were the result of the brilliant cryptographers that
helped produce it, they were the result of engineering shortcuts,
compromise among differing viewpoints in order to achieve
consensus (some of which appear in hindsight quite ridiculous),
haste to get the standards out there, and a failure to specify the
protocol properly.

  The rubber hits the road in an IETF WG. If you want to make sure
that a particular IETF protocol is done right than engage there.
The CFRG should be, in my opinion, a bridge between theory and
practice.

  regards,

  Dan.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 7 Feb 2014 07:59:55 -0800

> protocols-- EAP, IKE, 802.11, TLS. All that activity precedes the

I stand corrected.

> The CFRG should be, in my opinion, a bridge between theory and

How does the bridge between theory and practice help the rubber hit
the road? I can't possibly ensure every protocol is done right: at
some point people need to learn how crypto works, or not do crypto. In
your view CFRG only comes in for standardizing something that the WGs
admit they can't understand. Of course, 90% of IETF (maybe all IETF)
protocols don't use advanced crypto. No one is suggesting a fully
homomorphic traitor tracing oblivious transfer protocol for use
between computationally restricted nodes. Most protocols need to
authenticate information to everyone (use a signature), authenticate
two parties to each other (hundreds of good solutions, hundreds of bad
solutions), and encrypt and authenticate information flowing between
parties (use CBC+HMAC, or GCM, or ...). We don't really have that much
to do in that view, other than post-quantum stuff.

But let's go into detail about how well the cryptographers did in TLS.

In 1995 Phil Rogaway tells everyone to use encrypt-then-MAC. Also in
1995 RC4 is broken by the exhibition of several two-byte biases by
Flueuer and a coauthor. In 2004 Gregory Bard describes BEAST.

As we should all be aware, it's not until 2013 that these problems
start getting addressed, and it is unlikely that we will fully fix
them for a decade. What exactly was so important to the sausage making
process that letting attackers steal millions of credit card numbers
wasn't as big a priority?

I don't think the TLS WG is uniquely bad in this regard. IPSEC has had
its share of missteps, which I'm not that familiar with. I'm sure
plenty of protocols are sitting out there, vulnerable because
researchers just haven't looked.

What do we do to address this problem?

Sincerely,
Watson Ladd

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 07 Feb 2014 17:11:50 +0100

On 02/07/2014 04:59 PM, Watson Ladd wrote:

> In 1995 Phil Rogaway tells everyone to use encrypt-then-MAC.

I believe you are oversimplifying things. Indeed Rogaway suggested
encrypt-then-MAC, but other cryptographers were suggesting
MAC-then-Encrypt (authenticate what is meant not what is sent). There
was also no attack known for MAC-then-encrypt.

In general it is very easy to see the obvious solution 20 years later,
but the challenge is to properly decide at the right time.

regards,
Nikos

---

From: Watson Ladd <[email-masked]>
Date: Fri, 7 Feb 2014 08:28:41 -0800

> was also no attack known for MAC-then-encrypt.

Show me one cryptographer who recommended MAC-then-Encrypt.
Also, absence of known attacks is not the same as absence of attacks.
Encrypt-then-MAC was the conservative choice.

> but the challenge is to properly decide at the right time.

It was obvious then: encrypt-then-MAC was known secure, while
MAC-then-encrypt was not.
Any excuse vanishes with Bellare-Nampare (2000). Of course, even if we
take the best interpretation, the TLS WG frittered away 9 years after
being informed of an attack.

Sincerely,
Watson Ladd

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Fri, 7 Feb 2014 11:39:51 -0500

Don Johnson, for one. Carl Meyer. (Yes, those guys who invented Lucifer and DES ciphers.)

You keep forgetting (or simply aren't old enough to be aware?) of how things were done back when the "Cryptography: The New Dimension" book was published.

The standard was "MAC, then Encrypt", and it had reasons for doing things in that order. In fact, SNMP was the first IETF protocol (circa 1992-1994) to diverge from that approach, and it took some flak for not doing what was the conventional wisdom of that day.

Since then the priorities and the attacks changed, and now "Encrypt-then-MAC" is the standard.

Watson, I'd like to join other suggesting that you become less combative here. I'm not a "peacenik" myself, but any patience has a limit.

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street                        Email: <[email-masked]>
Lexington, MA  02420-9185       

Web:  http://www.ll.mit.edu/CST/

MIT LL Root CA: 

 <https://www.ll.mit.edu/labcertificateauthority.html>

DSN:   478-5980 ask Lincoln ext.1638

----- Original Message -----
From: Watson Ladd [mailto:[email-masked]]
Sent: Friday, February 07, 2014 11:28 AM
To: Nikos Mavrogiannopoulos <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Cfrg] NSA sabotaging crypto standards

Sincerely,
Watson Ladd

---

From: Watson Ladd <[email-masked]>
Date: Fri, 7 Feb 2014 09:10:13 -0800

> The standard was "MAC, then Encrypt", and it had reasons for doing things in that order. In fact, SNMP was the first IETF protocol (circa 1992-1994) to diverge from that approach, and it took some…

Was that flack informed? Or was it coming from people who didn't
really understand the mathematics behind crypto? Were those reasons
informed? Just because everyone was making the same mistakes doesn't
make those mistakes less serious. Even if we make Bellare-Nampare the
point at which no one should have done MAC then Encrypt, that was 13
years ago. Bard explained BEAST 9 years before the demonstration.

The best you can say is that the TLS WG was woefully slow in
responding to the changing situation.

> Watson, I'd like to join other suggesting that you become less combative here. I'm not a "peacenik" myself, but any patience has a limit.

What should the CFRG and the IETF do more broadly to ensure that
blunders as serious as the ones above don't happen again? What has the
CFRG done to ensure that other 90's era protocols have these problems
addressed, particularly when the WGs responsible have disbanded?
Should we simply let sleeping dogs lie, and work on ensuring that new
protocols don't make similar mistakes?
I'm here to fix the problems: explain what I need to do to fix them,
and I'll do it.

Sincerely,
Watson

---

From: David McGrew <[email-masked]>
Date: Fri, 07 Feb 2014 14:04:13 -0500

Hi All,

it is healthy to have a discussion on what CFRG and IETF can do 
differently to improve security and privacy in the Internet.

Ultimately, we are not limited by the current CFRG charter, but rather 
by our collective willingness to do the work that needs to be done, and 
I suppose on our ability to develop enough rough consensus about what 
needs to be done.   We do have a charter that we need to stick to at 
present, but we can do more within that charter, and we can consider 
changes to the charter if we think those are needed.   (Though note that 
we would need to get those changes approved.)

An approach that might work for us is to develop replacement mechanisms 
for the ones in current use that we think need to be replaced, keeping 
in mind that the actual replacement might take ten years or so, or might 
never happen.   At the same time, we can document the problems with 
existing mechanisms, to help provide a motivation for that replacement.

It is worthwhile to keep in mind the interoperability problems that can 
be caused by changes in cryptography, and the inertia created by all of 
those millions of crypto implementations that are currently in use.   We 
can't expect new crypto to appear in a five year old piece of software 
that is no longer supported by its creator, for instance, and that will 
slow down adoption of newer crypto, no matter how much better it is.   
As a practical matter, we also need to realize that many users of 
cryptography believe that there is no economic justification for 
deploying new crypto until breaking the old crypto scheme is so easy 
that a script kiddie can do it with a backtrack CD-ROM.   The burden is 
on us to provide this justification.

At the same time, I share the frustration that too much bad cryptography 
is in use, which should have been replaced long ago. The fact that it 
might take years to replace is no excuse not to start the process now.   
I'm thinking of RADIUS and other protocols that are used with 
human-generated passwords (and are not PAKE systems) in particular.   It 
would be *great* to have CFRG document what protocols are bad, and how 
bad they are, in a way that we could demonstrate expert consensus on our 
opinions. If we did a decent job, I bet we could get a slot in front of 
the IESG or some other responsible IETF group.   I am confident that, if 
we can offer IETF good information about the security of current 
standards, they will find a way to propagate and use that information.

An aside: a history of crypto protocols at IETF might provide some 
useful perspective; maybe a couple of people who were involved would be 
willing to write up something?    It might be useful to focus on one 
case study where things were done wrong, and one where things were done 
right.

David

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 07 Feb 2014 14:28:57 -0500

> existing mechanisms, to help provide a motivation for that replacement.

beyond figuring out how to deprecate currently-bad crypto, i think it
would also be a worthwhile exercise to think about how to design
*deprecatable* crypto mechanisms and protocols.

Our current state-of-the-art for cryptographic agility is that we build
ways for systems to tack on newer and better features.  The trouble is
that we don't have a way to systematically deprecate older/known-bad
features.

I don't know if this specifically in-scope for the CFRG, but i would be
very happy to see some best-practices advice that suggests a way to
ensure that the cryptographic mechanisms we deploy have a clear way to
deprecate them when known attacks and vulnerabilities surface.

One way of thinking about this is the idea of revocation, but algorithm
revocation instead of certificate revocation.  This is troubling,
though, because we are currently terrible at certificate revocation :(

Another approach could be to design cryptographic software with built-in
expiration dates for *every* algorithm.  The software could check the
current date, and would know when a given algorithm was due to expire,
and warn the user that their communications security is in doubt if they
are using an expired algorithm (or refuse to use the expired algorithm).
 Software updates could either (a) deploy new algorithms with later
expiration dates, or (b) indicate that we have more confidence in an
existing algorithm, thereby extending its current expiration date.

Having this built in from the beginning means that we would at least
have a time-limited window to re-validate algorithms, and service
operators could remove expired mechanisms with confidence.  It would
also mean that devices need to be able to update their software, or
their algorithm definitions and expiration dates as well (it would not
work for clockless or non-networked devices or devices without any way
to signal to the user that the algorithm is expired).

Anyone interested in discussing sane and safe ways to pro-actively plan
for secure and sane algorithm or protocol deprecation?  Can we deem this
in-scope for the CFRG, or are there other places where the discussion
might be better placed?

> standards, they will find a way to propagate and use that information.

I also think formally and explicitly deprecating known-bad approaches is
good.  RFC 6176 is an excellent and useful document.  However, i remain
surprised that we haven't made such a statement about cleartext(!) -- if
we believe that pervasive surveillance is an attack on the internet, a
strong and explicit RFC stating cleartext communication on the 'net is a
Bad Thing could be comparably useful.

	--dkg

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Fri, 7 Feb 2014 14:48:58 -0500

1. Yes, those objections were informed - and based on the best data we *all* had *back then*. (I personally discussed it with Don Johnson, and Don Coppersmith, which was easy as we worked in the same building. There is *a lot* to say on the subject, but it does not matter now.)
This is the blessing of and the problem with the hindsight. We did Encrypt-then-MAC mostly for performance reasons, and hoped there were no unforeseen negative security implications. A decade later it turned out that our approach was preferable from security point of view, and now (2+ decades later) people are criticized for not embracing our method... But for sure I can't call my colleagues of that time "mistaken".

Who knows what we'll learn in the next ten years?

2. "Blunder" is a strong word. I cannot call what happened in those WG a "blunder" (much unlike the [in]famous WEP).

What should be done? A good question. Theoretically, impacted standards and implementations should be re-done to address the problems we know about now. Practically, considering the inertia of the industry and the leg irons of backwards compatibility? With the money considerations (cost of the changes vs expected revenue from them) thrown in this mix?  Off-hand, I don't know.

On one hand, IETF needs a (better) ability to deprecate algorithms and protocols (as Dave McGrew just said). On the other hand, there is no enforcement arm, and if (for the sake of the argument) Microsoft decides to keep a deprecated protocol alive, you and I can criticize it all we want, but it won't take it off the 90% of the world's desktops and who knows what percentage of the servers that must communicate with those desktops. 

3. Regarding the new protocols? It should be simpler, as they rarely carry the burden of compatibility with something we may or may not like. IETF is trying to steer things away from bad by making statements like "No new protocol shall use MD5" (back then, or SHA-1, in later days). 

IMHO, one way to improve things is getting out IESG statements like "Construct X was shown to be vulnerable to A, B, and C - and must not be used in any new protocol", and "Construct Y was shown to be strong/good for D, E, and F - and new protocols doing those should employ Y"... Security AD  would be a reasonable source of such statements. It is up to the individual members to create, analyze/debug/vet such statements, and submit them for AD's consideration. If such a statement were coming from CFRG rather than a single individual, it would be even better.

Describing attacks against proposed protocols, together with recommended fixes, would also help. The more practical and specific the attacks are - the likelier it is that the WG would listen (and vs versa). Availability and usability of the fixes is a factor too...

One caveat: security proofs is a tricky field. I remember having fun reading proofs and "dis-proofs" on MQV/HMQV/FHMQV. It is far from, e.g., proofs in geometry or algebra that we're so used to rely upon. :-). So I personally tale security proofs with a good grain of salt, and try to look at the assumptions much more closely than at the actual proofs.

Also, implementers positively hate designs/protocols encumbered by IPR. They would much rather take a chance of a weird attack than of a potential litigation. If a good protocol is patented - it won't be touched with a 10-foot pole (e.g., think EKE), no matter how great security proofs or performance advantages it has. 

GPL license is great (when available :), but it doesn't cover all the needs of the industry...

I better stop here before I lose too much of coherence. :-)

Would be happy to answer specific questions, or discuss specific steps.

TNX!

MIT LL Root CA: 

----- Original Message -----
From: Watson Ladd [mailto:[email-masked]]
Sent: Friday, February 07, 2014 12:10 PM
To: Blumenthal, Uri - 0558 - MITLL
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Cfrg] NSA sabotaging crypto standards

Sincerely,
Watson

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 07 Feb 2014 21:37:58 +0000

Hi David,

good discussion points.

Here are my views:

a) If we look at the problems at the entire Internet software lifecycle,
as I did in
http://tools.ietf.org/html/draft-tschofenig-perpass-surveillance-01,
then I believe it is fair to say that the problems at the level of
cryptographic primitives are the least challenging issues with Internet
security. That's good news.

The problems you mentioned with RADIUS have little to do with work that
would be done in the CFRG. RADIUS, similarly to Diameter, does not offer
end-to-end security and that's something that could be fixed in the IETF
(and there is work ongoing in the DIME working group for Diameter at
least). The main challenge, however, is the attitude problem of those
deploying the protocol.

b) I do, however, believe that the CFRG could play an interesting role.
I am curious whether it would be possible to move some of the tasks that
are currently done in NIST to the IRTF, namely the cryptographic
algorithm selections. I know that this is a job that is today not done
by the IETF/IRTF but I believe it could be done since the ingredients are:
* open and transparent process for publishing, commenting, and selecting
an algorithm
* a suitable way for publishing these documents.

Doing this work in a global standards organization also gives it more
credibility. I am also confident that the IETF/IRTF community could
reach out to researchers working on hash algorithms, encryption
algorithms, etc.

Just a thought...

Ciao
Hannes

On 02/07/2014 07:04 PM, David McGrew wrote:
>>> You keep forgetting (or simply aren't old enough to be aware?) of how
>>> things were done back when the "Cryptography: The New Dimension" book
>>> was published.
>>>
>>> The standard was "MAC, then Encrypt", and it had reasons for doing
>>> things in that order. In fact, SNMP was the first IETF protocol
>>> (circa 1992-1994) to diverge from that approach, and it took some
>>> flak for not doing what was the conventional wisdom of that day.
>>> Watson, I'd like to join other suggesting that you become less
>>> combative here. I'm not a "peacenik" myself, but any patience has a
>>> limit.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 10 Feb 2014 15:15:57 +0000

On 07/02/14 19:28, Daniel Kahn Gillmor wrote:
<snip>
> existing algorithm, thereby extending its current expiration date.

No-longer-deemed-secure algorithms aren't the only security problems 
facing out-of-date cryptographic software.  So why not go one step 
further and make the cryptographic software itself expire?

(Yes, IE6, I'm looking at you!)

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: David McGrew <[email-masked]>
Date: Mon, 10 Feb 2014 14:18:21 -0500

HI Hannes,

> security. That's good news.

thanks for chiming in, I think you are right regarding primitives; let 
me note that weak protocols and insecure deployment practices are 
perfectly in scope for CFRG  as well as primitives.   But the other 
major category of weakness, widespread exploitable vulnerabilities in 
software implementations, is one that is hugely important, and which is 
out of scope for CFRG.   The problem of exploitable vulnerabilities 
doesn't get the air-time that it deserves, relative to the other 
issues.   An exploit could force its victim to do all sorts of bad 
cryptographic practices, such as leak a key in an IV, or use a fixed or 
low-entropy key.

> least). The main challenge, however, is the attitude problem of those

I agree about the attitude, but I don't agree that CFRG couldn't 
help.    Surely we don't need new crypto mechanisms to solve the 
problems with RADIUS, but analyzing and documenting security issues and 
helping to socialize them with the IETF and the user base are all in 
charter and are worth doing.

> reach out to researchers working on hash algorithms, encryption

Agree that IETF is and should be willing to act as an international 
standards body for crypto, and that CFRG could support that process.   
We need to be careful not to over-commit in this area, but if the IETF 
wanted CFRG to vet some crypto standards options, we should be able to 
do that.

David

---

From: Rene Struik <[email-masked]>
Date: Mon, 10 Feb 2014 15:05:04 -0500

Hi Hannes:

Historically, not that many CFRG/IETF people seem to have participated 
in solicitations for public review of NIST draft publications. I wonder, 
therefore, what makes you feel this would change dramatically, should 
CFRG/IETF take on an effort as complement or partially duplicated effort 
of what NIST has already done.

Note - data suggests this has been pretty consistent over time, both for 
the last solicited draft crypto recommendation review and for those in 
the last few years.

Best regards, Rene

==
[excerpt of email Hannes Tschofenig, February 7,2014, 4:37pm EST]

On 2/10/2014 2:18 PM, David McGrew wrote:
> software implementations, is one that is hugely important, and which 
> is out of scope for CFRG.   The problem of exploitable vulnerabilities 
> cryptographic practices, such as leak a key in an IV, or use a fixed 
> or low-entropy key.
>
>>
> problems with RADIUS, but analyzing and documenting security issues 
> and helping to socialize them with the IETF and the user base are all 
> in charter and are worth doing.
>
>>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Feb 2014 20:59:16 +0000

I think adding energy and appropriate tasking to CFRG is a fine
idea, but this bit is a bit of a potential rathole...

On 02/10/2014 07:18 PM, David McGrew wrote:
> Surely we don't need new crypto mechanisms to solve the problems with
> RADIUS, but analyzing and documenting security issues and helping to
> socialize them with the IETF and the user base are all in charter and
> are worth doing.

I'm not clear on this. I don't think there are non-obvious
crypto issues with RADIUS or Diameter that CFRG can tackle
to be honest. Or maybe I'm not missing something?

I don't think CFRG should be collectively "documenting security
issues" generally, if those that are not cryptographic. Reason
being that that'd likely generate more heat than light and would
overlap with secdir and IETF WGs too much probably.

I could maybe see re-chartering to include theorem-prover style
analyses or results in CFRG's charter, but I interpret the above
differently.

If some CFRG folk are interested in e.g. RADIUS security,
then they are just as free as anyone to send mail to the
DIME list.

Cheers,
S.

---

From: [email-masked]
Date: Tue, 11 Feb 2014 00:09:02 -0500

> further and make the cryptographic software itself expire?

Might I extend this to crypto-in-hardware-in-embedded-systems?

In other words, absolutely all embedded systems must either have a
remote upgrade capability or a not-to-exceed pre-defined lifetime.

Both options are ugly.

--dan

---

From: Watson Ladd <[email-masked]>
Date: Mon, 10 Feb 2014 21:47:53 -0800

> remote upgrade capability or a not-to-exceed pre-defined lifetime.

There is an assumption being made here: that algorithms will age
badly. This assumption is largely unwarranted.
First off, software does not decay. It does not develop security
problems spontaneously. Protocols with reductions remain
secure so long as the fundamental problems they reduce to remain hard.

The reasons why a piece of hardware made in 1996 would, 17 years
later, be no longer secure if properly designed in the first place,
would
likely be the hash function. IDEA remains secure, even with the small
block causing fun at 4 GB. Blowfish is unlikely to have been done in
hardware. Triple DES would be fine today, but single DES would have
been on the way out due to the small 2^56 key size.

Public key would likely be RSA. The big advances in algorithms were
all known at that point, so one just has to play the Moore's law game.
For ECC the security situation looks the same, and for Diffie-Hellman
over prime fields, I don't recall.

The hash function would have died: it would have been MD5. With any
luck they would have used signature schemes that avoid falling to
simple collisions, but that's unlikely for RSA.

The big problem is that the standards were and are so terrible. SSL v3
made 3 mistakes: predictable IVs, a complex state machine, and
exposing a CBC padding oracle. PKCS 1.5 had lots wrong with it. For
this hardware to be useful, it wouldn't have made it to 2013 without
massive problems beyond the weak hash.

Sincerely,
Watson Ladd

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 11 Feb 2014 01:40:32 -0500

> badly. This assumption is largely unwarranted.

As the person who suggested "expiring" algorithms or protocols, i should
probably point out that this is *not* my underlying assumption.

My assumption was that we gain knowledge and experience, and in light of
the new knowledge and experience, *some* algorithms or protocols do not
hold up well (as you document clearly about hash functions and SSLv3).

In hindsight, we know which mechanisms didn't hold up; but during
deployment, that's not necessarily knowable.  Presumably we believe the
code we're deploying to be reasonably strong when we deploy it; and we
assume that it will hold up over time, but we don't know.

Introducing an "expiration" date is a mechanism for ensuring that the
software actively validates that assumption against some external source
at some point.  It's even possible that the source could say "carry on;
algorithm X should have its expiration date extended to June of 2020".

The alternative might be what we have today: a bunch of known-broken
algorithms, widely-deployed, with no clear termination date, so everyone
keeps on deploying them, because we keep expecting to need to
interoperate with these interminably-unsupportable known-bad
implementations.

If there are other ideas about how to avoid this problem besides
expiration or revocation, i'd love to hear some suggestions.  What we
have now doesn't seem to be working to get the 'net switched over to
known-good tools with any sort of plausible speed, even as known
weaknesses are present.

> Protocols with reductions remain

Even with a security reduction, it's possible that researchers discover
that the security model used with the reduction doesn't actually apply
in a real-world scenario where the algorithm was actually used; or that
the algorithm's resistance to online attack in a given instance (or with
given parameters) can be weakened with some sort of novel massive
pre-computation that we didn't expect to be feasible; or some other
break in the relationship between the model and reality that no one foresaw.

If there is consensus that any of these cryptanalysis failures happened,
having an expiration or a globalized check for revocation would provide
a way to disable a mechanism for a given use.

Regards,

	--dkg

---

From: David McGrew <[email-masked]>
Date: Tue, 11 Feb 2014 11:16:43 -0500

Hi Stephen,

> overlap with secdir and IETF WGs too much probably.

I was being too vague, sorry.  By "documenting security issues" I had in 
mind those cases in which some sort of cryptanalysis needs to be brought 
to bear in order to show that, yes, there is an actual attack that can 
be performed.   Sometimes some applied cryptanalysis needs to be done to 
make the point that some existing algorithm or parameter choice is no 
longer appropriate (or perhaps was never a good idea).    The 
standards-oriented people in CFRG could probably identify some 
low-hanging fruit that the cryptanalysis-oriented people would enjoy 
breaking.

Definitely we need to avoid the overlap that you mention.

David

> .

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Feb 2014 16:31:16 +0000

Hi David,

Thanks for the clarification. Makes sense now.

On 02/11/2014 04:16 PM, David McGrew wrote:
> The standards-oriented people in CFRG could probably identify some

I have one that might tempt someone. HTTPBIS are trying to
find a way to compress headers that's not vulnerable to
BEAST/CRIME like attacks. There's a thread at. [1]

Its not crypto exactly, but the same kinds of expertise
would be very useful.

Cheers,
S.

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0233.html

---

From: Tom Ritter <[email-masked]>
Date: Tue, 11 Feb 2014 19:57:36 -0500

If I look at where we are now (well, I look at the bad parts of it) -
and  I look back at how we could have avoided being in the bad shapes
we are, the following comes to mind.

Small-Key RSA has taken too long to deprecate. RSA512, RSA1024.
RSA1024 is going to be used in some applications (payment devices) for
the next several years.  What would accelerate their deprecation? I've
spoken to numerous folks, and while they're all quite familiar with
the GNFS, no one is willing to go record with estimates. Perhaps the
CRFG could estimate computation needs, and costs for factoring RSA
1024 and 2048, and reevaluate it every so often. There's a difference
bewteen "The NSA can pobably factor RSA1024" and "This group of
cryptographers think we can factor it if we have $2 Million".
(Especially if someone has $2M and wants to have a go at it.)

SSL Devices have caused extraordinary upgrade pains. 0-Byte Record
Sizes, Version Intolerance, Suite & Extension Intolerance. Rigorous
test cases for these may have prevented these.  At the very least, we
wouldn't _still_ be generally ignorant about what vendors and firmware
versions are intolerant. Public pressure could help get these resolved
sooner.

We _still_ don't have a general purpose, largely complete SSL
certificate deployment for testing certificate validation. And lord
knows we have enough incorrect certificate validators.

We focus on content confidentiality. Maybe we don't care about sender
or receiver anonymity. (I do, a lot of folks do, but maybe this group
doesn't.) But if we do, we could work on that.

Similarly, there are very few designs (one?) for mutually distrusting
centrally managed architectures. In Certificate Transparency, you have
N logs all run independently asserting their view of things. What if
you had N logs talking to each other and voting to assert one
consensus document?

How about remote attestation of servers so we can assert they are
running the software stack (and web application) they purport to be?

Just some thoughts.
-tom

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Wed, 12 Feb 2014 20:01:09 +0000

Watson et al:

> 
> There is an assumption being made here: that algorithms will age badly.
> This assumption is largely unwarranted.
> problems spontaneously. Protocols with reductions remain secure so long
> as the fundamental problems they reduce to remain hard.
> 

I'd disagree slightly in that Moore's law says that the computational cost
of an attack halves every 18 months.  If one assumes Moore's law will continue
to apply, eventually its rising tide will engulf any given choice of parameter 
sizes.  Certainly Moore's Law must eventually grind to a halt, but over the 
years I've lost good money by drawing a line in the sand that I bet Moore's 
law could never get past.

There are, of course, more pressing issues than worrying about Moore's law.

> Sent: Tuesday, February 11, 2014 12:48 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Cfrg] how can CFRG improve cryptography in the Internet?
> 
> >  > No-longer-deemed-secure algorithms aren't the only security
> > problems  > facing out-of-date cryptographic software.  So why not go
> > one step  > further and make the cryptographic software itself
> expire?
> >
> >
> There is an assumption being made here: that algorithms will age badly.
> This assumption is largely unwarranted.
> problems spontaneously. Protocols with reductions remain secure so long
> as the fundamental problems they reduce to remain hard.
> 
I'd disagree slightly in that Moore's law says that the computational cost
of an attack halves every 18 months.  If one assume Moore's law will continue
to apply, inevitably the rising tide will engulf any give choice of parameter
sizes.  Of course Moore's Law must eventually grind to a halt, but over the
years I've lost good money by drawing a line in the sand that I bet Moore's 
law could never get past. 

> The reasons why a piece of hardware made in 1996 would, 17 years later,
> be no longer secure if properly designed in the first place, would
> Public key would likely be RSA. The big advances in algorithms were all
> known at that point, so one just has to play the Moore's law game.
> made 3 mistakes: predictable IVs, a complex state machine, and exposing
> a CBC padding oracle. PKCS 1.5 had lots wrong with it. For this
> hardware to be useful, it wouldn't have made it to 2013 without massive
> problems beyond the weak hash.
> 
> Sincerely,
> Watson Ladd
> 
> --

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 12 Feb 2014 17:08:38 +0000

Hi David,

I believe it is important to move beyond writing specifications to
improving implementations and deployments. I think we both agree. I have
been arguing for this for a while now and got pretty much no positive
feedback. I also tried to convince the IAB that this would be somewhat
important and completely failed. The response I got was: "This would
require a completely different skill set." and "ISOC should do it."

I don't have a good story for how to do that even at the level of
individual work groups. I tried this in the OAuth working group and
couldn't really find a way how to reach out to the large number of guys
implementing OAuth libraries let alone those who deploy them.

The CFRG might, unfortunately, not be the right group either. To me it
seems that the folks in this group are focused on crypto (as the name of
the group indicates). What we need is guys who understand the broader
Internet ecosystem and know how to improve security libraries and to
reach out to the wider Internet (security) community. One does not need
to start from scratch since some of these communities exist but they
often have no connection to the IETF or the relationship is very weak.
As such, you often find a misalignment between the IETF security
community and various other groups.

My impression is that most IETF participants have not even recognized
the need to take any action yet. I have often heard that this is
"out-side-the-scope".

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 12 Feb 2014 17:11:05 +0000

Hi Rene,

my impression was that until recently many IETF participants just
trusted NIST to do the right thing. So, why would you care when things
are going fine anyway?

During the last few months that impression might have changed a bit and
there might be more energy to improve transparency and to explore new
directions.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 12 Feb 2014 17:35:14 +0000

Hi David,

there are really no crypto issues with RADIUS and Diameter.

The issue is that vendors don't implement the security protocols
mandated in our RFCs and, if they are implemented, operators don't turn
them on because they rely on "physical security".

On top of that we don't have a incomplete toolbox; there is no e2e
security solution standardized for RADIUS/Diameter.

The consequence is that highly sensitive transaction data flies around
in the clear or, if it is protected, then all intermediaries see it.

I organized a few Diameter interops several years ago and the biggest
problem we had was with security. Very few implementations implemented
TLS and it took us a day at each event to configure the certificates
since every implementation had their own management interface which
nobody knew how to use. Once we got past that point we found out that
none of the implementations were actually checking the certificates anyway.

A couple of years have passed since that time and I really hope that the
situation is better now. At least there is FreeDiameter...

Ciao
Hannes

---

From: David McGrew <[email-masked]>
Date: Wed, 12 Feb 2014 17:34:41 -0500

Hi Hannes,

> there are really no crypto issues with RADIUS and Diameter.

certainly that's true if RFC 6614 is used (TLS for RADIUS).   There are 
issues with the crypto defined in the original RFC 2865 RADIUS, on the 
other hand.  (Encryption is done using MD5 as a keystream generator, 
with a secret that may be vulnerable to a dictionary attack, with 
incomplete authentication.)

> in the clear or, if it is protected, then all intermediaries see it.

Agreed.   We don't need a new crypto design to solve these problems.   
Some applied cryptanalysis on the currently-fielded systems might 
motivate people to upgrade to the newer, mandated mechanisms - that's 
what I was hoping when I mentioned RADIUS, anyway.

> none of the implementations were actually checking the certificates anyway.

Not good :-(

David

---

From: Paul Lambert <[email-masked]>
Date: Wed, 12 Feb 2014 16:19:24 -0800

>there are really no crypto issues with RADIUS and Diameter.

??  Perhaps because they have no crypto.
The RADIUS/Diameter AAA architecture is flawed by the inclusion
of so many options that insecure deployments are common.

>them on because they rely on "physical security".

Yes.  Our guidelines here are poor.  TLS or IPsec are specified
and even when used typically leave gaps due to ³physical security"

>security solution standardized for RADIUS/Diameter.

Would this be a work item?

>none of the implementations were actually checking the certificates
Yes!  A fundamental problem - X.509 :-)

Al

---

From: Watson Ladd <[email-masked]>
Date: Wed, 12 Feb 2014 22:28:49 -0800

> require a completely different skill set." and "ISOC should do it."

Well, let's take TLS as an example. The two liberally licensed TLS
implementations are terrible in terms of code quality. PolarSSL is
better, but is GPL licensed and missing some essential security
features. The API for certificate validation in particular is quite
complex, and so certificates tend not to be validated.

I'll use this as a point to riff on the earlier issue of
vulnerabilities. So long as we write in C for the last epsilon of
performance we have a problem. Ada, Go, Java, Pascal, etc. are all
better because you cannot have the sort of memory issues that lead to
remote code execution. However, we know the solution and there are
very few interop issues with implementing it. Crypto is harder because
interop means innovation has to come all at once, and the standards
committees (especially ISO, but also IEC) are terrible. Look up
cryptanalysis of ISO standards sometime.

> implementing OAuth libraries let alone those who deploy them.

The idea is to put in the RFC everything needed to do the job right.
However, this is tricky.

> the need to take any action yet. I have often heard that this is

Incentives determine behaviour. So long as end-users give vendors a
pass on security, vendors will treat it as not a priority. It's also
unclear what the IETF can do here.

Sincerely,
Watson Ladd

---

From: Rene Struik <[email-masked]>
Date: Thu, 13 Feb 2014 13:21:00 -0500

To me, this seems to be an entirely new perspective on what it means to be an engineer or scientist :(((.

==
So, why would you care when things are going fine anyway?

---

From: Geoffrey Waters <[email-masked]>
Date: Thu, 13 Feb 2014 19:00:11 +0000

Certification/Qualification is an expensive process.  Engineers under schedule pressure will use whatever is qualified, and gets the job done.  

We need an entity with the knowledge, resources, and reputation to say 'this algorithm is good for this purpose'. 

We thought NIST was that entity.  They've damaged their reputation.  Anyone planning to implement an algorithm standardized by NIST which hasn't gone through an open and transparent competition?

If NIST doesn't run open and transparent competitions for future algorithms, the world will look to some other organization to do it.  If there isn't a single organization we all trust, algorithm selection will fragment along national lines.  CFRG/IRTF can tell NIST how to earn back its reputation, CFRG/IRTF can step into the vacuum created by an untrustworthy NIST, or CRFG/IRTF can start cultivating NIST's replacement as the internationally recognized and trusted 'certifier' of crypto algorithms.

-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of Rene Struik
Sent: Thursday, February 13, 2014 12:21 PM
To: Hannes Tschofenig; David McGrew
Cc: [email-masked]
Subject: Re: [Cfrg] how can CFRG improve cryptography in the Internet?

==

On 2/12/2014 12:11 PM, Hannes Tschofenig wrote:
> During the last few months that impression might have changed a bit 
> and there might be more energy to improve transparency and to explore 
> new directions.
>
> Ciao
> Hannes
>
>> Historically, not that many CFRG/IETF people seem to have 
>> participated in solicitations for public review of NIST draft 
>> publications. I wonder, therefore, what makes you feel this would 
>> change dramatically, should CFRG/IETF take on an effort as complement 
>> or partially duplicated effort of what NIST has already done.
>>
>> Note - data suggests this has been pretty consistent over time, both 
>> for the last solicited draft crypto recommendation review and for 
>> those in the last few years.
>>
>> Best regards, Rene
>>
>> ==
>> I am curious whether it would be possible to move some of the tasks 
>> that are currently done in NIST to the IRTF, namely the cryptographic 
>> algorithm selections. I know that this is a job that is today not 
>> done by the IETF/IRTF but I believe it could be done since the ingredients are:
>> * open and transparent process for publishing, commenting, and 
>> selecting an algorithm
>>>> a) If we look at the problems at the entire Internet software 
>>>> lifecycle, as I did in 
>>>> http://tools.ietf.org/html/draft-tschofenig-perpass-surveillance-01
>>>> , then I believe it is fair to say that the problems at the level 
>>>> of cryptographic primitives are the least challenging issues with 
>>>> Internet security. That's good news.
>>> thanks for chiming in, I think you are right regarding primitives; 
>>> let me note that weak protocols and insecure deployment practices are
>>> major category of weakness, widespread exploitable vulnerabilities 
>>> in software implementations, is one that is hugely important, and which
>>>> The problems you mentioned with RADIUS have little to do with work 
>>>> that would be done in the CFRG. RADIUS, similarly to Diameter, does 
>>>> not offer end-to-end security and that's something that could be 
>>>> fixed in the IETF (and there is work ongoing in the DIME working 
>>>> group for Diameter at least). The main challenge, however, is the 
>>>> attitude problem of those deploying the protocol.
>>> and helping to socialize them with the IETF and the user base are 
>>> all in charter and are worth doing.
>>>
>>>> I am curious whether it would be possible to move some of the tasks 
>>>> that are currently done in NIST to the IRTF, namely the 
>>>> cryptographic algorithm selections. I know that this is a job that 
>>>> is today not done by the IETF/IRTF but I believe it could be done 
>>>> since the ingredients
>>>> are:
>>>> * open and transparent process for publishing, commenting, and 
>>>> selecting an algorithm
>>>> Doing this work in a global standards organization also gives it 
>>>> more credibility. I am also confident that the IETF/IRTF community 
>>>> could reach out to researchers working on hash algorithms, 
>>>> encryption algorithms, etc.
>>>>
>>>> Just a thought...
>>> We need to be careful not to over-commit in this area, but if the 
>>> IETF wanted CFRG to vet some crypto standards options, we should be 
>>> able to do that.
>>>
>>> David
>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>>
>>>>> Ultimately, we are not limited by the current CFRG charter, but 
>>>>> rather by our collective willingness to do the work that needs to 
>>>>> be done, and I suppose on our ability to develop enough rough consensus about what
>>>>> An approach that might work for us is to develop replacement 
>>>>> mechanisms for the ones in current use that we think need to be 
>>>>> replaced, keeping in mind that the actual replacement might take 
>>>>> ten years or so, or might
>>>>> It is worthwhile to keep in mind the interoperability problems 
>>>>> that can be caused by changes in cryptography, and the inertia 
>>>>> created by all of those millions of crypto implementations that are currently in
>>>>> use.   We
>>>>> can't expect new crypto to appear in a five year old piece of 
>>>>> software that is no longer supported by its creator, for instance, 
>>>>> and that will slow down adoption of newer crypto, no matter how much better it is.
>>>>> At the same time, I share the frustration that too much bad 
>>>>> cryptography is in use, which should have been replaced long ago. 
>>>>> The fact that it might take years to replace is no excuse not to 
>>>>> start the process now.
>>>>> would be *great* to have CFRG document what protocols are bad, and 
>>>>> how bad they are, in a way that we could demonstrate expert 
>>>>> consensus on our opinions. If we did a decent job, I bet we could 
>>>>> get a slot in front of
>>>>> case study where things were done wrong, and one where things were 
>>>>> done right.
>>>>>
>>>>> David
>>>>>
>>>>>>> You keep forgetting (or simply aren't old enough to be aware?) 
>>>>>>> of how things were done back when the "Cryptography: The New 
>>>>>>> Dimension" book was published.
>>>>>>>
>>>>>>> The standard was "MAC, then Encrypt", and it had reasons for 
>>>>>>> doing things in that order. In fact, SNMP was the first IETF 
>>>>>>> protocol (circa 1992-1994) to diverge from that approach, and it 
>>>>>>> took some flak for not doing what was the conventional wisdom of that day.
>>>>>> really understand the mathematics behind crypto? Were those 
>>>>>> reasons informed? Just because everyone was making the same 
>>>>>> mistakes doesn't make those mistakes less serious. Even if we 
>>>>>> make Bellare-Nampare the point at which no one should have done 
>>>>>> MAC then Encrypt, that was 13 years ago. Bard explained BEAST 9 years before the demonstration.
>>>>>>
>>>>>>> combative here. I'm not a "peacenik" myself, but any patience 
>>>>>>> has a limit.
>>>>>> blunders as serious as the ones above don't happen again? What 
>>>>>> has the CFRG done to ensure that other 90's era protocols have 
>>>>>> these problems addressed, particularly when the WGs responsible have disbanded?
>>>>>> Should we simply let sleeping dogs lie, and work on ensuring that 
>>>>>> new protocols don't make similar mistakes?
>>>>>> I'm here to fix the problems: explain what I need to do to fix 
>>>>>> them, and I'll do it.
>>>>>>
>>>>>> Sincerely,
>>>>>> Watson
>>>>>>> --
>>>>>>> Regards,
>>>>>>>> I believe you are oversimplifying things. Indeed Rogaway 
>>>>>>>> suggested encrypt-then-MAC, but other cryptographers were 
>>>>>>>> suggesting MAC-then-Encrypt (authenticate what is meant not what is sent).
>>>>>>>> There
>>>>>>>> In general it is very easy to see the obvious solution 20 years 
>>>>>>>> later, but the challenge is to properly decide at the right 
>>>>>>>> time.
>>>>>>> Any excuse vanishes with Bellare-Nampare (2000). Of course, even 
>>>>>>> if we take the best interpretation, the TLS WG frittered away 9 
>>>>>>> years after being informed of an attack.
>>>>>>>
>>>>>>> Sincerely,
>>>>>>> Watson Ladd
>>>>>>>> regards,
>>>>>>>> Nikos
>>>>>>>>

---

From: S Moonesamy <[email-masked]>
Date: Mon, 17 Feb 2014 11:25:18 -0800

Hi Hannes,
>community and various other groups.

The above is also valid for other IETF technologies, i.e. there is a 
void between writing specifications and the implementation or 
deployment side.  I would not try to convince the IETF or the IAB to 
do anything about that. :-)

>the need to take any action yet. I have often heard that this is

Yes.

Regards,
S. Moonesamy

---

From: David McGrew <[email-masked]>
Date: Mon, 17 Feb 2014 17:51:39 -0500

Hi Hannes,

> community and various other groups.

I think I know what you mean.   My own thinking in this space is that it 
would be healthy to develop stronger connections with the open source 
community.   For instance, if CFRG were to recommend a particular crypto 
mechanism, and then it turns out that the linux community rejects that 
mechanism (due to patents, performance, code size, complexity, API 
incompatibility, whatever), then there is probably something that we 
need to learn.   Better connections with the open source world could 
address some of that misalignment you mention, I think, though of course 
it is no panacea.

David