Subject: [saag] possible BCP on public review being needed for standards-track crypto

From: Stephen Farrell <[email-masked]>
Date: Wed, 23 Mar 2016 13:45:10 +0000

Hiya,

Rich Salz has put together an initial stab at a draft of a BCP [1]
that says "for IETF standards track, crypto algorithms need to
have had public analysis." (Thanks Rich!)

I think this'd be a good thing to progress but as you'll see the
-00 submitted just at the cutoff needs a good bit of work. (Still
great to have a starting point though, so thanks again Rich:-)

So, please read and comment on [email-masked]. As well as getting
detailed comments, I'd also be interested in whether or not
folks think the basic premise is something it'd be good to have
as a BCP, so thumbs-up/down messages are also useful at this
point. (If "thumbs-down" please say why, if "thumbs-up" then
later detailed wrangling over text will be fine.)

We'll have a short 5-min slot for this in the saag session in B-A
just to bring it to folks' attention.  If there are issues that
we don't resolve on the list (e.g. I'd expect that getting a good
enough description of "public review" might be tricky) we can have
a more extended discussion about this at saag in Berlin.

Cheers,
S.

[1] https://tools.ietf.org/html/draft-rsalz-drbg-speck-wap-wep

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 23 Mar 2016 17:26:52 +0000

For those playing along at home, my draft is maintained here: https://github.com/richsalz/draft-rsalz-dbrg-speck-wap-wep and it's had some changes since the cut-off deadline.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 23 Mar 2016 21:09:42 +0200

So here are two possibly controversial comments (based on reading the 
GitHub version of the draft).

- I think we need to say explicitly that publication as an RFC alone 
"does not count". The reason is, as far as I know most cryptographers do 
not review algorithms just because they were published as an 
informational RFC.

- On the other hand, like it or not, NIST is still the leading reference 
for crypto algorithms. Yes, DUAL_EC_DRBG is a terrible example, but NIST 
is also the source of GCM and many other crypto mechanisms that are 
central to our work. As a result, mechanisms published by NIST are 
scrutinized heavily by the crypto community.

And by the way, the title of this thread is misleading, in that it is 
much stronger than (the current version of) the draft.

Thanks,
	Yaron

On 03/23/2016 07:26 PM, Salz, Rich wrote:
> For those playing along at home, my draft is maintained here:
> https://github.com/richsalz/draft-rsalz-dbrg-speck-wap-wep and it's
> had some changes since the cut-off deadline.
>
> -- Senior Architect, Akamai Technologies IM: [email-masked]
> Twitter: RichSalz
>
> _______________________________________________ saag mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/saag
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 Mar 2016 22:02:05 +0100

Hi Stephen,

the document Rich wrote says that "RFCs cannot specify an algorithm as
mandatory-to-implement (MTI) unless that algorithm has had reasonable
public review."

Now, the question is what type of problem it this document really trying
to solve.

The mentioned examples, such as A5/1, A5/2, WEP and WPA, are not IETF
RFCs and therefore we can hardly give guidance to other organizations.
There are lots of closed organizations and the IAB work related to
Open-Stand, see https://open-stand.org/, covers these issues already
(although without a lot of impact).

The Algebraic Eraser example is not much better since the authors came
to the IETF with the intention to ask for review, which they actually
received.

IMHO the problem is that we have far too few people willing to do
reviews and researchers have incentives to look at technologies when
they are already deployed since the relevance of their investigations is
much larger with widely deployed protocols. This is why the most secure
protocols are those that never get beyond the paper-stage.

An example of how bad our review can be was shown with MIKEY-IBAKE and
MIKEY-SAKKE. Of course, you can argue that it did not receive reasonable
public review but why should we care.

Ciao
Hannes

On 03/23/2016 02:45 PM, Stephen Farrell wrote:
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Mar 2016 01:28:10 +0000

> much stronger than (the current version of) the draft.

Ah sorry, that's a fair point - I messed up and should've
said "MTI in standards-track." Please read the draft and
react to that and not to my badly chosen subject line.

Mind you that subject probably does represent my
unconscious asserting itself, as I do dislike the idea that
we'd use vanity or national crypto even if that's not MTI.
But I do accept that we'd not likely get consensus on what
my unconscious thinks:-)

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Mar 2016 01:45:23 +0000

Hiya,

> mandatory-to-implement (MTI) unless that algorithm has had reasonable

See my reply to Yaron.

> RFCs and therefore we can hardly give guidance to other organizations.

As it happens, I don't agree. That other SDOs have ended up
using crap crypto is telling and tells us to not do that. This
aims to help us avoid such pitfalls.

> (although without a lot of impact).

I don't believe open-stand is relevant here. For crypto algs we're
more talking about having had publications at Crypto, RWC etc.

> to the IETF with the intention to ask for review, which they actually

Well, I'm not sure though that we can depend on there being a
handy cryptographer in the room who happens to have a colleague
who can find issues in a timely manner before we standardise
stuff. We've so far done the right thing in that case I think,
but I'd prefer we had a BCP t help us be more likely to do that
without depending on such co-incidence.

> protocols are those that never get beyond the paper-stage.

Again we're looking at crypto algorithms here and not security
or privacy in general. CFRG have been making progress in getting
better eyeballs on those in general and I think we can build on
that via a BCP like this, if folks want a BCP like this.

> public review but why should we care.

Yeah, those are a good example. I've just cleared a related DISCUSS [1]
after a year+ on the basis that the authors agreed to experimental
and not standards track for just this reason. (You can see the history
there at [1].) I'd have been much more comfortable doing that if we
had a BCP at which I could have pointed.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/draft-ietf-manet-ibs/history/

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 24 Mar 2016 03:33:12 +0000

Stephen says:
> ... That other SDOs have ended up using crap
> crypto is telling and tells us to not do that. This aims to help us avoid such
> pitfalls.

In some ways this proposed BCP is very IETF-like, in that it requires something measurable (public review), but still has an aspect of rough consensus (enough public review).

> > to the IETF with the intention to ask for review, which they actually

That's not my recollection (I was in the room).  They came looking to impress with how good it was, and see if there were possibilities of using it in IETF documents.

> > they are already deployed since the relevance of their investigations
> > is much larger with widely deployed protocols. This is why the most
> > secure protocols are those that never get beyond the paper-stage.

The post-cutoff version adds some text about research incentives, and why MTI seems like the best place to do this.  Please look at https://raw.githubusercontent.com/richsalz/draft-rsalz-dbrg-speck-wap-wep/master/draft-rsalz-drbg-speck-wap-wep.md and see "Why limit to MTI"

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 24 Mar 2016 07:08:57 -0700

On 23 Mar 2016, at 20:33, Salz, Rich wrote:

> In some ways this proposed BCP is very IETF-like, in that it requires 
> something measurable (public review), but still has an aspect of rough 
> consensus (enough public review).

Yes, exactly. Instead of us saying "we know exactly how much review we 
need", we can admit that the amount is variable, but way above "no one 
has written a paper questioning it".

> That's not my recollection (I was in the room).  They came looking to 
> impress with how good it was, and see if there were possibilities of 
> using it in IETF documents.

Rich's recollection matches mine. As much as I respect the messenger in 
this case, his response to people saying "problems have been found" was 
a quick "we have now fixed those", not "so we will slow down and make 
sure we have enough external review".

--Paul Hoffman

---

From: Derek Atkins <[email-masked]>
Date: Thu, 24 Mar 2016 10:43:22 -0400

Hi,

> to the IETF with the intention to ask for review, which they actually

I agree with Hannes that this is a bad example specifically because, as
Hannes said, the goal of coming to the IRTF (note IR, not IE) was to get
more review, which did actually happen.  It's also a bad example
because, even though there was an I-D for AE in OpenPGP (which has since
expired), it was never intended to be MTI.

Moreover, Algebraic Eraser, while patented, HAS been published for over
a decade now.  So the fact that it is patented is orthogonal to getting

> protocols are those that never get beyond the paper-stage.

Agreed; this is the hard problem -- encouraging researchers to look at
algorithms.  I've been spending much of the past two years trying to get
this to happen, with some (but still limited) success.

Often, it's only once the algorithms look like they are going to get
deployed that researchers start to look at them!

>> [1] https://tools.ietf.org/html/draft-rsalz-drbg-speck-wap-wep

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Derek Atkins <[email-masked]>
Date: Thu, 24 Mar 2016 10:44:45 -0400

> without depending on such co-incidence.

I thought the whole point of CFRG *WAS* to connect to the cryptographers?

-derek

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 24 Mar 2016 14:52:03 +0000

> algorithms.  I've been spending much of the past two years trying to get this
> to happen, with some (but still limited) success.
> 
> Often, it's only once the algorithms look like they are going to get deployed
> that researchers start to look at them!

True, and I tried to add some text that addresses this in my current WIP, https://github.com/richsalz/draft-rsalz-dbrg-speck-wap-wep My thesis is that being patented is *not* orthogonal to getting good reviews and in fact, it is a barrier to it.

My recollection of AE at CFRG might be wrong, but at least one other person shares my view.  We can fix/remove it if this moves forward.  The fact that it wasn't MTI-track at the time is not relevant; the fact that it's patented crypto is, because it is harder to get reviews of such things, as this email thread seems to make clear.  Perhaps the text needs improvement. (Well, that's probably a tautology :)

---

From: Derek Atkins <[email-masked]>
Date: Thu, 24 Mar 2016 10:54:36 -0400

Rich,

> using it in IETF documents.

Sure, the end goal was to see if there were possibilities of using it in
IETF documents, but that's a very fine distinction.  CFRG is IMHO the
right place to start specifically because it's the place where
cryptographers and IETF engineers overlap.  It IS a research group,
after all, and not an IETF Working Group.

Besides, with only a 10 minute time slot to present a 10-year-old
published algorithm, how would YOU have spent that time?  I'll note that
most of the time was spent on the math and the algoritm details, with
only one or two slides (out of 9 or 10 -- I don't recall) on
performance.  The fact that you recall the 2 minutes going over
performance numbers means that the numbers actually impressed you; the
fact that you don't remember all the time spent on the math means...???

-derek

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 24 Mar 2016 15:02:44 +0000

Derek, you're a pal and I am sorry if you're offended/upset by what I wrote.  This note is not going to help, sorry.

>  The fact that you recall
> the 2 minutes going over performance numbers means that the numbers
> actually impressed you; the fact that you don't remember all the time spent
> on the math means...???

My impression of the presentation was as follows: you presented an algorithm with some interesting performance capabilities, some math (that is over my head, I'm not a cryptographer) and then near the end someone asked "isn't this patented?" and you said yes.

In a more impressionistic mode, as opposed to just reporting my recollection, I would replace the last three words with "you admitted it was."

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 24 Mar 2016 15:03:11 +0000

> I thought the whole point of CFRG *WAS* to connect to the cryptographers?

And the point of my draft is that this is necessary but not sufficient.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Mar 2016 15:08:01 +0000

> I thought the whole point of CFRG *WAS* to connect to the cryptographers?

Yes, but the fact that your talk ended up with someone doing
specific work on that algorithm was serendipitous. It was a
good thing.

What I meant in the above was that had that not happened then
there is a possibility we'd now be down the road to having
incorporated AE into standards. The public review you did in
the end trigger by presenting resulted in the right thing
happening. And that I think bolsters the argument for public
review of algorithms and hence the putative BCP.

S.

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 24 Mar 2016 11:10:37 -0400

Rich,

On Thu, March 24, 2016 11:02 am, Salz, Rich wrote:
> Derek, you're a pal and I am sorry if you're offended/upset by what I
> wrote.  This note is not going to help, sorry.

Thanks, Rich.  I'm not at all offended by this email; I do, however, still
believe that AE is a bad example.

> My impression of the presentation was as follows: you presented an
> algorithm with some interesting performance capabilities, some math (that
> is over my head, I'm not a cryptographer) and then near the end someone
> asked "isn't this patented?" and you said yes.
>
> In a more impressionistic mode, as opposed to just reporting my
> recollection, I would replace the last three words with "you admitted it
> was."

So what?  I still don't see the correlation between patents and peer
reviews.  RSA was patented and got many reviews.  ECC was (and in some
cases still is) patented, and got (and still gets) many reviews.  So just
being patented isn't (and should not IMHO be) a gating issue.

Being patented might be a deterrent to being standardized and/or deployed.
 However I do not see that being the issue at hand or preventing access
for reviews.

-derek

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 24 Mar 2016 11:30:34 -0400

Paul,

> sure we have enough external review".

At the time of the CFRG presentation the last attack had been over 6 years
prior.  And yes, at the time of the presentation all previous attacks HAD
long been fixed.  In your opinion, how long must one go without an attack
before you decide it's "good enough"?

This is certainly a question of consensus and one that IMHO does not have
a solid line.  But sorry, six years without an attack seems like a decent
metric to me.  For example, there was recently a serious attack against
ECC where one could recover an ECDSA signing key with just over 5000
trials.  What do you suggest we do?

BTW, since the more recent attack in November we HAVE slowed down,
including letting my OpenPGP draft expire.  So the right thing IS
happening.

My issue with the document isn't with any of that; it's singling out AE
being an issue because it is patented.  Besides, AE was never intended to
be MTI so yet another reason to remove it as an example from the document.

Thanks,

-derek

---

From: Watson Ladd <[email-masked]>
Date: Thu, 24 Mar 2016 08:50:42 -0700

> And the point of my draft is that this is necessary but not sufficient.

Let me expand on that point. None of the algorithms in SSLv3 have
failed in ways that make SSLv3 insecure (exception is MD5 in PKIX). if
SSLv3 was being proposed today, CFRG wouldn't be involved. Instead
we'd depend on the working group to which SSLv3 was presented to
realize it had significant problems.

This draft wouldn't help with that problem. It would help with
circumstances where CFRG review is limited, and someone is very
insistent on pushing the draft through.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 24 Mar 2016 08:56:25 -0700

> before you decide it's "good enough"?

Were people actually looking at the protocol presented, or the
algebraic problem claimed (incorrectly) to be equivalent? Were people
looking at all. Not all 6 year spans are equivalent.

> trials.  What do you suggest we do?

Sounds bad doesn't it? But what attack was actually being used by
Tromer et al.? Bleichenbacher's partial nonce recovery and the side
channel attacks of Koch, both from early 90's.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Mar 2016 15:56:27 +0000

> insistent on pushing the draft through.

We do also see cases where an algorithm has been standardised
by some other organisation but without the kind of public review
we'd like to see, and where there is then pressure to ensure that
algorithm can be used in IETF protocols, and even sometimes that
it become an MTI.

S.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 24 Mar 2016 15:58:17 +0000

> But sorry, six years without an attack seems like a decent metric to
> me.  For example, there was recently a serious attack against ECC where one
> could recover an ECDSA signing key with just over 5000 trials.  What do you
> suggest we do?

Again, I think this bolsters my point.  Very few people are looking at AE and many people are looking at ECDSA.  Why?  My hypothesis is that one major reason is that the former is patented and has little public use while the latter is not.  In true scientific method, let's try to disprove that. :)

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 24 Mar 2016 12:26:51 -0400

Rich,

On Thu, March 24, 2016 11:58 am, Salz, Rich wrote:
> Again, I think this bolsters my point.  Very few people are looking at AE
> and many people are looking at ECDSA.  Why?  My hypothesis is that one
> major reason is that the former is patented and has little public use
> while the latter is not.  In true scientific method, let's try to disprove
> that. :)

As my statistics professor used to say, "Correlation does not imply
Causation".  I would argue that it's the SECOND part of your statement
that is the cause, and not the first.  The fact that ECC is deployed and
being actively used makes it a "more interesting" target for researchers. 
It also lowers the barrier of entry because there are lots of
implementations available.

I would argue that it's the number of available implementations and the
amount of deployment (and not the patent status) that have a stronger
correlation (and probably even causal) effect on the amount of research
done.

It's certainly the case that when I was a grad student I would prefer to
bang on something that already existed versus having to implement it
myself and then bang on it.

-derek

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 24 Mar 2016 16:34:35 +0000

> Causation". 

I did not do well in 6.041 :)  [inside joke]

> I would argue that it's the SECOND part of your statement that is
> the cause, and not the first.

Shrug.  When/if this moves forward I'll be glad change it if consensus indicates that.

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Mar 2016 10:29:06 -0700

> mandatory-to-implement (MTI) unless that algorithm has had reasonable

I completely agree that all BCPs and standards-track RFCs should require
only algs and mechanisms that have had reasonable public review.

I thought it was an assumed requirement of all BCPs and standards-track
RFCs anyway. If it is not, a general statement to that effect seems
reasonable. However, I disagree that this uniquely applies to crypto.

Joe

---

From: "Paterson, Kenny" <[email-masked]>
Date: Thu, 24 Mar 2016 18:19:03 +0000

Hi Derek,

> However I do not see that being the issue at hand or preventing access

One very strong factor that prevents proper review of new crypto proposals
is the community having access to a complete specification of the proposal
being promoted.

For example, does SecureRF have plans to publish a full specification of
its Algebraic Eraser scheme, including the vital details of how key
generation is done so as to avoid the recent attacks? Or have you already
done so, and I just missed it? Or is there some source code that
researchers can use to experiment with the actual key generation process
you are currently proposing?

Without that kind of detail, I'm afraid SecureRF would remain vulnerable
to (possibly baseless) accusations of being in the business of selling
herpetological products.

Cheers,

Kenny

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Mar 2016 18:26:12 +0000

> reasonable. However, I disagree that this uniquely applies to crypto.

Sure, there are other things that would require equivalent review.

I think a reason crypto makes sense as a target for this BCP is that
in the IETF we do have a good few people who are qualified to judge
when the level of public review seems good, but who aren't the ones
who'd be doing the review. Put another way, we (IETF sec area folks)
know the set of venues for good publications here but aren't the ones
who'd write those.

It's not clear to me how to generalise a BCP beyond crypto and preserve
that property.

S

---

From: Rene Struik <[email-masked]>
Date: Thu, 24 Mar 2016 14:27:59 -0400

Dear colleagues:

I would like to echo Joe Touch's remark: indeed, one would assume that 
RFCs describe relatively mature technology, no matter the area.

Personally, I have trouble seeing what value the draft provides, since 
it states the obvious: it has been long common practice to require some 
(read: solid) rationale supporting suggested engineering approaches.

Aren't we all (well, most of us) engineers and scientists who should all 
do our own due diligence? In case we have collectively forgotten, adding 
this BCP to the shelf does not help and we have to look into the mirror, 
get back on our feet again, or hand in our degrees.

Or, is there perhaps a subliminal message in the draft that we now have 
to depend on nods of program committee members only? If so, this seems 
to provide a bad incentive for offloading our own responsibilities.

Let our acts be guided by time-tested engineering principles instead.

Best regards, Rene

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Mar 2016 12:20:58 -0700

> It's not clear to me how to generalise a BCP beyond crypto and preserve

Every interaction with a link layer has this property (usually because
the specs are limited access through the IEEE) as do many interactions
with upper layer protocols and services (not all of which are IETF).

IMO, if we have people here who want to do reviews, they should do so -
in the venues where that's relevant. I don't think the IETF is the only
place where that can or should occur, and I don't think we need to call
out review of crypto as a special case.

Joe

---

From: "Grigory Marshalko" <[email-masked]>
Date: Fri, 25 Mar 2016 04:47:06 +0000

Several comments to the draft

Comments

Abstract, second paragraph. Change «his document specifies a proposed best practice for any protocol (or data format) that uses cryptography.» to «his document specifies a proposed best practice for any mechanism (or data format) that uses cryptography.» The reason is that RFC specifies data formats, algorithms and protocols, so mechanism is more appropriate term.

3. Why is Cryptography Hard?

This part is not sound since it deals with a problem of correct implementation but concludes that a good crypto should be used. This problems drustically differs from a problem of using weak or flawed crypto mechanisms. These are two different problems, which should be treated consequently: first, select a good crypto, then implement it in a right way. And also, of cause, the final step -- is to use crypto correctly. So, I would suggets that these issues should be treated consequently, as a sequential parts of design of a sound crypto application.

As for the draft it,as far as I understood, is supposed to be focused on the first issue: the choice of good crypto mechanisms.

4. Things to avoid.

Frankly speaking, every crypto is developed in private:), in developer's mind. The question, whether it has received enough public review irrespective of its origin: independent proposal, standartised mechanism or commercial. 

It should be noted, that patended crypto could receive public review if it publicly availiable(though it could have problems with implemetations due to patent restrictions). The key question here is public availiability: if mechanism is publicly availiable it could receive public review. There are a lot of examples of such situations.

Cryptographic agility is a must, not probably a must. The security strength of crypto is always decreasing so there should be a way for transition to another crypto, or to use another algo which is more appropriate for implementation purposes.

What constitutes sufficient public review? It is, actually, easy to say. First of all cryptoalgorithm should be in public domain unchanged for several years (crypto competitions show that 3 years is a good time), in order to receive sufficent public review. Public review is actually is independent cryptanalysis: there should be publications on cryptanalytic results on the discussed crypto. These publications should be in peer reviewed conferences and journals in order to avoid flawed cryptanalysis (there are a lot examples of such flawed public review -- see the rate of eprint.iacr.org withdrawals).

Proof of contest could be useful if it is resulted in a number of such publications.

Regards,
Grigory Marshalko,
expert,
Technical committee for standardisation "Cryptography and security mechanisms" (TC 26)
www.tc26.ru

---

From: Watson Ladd <[email-masked]>
Date: Fri, 25 Mar 2016 09:43:31 -0700

On Thu, Mar 24, 2016 at 11:27 AM, Rene Struik <[email-masked]> wrote:
> Dear colleagues:
>
> I would like to echo Joe Touch's remark: indeed, one would assume that RFCs
> describe relatively mature technology, no matter the area.
>
> Personally, I have trouble seeing what value the draft provides, since it
> states the obvious: it has been long common practice to require some (read:
> solid) rationale supporting suggested engineering approaches.
>
> Aren't we all (well, most of us) engineers and scientists who should all do
> our own due diligence? In case we have collectively forgotten, adding this
> BCP to the shelf does not help and we have to look into the mirror, get back
> on our feet again, or hand in our degrees.

Real engineers don't use materials known to fail in catastrophic ways.
Software engineers use C. Real engineers know the relevant science.
Software engineers continue to insist that MD5 is ok, endorse MtE over
EtM, etc for years after they shouldn't.
>
> Or, is there perhaps a subliminal message in the draft that we now have to
> depend on nods of program committee members only? If so, this seems to
> provide a bad incentive for offloading our own responsibilities.

No, it's pointing out that cryptographic algorithms need specialized
knowledge to examine, which there is no reason the BGP master will
know.

> Let our acts be guided by time-tested engineering principles instead.

Like knowing the limits of one's knowledge and deferring to experts?

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 25 Mar 2016 19:10:26 +0100

I think I am now getting the idea.

Let me try to summarize.

1) You don't want to publish RFCs that contain cryptographic algorithms
that have not gone through substantial public review *elsewhere*. While
we have a "good" review process it does hot really cover the hard-core
crypto stuff.

2) We don't have the time, interest and expertise in the IETF to do a
review of cryptographic algorithms. Therefore we have to delegate it to
others.

3) You want to send a message to document authors to not even try to
come along with a document that includes crypto that nobody in the IETF
is likely to analyse.

4) You are not trying to send a message to other organizations that
develop crypto being closed doors.

Most likely (I am guessing) the reason that triggered your interest to
have such a document is the Algebraic Eraser. With this BCP you would
essentially tell someone coming along with, for example, a new
password-based authenticated key exchange, identity-based crypto,
threshold key exchange algorithm, etc. to first have that substantial
public review outside the IETF (most likely in the academic community)
before they should even try to approach the IETF.

Is that a fair summary?

If that's the idea then I believe I can agree with you that such a BCP
would be useful. I think it is also a "safeguard" for the security ADs
and for the IESG in general who have a hard time judging stuff that
comes along where nobody really knows whether it is secure.

Ciao
Hannes

PS: The examples provided in the document, namely A5/1, A5/2, WEP and
WPA, are misleading since nobody (to my knowledge) ever wanted to use
them in IETF specifications anyway.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 25 Mar 2016 19:13:27 +0100

I agree with Derek that this also needs to be clarified. The BCP is
specially aiming at the IETF and the IRTF in fact has a slightly
different mission where we specially tried to get cryptographers to
share their views.

If this is not clearly indicated in the BCP I fear that researchers
could easily get confused.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 25 Mar 2016 19:23:26 +0100

Stephen, Rich,

I think we need to have an honest discussion what problem we are really
trying to solve here.

Examples are useful but we have often had problems with talking about
mistakes we made (since someone will be unhappy).

Unless there aren't a handful of examples I prefer not to publish a
"best current practice" document.

I personally would rather like to solve the MIKEY-IBAKE and
MIKEY-SAKKE type problems first, particularly since they have been
caused by the IESG and our review process.

Ciao
Hannes

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Mar 2016 19:45:51 +0000

> I personally would rather like to solve the MIKEY-IBAKE and MIKEY-SAKKE
> type problems first, particularly since they have been caused by the IESG and
> our review process.

Where can I see thie history of these issues?

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Mar 2016 19:57:51 +0000

> Is that a fair summary?

Yep. AE wasn't the direct motivation for me as it happens
but that's by the by. [1] was more of a deal for me - that
was originally proposed for PS and with an algorithm that
has had basically no public scrutiny that we could find.

S.

[1] https://datatracker.ietf.org/doc/draft-ietf-manet-ibs/

---

From: "Derek Atkins" <[email-masked]>
Date: Fri, 25 Mar 2016 16:11:12 -0400

> [1] https://datatracker.ietf.org/doc/draft-ietf-manet-ibs/

Honestly, I would hope that AE was *NOT* the motivation, considering
progress on all AE documents has slowed down (or stopped) since November.

-derek

---

From: Randy Bush <[email-masked]>
Date: Sat, 26 Mar 2016 11:06:57 +0900

> Like knowing the limits of one's knowledge and deferring to experts?

or begging the experts and implementors for usable, safe, and boring
(thanks djb) algorithms and code.

e.g. to use the example in this thread, bgp ops have been told that they
want/need something better than md5 for over a decade.  what are they
given?  AO.  simple?  no.  safe?  how the hell do they know?  boring?
yes, because no vendor implemented it.

feh.

randy